[opensuse-buildservice] _workerstatus returning wrong info and other questions
I have a local OBS instance, and I have _3_ problems/questions I was hoping to get some help with. I am running 1.6.0-7.2 on openSUSE 11.2 1. When I call /build/_workerstatus, I get back XML (as expected) but the contents are wrong. Specifically, I have *4* workers configured for the local host, but I get back *5* <building/> elements. One of the elements is just plain wrong. The workerid is the duplicated from one of the others, it's starttime value doesn't change even after multiple restarts of the worker, and so on. What's going on here? Is this related to the (still unfixed?) bug where one cannot reduce the number of workers? 2. When can we expect the next 'stable'-ish release of the obs server component? Recent versions of osc seem to have their fair share of issues with obs 1.6. 3. Sometimes my builds seem to get stuck in loops. Usually, some core library like libtool or glibc changes, and that kicks off a rebuild of, well, everything. It seems, then, that things get stuck in a loop and some packages get rebuilt multiple times, and yet there are no obvious loops present in the dependencies. What might be going on, and how do I diagnose -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Sonntag, 3. Januar 2010 19:29:39 schrieb Jon Nelson:
I have a local OBS instance, and I have _3_ problems/questions I was hoping to get some help with.
I am running 1.6.0-7.2 on openSUSE 11.2
1. When I call /build/_workerstatus, I get back XML (as expected) but the contents are wrong.
Specifically, I have *4* workers configured for the local host, but I get back *5* <building/> elements. One of the elements is just plain wrong. The workerid is the duplicated from one of the others, it's starttime value doesn't change even after multiple restarts of the worker, and so on. What's going on here? Is this related to the (still unfixed?) bug where one cannot reduce the number of workers?
You may have a stale build job ? (stale file in /srv/obs/jobs/*/) OBS 1.7 will have the warden process, which is cleaning up jobs of died build hosts.
2. When can we expect the next 'stable'-ish release of the obs server component? Recent versions of osc seem to have their fair share of issues with obs 1.6.
For example ? I think we release the OBS 1.7 this or next month.
3. Sometimes my builds seem to get stuck in loops. Usually, some core library like libtool or glibc changes, and that kicks off a rebuild of, well, everything. It seems, then, that things get stuck in a loop and some packages get rebuilt multiple times, and yet there are no obvious loops present in the dependencies. What might be going on, and how do I diagnose
These are cycles, yes OBS detects this and need to build them multiple times. But there should be no endless loops. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Jan 4, 2010 at 1:50 AM, Adrian Schröter <adrian@suse.de> wrote:
Am Sonntag, 3. Januar 2010 19:29:39 schrieb Jon Nelson:
I have a local OBS instance, and I have _3_ problems/questions I was hoping to get some help with.
I am running 1.6.0-7.2 on openSUSE 11.2
1. When I call /build/_workerstatus, I get back XML (as expected) but the contents are wrong.
Specifically, I have *4* workers configured for the local host, but I get back *5* <building/> elements. One of the elements is just plain wrong. The workerid is the duplicated from one of the others, it's starttime value doesn't change even after multiple restarts of the worker, and so on. What's going on here? Is this related to the (still unfixed?) bug where one cannot reduce the number of workers?
You may have a stale build job ? (stale file in /srv/obs/jobs/*/)
OK. Fixed. Thanks!
OBS 1.7 will have the warden process, which is cleaning up jobs of died build hosts.
Good to know.
3. Sometimes my builds seem to get stuck in loops. Usually, some core library like libtool or glibc changes, and that kicks off a rebuild of, well, everything. It seems, then, that things get stuck in a loop and some packages get rebuilt multiple times, and yet there are no obvious loops present in the dependencies. What might be going on, and how do I diagnose
These are cycles, yes OBS detects this and need to build them multiple times. But there should be no endless loops.
OK. Another question I have has to do with rpm selection. Let's say we have a package, foo, which lots of other packages depend on (BuildRequires: foo). Let's also say that foo has been replaced by bar, and bar's specfile has this: "Provides: foo" and "Obsoletes: foo", and that foo and bar and the other packages are all in the same project. Why isn't bar being installed in favor of foo? -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, 2010-01-04 at 09:23 -0600, Jon Nelson wrote:
On Mon, Jan 4, 2010 at 1:50 AM, Adrian Schröter <adrian@suse.de> wrote:
Am Sonntag, 3. Januar 2010 19:29:39 schrieb Jon Nelson:
I have a local OBS instance, and I have _3_ problems/questions I was hoping to get some help with.
I am running 1.6.0-7.2 on openSUSE 11.2
1. When I call /build/_workerstatus, I get back XML (as expected) but the contents are wrong.
Specifically, I have *4* workers configured for the local host, but I get back *5* <building/> elements. One of the elements is just plain wrong. The workerid is the duplicated from one of the others, it's starttime value doesn't change even after multiple restarts of the worker, and so on. What's going on here? Is this related to the (still unfixed?) bug where one cannot reduce the number of workers?
You may have a stale build job ? (stale file in /srv/obs/jobs/*/)
OK. Fixed. Thanks!
OBS 1.7 will have the warden process, which is cleaning up jobs of died build hosts.
Good to know.
3. Sometimes my builds seem to get stuck in loops. Usually, some core library like libtool or glibc changes, and that kicks off a rebuild of, well, everything. It seems, then, that things get stuck in a loop and some packages get rebuilt multiple times, and yet there are no obvious loops present in the dependencies. What might be going on, and how do I diagnose
These are cycles, yes OBS detects this and need to build them multiple times. But there should be no endless loops.
OK.
Another question I have has to do with rpm selection. Let's say we have a package, foo, which lots of other packages depend on (BuildRequires: foo). Let's also say that foo has been replaced by bar, and bar's specfile has this: "Provides: foo" and "Obsoletes: foo", and that foo and bar and the other packages are all in the same project. Why isn't bar being installed in favor of foo?
Unless something changed in 1.7, the scheduler does first hit for deciding which package to use, so it probably see foo first and just stops looking, and so never sees bar. This is how the precedence with build repository paths works.
-- Jon
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Montag, 4. Januar 2010 16:23:29 schrieb Jon Nelson: ...
Another question I have has to do with rpm selection. Let's say we have a package, foo, which lots of other packages depend on (BuildRequires: foo). Let's also say that foo has been replaced by bar, and bar's specfile has this: "Provides: foo" and "Obsoletes: foo", and that foo and bar and the other packages are all in the same project. Why isn't bar being installed in favor of foo?
If you have two packages with same provides name you get an expansion error. Unlike rpm/zypper/yum/apt/... the OBS needs a unique definition to guarantee that a rebuild is reproducable. So you need either the prefer one of them or remove the other one. Apart from that, bar should be used if it provides foo. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Jan 4, 2010 at 9:51 AM, Adrian Schröter <adrian@suse.de> wrote:
Am Montag, 4. Januar 2010 16:23:29 schrieb Jon Nelson: ...
Another question I have has to do with rpm selection. Let's say we have a package, foo, which lots of other packages depend on (BuildRequires: foo). Let's also say that foo has been replaced by bar, and bar's specfile has this: "Provides: foo" and "Obsoletes: foo", and that foo and bar and the other packages are all in the same project. Why isn't bar being installed in favor of foo?
If you have two packages with same provides name you get an expansion error. Unlike rpm/zypper/yum/apt/... the OBS needs a unique definition to guarantee that a rebuild is reproducable.
The specfile for foo does not have a "Provides: foo". Do rpms have an implicit "Provides: $packagename" ?
So you need either the prefer one of them or remove the other one.
I'm not sure what that means.
Apart from that, bar should be used if it provides foo.
I am using 1.6. Also, the above statement appears to conflict with what Luke said (which is "first found" wins). I was also wrong about one thing: the "foo" package actually comes from one of the the project configuration's <repository/> <path/> elements. Does that matter? I would have expected the following behavior: 1. parse specfile. 2. one of the build deps is "foo" 3. the current project has "bar" which obsoletes and provides "foo". use that to meet the build dep. -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, 2010-01-04 at 09:59 -0600, Jon Nelson wrote:
On Mon, Jan 4, 2010 at 9:51 AM, Adrian Schröter <adrian@suse.de> wrote:
Am Montag, 4. Januar 2010 16:23:29 schrieb Jon Nelson: ...
Another question I have has to do with rpm selection. Let's say we have a package, foo, which lots of other packages depend on (BuildRequires: foo). Let's also say that foo has been replaced by bar, and bar's specfile has this: "Provides: foo" and "Obsoletes: foo", and that foo and bar and the other packages are all in the same project. Why isn't bar being installed in favor of foo?
If you have two packages with same provides name you get an expansion error. Unlike rpm/zypper/yum/apt/... the OBS needs a unique definition to guarantee that a rebuild is reproducable.
The specfile for foo does not have a "Provides: foo". Do rpms have an implicit "Provides: $packagename" ?
So you need either the prefer one of them or remove the other one.
I'm not sure what that means.
Apart from that, bar should be used if it provides foo.
I am using 1.6. Also, the above statement appears to conflict with what Luke said (which is "first found" wins).
I was also wrong about one thing: the "foo" package actually comes from one of the the project configuration's <repository/> <path/> elements. Does that matter? I would have expected the following behavior:
1. parse specfile. 2. one of the build deps is "foo" 3. the current project has "bar" which obsoletes and provides "foo". use that to meet the build dep.
Whether it's an expansion error or it picks first depends on if foo and bar have the same precedence. If foo and bar are at the same level, so from the same project or both package found under --prefer-pkgs directories, then they conflict and you get an expansion error. If foo is in the current project (precedence 1), but bar is in a build repository path (precedence 2), then foo wins since the scheduler will pick foo over bar. This is how you can rebuild something like glibc in a project and have everything in the project use that glibc instead of the one from openSUSE:Factory when openSUSE:Factory is a build repository path. If foo and bar both come from build repository path projects then whichever path entry (in the xml) is first wins.
-- Jon
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Jan 4, 2010 at 10:34 AM, Luke Imhoff <luke@cray.com> wrote:
On Mon, 2010-01-04 at 09:59 -0600, Jon Nelson wrote:
On Mon, Jan 4, 2010 at 9:51 AM, Adrian Schröter <adrian@suse.de> wrote:
Am Montag, 4. Januar 2010 16:23:29 schrieb Jon Nelson: ...
Another question I have has to do with rpm selection. Let's say we have a package, foo, which lots of other packages depend on (BuildRequires: foo). Let's also say that foo has been replaced by bar, and bar's specfile has this: "Provides: foo" and "Obsoletes: foo", and that foo and bar and the other packages are all in the same project. Why isn't bar being installed in favor of foo?
If you have two packages with same provides name you get an expansion error. Unlike rpm/zypper/yum/apt/... the OBS needs a unique definition to guarantee that a rebuild is reproducable.
The specfile for foo does not have a "Provides: foo". Do rpms have an implicit "Provides: $packagename" ?
So you need either the prefer one of them or remove the other one.
I'm not sure what that means.
Apart from that, bar should be used if it provides foo.
I am using 1.6. Also, the above statement appears to conflict with what Luke said (which is "first found" wins).
I was also wrong about one thing: the "foo" package actually comes from one of the the project configuration's <repository/> <path/> elements. Does that matter? I would have expected the following behavior:
1. parse specfile. 2. one of the build deps is "foo" 3. the current project has "bar" which obsoletes and provides "foo". use that to meet the build dep.
Whether it's an expansion error or it picks first depends on if foo and bar have the same precedence.
If foo and bar are at the same level, so from the same project or both package found under --prefer-pkgs directories, then they conflict and you get an expansion error.
What is "prefer-pkgs" ??
If foo is in the current project (precedence 1), but bar is in a build repository path (precedence 2), then foo wins since the scheduler will pick foo over bar. This is how you can rebuild something like glibc in a project and have everything in the project use that glibc instead of the one from openSUSE:Factory when openSUSE:Factory is a build repository path.
Actually, for me it's the other way around: bar is in the current project (precedence 1), foo is in a build repo path (precedence 2). Packages in the project all have "BuildRequires: foo" and "Requires: foo". However, foo is still being installed instead of bar.
If foo and bar both come from build repository path projects then whichever path entry (in the xml) is first wins.
Ah. *first* wins? Interesting. Good to know. That doesn't help this situation, though. -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Jon Nelson napsal(a):
Another question I have has to do with rpm selection. Let's say we have a package, foo, which lots of other packages depend on (BuildRequires: foo). Let's also say that foo has been replaced by bar, and bar's specfile has this: "Provides: foo" and "Obsoletes: foo", and that foo and bar and the other packages are all in the same project. Why isn't bar being installed in favor of foo?
See http://lists.opensuse.org/opensuse-buildservice/2007-06/msg00012.html Michal -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Jan 4, 2010 at 2:06 PM, Michal Marek <mmarek@suse.cz> wrote:
Jon Nelson napsal(a):
Another question I have has to do with rpm selection. Let's say we have a package, foo, which lots of other packages depend on (BuildRequires: foo). Let's also say that foo has been replaced by bar, and bar's specfile has this: "Provides: foo" and "Obsoletes: foo", and that foo and bar and the other packages are all in the same project. Why isn't bar being installed in favor of foo?
See http://lists.opensuse.org/opensuse-buildservice/2007-06/msg00012.html
I see. So in summary, the OBS doesn't look at Obsoletes for preferential rpm dependencies. However, it would appear that it's not looking that Provides, either: the package "bar" is using Provides: foo and yet it is not, apparently, being considered for dependency fulfillment for other packages in the same project. I'm unclear as to whether or not this behavior is expected. -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 5.1.2010 00:03, Jon Nelson wrote:
I see. So in summary, the OBS doesn't look at Obsoletes for preferential rpm dependencies. However, it would appear that it's not looking that Provides, either: the package "bar" is using Provides: foo and yet it is not, apparently, being considered for dependency fulfillment for other packages in the same project. I'm unclear as to whether or not this behavior is expected.
Please read the whole email at http://lists.opensuse.org/opensuse-buildservice/2007-06/msg00012.html. Michael explains that packages with the exact required name take precedence over packages that provide the dependency. Michal -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, Jan 5, 2010 at 3:37 AM, Michal Marek <mmarek@suse.cz> wrote:
On 5.1.2010 00:03, Jon Nelson wrote:
I see. So in summary, the OBS doesn't look at Obsoletes for preferential rpm dependencies. However, it would appear that it's not looking that Provides, either: the package "bar" is using Provides: foo and yet it is not, apparently, being considered for dependency fulfillment for other packages in the same project. I'm unclear as to whether or not this behavior is expected.
Please read the whole email at http://lists.opensuse.org/opensuse-buildservice/2007-06/msg00012.html. Michael explains that packages with the exact required name take precedence over packages that provide the dependency.
I see. When combined with what Luke was saying: <quote> Whether it's an expansion error or it picks first depends on if foo and bar have the same precedence. If foo and bar are at the same level, so from the same project or both package found under --prefer-pkgs directories, then they conflict and you get an expansion error. If foo is in the current project (precedence 1), but bar is in a build repository path (precedence 2), then foo wins since the scheduler will pick foo over bar. This is how you can rebuild something like glibc in a project and have everything in the project use that glibc instead of the one from openSUSE:Factory when openSUSE:Factory is a build repository path. </quote> The algorithm is something more like this (excluding duplicate provides), when trying to fulfill a dependency: dependency with exact name available? use that and stop. rpm with provides? use that and stop. go to next repository and repeat. In any case, I guess it doesn't really matter. Ultimately, the OBS is not taking Obsoletes into consideration, and that was the big surprise for me. Thanks for the help! -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (4)
-
Adrian Schröter -
Jon Nelson -
Luke Imhoff -
Michal Marek