Arch Linux User Repository

That seems to have done the trick!

I see what's wrong. Please try 2.75 which should work in either case.

It works when I use 'ccm <capital es>' to build targetcli-fb-git and the second of the deps (regardless of the order I build the deps). If I don't build the second dep with <capital es> it isn't found when attempting to build t-f-g.

In my case it doesn't make sense to build the second without <capital es>. But in a case where an AUR pkg had one AUR dep, someone might build the dep with <little es> and it wouldn't be found when building the dependent pkg with <capital es>. I confirmed this by modifying the PKGBUILD of t-f-g to only require one of the two, nuked and re-created the chroot, then tried to build t-f-g with <capital es> after building the dep with <little es>. So there's no confusion, it failed because the dep I'd just built couldn't be found:

$ sudo ccm n
$ sudo ccm c
...
$ sudo ccm s
...
==> Making package: python-rtslib-fb-git 2.1.fb59-1
...
$ cd ../targetcli-fb-git
$ sudo ccm S
...
==> Installing missing dependencies...
error: target not found: python-rtslib-fb-git
==> ERROR: 'pacman' failed to install missing dependencies.
...

@alpha - Sounds good, thanks.

Thanks, I'll try it out before the end of the day.

@alpha - Would you trying version 2.74? Please modify this PKGBUILD to that pkgver, update the sums and build. I don't want to bump formally to 2.74 until I get some feedback from you. In my test cases, it seems to solve the issue.

As an interim solution I just modified the buildnc function to cp the necessary things from $CHROOTPATH64/root to $CHROOTPATH64/$USER. I didn't realize at first that pacman.conf may also need updating.

@@ -247,6 +247,11 @@
local mesg="Attempting to build package..."
echo -e "${YELLOW}---->${ALL_OFF}${BOLD} ${mesg}${ALL_OFF}"

+ local mesg="Updating user chroot local repo..."
+ echo -e "${YELLOW}---->${ALL_OFF}${BOLD} ${mesg}${ALL_OFF}"
+ /usr/bin/cp -a "$CHROOTPATH64/root/etc/pacman.conf" "$CHROOTPATH64/$USER/etc"
+ /usr/bin/cp -a "$CHROOTPATH64/root/repo/" "$CHROOTPATH64/$USER"
+
if [[ -z "$RUNNAMCAP" ]]; then
nice -19 $CHROOTPATH64/root/makechrootpkg-mod -u -r $CHROOTPATH64
else

Yes, I couldn't read the difference between s and S on my phone when I saw your original post and that error propagated... perhaps adjusting that behavior when calling with the S (capital S) option would be in order here... That would be two calls to update as I think through it thought... one to $CHROOTPATH64/root/repo and another to $CHROOTPATH64/$USER/repo or perhaps an rsync call or the like.

I don't think it's anything to do with my PKGBULIDs.

Looking at the script (specifically clean-chroot-manager64) it seems that building packages updates the local repo at "$CHROOTPATH64/root/repo" but not "$CHROOTPATH64/$USER/repo". It's running makechrootpkg-mod with -c that causes "$USER/repo" to be 'updated', and of course -c is the "clean" flag so it's not used when makechrootpkg-mod is called in the case of 'ccm S'.

Not sure what to say... is there something odd in the respective PKGBUILD files for the git packages such that they wouldn't be visible as providing themselves? I cannot find any of these three in the AUR so I am assuming you modified them for your needs.