Mailinglist Archive: opensuse-buildservice (182 mails)

< Previous Next >
Re: [opensuse-buildservice] Why do I keep getting "spec file conflicts?
  • From: Dave Plater <dplater@xxxxxxxxxxxxxxxx>
  • Date: Tue, 23 Feb 2010 11:33:37 +0200
  • Message-id: <4B83A0F1.5070206@xxxxxxxxxxxxxxxx>
On 02/22/2010 09:53 PM, Tejas Guruswamy wrote:
On 22/02/10 16:53, Dave Plater wrote:

Hi, I keep on getting spec file conflicts when I work on my branch
project and in this case the main contrib project. This is getting very
frustrating as it is happening ATM while I'm trying to get to the bottom
of a difficult gcc45 build problem. It seems that I am unable to alter
the branch project online, in this case load the development tarball
directly into the branch project. As I've explained previously, I have
limited internet cap.
Can somebody please explain what a "spec file conflict" is and what it
is supposed to achieve because all it achieves with me is frustration.
The last time I asked for help nobody seemed to be able to.
Maybe somebody wishes to take over lilypond because with no help from
upstream and this list, it takes up too much of my time.
Regards
Dave P


As I understand it (with the proviso that IANA Build Service developer)

When you make a branch of a project, the server actually keeps the diff
between the two projects rather than keeping two copies of the source.
So on the server in the original project there is a full copy of the source
and on the server in the branch there is a link file and a diff of all
the changes that have been made relative to the original.
Not sure how the new vs old types of branches fit in but anyway.

What this means is if the original project sources change, the diff
might no longer apply cleanly - there might be a conflict. In this case,
the original project's spec file changed so your branch diff no longer
works. The build service then complains "file conflict" and the branch
package fails to build.

Looking at your project (I assume its this one:
home:plater:branches:openSUSE:Factory:Contrib) it looks like you were
able to resolve the conflict.
The only way that I was able to resolve the conflict was to delete and
recreate the branch, "osc resolved {file}" didn't help and osc pull fails.


IIRC the way to do this is to use "osc
pull"; do fix the conflicts in {file}; "osc resolved {file}" until no
more conflicts are left; then "osc ci -m"Fixed conflicts".

osc pull gives the following "osc pull only works on expanded links"
What I find odd is why you should be having so much problem with these
conflicts. Is someone else besides you working on the package? If its
only you, remember to only alter the branch project.
I'm the maintainer of the main project and am using the branch project
to compare the development version of lilyponds build with the
openSUSE:Contrib stable build. I had altered the main spec file prior to
using the web interface to load the development tarball into the branch
project. So yes there are two people working on the file, both of them
are me.
If you make
different changes in each then obviously you'll get conflicts. And to
move over your changes from the branch to the original, if you move the
modified files from the branch to the original - that will cause a
conflict, because the branch diff still exists except now the original
changed. Basically, after doing an "osc copypac" or a "osc sr" to get a
full server-side copy of all the changes from branch to original, delete
and remake the branch to rebase it on the new source.

Regards,
Tejas


I think that using a linked copy instead of a branch would be the better
way of doing what I'm doing, it's a pity that osc doesn't have a
mechanism to resolve this automatically because I like to be able to use
the branch method in cases like this because I can see all of the files
in the package in both projects.
I just altered the spec file in the main project and I have a conflict
in the branch project again. My personal opinion is that something is
wrong with the system but when using a tool one has to use it in the way
it's designed to be used. I'm trying to resolve a very frustrating gcc45
build problem (I have a conflict between upstream and os-packaging) so I
wish to avoid adding to that frustration with osc problems.
While writing this message, I've found a solution to my problem :-)
I deleted the link in the branch project package using the web interface
and all is now well. If somebody wishes to improve on this usability
problem I have had, I can most probably recreate it but for now I'm happy.
Thank you for taking the time to explain the spec file conflict, I've
asked on this list for help with this for more than a week.
I have one more question, when I used osc up on the branch before
deleting the link, osc replied :-
osc up
U _link
A lilypond-2.12.3-gcc45fix.patch
'NoneType' object has no attribute 'md5

The above patch was previously enabled in the main spec file. Next :-
osc st
? lilypond-2.13.13
D lilypond-2.12.3.tar.gz
M lilypond.changes
M lilypond.spec

Next :-
osc pull
Please commit your local changes first!

Then :-
osc up
G lilypond.spec
At revision 4.

Then :-
osc st
? lilypond-2.13.13
D lilypond-2.12.3.tar.gz
M lilypond.changes

What does the G in "G lilypond.spec" mean?
Thanks again for your help.
Dave P
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >