[opensuse-buildservice] What to do about "broken" state
Hi all, I'm working on setting up a private OBS to replace an old version that has been running for many years. I need to build packages for *at least* CentOS 7 and Scientific Linux 6.x (x = 7, 8, whatever is latest). I successfully added a project "CentOS:C7" as a binary import. We already have local mirrors of all upstream OS packages, so IMHO there's no point in using download-on-demand. Anyways, after I added the CentOS:C7 project and configured my home:gward project to build for CentOS 7 using that project, packages in my project were in state "broken" for a little while. I poked around trying to figure things out, but did not succeed. After a while, I noticed that the packages had built -- apparently *something* cleared the "broken" state, but I have no idea what. So I carried on and added a project ScientificLinux:SL6.7. To the best of my knowledge and memory, I repeated the same steps that I did to create CentOS:C7. And it half worked: packages in home:gward now want to build for SL 6.7, i586 and x86_64. But it half didn't work: those packages have been stuck in state "broken" for ~30 min now, and they do not appear to be magically getting unbroken. Any idea what is going on here? How do I investigate when a package is "broken"? How do I unbreak it? Thanks! Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mon, Feb 13, 2017 at 06:04:12PM -0500, Greg Ward wrote:
Hi all,
I'm working on setting up a private OBS to replace an old version that has been running for many years. I need to build packages for *at least* CentOS 7 and Scientific Linux 6.x (x = 7, 8, whatever is latest). I successfully added a project "CentOS:C7" as a binary import. We already have local mirrors of all upstream OS packages, so IMHO there's no point in using download-on-demand.
Anyways, after I added the CentOS:C7 project and configured my home:gward project to build for CentOS 7 using that project, packages in my project were in state "broken" for a little while. I poked around trying to figure things out, but did not succeed. After a while, I noticed that the packages had built -- apparently *something* cleared the "broken" state, but I have no idea what.
So I carried on and added a project ScientificLinux:SL6.7. To the best of my knowledge and memory, I repeated the same steps that I did to create CentOS:C7. And it half worked: packages in home:gward now want to build for SL 6.7, i586 and x86_64. But it half didn't work: those packages have been stuck in state "broken" for ~30 min now, and they do not appear to be magically getting unbroken.
Any idea what is going on here? How do I investigate when a package is "broken"? How do I unbreak it?
Use "osc results -v" in the package to see why it is broken (or the popup on the website). It might be repository related or package related, but its hard to say. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Dienstag, 14. Februar 2017, 06:21:14 CET wrote Marcus Meissner:
On Mon, Feb 13, 2017 at 06:04:12PM -0500, Greg Ward wrote:
Hi all,
I'm working on setting up a private OBS to replace an old version that has been running for many years. I need to build packages for *at least* CentOS 7 and Scientific Linux 6.x (x = 7, 8, whatever is latest). I successfully added a project "CentOS:C7" as a binary import. We already have local mirrors of all upstream OS packages, so IMHO there's no point in using download-on-demand.
Anyways, after I added the CentOS:C7 project and configured my home:gward project to build for CentOS 7 using that project, packages in my project were in state "broken" for a little while. I poked around trying to figure things out, but did not succeed. After a while, I noticed that the packages had built -- apparently *something* cleared the "broken" state, but I have no idea what.
So I carried on and added a project ScientificLinux:SL6.7. To the best of my knowledge and memory, I repeated the same steps that I did to create CentOS:C7. And it half worked: packages in home:gward now want to build for SL 6.7, i586 and x86_64. But it half didn't work: those packages have been stuck in state "broken" for ~30 min now, and they do not appear to be magically getting unbroken.
Any idea what is going on here? How do I investigate when a package is "broken"? How do I unbreak it?
Use "osc results -v" in the package to see why it is broken (or the popup on the website).
It might be repository related or package related, but its hard to say.
Well, not with "osc r -v" or via the mouse-over information in webui. Usually it is a conflicting source commit which can get resolved with "osc pull". -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, 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 Tue, Feb 14, 2017, at 02:55, Adrian Schröter wrote:
Any idea what is going on here? How do I investigate when a package is "broken"? How do I unbreak it?
Use "osc results -v" in the package to see why it is broken (or the popup on the website).
It might be repository related or package related, but its hard to say.
Well, not with "osc r -v" or via the mouse-over information in webui.
Yeah, I figured out the mouse-over already. I get the same message at the command line: obs-new:/tmp/home:gward/sortu # osc results -v sl67 x86_64 broken: bad build configuration, no build type defined or detected sl67 i586 broken: bad build configuration, no build type defined or detected ol7 x86_64 succeeded c7 x86_64 succeeded But I don't *understand* the error. Hmmm: I just realized I didn't do anything to define a build worker for SL 6.7. My colleague, who created this private instance, took care of the ol7 (Oracle Linux 7) build worker When I added c7 (CentOS 7), it just worked without me adding a builder, and I don't understand why. Now I've added sl67 (Scientific Linux 6.7) without adding a build worker, and it doesn't work. Maybe my question should be: why are my CentOS 7 builds working even though I did not define a build worker?
Usually it is a conflicting source commit which can get resolved with "osc pull".
I'm the only person using this instance, and there are only two users: Admin and gward. So I'm pretty sure we can eliminate this, right? Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tue, Feb 14, 2017, at 09:19, Greg Ward wrote:
Yeah, I figured out the mouse-over already. I get the same message at the command line:
obs-new:/tmp/home:gward/sortu # osc results -v sl67 x86_64 broken: bad build configuration, no build type defined or detected sl67 i586 broken: bad build configuration, no build type defined or detected ol7 x86_64 succeeded c7 x86_64 succeeded
But I don't *understand* the error.
Hmmm: I just realized I didn't do anything to define a build worker for SL 6.7. My colleague, who created this private instance, took care of the ol7 (Oracle Linux 7) build worker When I added c7 (CentOS 7), it just worked without me adding a builder, and I don't understand why. Now I've added sl67 (Scientific Linux 6.7) without adding a build worker, and it doesn't work.
Maybe my question should be: why are my CentOS 7 builds working even though I did not define a build worker?
The plot thickens. My formerly broken packages now build. I have no idea why. Here's what I did: * let time elapse: ~36 h while I dug into OBS source code, slept, worked on other things, etc. * made bogus whitespace-only commits to the .spec files to force a build It appears that elapsed time fixed my problem, i.e. now I have build workers capable of building for Scientific Linux 6.7. This is exactly what I observed when I added CentOS 7, only the time elapsed was longer. I still don't understand what happened. Related question: how do you trigger a build without a bogus whitespace-only commit? Thanks! Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mittwoch, 15. Februar 2017, 17:25:31 CET wrote Greg Ward:
On Tue, Feb 14, 2017, at 09:19, Greg Ward wrote:
Yeah, I figured out the mouse-over already. I get the same message at the command line:
obs-new:/tmp/home:gward/sortu # osc results -v sl67 x86_64 broken: bad build configuration, no build type defined or detected
this says there is neiter a build config (osc meta prjconf) which defines the type of build (rpm/deb/..) and neither any binaries in the repositories which can be used to auto detect the type. not sure about your setup, maybe the packages were missing on setup?
sl67 i586 broken: bad build configuration, no build type defined or detected ol7 x86_64 succeeded c7 x86_64 succeeded
But I don't *understand* the error.
Hmmm: I just realized I didn't do anything to define a build worker for SL 6.7. My colleague, who created this private instance, took care of the ol7 (Oracle Linux 7) build worker When I added c7 (CentOS 7), it just worked without me adding a builder, and I don't understand why. Now I've added sl67 (Scientific Linux 6.7) without adding a build worker, and it doesn't work.
Maybe my question should be: why are my CentOS 7 builds working even though I did not define a build worker?
The plot thickens. My formerly broken packages now build. I have no idea why. Here's what I did:
* let time elapse: ~36 h while I dug into OBS source code, slept, worked on other things, etc. * made bogus whitespace-only commits to the .spec files to force a build
It appears that elapsed time fixed my problem, i.e. now I have build workers capable of building for Scientific Linux 6.7. This is exactly what I observed when I added CentOS 7, only the time elapsed was longer. I still don't understand what happened.
Related question: how do you trigger a build without a bogus whitespace-only commit?
Thanks!
Greg
-- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, 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 Thu, Feb 16, 2017, at 02:46, Adrian Schröter wrote:
On Mittwoch, 15. Februar 2017, 17:25:31 CET wrote Greg Ward:
On Tue, Feb 14, 2017, at 09:19, Greg Ward wrote:
Yeah, I figured out the mouse-over already. I get the same message at the command line:
obs-new:/tmp/home:gward/sortu # osc results -v sl67 x86_64 broken: bad build configuration, no build type defined or detected
this says there is neiter a build config (osc meta prjconf) which defines the type of build (rpm/deb/..) and neither any binaries in the repositories which can be used to auto detect the type.
This was definitely true at one point. It is no longer true: * I used "osc meta prjconf -F" to load a known-good prjconf into my binary import repositories * I used "bs_admin --rescan-repositories" to ensure that :full.solv exists for binary import project/repo/arch At some point after I satisfied those two conditions, my "broken" packages started to build, and built successfully. In some cases, I didn't do anything and things started to build. In other cases, I made a whitespace-only commit to force builds. The big mystery at this point: what caused the transition from "broken" to "able to build"? Surely something happened, but so far all I can say is "some time elapsed". Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (3)
-
Adrian Schröter -
Greg Ward -
Marcus Meissner