What command can be used, beside 'osc commit', to trigger a reevaluation of prjconf? If a pkg is in state "unresolvable" after commit, and the prjconf gets changed to solve the dependency no rebuild happens. A local 'osc build' works, but 'osc wipebinaries -r <repo>' or 'osc rebuild -f' will still use the previous state of prjconf.
Olaf
Olaf Hering olaf@aepfle.de writes:
What command can be used, beside 'osc commit', to trigger a reevaluation of prjconf?
Wait for the scheduler to come along.
Andreas.
On Tuesday 2015-12-15 14:48, Olaf Hering wrote:
What command can be used, beside 'osc commit', to trigger a reevaluation of prjconf?
osc meta prjconf -e
and add a blank line :p
On Tue, Dec 15, Jan Engelhardt wrote:
On Tuesday 2015-12-15 14:48, Olaf Hering wrote:
What command can be used, beside 'osc commit', to trigger a reevaluation of prjconf?
osc meta prjconf -e
and add a blank line :p
Thanks. But see thr "If a pkg is in state "unresolvable" after commit, and the prjconf gets changed to solve the dependency no rebuild happens."
Olaf
On Tuesday 2015-12-15 16:18, Olaf Hering wrote:
On Tue, Dec 15, Jan Engelhardt wrote:
On Tuesday 2015-12-15 14:48, Olaf Hering wrote:
What command can be used, beside 'osc commit', to trigger a reevaluation of prjconf?
osc meta prjconf -e
and add a blank line :p
Thanks. But see thr "If a pkg is in state "unresolvable" after commit, and the prjconf gets changed to solve the dependency no rebuild happens."
Another way of kicking the scheduler into reevaluation is changing the set of <path>s, like adding a path to an empty project with no <path>s itself.
Hey,
On 15.12.2015 16:18, Olaf Hering wrote:
But see thr "If a pkg is in state "unresolvable" after commit, and the prjconf gets changed to solve the dependency no rebuild happens."
How about you create a bug report or better a pull-request? :-)
Henne
On 12/15/2015 10:47 AM, Henne Vogelsang wrote:
Hey,
On 15.12.2015 16:18, Olaf Hering wrote:
But see thr "If a pkg is in state "unresolvable" after commit, and the prjconf gets changed to solve the dependency no rebuild happens."
How about you create a bug report or better a pull-request? :-)
Henne
Apologies for dredging up an old thread.
Why is it more right to jump to the conclusion that it's a bug in need of a bug report, before asking if it even is a bug?
He really asked if there was a re-eval command, which seems like a perfectly reasonable question to start with. If the answer turns out to be "no such command exists", so what? How could he know that *before* finding out?
His response here is also quite rationally pointing out that the suggestion to edit the file was nonsensical, since he already said the file was edited.
Basically, to me it looks like you treated him like someone making demands, when he made no demands. Shall I add a disingenuous smiley too? No.
I don't have patience for people who expect me to do work for free just so they don't have to bother doing something they could and should do for themselves either, but if you are going to be intolerant like that (as I admit I am too), then you obligate yourself to be correct yourself, and only chastise the deserving.
On Sonntag, 7. Februar 2016, 23:17:59 CET wrote Brian K. White:
On 12/15/2015 10:47 AM, Henne Vogelsang wrote:
Hey,
On 15.12.2015 16:18, Olaf Hering wrote:
But see thr "If a pkg is in state "unresolvable" after commit, and the prjconf gets changed to solve the dependency no rebuild happens."
How about you create a bug report or better a pull-request? :-)
Henne
Apologies for dredging up an old thread.
Why is it more right to jump to the conclusion that it's a bug in need of a bug report, before asking if it even is a bug?
He really asked if there was a re-eval command, which seems like a perfectly reasonable question to start with. If the answer turns out to be "no such command exists", so what? How could he know that *before* finding out?
Yes, sorry. It is currently a wanted behaviour by design. Therefore Olaf is right to complain. Question is if we want to tackle this via an extra command or via a behaviour change of the scheduler. That needs some discussion ...
His response here is also quite rationally pointing out that the suggestion to edit the file was nonsensical, since he already said the file was edited.
Basically, to me it looks like you treated him like someone making demands, when he made no demands. Shall I add a disingenuous smiley too? No.
I don't have patience for people who expect me to do work for free just so they don't have to bother doing something they could and should do for themselves either, but if you are going to be intolerant like that (as I admit I am too), then you obligate yourself to be correct yourself, and only chastise the deserving.
Henne tried to involve more parties and the bug report would avoid that the issue get's lost. I can tell that it is a known issue, but the solution is not obvious, so the chances are high that a mail on a mailing list will not finally lead to a solution...
good morning :) adrian
Hey Brian,
On 08.02.2016 05:17, Brian K. White wrote:
On 12/15/2015 10:47 AM, Henne Vogelsang wrote:
On 15.12.2015 16:18, Olaf Hering wrote:
But see thr "If a pkg is in state "unresolvable" after commit, and the prjconf gets changed to solve the dependency no rebuild happens."
How about you create a bug report or better a pull-request? :-)
Why is it more right to jump to the conclusion that it's a bug in need of a bug report, before asking if it even is a bug?
Olaf pointed out that this situation is obviously a bug in the work flow. I've tried to remind him that bug reports here get lost and tried to encourage him to report it. Or better yet fix it himself as I know he's more than capable to do this.
The rest is your somewhat far out interpretation.
Henne
buildservice@lists.opensuse.org