On Mittwoch, 18. Februar 2015, 15:55:32 wrote Brian K. White:
On 2/13/2015 10:38 AM, Ruediger Meier wrote:
On Friday 13 February 2015, Adrian Schröter wrote:
On Freitag, 13. Februar 2015, 15:03:10 wrote Ruediger Meier:
On Friday 13 February 2015, Adrian Schröter wrote:
On Freitag, 13. Februar 2015, 14:17:52 wrote Ruediger Meier:
I'am already using latest git HEAD "osc" client locally installed in my /home. How could I teach it to not use globally (broken) services in /usr/lib/obs/service/ but from another directory?
this path is currently hard coded in osc/core.py around line 400.
Either patch it in your copy and create a pull request turning this into a ~/.oscrc option :)
I would probably change two things:
1. The global path /usr/lib/obs/service/ should respect --exec-prefix and/or --prefix used in "./setup.py install"
okay
Hm, this seems to be more complicated than I thought.
2. Introduce another config dir like ~/.obs/service/ where services are looked up first. So certain global installed services could be "fixed/disabled" by providing empty scripts there.
not sure if I like this... well, maybe if osc prints big warning letters that it is using an own, possibly outdated version ...
As root you could already skip it right now like this $ sudo truncate -s0 /usr/lib/obs/service/format_spec_file
As already said I think that it does not make much sense that server admins (project owners) trust on a particular file called "/usr/lib/obs/service/format_spec_file" to be executed on client side.
Why not just review/correct style policies automatically on server-side by _one_ up-to-date script.
For example last commit in obs-service-format_spec_file is ------------------- ### company name changed
-unshift @copyrights, "# Copyright (c) $thisyear SUSE LINUX Products GmbH, Nuernberg, Germany."; +unshift @copyrights, "# Copyright (c) $thisyear SUSE LINUX GmbH, Nuernberg, Germany."; --------------------
Couldn't you just correct things like this one time for all packages without bothering "osc commit"? The currently preferred way with dozens of different format_spec_file versions on client sides will only make sure that we will finally use as much different company names as possible ...
cu, Rudi
There is no getting around the fact that a vcs tool that modifies your data on it's own is wrong. Nothing you could ever say makes that ok.
actually almost every vcs tool I know can do this, if you want ...
Would you tolerate it if the cp command *ever* made *any* change to the data on it's own along the way?
... it is a matter of tast if you want to use it in your project or not. I agree that the changes should be limited to things which are save to change and it must never break things (or make it at least very-very unlikely).
Whatever high level result you wanted to get from this behavior, this is the wrong place to insert it.
we could turn it around and just check the policies and ask the people to execute formaters manually and in addition auto-decline requests with wrong formating. however, that will force people always to update their tools at the same point of time and it will add multiple manual steps. And we live with it since more then 15 years with this. I do not see a reason (except bugfixing certain issues) to change it suddenly and add additional burden to the packagers. I am sure to hear complains about declined requests if we would do so. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org