Package Details: clean-chroot-manager 2.209-1

Git Clone URL: https://aur.archlinux.org/clean-chroot-manager.git (read-only, click to copy)
Package Base: clean-chroot-manager
Description: Wrapper for managing clean chroot builds with local repo therein.
Upstream URL: https://github.com/graysky2/clean-chroot-manager
Licenses: MIT
Conflicts: clean_chroot_manager
Replaces: clean_chroot_manager
Submitter: graysky
Maintainer: graysky
Last Packager: graysky
Votes: 57
Popularity: 0.018960
First Submitted: 2013-08-18 16:52
Last Updated: 2020-06-21 12:17

Dependencies (4)

Required by (0)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

alpha.niner commented on 2016-01-29 17:33

That seems to have done the trick!

graysky commented on 2016-01-29 00:21

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

alpha.niner commented on 2016-01-28 21:46

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.
...

graysky commented on 2016-01-28 18:59

@alpha - Sounds good, thanks.

alpha.niner commented on 2016-01-28 14:33

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

graysky commented on 2016-01-27 20:56

@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.

alpha.niner commented on 2016-01-26 21:18

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

graysky commented on 2016-01-26 20:44

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.

alpha.niner commented on 2016-01-26 20:35

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'.

graysky commented on 2016-01-26 19:57

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.