Package Details: clean-chroot-manager 2.222-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.010330
First Submitted: 2013-08-18 16:52 (UTC)
Last Updated: 2022-05-05 18:19 (UTC)

Latest Comments

graysky commented on 2019-10-23 22:28 (UTC)

All - I added support for an external makepkg.conf and pacman.conf in 2.201-1 ... lots of internals changed so please test and use the github page to report any issues.

graysky commented on 2019-10-23 17:42 (UTC)

@artafinde - Yes, ETA 9 min ago :p

artafinde commented on 2019-10-23 08:21 (UTC)

@graysky any ETA on pacman >= 5.2 support? This already hit stable repos today.

graysky commented on 2019-10-16 18:25 (UTC)

I replied to the closed ticket, https://github.com/graysky2/clean-chroot-manager/issues/57

gillecaluim commented on 2019-10-16 18:13 (UTC)

t really doesn’t matter what packages I’m building I have to nuke and create after the first package which completely defeats the purpose of ccm for me

jpapadopoulos commented on 2019-10-16 08:36 (UTC) (edited on 2019-10-16 08:46 (UTC) by jpapadopoulos)

Hi, I'm also getting that error(Failed to stat /repo: No such file or directory) after building llvm-minimal-git and then trying to build mesa-git with "ccm64 S". This happened with a freshly nuked chroot. Trying to use "ccm64 s" for mesa-git instead gives me the following error "Failed to resolve /home/user/Data/chroot/user//home/user/Data/chroot//root/repo: No such file or directory"

https://github.com/graysky2/clean-chroot-manager/issues/57

graysky commented on 2019-10-10 20:59 (UTC)

Please post to the closed github issue, give me the example packages you're building so I can try to recreate.

gillecaluim commented on 2019-10-10 20:14 (UTC)

been there, done that, even removed and reinstalled ccm :(

graysky commented on 2019-10-10 19:09 (UTC)

@gill - Yes, it should be fixed. Can you nuke your build root and try again?

gillecaluim commented on 2019-10-10 18:57 (UTC)

I'm still getting the same problem with stat /repo. System is up to date, devtools = 20190912-1, clean-chroot-manager = 2.97-1 I can build the first package ok, but after that I get Failed to stat /repo You seemed to close the discussion on the github page as if this problem was fixed? If so, how can I fix this?

graysky commented on 2019-09-04 16:49 (UTC) (edited on 2019-09-07 11:35 (UTC) by graysky)

Do you mind taking this to the issue section on github so we don't pollute the AUR page with comments? Steps to reproduce there will be helpful for me to see what you're seeing.

EDIT: https://github.com/graysky2/clean-chroot-manager/issues/57

adsun commented on 2019-09-04 16:30 (UTC) (edited on 2019-09-04 16:31 (UTC) by adsun)

@graysky I nuked the existing chroot: while it works when initially building a first package, the "stat" error starts occurring after the package is added to the repo directory of the chroot for the first time.

adsun commented on 2019-09-04 13:32 (UTC) (edited on 2019-09-04 13:34 (UTC) by adsun)

This needs to be fixed with the new devtools version 20190821. Otherwise: 

Failed to stat /repo: No such file or directory

xuanruiqi commented on 2019-06-17 00:04 (UTC)

The new release now supports chroots on Btrfs!

graysky commented on 2019-01-20 10:10 (UTC) (edited on 2019-01-20 10:10 (UTC) by graysky)

@jtmb - If you follow Arch upstream, update to match.

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pacman&id=c81d3556e03d4b3da79779a4804ba8bf8b127cb3

https://bugs.archlinux.org/task/54736

jtmb commented on 2019-01-19 23:00 (UTC)

I did a little cursory googling, but I was curious the reasoning in updating the CFLAGS in 2.93. Should I update my conf to match the skel? any advantages/disadvantages that we're looking at?

graysky commented on 2018-12-11 04:17 (UTC)

@dmp1ce - I just used the nodev option and I get no errors:

tmpfs  /scratch  tmpfs size=27G,nodev  0  0

dmp1ce commented on 2018-12-11 00:30 (UTC)

I ended up adding a line in /etc/fstab copying what was in tmp.service without the nosuid. Works great!

# Development chroot
tmpfs   /mnt/chroot64   tmpfs   mode=1777,strictatime,nodev,size=8G 0 0

dmp1ce commented on 2018-12-10 23:23 (UTC)

I'm using the tmp.mount mount with systemd to create /tmp. When I set CHROOTPATH64=/tmp/.chroot64 I get the error sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?.

What do you recommend? I would like to use tmpfs because it is much faster for testing builds. Should I edit the tmp.mount file to remove nosuid from /tmp?

graysky commented on 2018-10-25 19:39 (UTC)

@Dark-sky - Glad you're up and running.

Dark-Sky commented on 2018-08-28 14:02 (UTC)

I solved my problem by copying over pacman.conf-pacnew to pacman.conf.

Dark-Sky commented on 2018-08-28 03:29 (UTC) (edited on 2018-08-28 13:51 (UTC) by Dark-Sky)

I tried to follow the directions here:

https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot

I thought I was pretty good w/ copy/paste and decided maybe I was not. So I ran across this package and running into the same issue of it bombing out with a million warnings and nothing getting installed:

[ray@arch chroot64]$ sudo ccm64 c ==> Creating install root at /home/ray/src/chroot64/root ==> Installing packages to /home/ray/src/chroot64/root :: Synchronizing package databases... core 131.4 KiB 684K/s 00:00 [----------------------] 100% extra 1645.2 KiB 1277K/s 00:01 [----------------------] 100% community 4.5 MiB 1555K/s 00:03 [----------------------] 100% multilib 171.7 KiB 1590K/s 00:00 [----------------------] 100% :: There are 26 members in group base-devel: :: Repository core 1) autoconf 2) automake 3) binutils 4) bison 5) fakeroot 6) file 7) findutils 8) flex 9) gawk 10) gcc 11) gettext 12) grep 13) groff 14) gzip 15) libtool 16) m4 17) make 18) pacman 19) patch 20) pkgconf 21) sed 22) sudo 23) systemd 24) texinfo 25) util-linux 26) which

