[opensuse-buildservice] Request to define two new attributes

Hi, To make it possible to know when a package could be updated to a new upstream version, I'd like to have two new attributes: + OBS:UpstreamVersion - would contain the latest upstream version for the upstream module + OBS:UpstreamTarballURL - would contain the URL of the latest upstream tarball Right now, the idea is to have an external script update those attributes. So, who wants to be bribed and create those attributes? :-) Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Sunday 31 Jan 2010 14:54:01 Vincent Untz wrote:
To make it possible to know when a package could be updated to a new upstream version, I'd like to have two new attributes:
+ OBS:UpstreamVersion - would contain the latest upstream version for the upstream module
+ OBS:UpstreamTarballURL - would contain the URL of the latest upstream tarball
Right now, the idea is to have an external script update those attributes.
So, who wants to be bribed and create those attributes? :-)
Not me, but Adrian has mentioned before that there's a plan to have tarball/svn/git urls per package and pull the sources directly into the buildservice - so I bet he has something to say about creating these attributes. Will -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Jan 31, 2010, at 14:18, Will Stephenson <wstephenson@suse.de> wrote:
On Sunday 31 Jan 2010 14:54:01 Vincent Untz wrote:
To make it possible to know when a package could be updated to a new upstream version, I'd like to have two new attributes:
+ OBS:UpstreamVersion - would contain the latest upstream version for the upstream module
+ OBS:UpstreamTarballURL - would contain the URL of the latest upstream tarball
Right now, the idea is to have an external script update those attributes.
So, who wants to be bribed and create those attributes? :-)
Not me, but Adrian has mentioned before that there's a plan to have tarball/svn/git urls per package and pull the sources directly into the buildservice - so I bet he has something to say about creating these attributes.
Will
For tarballs, you might want to consider something like fedora's spectool. If you could integrate spectool into the buildservice, that could take care of the downloading of tarballs.
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Sonntag, 31. Januar 2010 14:54:01 schrieb Vincent Untz:
Hi,
To make it possible to know when a package could be updated to a new upstream version, I'd like to have two new attributes:
+ OBS:UpstreamVersion - would contain the latest upstream version for the upstream module
Hm, if this is something, which is only happening at the .opensuse.org instance (because the support for this is not integrated into OBS), it should be for example openSUSE:UpstreamVersion instead. (Everything in OBS: is delivered with the OBS server itself and may be used by its tools (osc, webui, api)).
+ OBS:UpstreamTarballURL - would contain the URL of the latest upstream tarball
That is the thing (as mentioned before), which should go into the _service stuff. In that way we actually know that the server has downloaded it from there (helpfull during review). The support for this is already in OBS 1.7, I just have to get another piece of hardware setup for our opensuse.org instance. (Not managed to do so since 2 month, but I really want to this month). -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Le lundi 01 février 2010, à 08:46 +0100, Adrian Schröter a écrit :
Am Sonntag, 31. Januar 2010 14:54:01 schrieb Vincent Untz:
Hi,
To make it possible to know when a package could be updated to a new upstream version, I'd like to have two new attributes:
+ OBS:UpstreamVersion - would contain the latest upstream version for the upstream module
Hm, if this is something, which is only happening at the .opensuse.org instance (because the support for this is not integrated into OBS), it should be for example
openSUSE:UpstreamVersion
instead.
(Everything in OBS: is delivered with the OBS server itself and may be used by its tools (osc, webui, api)).
Ah okay, fine with me :-)
+ OBS:UpstreamTarballURL - would contain the URL of the latest upstream tarball
That is the thing (as mentioned before), which should go into the _service stuff. In that way we actually know that the server has downloaded it from there (helpfull during review).
I thought about it and my conclusion was that it would probably affect performance if we want to use the URL in the status page: we need to fetch the data for all packages in a project. Another point, but minor, is that I'm unsure it's useful to put the URL there if it's not the tarball currently used to build the package. The goal of the attribute would be to have the URL of the new unpackaged version from upstream. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag, 1. Februar 2010 10:42:20 schrieb Vincent Untz:
Le lundi 01 février 2010, à 08:46 +0100, Adrian Schröter a écrit :
Am Sonntag, 31. Januar 2010 14:54:01 schrieb Vincent Untz: ...
+ OBS:UpstreamTarballURL - would contain the URL of the latest upstream tarball
That is the thing (as mentioned before), which should go into the _service stuff. In that way we actually know that the server has downloaded it from there (helpfull during review).
I thought about it and my conclusion was that it would probably affect performance if we want to use the URL in the status page: we need to fetch the data for all packages in a project.
Well, okay, but we should not missuse the attributes as cache system. (or at least not with server side support).
Another point, but minor, is that I'm unsure it's useful to put the URL there if it's not the tarball currently used to build the package. The goal of the attribute would be to have the URL of the new unpackaged version from upstream.
So you want to have this as manually user setting unrelated to building ? Hm, I would go first to try to define URLs in our packages and try to automatically check for new versions, before I would add a manual option here. How is this supposed to work ? Everybody can replace the attribute to report that there is a new version ? -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag 01 Februar 2010 schrieb Adrian Schröter:
So you want to have this as manually user setting unrelated to building ? Exactly. We can later add a mechanism to take over the attributes into building, but automatically picking upstream versions is too fragile, so adding a reporting is the first step.I can also imagine a project setting that takes upstream versions automatically, but I don't think this should be the default.
Hm, I would go first to try to define URLs in our packages and try to automatically check for new versions, before I would add a manual option here.
The URL of packages is the home page not the upstream tar ball.
How is this supposed to work ? Everybody can replace the attribute to report that there is a new version ?
Yes, that was exactly the idea. We will have to experiment a bit, but I don't expect huge SPAM potential. Of course not having history for attributes can become a problem - but as I said: we need to experiment. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag, 1. Februar 2010 12:11:09 schrieb Stephan Kulow:
Am Montag 01 Februar 2010 schrieb Adrian Schröter:
So you want to have this as manually user setting unrelated to building ? Exactly. We can later add a mechanism to take over the attributes into building, but automatically picking upstream versions is too fragile, so adding a reporting is the first step.I can also imagine a project setting that takes upstream versions automatically, but I don't think this should be the default.
Hm, I would go first to try to define URLs in our packages and try to automatically check for new versions, before I would add a manual option here.
The URL of packages is the home page not the upstream tar ball.
Right now we have the official place for it in package meta data. But I agree completely that it shouldn't be there. However, we might should sync the data initially. And it should not be named UpstreamTarballURL than IMHO. Maybe UpstreamHomepage ?
How is this supposed to work ? Everybody can replace the attribute to report that there is a new version ?
Yes, that was exactly the idea. We will have to experiment a bit, but I don't expect huge SPAM potential. Of course not having history for attributes can become a problem - but as I said: we need to experiment.
Okay, but when it is experimental, I don't want it in OBS: namespace. This is what really everybody in his own instance is getting and should be able to rely on (at least during 1.X timeline). -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag 01 Februar 2010 schrieb Adrian Schröter:
The URL of packages is the home page not the upstream tar ball.
Right now we have the official place for it in package meta data. But I agree completely that it shouldn't be there.
However, we might should sync the data initially.
And it should not be named UpstreamTarballURL than IMHO. Maybe UpstreamHomepage ? You mix two things. We right now have a "url" both in the spec file and the <meta/> - both are described as home page for the package. We want explicitly to set the upstream _sources_ of the _latest_ release set. This is bound 1:1 to the other attribute, so my original proposal was having _one_ attribute with a version and an optional tarball url.
How is this supposed to work ? Everybody can replace the attribute to report that there is a new version ?
Yes, that was exactly the idea. We will have to experiment a bit, but I don't expect huge SPAM potential. Of course not having history for attributes can become a problem - but as I said: we need to experiment.
Okay, but when it is experimental, I don't want it in OBS: namespace. This is what really everybody in his own instance is getting and should be able to rely on (at least during 1.X timeline).
Fine with me, but we need to have this done _real soon now_ as the version freeze for 11.3 is coming closer every day. So give this a place where we can do actual coding instead of talking about your nice to have things. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag, 1. Februar 2010 13:14:01 schrieb Stephan Kulow:
Am Montag 01 Februar 2010 schrieb Adrian Schröter: ...
How is this supposed to work ? Everybody can replace the attribute to report that there is a new version ?
Yes, that was exactly the idea. We will have to experiment a bit, but I don't expect huge SPAM potential. Of course not having history for attributes can become a problem - but as I said: we need to experiment.
Okay, but when it is experimental, I don't want it in OBS: namespace. This is what really everybody in his own instance is getting and should be able to rely on (at least during 1.X timeline).
Fine with me, but we need to have this done _real soon now_ as the version freeze for 11.3 is coming closer every day. So give this a place where we can do actual coding instead of talking about your nice to have things.
It is below openSUSE namespace now. It can currently be edited, if you have maintainer rights. You need one value inside of the attribute (not 0, not >= 2). hope this is okay. adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Monday 01 February 2010 17:23:34 Adrian Schröter wrote:
How is this supposed to work ? Everybody can replace the attribute to report that there is a new version ?
Yes, that was exactly the idea. We will have to experiment a bit, but
It can currently be edited, if you have maintainer rights.
You need one value inside of the attribute (not 0, not >= 2).
hope this is okay. I don't think this will be okay, but we need to try.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag, 1. Februar 2010 21:22:43 schrieb Stephan Kulow:
On Monday 01 February 2010 17:23:34 Adrian Schröter wrote:
How is this supposed to work ? Everybody can replace the attribute to report that there is a new version ?
Yes, that was exactly the idea. We will have to experiment a bit, but
It can currently be edited, if you have maintainer rights.
You need one value inside of the attribute (not 0, not >= 2).
hope this is okay. I don't think this will be okay, but we need to try.
what exactly ? Please note that there is currently nothing like a world writable permission. Hm, maybe we could emulate this via group="user", but as long there is no history log, it can be simply missused. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Le lundi 01 février 2010, à 21:22 +0100, Stephan Kulow a écrit :
On Monday 01 February 2010 17:23:34 Adrian Schröter wrote:
How is this supposed to work ? Everybody can replace the attribute to report that there is a new version ?
Yes, that was exactly the idea. We will have to experiment a bit, but
It can currently be edited, if you have maintainer rights.
You need one value inside of the attribute (not 0, not >= 2).
hope this is okay. I don't think this will be okay, but we need to try.
I think it will be okay in the short term -- we can plug the data from collab in the build service, and we this should already give us quite some useful data. To do this, we just need to have the attributes editable by one specific user. (sure, that's not completely perfect since we don't have upstream versions for everything, but maybe that's what we should be fixing instead?) Adrian, can you make those attributes editable by os-gnome-maintainers in all projects? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Dienstag 02 Februar 2010 schrieb Vincent Untz:
Le lundi 01 février 2010, à 21:22 +0100, Stephan Kulow a écrit :
On Monday 01 February 2010 17:23:34 Adrian Schröter wrote:
> How is this supposed to work ? Everybody can replace the > attribute to report that there is a new version ?
Yes, that was exactly the idea. We will have to experiment a bit, but
It can currently be edited, if you have maintainer rights.
You need one value inside of the attribute (not 0, not >= 2).
hope this is okay.
I don't think this will be okay, but we need to try.
I think it will be okay in the short term -- we can plug the data from collab in the build service, and we this should already give us quite some useful data. To do this, we just need to have the attributes editable by one specific user.
(sure, that's not completely perfect since we don't have upstream versions for everything, but maybe that's what we should be fixing instead?)
Adrian, can you make those attributes editable by os-gnome-maintainers in all projects?
Do you already include the data Marcus collects or should Marcus be able to write there too? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Le mercredi 03 février 2010, à 13:41 +0100, Stephan Kulow a écrit :
Do you already include the data Marcus collects or should Marcus be able to write there too?
The data from Marcus' script is included already. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Mittwoch, 3. Februar 2010 13:41:39 schrieb Stephan Kulow:
Am Dienstag 02 Februar 2010 schrieb Vincent Untz:
Le lundi 01 février 2010, à 21:22 +0100, Stephan Kulow a écrit :
On Monday 01 February 2010 17:23:34 Adrian Schröter wrote:
> > How is this supposed to work ? Everybody can replace the > > attribute to report that there is a new version ? > > Yes, that was exactly the idea. We will have to experiment a bit, > but
It can currently be edited, if you have maintainer rights.
You need one value inside of the attribute (not 0, not >= 2).
hope this is okay.
I don't think this will be okay, but we need to try.
I think it will be okay in the short term -- we can plug the data from collab in the build service, and we this should already give us quite some useful data. To do this, we just need to have the attributes editable by one specific user.
(sure, that's not completely perfect since we don't have upstream versions for everything, but maybe that's what we should be fixing instead?)
Adrian, can you make those attributes editable by os-gnome-maintainers in all projects?
Do you already include the data Marcus collects or should Marcus be able to write there too?
Marcus and os-gnome-maintainers have now write permissions to both attributes. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag 01 Februar 2010 schrieb Adrian Schröter:
Am Sonntag, 31. Januar 2010 14:54:01 schrieb Vincent Untz:
Hi,
To make it possible to know when a package could be updated to a new upstream version, I'd like to have two new attributes:
+ OBS:UpstreamVersion - would contain the latest upstream version for the upstream module
Hm, if this is something, which is only happening at the .opensuse.org instance (because the support for this is not integrated into OBS), it should be for example
openSUSE:UpstreamVersion
OBS will set this as users report a package outdated, even though it won't make other use of it than displaying it. This can also be useful when someone wants to track what packages are outdated and which are fine for his own projects. So I opt for OBS: Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (5)
-
Adrian Schröter
-
Robert Xu
-
Stephan Kulow
-
Vincent Untz
-
Will Stephenson