[arch-dev-public] Database breakage - again!
belanger at ASTRO.UMontreal.CA
Mon Apr 21 20:09:38 EDT 2008
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:
>> 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:
>> 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 at astro.umontreal.ca> wrote:
> On Mon, 21 Apr 2008, Jason Chu wrote:
> > On Mon, Apr 21, 2008 at 10:12 AM, Eric Belanger
> > <belanger at astro.umontreal.ca> wrote:
> > >
> > > Hi,
> > >
> > > Can you explain what went wrong when I initially submitted the package
> > > 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.
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.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the arch-dev-public