Enter a selection (default=all): resolving dependencies... warning: ignoring package linux-api-headers-4.17.11-1 warning: cannot resolve "linux-api-headers>=4.10", a dependency of "glibc" warning: cannot resolve "glibc", a dependency of "readline" warning: ignoring package linux-api-headers-4.17.11-1

bronek commented on 2018-05-31 09:52 (UTC) (edited on 2018-05-31 09:53 (UTC) by bronek)

@ProfessorKaos64 arch-bootstrap will not build any packages. It will perform a part of the installation of a new ArchLinux system in a bootstrap directory (which later would be the root filesystem of the new system). For this purpose, it will download an earlier prepared minimum set of packages, from a given URL. This package clean-chroot-manager can be used to build packages (on an existing ArchLinux system) which will be used for a subsequent installation of a new system, or (most likely) upgrades. You could use these two packages together to create your own fork of ArchLinux if you were really keen

(I know it is almost a year after the question was asked, but perhaps someone will find this answer useful)

ProfessorKaos64 commented on 2017-07-17 16:21 (UTC)

How does this compare to https://github.com/tokland/arch-bootstrap ?

graysky commented on 2016-08-23 23:05 (UTC)

I will check into this... I use ccm all the time on my i7-4790 (9 threads) and see all 8 cores used up. Isn't the default values for MAKEFLAGS 2? Is the bug causing it to use /etc/makepkg.conf on the live filesystem or the default one installed by pacman?

bronek commented on 2016-08-23 12:38 (UTC) (edited on 2016-08-23 12:43 (UTC) by bronek)

@graysky many thanks for providing this package. I think it had been broken by change in devtools , perhaps this one https://bugs.archlinux.org/task/44827 , which results in makechrootpkg removing MAKEFLAGS set in root/etc/makepkg.conf . The result of this is that THREADS set in ~/.config/clean-chroot-manager.conf is ignored. The working workaround is hinted at in comments to #44827 , which is to create/update ~/.makepkg.conf like this: MAKEFLAGS='-j17' I would suggest that, given the availability of a workaround, the proper fix would be to entirely remove THREADS from ~/.config/clean-chroot-manager.conf and scripts, and instead advice user to create/update ~/.makepkg.conf with MAKEFLAGS option.

francoism90 commented on 2016-04-03 16:18 (UTC) (edited on 2016-04-03 16:19 (UTC) by francoism90)

@graysky: Thanks for your reply. :) I'm compiling firefox-kde; this package does take a lot of time to build, by tweaking makepkg.conf, adding ccache (although I understand it doesn't work), I hope to improve the build time. The package I'm using (kmozillahelper) doesn't have Python2/3 as makedeps, so I just installed it manually to the chroot by using the arch-nspawn command. You are correct this should be corrected in PKGBUILD, but sometimes you may want to install additional packages without having to modify the PKG. :P

