Re: [opensuse-buildservice] how to programmatically differentiate between linkpac and bco?
Dirk Müller (dirk@dmllr.de) wrote:
Am 04.01.2013 00:06 schrieb "Adam Spiers" <aspiers@suse.com>:
If it's checked out unexpanded ("osc co -u") then it seems I can take a guess by looking for
<patches> <branch/> </patches>
in the _link file, but I'm not sure this is correct
This is correct.
and it's not even possible when the sources are expanded, since then _link doesn't exist. Suggestions?
I haven't tried it, but perhaps osc info does say it somewhere? Other than that you could use osc cat to query the Server, but I'm not sure if your goal was to avoid the roundtrip.
Yes I was hoping to avoid that :-)
Maybe there is something hidden in the .osc dir :-)
As you said in a separate mail, checking if the linkinfo in .osc/_meta has a baserev is a close-enough estimation, as usually links do not have baserevs. Thanks for the very helpful info! Here's the resulting script: https://github.com/aspiers/SUSE-dist/blob/master/bin/osc-classify-link -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Adam Spiers (aspiers@suse.com) wrote:
Here's the resulting script:
https://github.com/aspiers/SUSE-dist/blob/master/bin/osc-classify-link
Sample output: $ cd /home/adam/SUSE/OBS/systemsmanagement/crowbar/2.0 $ osc-classify-link [... snipped ...] rubygem-tilt linkpac -> devel:languages:ruby:extensions/rubygem-tilt rubygem-treetop linkpac -> systemsmanagement:chef:10/rubygem-treetop rubygem-tzinfo linkpac expanded -> devel:languages:ruby:extensions/rubygem-tzinfo rubygem-unicorn normal or copypac rubygem-uuidtools linkpac -> systemsmanagement:chef:10/rubygem-uuidtools rubygem-wsman normal or copypac rubygem-xml-simple normal or copypac rubygem-yajl-ruby linkpac -> systemsmanagement:chef:10/rubygem-yajl-ruby sleshammer normal or copypac -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Today is osc plugin day ;-) I just rewrote my osc-classify-link shellscript (see below) as a proper osc plugin: https://gist.github.com/09641ddd5ddcca9a2a7e (Try by installing into ~/.osc-plugins or /var/lib/osc-plugins) It's now MUCH faster, and also supports a new -s / --server option which enables server-side checks for greater accuracy where required. Sample usage: $ cd ~/OBS/home/aspiers/branches/devel/languages/ruby/ $ osc classify ruby-common branch of or linkpac -> devel:languages:ruby/ruby-common $ osc classify -s ruby-common branch of devel:languages:ruby/ruby-common $ cd ~/OBS/systemsmanagement/crowbar/2.0 $ osc classify [...] crowbar-sledgehammer normal or copypac erlang linkpac -> systemsmanagement:chef:10/erlang fakechroot branch of home:dmacvicar/fakechroot gecode linkpac -> systemsmanagement:chef:10/gecode js linkpac -> systemsmanagement:chef:10/js libyaml aggregate -> devel:languages:ruby rabbitmq-server branch of or linkpac -> systemsmanagement:chef:10/rabbitmq-server ruby aggregate -> devel:languages:ruby ruby-common aggregate -> devel:languages:ruby ruby19 aggregate -> devel:languages:ruby rubygem-abstract branch of or linkpac -> devel:languages:ruby:extensions/rubygem-abstract rubygem-actionmailer-3_2 linkpac -> devel:languages:ruby:extensions/rubygem-actionmailer-3_2 [...] As with the prdiff plugin I announced earlier today, I think there's a good argument for including it in the core rather than packaging it as a plugin, but I'd welcome opinions on that. Cheers, Adam Adam Spiers (aspiers@suse.com) wrote:
Dirk Müller (dirk@dmllr.de) wrote:
Am 04.01.2013 00:06 schrieb "Adam Spiers" <aspiers@suse.com>:
If it's checked out unexpanded ("osc co -u") then it seems I can take a guess by looking for
<patches> <branch/> </patches>
in the _link file, but I'm not sure this is correct
This is correct.
and it's not even possible when the sources are expanded, since then _link doesn't exist. Suggestions?
I haven't tried it, but perhaps osc info does say it somewhere? Other than that you could use osc cat to query the Server, but I'm not sure if your goal was to avoid the roundtrip.
Yes I was hoping to avoid that :-)
Maybe there is something hidden in the .osc dir :-)
As you said in a separate mail, checking if the linkinfo in .osc/_meta has a baserev is a close-enough estimation, as usually links do not have baserevs. Thanks for the very helpful info!
Here's the resulting script:
https://github.com/aspiers/SUSE-dist/blob/master/bin/osc-classify-link -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Adam Spiers (aspiers@suse.com) wrote:
Today is osc plugin day ;-)
I just rewrote my osc-classify-link shellscript (see below) as a proper osc plugin:
https://gist.github.com/09641ddd5ddcca9a2a7e
(Try by installing into ~/.osc-plugins or /var/lib/osc-plugins)
This plugin now lives in a github repo: https://github.com/aspiers/SUSE-dist Feel free to submit issues and pull requests. However I would also like the code to be considered for inclusion in osc core if possible. Thanks, Adam -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Hi Adam, On 2013-01-16 23:48:01 +0000, Adam Spiers wrote: <SNIP>
As with the prdiff plugin I announced earlier today, I think there's a good argument for including it in the core rather than packaging it as a plugin, but I'd welcome opinions on that.
Hmm what about adding these additional information to the existing "info" command? I'm not sure if a new command is needed for it. What do you think? Some comments/thoughts about the code: - parse_xml: It should raise an OscIOError if the file doesn't exist (instead of OscBaseError (this class is only used as a base class for all osc related exceptions)). Raising a NoWorkingCopy exception in case of a SyntaxError is "wrong" because it _is_ a (valid) wc (just the _link file is corrupt). - _classify_dir: An _aggregate might aggregate packages from multiple projects (that is there might be multiple <aggregate /> elements). Currently your code only considers the last <aggregate /> element. If you want to check if a '_link' file is present in a package you can simply use "if '_link' in pkg.filenamelist..." instead of directly inspecting the storedir. In order to retrieve the contents of a storefile you should use "store_read_file". - do_classify: Use "is_project_dir" and "is_package_dir". As I already wrote in my other mail feel free to ignore the comments from above - most of them are just "cosmetic":) Keep up the good work! Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Marcus Hüwe (suse-tux@gmx.de) wrote:
Hi Adam,
On 2013-01-16 23:48:01 +0000, Adam Spiers wrote:
<SNIP>
As with the prdiff plugin I announced earlier today, I think there's a good argument for including it in the core rather than packaging it as a plugin, but I'd welcome opinions on that.
Hmm what about adding these additional information to the existing "info" command? I'm not sure if a new command is needed for it. What do you think?
Some comments/thoughts about the code: - parse_xml: It should raise an OscIOError if the file doesn't exist (instead of OscBaseError (this class is only used as a base class for all osc related exceptions)).
Oops right :) I'll fix that.
Raising a NoWorkingCopy exception in case of a SyntaxError is "wrong" because it _is_ a (valid) wc (just the _link file is corrupt).
Also true - late night hacking is not good ... So maybe I should just drop the try/except so the SyntaxError bubbles up?
- _classify_dir: An _aggregate might aggregate packages from multiple projects (that is there might be multiple <aggregate /> elements).
Ah, I didn't know that.
Currently your code only considers the last <aggregate /> element.
Yup, fixing ...
If you want to check if a '_link' file is present in a package you can simply use "if '_link' in pkg.filenamelist..." instead of directly inspecting the storedir. In order to retrieve the contents of a storefile you should use "store_read_file". - do_classify: Use "is_project_dir" and "is_package_dir".
OK, thanks.
As I already wrote in my other mail feel free to ignore the comments from above - most of them are just "cosmetic":)
Nope, they are very good comments and the fixes are now in my github repo :) I'll defer working on merging this into osc until: - we've resolved the Travis issues - I've done a pull request for prdiff into osc Thanks again! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (2)
-
Adam Spiers -
Marcus Hüwe