On Mon, 21 Apr 2008, Thomas Bächler wrote:
Eric Belanger schrieb:
Inconsistency: firefox3 3.0b4-1 vs. firefox3-3.0b5-1-x86_64.pkg.tar.gz Inconsistency: bmpx 0.40.13-1 vs. bmpx-0.40.13-2-i686.pkg.tar.gz Inconsistency: bzr 1.3-1.1 vs. bzr-1.3-1-x86_64.pkg.tar.gz Inconsistency: darcs 1.0.9-1 vs. darcs-2.0.0-1-x86_64.pkg.tar.gz Inconsistency: pidgin 2.4.0-1 vs. pidgin-2.4.1-1-x86_64.pkg.tar.gz
I tried again to fix bmpx but it idn't work: http://archlinux.org/pipermail/arch-dev-public/2008-April/005883.html
The others are packages that I built for x86_64. For reasons I don't know, something went wrong. I asked for help on this ML: http://archlinux.org/pipermail/arch-dev-public/2008-April/005798.html http://archlinux.org/pipermail/arch-dev-public/2008-April/005726.html
So far no response. Can anyone explicitly explain how to fix these things? I don't know snv and don't want to break the repos further.
I wonder if the problem isn't that the other dev modified the files in repos/extra/i686 instead of trunk...
First of all, before you try to change anything, run "svn up" in the $pkgname directory, that should solve most of your problems. If there are conflicting files (C), delete them, do it again. If there are conflicting files with modifications you need, move them away, "svn up", copy them back (not clean, but works).
About the "nothing to commit", maybe setting "svnmerge init" on the directory containing the PKGBUILD helps. For anything else, let Aaron help you ...
All these things are fixed now thanks to Jason's help. Here is his explanation why these inconsistencies happened and how to fix them: ====================================== On Mon, Apr 21, 2008 at 1:21 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Mon, 21 Apr 2008, Jason Chu wrote:
On Mon, Apr 21, 2008 at 10:12 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
Hi,
Can you explain what went wrong when I initially submitted the package
for
x86_64 (if it's possible to tell) and how did you fixed it?
Thanks, Eric
Actually, this was entirely not your fault. It had to do with how we created the original repo. Basically there are three directories, extra-i686, extra-x86_64, and trunk. These directories are related by the svnmerge properties that are set.
Because we don't exactly have enough information to describe the differences between extra-i686 and extra-x86_64 in trunk, I took a shortcut when setting up the svnmerge info. I told svnmerge that extra-i686 and extra-x86_64 both had merged the same information from trunk. The problem exists when they hadn't (like in this case). svnmerge figured that there wasn't anything to actually change, even though there was. I made the change by hand in extra-x86_64 and made sure that svnmerge knew that things were more correct.
We will run into these problems a little more before they all but go away. As updates and fixes are cleaned up like this, they won't happen again because the correct information will be tracked by svnmerge.
Jason
Thanks for the explanation.
But could you be more specific on the procedure to fix these inconsistencies? I assume that you copied the trunk PKGBUILD to unstable-x86_64 then you ran some commands. Is that correct? What specific command lines did you used and in what directories did you ran them? I don't know svn except the very basic info that trickled on the ML (svn add, rm and commit). There are several other packages with that problem currently. I would like to be able to fix them and fix any future problems.
Thanks, Eric
Sure, ok. Yeah, you have to copy the PKGBUILD (and any other files that differ) that you wanted from trunk to repos/extra-x86_64. If files are in trunk that aren't in repos/extra-x86_64 you'll have to svn add them (svn status will show those files as '?' before and 'A' after). Then just svn commit the change. That's all you really need to do. Jason ====================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.