graysky commented on 2016-04-03 15:28 (UTC)

CCM doesn't support ccache[1] to the best of my knowledge. You can execute commands within the chroot if you wish and the syntax you proposed is correct. I will consider adding it to the man page. What are you needing to do within the chroot? I'd like to provide an example or 2 but can't really think of anything... 1. https://github.com/graysky2/clean-chroot-manager/issues/23

francoism90 commented on 2016-04-03 15:14 (UTC) (edited on 2016-04-03 15:15 (UTC) by francoism90)

Hi graysky, Thanks for providing this chroot manager. :) Few requests/questions: - Is it useful to add ccache/--threads=0 inside /chroot/path/etc/makepkg.conf? - If I understand correctly, commands in the chroot should be execute like so: sudo arch-nspawn /path/to/chroot64/root <command> If so, could you add it to the readme please. :) Many thanks!

graysky commented on 2016-01-29 20:06 (UTC)

Thanks for reporting. If you don't have a github account, get one (free) as it makes bug tracking better and doesn't pollute the AUR with bug reports.

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

That seems to have done the trick!

graysky commented on 2016-01-29 00:21 (UTC)

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

alpha.niner commented on 2016-01-28 21:46 (UTC) (edited on 2016-01-28 21:54 (UTC) by alpha.niner)

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 (UTC)

@alpha - Sounds good, thanks.

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

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

graysky commented on 2016-01-27 20:56 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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.

alpha.niner commented on 2016-01-26 15:25 (UTC)

$ sudo ccm l ==> Listing out packages in chroot repo... -rw-r--r-- 1 root root 51K Jan 26 10:19 python-configshell-fb-git-1.1.fb19.r0.g7d537ea-1-any.pkg.tar.xz -rw-r--r-- 1 root root 65K Jan 26 10:19 python-rtslib-fb-git-2.1.fb59.r10.g2b12785-1-any.pkg.tar.xz $ sudo ccm S ... error: target not found: python-rtslib-fb-git error: target not found: python-configshell-fb-git ==> ERROR: 'pacman' failed to install missing dependencies. ==> ERROR: Build failed, check /mnt/scratch/service/build $ ls -a /mnt/scratch/service/build . .. $ sudo ccm s <success>

graysky commented on 2016-01-26 13:43 (UTC)

Are the packages in the local repo? What is the output of: ccm l

alpha.niner commented on 2016-01-26 05:04 (UTC)

