[opensuse-buildservice] Retrieving package version numbers
Hello, is there a way to retrieve the version number of a package, possibly even through the publically accessible part of the API? So far I've found that the buildinfo response to contains a <versrel> element. This however requires authentication and is not very efficient as a repository and architecture need to be discovered first. A rather hackish way which does not require authentication is to extract the version by parsing the filenames returned from the fileinfo response. But this also requires discovering the architecture and repo and has the additional disadvantage that it fails if no packages are built. I'm trying to programmatically compare the versions of packages inside OBS with upstream packages or packages in other automatic build systems. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Montag, 4. April 2011 schrieb Guido Berhoerster:
Hello,
is there a way to retrieve the version number of a package, possibly even through the publically accessible part of the API?
For factory packages you can retrieve a summary with osc api /status/project/openSUSE:Factory The API is rather restrictive what it allows without user and I think we want to keep it that way. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Apr 04, 2011 at 01:55:00PM +0200, Stephan Kulow wrote:
Am Montag, 4. April 2011 schrieb Guido Berhoerster:
Hello,
is there a way to retrieve the version number of a package, possibly even through the publically accessible part of the API?
For factory packages you can retrieve a summary with osc api /status/project/openSUSE:Factory
Is the /status URL documented somewhere? I can't find it at https://api.opensuse.org/apidocs/ I'd like to retrieve version number for a single package.
The API is rather restrictive what it allows without user and I think we want to keep it that way.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
-- Vitezslav Cizek
Am Montag, 4. April 2011 schrieb Vita Cizek:
On Mon, Apr 04, 2011 at 01:55:00PM +0200, Stephan Kulow wrote:
Am Montag, 4. April 2011 schrieb Guido Berhoerster:
Hello,
is there a way to retrieve the version number of a package, possibly even through the publically accessible part of the API?
For factory packages you can retrieve a summary with osc api /status/project/openSUSE:Factory
Is the /status URL documented somewhere? I can't find it at https://api.opensuse.org/apidocs/
I'd like to retrieve version number for a single package.
Then better use osc api '/source/openSUSE:Factory/perl?view=info&parse=1' Michael implemented this last week. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
* Stephan Kulow <coolo@suse.de> [2011-04-04 13:02]:
Am Montag, 4. April 2011 schrieb Vita Cizek:
On Mon, Apr 04, 2011 at 01:55:00PM +0200, Stephan Kulow wrote:
Am Montag, 4. April 2011 schrieb Guido Berhoerster:
Hello,
is there a way to retrieve the version number of a package, possibly even through the publically accessible part of the API?
For factory packages you can retrieve a summary with osc api /status/project/openSUSE:Factory
Is the /status URL documented somewhere? I can't find it at https://api.opensuse.org/apidocs/
I'd like to retrieve version number for a single package.
Then better use osc api '/source/openSUSE:Factory/perl?view=info&parse=1'
Michael implemented this last week.
Through /public/source/<project>/<package>?view=info&parse=1 it is publically accessible. Thanks a lot, this is exactly what I was looking for and allows for easy version checking/comparison with upstream projects. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Montag, 4. April 2011, 15:22:02 schrieb Guido Berhoerster:
* Stephan Kulow <coolo@suse.de> [2011-04-04 13:02]:
Am Montag, 4. April 2011 schrieb Vita Cizek:
On Mon, Apr 04, 2011 at 01:55:00PM +0200, Stephan Kulow wrote:
Am Montag, 4. April 2011 schrieb Guido Berhoerster:
Hello,
is there a way to retrieve the version number of a package, possibly even through the publically accessible part of the API?
For factory packages you can retrieve a summary with osc api /status/project/openSUSE:Factory
Is the /status URL documented somewhere? I can't find it at https://api.opensuse.org/apidocs/
I'd like to retrieve version number for a single package.
Then better use osc api '/source/openSUSE:Factory/perl?view=info&parse=1'
Michael implemented this last week.
Through /public/source/<project>/<package>?view=info&parse=1 it is publically accessible.
This is pure luck due to a miss configuration in lighttpd setup. Please never ever use /public, it is just for remote OBS instances and may change at any time. It is not part of official api.
Thanks a lot, this is exactly what I was looking for and allows for easy version checking/comparison with upstream projects.
-- 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
* Adrian Schröter <adrian@suse.de> [2011-04-04 16:08]:
Am Montag, 4. April 2011, 15:22:02 schrieb Guido Berhoerster:
* Stephan Kulow <coolo@suse.de> [2011-04-04 13:02]:
Am Montag, 4. April 2011 schrieb Vita Cizek:
On Mon, Apr 04, 2011 at 01:55:00PM +0200, Stephan Kulow wrote:
Am Montag, 4. April 2011 schrieb Guido Berhoerster:
Hello,
is there a way to retrieve the version number of a package, possibly even through the publically accessible part of the API?
For factory packages you can retrieve a summary with osc api /status/project/openSUSE:Factory
Is the /status URL documented somewhere? I can't find it at https://api.opensuse.org/apidocs/
I'd like to retrieve version number for a single package.
Then better use osc api '/source/openSUSE:Factory/perl?view=info&parse=1'
Michael implemented this last week.
Through /public/source/<project>/<package>?view=info&parse=1 it is publically accessible.
This is pure luck due to a miss configuration in lighttpd setup.
Please never ever use /public, it is just for remote OBS instances and may change at any time.
It is not part of official api.
That's unfortunate, is there any reason why this cannot be made publically accessible? The information can already be obtained as described in my intial mail, although that is quite a kludge and inefficient as it requires several instead of a single request. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Montag, 4. April 2011, 16:50:05 schrieb Guido Berhoerster:
* Adrian Schröter <adrian@suse.de> [2011-04-04 16:08]:
Am Montag, 4. April 2011, 15:22:02 schrieb Guido Berhoerster:
* Stephan Kulow <coolo@suse.de> [2011-04-04 13:02]:
Am Montag, 4. April 2011 schrieb Vita Cizek:
On Mon, Apr 04, 2011 at 01:55:00PM +0200, Stephan Kulow wrote:
Am Montag, 4. April 2011 schrieb Guido Berhoerster: > Hello, > > is there a way to retrieve the version number of a package, > possibly even through the publically accessible part of the API?
For factory packages you can retrieve a summary with osc api /status/project/openSUSE:Factory
Is the /status URL documented somewhere? I can't find it at https://api.opensuse.org/apidocs/
I'd like to retrieve version number for a single package.
Then better use osc api '/source/openSUSE:Factory/perl?view=info&parse=1'
Michael implemented this last week.
Through /public/source/<project>/<package>?view=info&parse=1 it is publically accessible.
This is pure luck due to a miss configuration in lighttpd setup.
(small note, it is not the lighttpd setup, but the public controller)
Please never ever use /public, it is just for remote OBS instances and may change at any time.
It is not part of official api.
That's unfortunate, is there any reason why this cannot be made publically accessible?
Yes, the api is for developers in first place. We do not want to have random load (and some requests can create a lot load) on our server without control about it. So we may abadone /public and ask our remote instances to use at login at some point of time.
The information can already be obtained as described in my intial mail, although that is quite a kludge and inefficient as it requires several instead of a single request.
Just create a user and use /source directly. If that user creates too much load we can block it and talk back to you in that situation for a solution. Otherwise we do need to block entire IPs or access to /public in general. bye 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 16:59 Mon 04 Apr 2011, Adrian Schröter wrote:
(small note, it is not the lighttpd setup, but the public controller)
Please never ever use /public, it is just for remote OBS instances and may change at any time.
It is not part of official api.
That's unfortunate, is there any reason why this cannot be made publically accessible?
Yes, the api is for developers in first place. We do not want to have random load (and some requests can create a lot load) on our server without control about it.
So we may abadone /public and ask our remote instances to use at login at some point of time.
Claiming it "is not part of the official API" is funny. The _third_ sentence in the API docs[1] reads: "The /public routes are also accessible as anonymous user." If the plan is to remove /public and replace it with per application accounts in the near future please document it. I was planning on building a small application on top of it this week. Thanks, Brandon [1] https://api.opensuse.org/apidocs/#1 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Apr 04, 11 11:02:42 -0700, Brandon Philips wrote:
On 16:59 Mon 04 Apr 2011, Adrian Schröter wrote:
(small note, it is not the lighttpd setup, but the public controller)
Please never ever use /public, it is just for remote OBS instances and may change at any time.
It's a misnomer then. It should rather be called /private in that case.
That's unfortunate, is there any reason why this cannot be made publically accessible?
Yes, the api is for developers in first place. We do not want to have random load (and some requests can create a lot load) on our server without control about it.
The new /public/source/PROJ/PACK?parse=1&view=info actually decreases load on the servers. The only other way to poke for a version number is by downloading a _history file, which can be huge. Been there, done that. :-(
"The /public routes are also accessible as anonymous user." But no further details are given. So we cannot rely on anything there.
Let's improve API efficiency to keep up with public usage. Cutting back public services (aka open-ness) should be last resort. cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Montag, 4. April 2011, 20:44:50 schrieb Juergen Weigert:
On Apr 04, 11 11:02:42 -0700, Brandon Philips wrote:
On 16:59 Mon 04 Apr 2011, Adrian Schröter wrote:
(small note, it is not the lighttpd setup, but the public controller)
Please never ever use /public, it is just for remote OBS instances and may change at any time.
It's a misnomer then. It should rather be called /private in that case.
That's unfortunate, is there any reason why this cannot be made publically accessible?
Yes, the api is for developers in first place. We do not want to have random load (and some requests can create a lot load) on our server without control about it.
The new /public/source/PROJ/PACK?parse=1&view=info actually decreases load on the servers. The only other way to poke for a version number is by downloading a _history file, which can be huge. Been there, done that. :-(
You can use the same call without /public. No one said you should use _history. -- 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 Mon, Apr 04, 2011 at 08:44:50PM +0200, Juergen Weigert wrote:
The new /public/source/PROJ/PACK?parse=1&view=info actually decreases load on the servers.
The new method is /source/PROJ/PACK?parse=1&view=info without the /public. /public was only introduced to make the OBS interconnect work with ichain authentification. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Montag, 4. April 2011, 11:02:42 schrieb Brandon Philips:
On 16:59 Mon 04 Apr 2011, Adrian Schröter wrote:
(small note, it is not the lighttpd setup, but the public controller)
Please never ever use /public, it is just for remote OBS instances and may change at any time.
It is not part of official api.
That's unfortunate, is there any reason why this cannot be made publically accessible?
Yes, the api is for developers in first place. We do not want to have random load (and some requests can create a lot load) on our server without control about it.
So we may abadone /public and ask our remote instances to use at login at some point of time.
Claiming it "is not part of the official API" is funny. The _third_ sentence in the API docs[1] reads:
"The /public routes are also accessible as anonymous user."
If the plan is to remove /public and replace it with per application accounts in the near future please document it. I was planning on building a small application on top of it this week.
right, that is plain wrong. I fixed it in my git now. -- 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
* Adrian Schröter <adrian@suse.de> [2011-04-04 16:59]:
That's unfortunate, is there any reason why this cannot be made publically accessible?
Yes, the api is for developers in first place. We do not want to have random load (and some requests can create a lot load) on our server without control about it.
So we may abadone /public and ask our remote instances to use at login at some point of time.
The information can already be obtained as described in my intial mail, although that is quite a kludge and inefficient as it requires several instead of a single request.
Just create a user and use /source directly. If that user creates too much load we can block it and talk back to you in that situation for a solution. Otherwise we do need to block entire IPs or access to /public in general.
I don't think it is currently possible to create per-application accounts which are not bound to a person but can be distributed with an application, is it? -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Montag, 4. April 2011, 21:58:06 schrieb Guido Berhoerster:
* Adrian Schröter <adrian@suse.de> [2011-04-04 16:59]:
That's unfortunate, is there any reason why this cannot be made publically accessible?
Yes, the api is for developers in first place. We do not want to have random load (and some requests can create a lot load) on our server without control about it.
So we may abadone /public and ask our remote instances to use at login at some point of time.
The information can already be obtained as described in my intial mail, although that is quite a kludge and inefficient as it requires several instead of a single request.
Just create a user and use /source directly. If that user creates too much load we can block it and talk back to you in that situation for a solution. Otherwise we do need to block entire IPs or access to /public in general.
I don't think it is currently possible to create per-application accounts which are not bound to a person but can be distributed with an application, is it?
right, it isn't. And I wonder if this should be possible ever, because following our rule developers first for the api, it should be always bound to persons. So the application would need to ask the user for login/password. If we want to have something public for end users, we should transfer the data to another host on deliver it from there. This host would be able to work way more efficient, because it does not need to do all kinds of permission checks. What is the use case for your example ? -- 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 2011-04-05 09:04:53 +0200, Adrian Schröter wrote:
And I wonder if this should be possible ever, because following our rule developers first for the api, it should be always bound to persons.
oauth.
So the application would need to ask the user for login/password.
no it doesnt. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
* Adrian Schröter <adrian@suse.de> [2011-04-05 09:04]:
I don't think it is currently possible to create per-application accounts which are not bound to a person but can be distributed with an application, is it?
right, it isn't.
And I wonder if this should be possible ever, because following our rule developers first for the api, it should be always bound to persons.
So the application would need to ask the user for login/password.
If we want to have something public for end users, we should transfer the data to another host on deliver it from there. This host would be able to work way more efficient, because it does not need to do all kinds of permission checks.
What is the use case for your example ?
That would be a simple version checking framework for monitoring the versions of upstream projects and corresponding packages in automated build services like OBS. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Apr 05, 2011 at 03:08:01PM +0200, Guido Berhoerster wrote:
* Adrian Schröter <adrian@suse.de> [2011-04-05 09:04]:
I don't think it is currently possible to create per-application accounts which are not bound to a person but can be distributed with an application, is it?
right, it isn't.
And I wonder if this should be possible ever, because following our rule developers first for the api, it should be always bound to persons.
So the application would need to ask the user for login/password.
If we want to have something public for end users, we should transfer the data to another host on deliver it from there. This host would be able to work way more efficient, because it does not need to do all kinds of permission checks.
What is the use case for your example ?
That would be a simple version checking framework for monitoring the versions of upstream projects and corresponding packages in automated build services like OBS.
Well, my scripts run just osc ls, osc cat. ;) (actually meta data dump for O:F too ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
* Marcus Meissner <meissner@suse.de> [2011-04-05 15:11]:
On Tue, Apr 05, 2011 at 03:08:01PM +0200, Guido Berhoerster wrote:
* Adrian Schröter <adrian@suse.de> [2011-04-05 09:04]:
I don't think it is currently possible to create per-application accounts which are not bound to a person but can be distributed with an application, is it?
right, it isn't.
And I wonder if this should be possible ever, because following our rule developers first for the api, it should be always bound to persons.
So the application would need to ask the user for login/password.
If we want to have something public for end users, we should transfer the data to another host on deliver it from there. This host would be able to work way more efficient, because it does not need to do all kinds of permission checks.
What is the use case for your example ?
That would be a simple version checking framework for monitoring the versions of upstream projects and corresponding packages in automated build services like OBS.
Well, my scripts run just osc ls, osc cat. ;)
(actually meta data dump for O:F too ;)
I also currently osc cat specfiles and then extract the version using rpm but that seems quite a waste of resources. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (9)
-
Adrian Schröter -
Brandon Philips -
Guido Berhoerster -
Juergen Weigert -
Marcus Meissner -
Marcus Rueckert -
Michael Schroeder -
Stephan Kulow -
Vita Cizek