[opensuse-buildservice] Getting old _service:*.spec file in a _link
See https://build.opensuse.org/package/files?package=lightspark&project=home%3ARedDwarf:multimedia The _service:format_spec_file:lightspark.spec file uses CMAKE_SKIP_RPATH instead of the CMAKE_BUILD_WITH_INSTALL_RPATH from the original .spec file. It's from an old revision and I have no idea why it appeared there when I added the "<topadd>%define _with_ffmpeg 1</topadd>" line to the _link file. If you check the date you can see the _service file is older than the original .spec file!! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Dienstag, 27. März 2012, 13:08:51 schrieb Cristian Morales Vega:
See https://build.opensuse.org/package/files?package=lightspark&project=home%3ARedDwarf:multimedia
The _service:format_spec_file:lightspark.spec file uses CMAKE_SKIP_RPATH instead of the CMAKE_BUILD_WITH_INSTALL_RPATH from the original .spec file. It's from an old revision and I have no idea why it appeared there when I added the "<topadd>%define _with_ffmpeg 1</topadd>" line to the _link file. If you check the date you can see the _service file is older than the original .spec file!!
You configured project global spec file formater service. osc api /source/home%3ARedDwarf/_project/_service <services> <service name="format_spec_file"/> <service name="download_files"/> <service name="source_validator"/> </services> I would suggest that you switch to mode="trylocal" or mode="localonly" for the format_spec_file service as we do in Factory. apart from that ffmpeg sounds a little bit like a policy violation ? -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 27 March 2012 13:27, Adrian Schröter <adrian@suse.de> wrote:
I would suggest that you switch to mode="trylocal" or mode="localonly" for the format_spec_file service as we do in Factory.
So it's a known bug? I mean, the service seems to be running against an old revision of the spec file... Whatever the config it looks wrong.
apart from that ffmpeg sounds a little bit like a policy violation ?
It's building against home:RedDwarf:fakePackman, there is no real code there. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Dienstag, 27. März 2012, 13:42:09 schrieb Cristian Morales Vega:
On 27 March 2012 13:27, Adrian Schröter <adrian@suse.de> wrote:
I would suggest that you switch to mode="trylocal" or mode="localonly" for the format_spec_file service as we do in Factory.
So it's a known bug? I mean, the service seems to be running against an old revision of the spec file... Whatever the config it looks wrong.
It is not a bug, it did run when the _link file got changed the last time. You have to manualy re-trigger it when you run services in _linked packages and change the link target below.
apart from that ffmpeg sounds a little bit like a policy violation ?
It's building against home:RedDwarf:fakePackman, there is no real code there.
k:) -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 27 March 2012 14:00, Adrian Schröter <adrian@suse.de> wrote:
Am Dienstag, 27. März 2012, 13:42:09 schrieb Cristian Morales Vega:
On 27 March 2012 13:27, Adrian Schröter <adrian@suse.de> wrote:
I would suggest that you switch to mode="trylocal" or mode="localonly" for the format_spec_file service as we do in Factory.
So it's a known bug? I mean, the service seems to be running against an old revision of the spec file... Whatever the config it looks wrong.
It is not a bug, it did run when the _link file got changed the last time. You have to manualy re-trigger it when you run services in _linked packages and change the link target below.
If I delete the package in home:RedDwarf:multimedia now and I recreate the link there will not be any _service* file at all (I did it a few times already). Now I modify the _link file to add the "topadd" and the service triggers, OK... but the _service file it generates is not based on the *latest* .spec file in home:RedDwarf:multimedia/lightspark and neither on the one from home:RedDwarf/lightspark.). To make it clear, the revision 1 of home:RedDwarf:multimedia/lightspark has no _service file at all and the revision 2, commited *now*, has a _service file with a timestamp from four days ago :-? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Dienstag, 27. März 2012, 14:21:32 schrieb Cristian Morales Vega:
On 27 March 2012 14:00, Adrian Schröter <adrian@suse.de> wrote:
Am Dienstag, 27. März 2012, 13:42:09 schrieb Cristian Morales Vega:
On 27 March 2012 13:27, Adrian Schröter <adrian@suse.de> wrote:
I would suggest that you switch to mode="trylocal" or mode="localonly" for the format_spec_file service as we do in Factory.
So it's a known bug? I mean, the service seems to be running against an old revision of the spec file... Whatever the config it looks wrong.
It is not a bug, it did run when the _link file got changed the last time. You have to manualy re-trigger it when you run services in _linked packages and change the link target below.
If I delete the package in home:RedDwarf:multimedia now and I recreate the link there will not be any _service* file at all (I did it a few times already). Now I modify the _link file to add the "topadd" and the service triggers, OK... but the _service file it generates is not based on the *latest* .spec file in home:RedDwarf:multimedia/lightspark and neither on the one from home:RedDwarf/lightspark.).
To make it clear, the revision 1 of home:RedDwarf:multimedia/lightspark has no _service file at all and the revision 2, commited *now*, has a _service file with a timestamp from four days ago :-?
You have have project wide services configured in "home:RedWarf" and since your package is a source link to there they get executed as well. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 30 March 2012 10:51, Adrian Schröter <adrian@suse.de> wrote:
Am Dienstag, 27. März 2012, 14:21:32 schrieb Cristian Morales Vega:
On 27 March 2012 14:00, Adrian Schröter <adrian@suse.de> wrote:
Am Dienstag, 27. März 2012, 13:42:09 schrieb Cristian Morales Vega:
On 27 March 2012 13:27, Adrian Schröter <adrian@suse.de> wrote:
I would suggest that you switch to mode="trylocal" or mode="localonly" for the format_spec_file service as we do in Factory.
So it's a known bug? I mean, the service seems to be running against an old revision of the spec file... Whatever the config it looks wrong.
It is not a bug, it did run when the _link file got changed the last time. You have to manualy re-trigger it when you run services in _linked packages and change the link target below.
If I delete the package in home:RedDwarf:multimedia now and I recreate the link there will not be any _service* file at all (I did it a few times already). Now I modify the _link file to add the "topadd" and the service triggers, OK... but the _service file it generates is not based on the *latest* .spec file in home:RedDwarf:multimedia/lightspark and neither on the one from home:RedDwarf/lightspark.).
To make it clear, the revision 1 of home:RedDwarf:multimedia/lightspark has no _service file at all and the revision 2, commited *now*, has a _service file with a timestamp from four days ago :-?
You have have project wide services configured in "home:RedWarf" and since your package is a source link to there they get executed as well.
Since lightspark doesn't really build without ffmpeg I just put it directly in home:RedDwarf:multimedia, so it's not a problem anymore. But I wasn't complaining about the services being executed. The problem was that the output of the format_spec_file service contained the string "CMAKE_SKIP_RPATH", and that string: a) Wasn't in the spec file from the linked package (home:RedDwarf/lightspark) b) Wasn't in the spec file from the linking package (home:RedDwarf:multimedia/lightspark) c) To the best of my knowledge is not added by the format_spec_file service itself The "CMAKE_SKIP_RPATH" WAS in old revision of home:RedDwarf/lightspark. So it seems the format_spec_file service was executed against the old spec file, from the old revision. Deleting both home:RedDwarf/lightspark and home:RedDwarf:multimedia/lightspark and recreating them didn't help. The output of the format_spec_file service still contained the string "CMAKE_SKIP_RPATH" even if now in wasn't contained in any revision of the spec file from home:RedDwarf/lightspark since it was a completely new package. Apparently somehow the old spec file survived the deletion of the package and the format_spec_file was executed against it again. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 30 March 2012 11:18, Cristian Morales Vega <reddwarf@opensuse.org> wrote:
On 30 March 2012 10:51, Adrian Schröter <adrian@suse.de> wrote:
Am Dienstag, 27. März 2012, 14:21:32 schrieb Cristian Morales Vega:
On 27 March 2012 14:00, Adrian Schröter <adrian@suse.de> wrote:
Am Dienstag, 27. März 2012, 13:42:09 schrieb Cristian Morales Vega:
On 27 March 2012 13:27, Adrian Schröter <adrian@suse.de> wrote:
I would suggest that you switch to mode="trylocal" or mode="localonly" for the format_spec_file service as we do in Factory.
So it's a known bug? I mean, the service seems to be running against an old revision of the spec file... Whatever the config it looks wrong.
It is not a bug, it did run when the _link file got changed the last time. You have to manualy re-trigger it when you run services in _linked packages and change the link target below.
If I delete the package in home:RedDwarf:multimedia now and I recreate the link there will not be any _service* file at all (I did it a few times already). Now I modify the _link file to add the "topadd" and the service triggers, OK... but the _service file it generates is not based on the *latest* .spec file in home:RedDwarf:multimedia/lightspark and neither on the one from home:RedDwarf/lightspark.).
To make it clear, the revision 1 of home:RedDwarf:multimedia/lightspark has no _service file at all and the revision 2, commited *now*, has a _service file with a timestamp from four days ago :-?
You have have project wide services configured in "home:RedWarf" and since your package is a source link to there they get executed as well.
Since lightspark doesn't really build without ffmpeg I just put it directly in home:RedDwarf:multimedia, so it's not a problem anymore.
But I wasn't complaining about the services being executed. The problem was that the output of the format_spec_file service contained the string "CMAKE_SKIP_RPATH", and that string: a) Wasn't in the spec file from the linked package (home:RedDwarf/lightspark) b) Wasn't in the spec file from the linking package (home:RedDwarf:multimedia/lightspark) c) To the best of my knowledge is not added by the format_spec_file service itself
The "CMAKE_SKIP_RPATH" WAS in old revision of home:RedDwarf/lightspark. So it seems the format_spec_file service was executed against the old spec file, from the old revision. Deleting both home:RedDwarf/lightspark and home:RedDwarf:multimedia/lightspark and recreating them didn't help. The output of the format_spec_file service still contained the string "CMAKE_SKIP_RPATH" even if now in wasn't contained in any revision of the spec file from home:RedDwarf/lightspark since it was a completely new package. Apparently somehow the old spec file survived the deletion of the package and the format_spec_file was executed against it again.
OK, now I have an even more clear case: https://build.opensuse.org/package/files?package=scummvm&project=home%3ARedDwarf%3Amultimedia How I got that _service:download_url:scummvm-1.2.0.tar.bz2 file is beyond my understanding. Notice the spec file is for version 1.4.1... -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 30 March 2012 15:56, Cristian Morales Vega <reddwarf@opensuse.org> wrote:
OK, now I have an even more clear case: https://build.opensuse.org/package/files?package=scummvm&project=home%3ARedDwarf%3Amultimedia
How I got that _service:download_url:scummvm-1.2.0.tar.bz2 file is beyond my understanding. Notice the spec file is for version 1.4.1...
I guess that if I force a run of the services the problem will be "fixed". I am not doing so to have a good test case. Do you need it? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (2)
-
Adrian Schröter -
Cristian Morales Vega