[opensuse-buildservice] osc, disable spec file auto format
Hi, Is there any way to disable format_spec_file service for any osc command? cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thu, 2015-02-12 at 17:26 +0100, Ruediger Meier wrote:
Hi,
Is there any way to disable format_spec_file service for any osc command?
--noservice exists for most commands that would call then.
e.g. osc ci --noservice. But that will disable all services of course.
If there is a problem with the service, it ought to be reported and
fixed.
Cheers,
Dominique
--
Dimstar / Dominique Leuenberger
On Thursday 12 February 2015, Dimstar / Dominique Leuenberger wrote:
On Thu, 2015-02-12 at 17:26 +0100, Ruediger Meier wrote:
Hi,
Is there any way to disable format_spec_file service for any osc command?
--noservice exists for most commands that would call then.
e.g. osc ci --noservice. But that will disable all services of course.
I'd like to have --noservice always per default. Or better just --no-format_spec_file. After years of pain I just want to get rid of it.
If there is a problem with the service, it ought to be reported and fixed.
The main problem is that it does the opposite of what anybody would expect from a VCS (like osc). After editing some files it silently changes the files in the critical moment when I want to safe my changes (commit). There is no way to see what it did and there is no way to revert these auto-changes. The only fix is to disable it. Such auto-format thing is something you could teach your editor but not arbitrary other commands like "osc build" or "osc commit" or wherever else it's called. BTW if you have a clean working copy, then "osc commit" even commits auto-changes without any possibility to review and abort it. You can reproduce it easily: $ osc branch Base:System/util-linux $ osc co home:xxx:branches:Base:System/util-linux $ cd home:xxx:branches:Base:System/util-linux $ osc commit ... and it commits broken spec files without commit message ... cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thu, 2015-02-12 at 17:56 +0100, Ruediger Meier wrote:
On Thursday 12 February 2015, Dimstar / Dominique Leuenberger wrote:
On Thu, 2015-02-12 at 17:26 +0100, Ruediger Meier wrote:
Hi,
Is there any way to disable format_spec_file service for any osc command?
--noservice exists for most commands that would call then.
e.g. osc ci --noservice. But that will disable all services of course.
I'd like to have --noservice always per default. Or better just --no-format_spec_file. After years of pain I just want to get rid of it.
rpm -e obs-service-format_spec_file
If there is a problem with the service, it ought to be reported and fixed.
The main problem is that it does the opposite of what anybody would expect from a VCS (like osc). After editing some files it silently changes the files in the critical moment when I want to safe my changes (commit). There is no way to see what it did and there is no way to revert these auto-changes. The only fix is to disable it.
Such auto-format thing is something you could teach your editor but not arbitrary other commands like "osc build" or "osc commit" or wherever else it's called.
BTW if you have a clean working copy, then "osc commit" even commits auto-changes without any possibility to review and abort it. You can reproduce it easily: $ osc branch Base:System/util-linux $ osc co home:xxx:branches:Base:System/util-linux $ cd home:xxx:branches:Base:System/util-linux $ osc commit ... and it commits broken spec files without commit message ...
The issue lies in BROKEN spec file; and THAT part is what needs to be
reported so it can be fixed;
Dominique
--
Dimstar / Dominique Leuenberger
On Thursday 12 February 2015, Dimstar / Dominique Leuenberger wrote:
On Thu, 2015-02-12 at 17:56 +0100, Ruediger Meier wrote:
On Thursday 12 February 2015, Dimstar / Dominique Leuenberger wrote:
On Thu, 2015-02-12 at 17:26 +0100, Ruediger Meier wrote:
Hi,
Is there any way to disable format_spec_file service for any osc command?
--noservice exists for most commands that would call then.
e.g. osc ci --noservice. But that will disable all services of course.
I'd like to have --noservice always per default. Or better just --no-format_spec_file. After years of pain I just want to get rid of it.
rpm -e obs-service-format_spec_file
But I'am not root on that system and I also want to use it manually from time to time, like $ osc service run The only critical bug is IMO that it runs per default for arbitrary osc commands. This makes ocs to a VCS which does not want to archive user's changes. People with different installed osc and obs-service-format_spec_file always revert each other's changes ... that's insane.
If there is a problem with the service, it ought to be reported and fixed.
The main problem is that it does the opposite of what anybody would expect from a VCS (like osc). After editing some files it silently changes the files in the critical moment when I want to safe my changes (commit). There is no way to see what it did and there is no way to revert these auto-changes. The only fix is to disable it.
Such auto-format thing is something you could teach your editor but not arbitrary other commands like "osc build" or "osc commit" or wherever else it's called.
BTW if you have a clean working copy, then "osc commit" even commits auto-changes without any possibility to review and abort it. You can reproduce it easily: $ osc branch Base:System/util-linux $ osc co home:xxx:branches:Base:System/util-linux $ cd home:xxx:branches:Base:System/util-linux $ osc commit ... and it commits broken spec files without commit message ...
The issue lies in BROKEN spec file; and THAT part is what needs to be reported so it can be fixed;
You may take my "BTW ..." paragraph as one bug report if you want. cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thu, 2015-02-12 at 18:26 +0100, Ruediger Meier wrote:
BTW if you have a clean working copy, then "osc commit" even commits auto-changes without any possibility to review and abort it. You can reproduce it easily: $ osc branch Base:System/util-linux $ osc co home:xxx:branches:Base:System/util-linux $ cd home:xxx:branches:Base:System/util-linux $ osc commit ... and it commits broken spec files without commit message ...
The issue lies in BROKEN spec file; and THAT part is what needs to be reported so it can be fixed;
You may take my "BTW ..." paragraph as one bug report if you want.
But it does not describe in what way the .spec file breaks - the fact
that it commits something after you asked it to (using osc commit) is
not a defect in the spec-formatter.
Dominique
--
Dimstar / Dominique Leuenberger
On Donnerstag, 12. Februar 2015, 18:56:07 wrote Dimstar / Dominique Leuenberger:
On Thu, 2015-02-12 at 18:26 +0100, Ruediger Meier wrote:
BTW if you have a clean working copy, then "osc commit" even commits auto-changes without any possibility to review and abort it. You can reproduce it easily: $ osc branch Base:System/util-linux $ osc co home:xxx:branches:Base:System/util-linux $ cd home:xxx:branches:Base:System/util-linux $ osc commit ... and it commits broken spec files without commit message ...
The issue lies in BROKEN spec file; and THAT part is what needs to be reported so it can be fixed;
You may take my "BTW ..." paragraph as one bug report if you want.
But it does not describe in what way the .spec file breaks - the fact that it commits something after you asked it to (using osc commit) is not a defect in the spec-formatter.
In any case, I agree that such a bug needs to be fixed instead of just skipping some code. It is the decision of the project owners who have this services configured. And you can not submit a package to factory either which violates other guidelines there either ... -- 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
On Friday 13 February 2015, Adrian Schröter wrote:
On Donnerstag, 12. Februar 2015, 18:56:07 wrote Dimstar / Dominique Leuenberger:
On Thu, 2015-02-12 at 18:26 +0100, Ruediger Meier wrote:
BTW if you have a clean working copy, then "osc commit" even commits auto-changes without any possibility to review and abort it. You can reproduce it easily: $ osc branch Base:System/util-linux $ osc co home:xxx:branches:Base:System/util-linux $ cd home:xxx:branches:Base:System/util-linux $ osc commit ... and it commits broken spec files without commit message ...
The issue lies in BROKEN spec file; and THAT part is what needs to be reported so it can be fixed;
You may take my "BTW ..." paragraph as one bug report if you want.
But it does not describe in what way the .spec file breaks - the fact that it commits something after you asked it to (using osc commit) is not a defect in the spec-formatter.
In any case, I agree that such a bug needs to be fixed instead of just skipping some code.
It's unfixable. Old versions of "obs-service-format_spec_file" (the ones we have in any stable openSUSE release) will always revert spec files which were formatted by newer fixed versions. You see these kind of stupidly commited changes in many osc logs. It's a pain for any reviewer.
It is the decision of the project owners who have this services configured. And you can not submit a package to factory either which violates other guidelines there either ...
So the project owner of one single project forces me to have a certain spec-formatter installed. And then this spec-formatter runs by default on any other project I want to contribute too. How stupid is that? For example prepare_spec always adds a line like "# Copyright (c) 2015 SUSE LINUX GmbH, Nuernberg, Germany." How can it add a SUSE Copyright to my own code? Anyway you said the "It is the decision of the project owners ...". So I ask a bit different. What is the correct way to decide this? How can I disable it for all _my_own_ projects "home:rudi_m:*". cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Freitag, 13. Februar 2015, 13:17:31 wrote Ruediger Meier:
On Friday 13 February 2015, Adrian Schröter wrote:
On Donnerstag, 12. Februar 2015, 18:56:07 wrote Dimstar / Dominique Leuenberger:
On Thu, 2015-02-12 at 18:26 +0100, Ruediger Meier wrote:
BTW if you have a clean working copy, then "osc commit" even commits auto-changes without any possibility to review and abort it. You can reproduce it easily: $ osc branch Base:System/util-linux $ osc co home:xxx:branches:Base:System/util-linux $ cd home:xxx:branches:Base:System/util-linux $ osc commit ... and it commits broken spec files without commit message ...
The issue lies in BROKEN spec file; and THAT part is what needs to be reported so it can be fixed;
You may take my "BTW ..." paragraph as one bug report if you want.
But it does not describe in what way the .spec file breaks - the fact that it commits something after you asked it to (using osc commit) is not a defect in the spec-formatter.
In any case, I agree that such a bug needs to be fixed instead of just skipping some code.
It's unfixable. Old versions of "obs-service-format_spec_file" (the ones we have in any stable openSUSE release) will always revert spec files which were formatted by newer fixed versions. You see these kind of stupidly commited changes in many osc logs. It's a pain for any reviewer.
so what, a maintenance update for that package should be possible. Note: the one installed on the system of the packager is used, not the one inside of some distro.
It is the decision of the project owners who have this services configured. And you can not submit a package to factory either which violates other guidelines there either ...
So the project owner of one single project forces me to have a certain spec-formatter installed. And then this spec-formatter runs by default on any other project I want to contribute too. How stupid is that?
no, it runs only in projects and packages which define to use it. Eg osc cat openSUSE:Factory _project _service
For example prepare_spec always adds a line like "# Copyright (c) 2015 SUSE LINUX GmbH, Nuernberg, Germany." How can it add a SUSE Copyright to my own code?
please discuss it in this tools git directly: https://github.com/openSUSE/obs-service-format_spec_file However, adding a copyright is fine IMHO when it delivers the concrete template format. It must not remove any other copyright of course.
Anyway you said the "It is the decision of the project owners ...". So I ask a bit different. What is the correct way to decide this? How can I disable it for all _my_own_ projects "home:rudi_m:*".
don't branch from projects which define these global services. Because by default OBS is merging the sources (and so also the project service definitions) with yours. However, since they are the official policy in openSUSE:* you should do so only when you do not plan to submit back to these projects. Or stuff breaks later without that you become aware of it. -- 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
On Freitag, 13. Februar 2015, 13:24:25 wrote Adrian Schröter:
On Freitag, 13. Februar 2015, 13:17:31 wrote Ruediger Meier: ...
It's unfixable. Old versions of "obs-service-format_spec_file" (the ones we have in any stable openSUSE release) will always revert spec files which were formatted by newer fixed versions. You see these kind of stupidly commited changes in many osc logs. It's a pain for any reviewer.
so what, a maintenance update for that package should be possible. Note: the one installed on the system of the packager is used, not the one inside of some distro.
another note: this is only true, because this particular service is configured as "localonly" in openSUSE:* projects. Could you do me a favour and test the current version from openSUSE:Tools project if it is fixing your problems already? We will take care of a maintenance update then. ... -- 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
On Friday 13 February 2015, Adrian Schröter wrote:
On Freitag, 13. Februar 2015, 13:24:25 wrote Adrian Schröter:
On Freitag, 13. Februar 2015, 13:17:31 wrote Ruediger Meier:
...
It's unfixable. Old versions of "obs-service-format_spec_file" (the ones we have in any stable openSUSE release) will always revert spec files which were formatted by newer fixed versions. You see these kind of stupidly commited changes in many osc logs. It's a pain for any reviewer.
so what, a maintenance update for that package should be possible. Note: the one installed on the system of the packager is used, not the one inside of some distro.
another note: this is only true, because this particular service is configured as "localonly" in openSUSE:* projects.
Could you do me a favour and test the current version from openSUSE:Tools project if it is fixing your problems already?
Because I'm not root I did it manually like this: $ ~/devel/osc/openSUSE:Tools/obs-service-format_spec_file/binaries/usr/lib/obs/service/format_spec_file.files/prepare_spec python-libmount.spec > new.spec $ diff python-libmount.spec new.spec ... looks ok
We will take care of a maintenance update then.
To solve the problem of reverted and re-reverted spec files you would keep any client installation in sync. Good luck! 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? cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Freitag, 13. Februar 2015, 14:17:52 wrote Ruediger Meier:
On Friday 13 February 2015, Adrian Schröter wrote:
On Freitag, 13. Februar 2015, 13:24:25 wrote Adrian Schröter:
On Freitag, 13. Februar 2015, 13:17:31 wrote Ruediger Meier:
...
It's unfixable. Old versions of "obs-service-format_spec_file" (the ones we have in any stable openSUSE release) will always revert spec files which were formatted by newer fixed versions. You see these kind of stupidly commited changes in many osc logs. It's a pain for any reviewer.
so what, a maintenance update for that package should be possible. Note: the one installed on the system of the packager is used, not the one inside of some distro.
another note: this is only true, because this particular service is configured as "localonly" in openSUSE:* projects.
Could you do me a favour and test the current version from openSUSE:Tools project if it is fixing your problems already?
Because I'm not root I did it manually like this:
$ ~/devel/osc/openSUSE:Tools/obs-service-format_spec_file/binaries/usr/lib/obs/service/format_spec_file.files/prepare_spec python-libmount.spec > new.spec $ diff python-libmount.spec new.spec
... looks ok
good, I created maintenace update requests now.
We will take care of a maintenance update then.
To solve the problem of reverted and re-reverted spec files you would keep any client installation in sync. Good luck!
same as with osc and build package ....
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 :) -- 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
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" 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. or maybe instead of 2. indroducing env var "OSC_SERVICE_PATH", colon separated list of paths. cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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
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 ...
or maybe instead of 2. indroducing env var "OSC_SERVICE_PATH", colon separated list of paths.
cu, Rudi
-- 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
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 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
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. Would you tolerate it if the cp command *ever* made *any* change to the data on it's own along the way? Whatever high level result you wanted to get from this behavior, this is the wrong place to insert it. -- bkw -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wednesday 18 February 2015 15:55:32 Brian K. White wrote:
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.
CVS can update a version tag and inject log messages into your file ...
Would you tolerate it if the cp command *ever* made *any* change to the data on it's own along the way?
At least file owner and timestamps will be changed. Ok, these are metadata, but ...
Whatever high level result you wanted to get from this behavior, this is the wrong place to insert it.
The OBS could reject files which are not compliant. Something along: --- The file "foo.spec" has been rejected as it is not compliant to formatting rules, see https://en.opensuse.org/openSUSE:Specfile_guidelines for details. Please fix these issues, either manually or by executing "osc service run format_spec_file". The following issues were found by format_spec_file (Version 0.1234) Line 14: Bad ordering for "Requires:", please sort alphabetically Line 18: Unknown or bad "License:" Line 43: ... ... --- Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
# stefan.bruens@rwth-aachen.de / 2015-02-19 01:13:30 +0100:
On Wednesday 18 February 2015 15:55:32 Brian K. White wrote:
Whatever high level result you wanted to get from this behavior, this is the wrong place to insert it.
The OBS could reject files which are not compliant. Something along:
--- The file "foo.spec" has been rejected as it is not compliant to formatting rules, see https://en.opensuse.org/openSUSE:Specfile_guidelines for details.
Please fix these issues, either manually or by executing "osc service run format_spec_file".
The following issues were found by format_spec_file (Version 0.1234) Line 14: Bad ordering for "Requires:", please sort alphabetically Line 18: Unknown or bad "License:" Line 43: ... ... ---
that is definitely the way to go about it. OTOH, people need tools to automate the compliance-related changes. spec-cleaner still makes sense, but the server-generated error message needs to identify clearly the rules it is currently enforcing, perhaps with a (working!) http(s) url pointing to a release tarball. -- roman -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thursday 2015-02-19 01:13, Stefan Bruens wrote:
On Wednesday 18 February 2015 15:55:32 Brian K. White wrote:
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.
CVS can update a version tag and inject log messages into your file ...
And then people realized it was a bad idea and stopped doing it with Git. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Donnerstag, 19. Februar 2015, 09:44:01 wrote Jan Engelhardt:
On Thursday 2015-02-19 01:13, Stefan Bruens wrote:
On Wednesday 18 February 2015 15:55:32 Brian K. White wrote:
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.
CVS can update a version tag and inject log messages into your file ...
And then people realized it was a bad idea and stopped doing it with Git.
git has also pre-commit hooks. Nevertheless, we do still consider other ways way to much additional overhead atm for the packager. But when you want to discuss it, you should go to the factory mailing list. OBS is just offering the hooks, but the project maintainers are the ones who decide how to use them. -- 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
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
On Thursday 12 February 2015, Dimstar / Dominique Leuenberger wrote:
I'd like to have --noservice always per default. Or better just --no-format_spec_file. After years of pain I just want to get rid of it.
rpm -e obs-service-format_spec_file
I've tried this now on a second machine but it does not work: rudi@zappa:~/devel/osc/home:rudi_m:ul-all/util-linux> osc commit *** Error: Package obs-service-format_spec_file is required for this operation rudi@zappa:~/devel/osc/home:rudi_m:ul-all/util-linux> osc service run *** Error: Package obs-service-format_spec_file is required for this operation cu, Rudi -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (7)
-
Adrian Schröter -
Brian K. White -
Dimstar / Dominique Leuenberger -
Jan Engelhardt -
Roman Neuhauser -
Ruediger Meier -
Stefan Bruens