When I try to build a package with 'ccm S' that depends on packages already built with ccm (also 'ccm S') the build fails: ==> Making package: targetcli-fb-git <snip> ==> Checking runtime dependencies... ==> Installing missing dependencies... error: target not found: python-rtslib-fb-git error: target not found: python-configshell-fb-git ==> ERROR: 'pacman' failed to install missing dependencies. The build succeeds when using 'ccm s'. Note the deps (and the pkg I'm building) are modified-for-git versions of AUR packages so you won't find them anywhere.

graysky commented on 2015-11-14 16:31 (UTC)

Bump to v2.73-1 Changelog: Better distcc integration. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.72...v2.73

ilusi0n commented on 2015-10-10 22:57 (UTC)

@graysky I knew I was missing something stupid. I though I was suppose to do more than building the package. Now that you mention the handling by the localrepo it made me a "click". Yes, it's working fine. Sorry for the confusion.

graysky commented on 2015-10-10 11:42 (UTC)

The whole point of the localrepo in the chroot is to obviate that specific scenario. Build B first. If B is needed to build A it is handled automatically by the localrepo. Is that not working?

ilusi0n commented on 2015-10-10 09:04 (UTC)

graysky, I'm sorry if this question is kinda easy but I didn't find any information on the github or in the man page. Let's imagine that I want to build a package A in the chroot, but that package A has a dependence B that is in the AUR. How do I install the B package in the chroot?

graysky commented on 2015-10-08 19:55 (UTC)

Bump to v2.72-1 Changelog: Better btrfs support. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.70...v2.72

graysky commented on 2015-09-24 15:26 (UTC)

Bump to v2.69-1 Changelog: Support for distcc. Commit:https://github.com/graysky2/clean-chroot-manager/compare/v2.68...v2.69

graysky commented on 2015-07-09 19:37 (UTC)

Bump to v2.68-1 Changelog: Run makechrootpkg at nice 19. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.67...v2.68

graysky commented on 2015-05-14 20:32 (UTC)

Bump to v2.67-1 Changelog: Set threads for new users. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.66...v2.67

graysky commented on 2015-03-29 11:56 (UTC)

Bump to v2.66-1 Changelog: Minor updates to man page. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.65...v2.66

graysky commented on 2015-02-05 22:53 (UTC)

Bump to v2.65-1 Changelog: Add zsh-completion and cosmetic fix-up of Makefile. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.64...v2.65

graysky commented on 2015-01-27 12:33 (UTC)

Bump to v2.64-1 Changelog: Fix user detect under tmux and urxvt. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.61...v2.64

graysky commented on 2015-01-24 16:07 (UTC)

Bump to v2.62-1 Changelog: Minor note added to skel. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.61...v2.62

graysky commented on 2015-01-15 21:37 (UTC)

Execute commands in the chroot? This package merely controls the devtools scripts for building in a clean environment... what you want is out of scope. I believe you want a totally separate package for that called schroot. See the wiki. https://wiki.archlinux.org/index.php/Schroot EDIT: wait, guess we need to define what you wanna do... just doing operations in the clean-chroot can be done as you posted below I believe... if however you wanna have a sandbox in a chroot, and run something from within it, that is what schroot can do.

ceri commented on 2015-01-15 21:33 (UTC)

@graysky That works too, but I wanted to figure out how to execute commands in the chroot in any case.

graysky commented on 2015-01-15 20:58 (UTC)

I have a line in /etc/fstab setting up the tmpfs: tmpfs /scratch tmpfs nodev,size=28G 0 0 And I have systemd create the two dirs for me with /etc/tmpfiles.d/tmpfs_dirs.conf which contains: d /scratch/.chroot64 0755 facade users - d /scratch/.chroot32 0755 facade users -

coderkun commented on 2015-01-15 16:27 (UTC)

graysky: How do you set the tmpfs up and make sure that it is built at boot?

graysky commented on 2015-01-15 15:22 (UTC)

Or just nuke and rebuild your chroot.. My system has quite a bit of RAM so I actaully put $CHROOT in tmpfs which is good for several reasons, speed, no wear to my ssd, and it always gets built freshly when I reboot.

ceri commented on 2015-01-15 13:06 (UTC)

To fix the following error (after the major pacman update): error: failed to initialize alpm library (database is incorrect version: /var/lib/pacman/) error: try running pacman-db-upgrade Run the following: arch-nspawn $CHROOT/root pacman-db-upgrade (specify or change $CHROOT to your chroot)

graysky commented on 2015-01-07 14:53 (UTC)

@BeepDog - OK. For tmux to work, it requires a patch from tmux-git. I opened a FS asking for it to be included in the official package[1], but you can try it from the files in the FS yourself or build tmux from git and have libutempter installed before compiling it. 1. https://bugs.archlinux.org/task/43368

graysky commented on 2015-01-06 20:49 (UTC)

Scratch that... thought I had it working but cannot get it to work now :/ Also: https://github.com/graysky2/clean-chroot-manager/issues/10

BeepDog commented on 2015-01-04 22:46 (UTC)

So this is super awesome, I only discovered it today, however it's being super frustrating to me. it always fails with: "==> ERROR: Cannot determine your username so exiting." if I run it within tmux. That's super annoying, and I thought I'd let you know about it, because I do most of my operations in a tmux. :( Thanks!

graysky commented on 2014-11-17 20:05 (UTC)

Bump to v2.61-1 Changelog: Added option to delete local repo and minor clean up of option screen. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.60...v2.61

graysky commented on 2014-11-17 12:31 (UTC)

Bump to v2.60-1 Changelog: Improve script exit codes/chroot failure detection. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.59...v2.60

graysky commented on 2014-11-13 00:20 (UTC)

Bump to v2.59-1 Changelog: add the 'S' switch to build without cleaning the chroot. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.58...v2.59

graysky commented on 2014-11-09 04:11 (UTC)

Bump to v2.58-1 Changelog: added colorized diagnostics and fixed a few cosmetic errors. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.57...v2.58

graysky commented on 2014-09-23 23:29 (UTC)

Bump to v2.57-1 Changelog: packages built by up the user in the local repo take priority over repo packages. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.56...v2.57

graysky commented on 2014-06-09 22:01 (UTC)

Bump to v2.56-1 Changelog: Added option for custom CFLAGS on chroot creation. Commit: https://github.com/graysky2/clean-chroot-manager/compare/v2.55...v2.56

graysky commented on 2014-05-04 12:19 (UTC)

Bump to v2.55-1 Changelog: Break on logname failure.