Package Details: arch32-light 2015-2

Git Clone URL: https://aur.archlinux.org/arch32-light.git (read-only, click to copy)
Package Base: arch32-light
Description: Lightweight 32-bit chroot intended for 64-bit systems.
Upstream URL: https://xyne.dev/projects/arch32-light
Keywords: arch_linux system
Licenses: GPL
Conflicts: arch32
Submitter: Xyne
Maintainer: Xyne
Last Packager: Xyne
Votes: 47
Popularity: 0.000000
First Submitted: 2010-05-23 02:42 (UTC)
Last Updated: 2021-11-18 23:54 (UTC)

Latest Comments

commented on 2015-06-04 11:39 (UTC)

pacman32 needs #!/bin/bash too

Xyne commented on 2014-08-08 04:15 (UTC)

@Alad The necessary packages should be installed by the user in the chroot. arch32d.conf should only be used to copy configuration files that the user wishes to keep synchronized with the host.

Alad commented on 2014-08-07 07:29 (UTC)

Note that without /usr/lib/locale/* in the chroot (arch32d.conf), setlocale fails in the chroot.

Xyne commented on 2013-03-01 07:35 (UTC)

arch32.conf now includes 2 new variables for configuring the pacman32 helper script. PACMAN32BIN can be used to set the pacman binary to anything that supports the pacman options used in pacman32 (e.g. powerpill). PACMAN32ARGS is an array of extra static arguments to pass to pacman32. By default it includes the host pacman package cache. This allows pacman32 to re-use "any" packages that it finds there instead of downloading them again. It will not save any packages in the host cache.

Xyne commented on 2013-01-31 15:44 (UTC)

The sources have been restored.

Dirk commented on 2013-01-30 19:54 (UTC)

HTTP 404 for arch32-light-2012.12.31.tar.xz

Xyne commented on 2013-01-11 00:16 (UTC)

@wolfjb It works fine on my system and I don't even have initscripts installed. I suspect that you are still trying to use /etc/rc.d/arch32d. You should be using /usr/bin/arch32m instead for manual management and the arch32.service for automatic startup. Unless you provide more information about how you are using it, what it is doing and what you expect it to do, I really have no idea what the problem is.

wolfjb commented on 2013-01-08 16:50 (UTC)

still seems to depend on rc scripts, maybe those need to be ported? I basically converted them all to either 'echo' or 'exit' depending on what seemed to be going on in the script at the time.

Xyne commented on 2013-01-02 08:07 (UTC)

It's only playing dead. Kick it a few times and you'll hear it yelp.

ngoonee commented on 2013-01-01 23:43 (UTC)

Link for this looks dead from here as well.

ngoonee commented on 2012-12-03 23:43 (UTC)

@dsohler - arch32-light.install has no reference to any rc, and the only mention of initscripts is 'still provided but will likely be removed in the future'. If (as I suspect) you're talking about the build() section of the PKGBUILD, then please go learn more about Arch, PKGBUILDs, and packaging first. @Xyne - while checking this out, I realize you've got two vim modelines at the bottom of the PKGBUILD, probably an artifact of your json-generation system or something?

Xyne commented on 2012-12-03 18:39 (UTC)

@dsohler >The install script is all about initscripts and rc stuff. Explain what you mean and make some suggestions. Nebulous statements and abusing the "flag out-of-date" function is not the way to get me to change anything.

Dirk commented on 2012-12-03 11:02 (UTC)

The complete package should be updated to systemd, not only the service file. The install script is all about initscripts and rc stuff.

Xyne commented on 2012-11-25 04:25 (UTC)

@freethinker arch32initialize should change the architecture to i686 when it initialized the chroot. @everyone I have added a service file and a new executable (arch32m: m for manager). I am in the process of converting to systemd so I haven't actually tested the service yet. Feedback would be appreciated. The manager takes over the daemon's functionality (mounting, unmounting, synchronizing files). The man pages probably need to be updated as well. Remind me in a few days if I forget.

commented on 2012-11-14 19:33 (UTC)

Not sure if this is mentioned anywhere in the documentation, but on a 64 bit system, change the 'Architecture = auto' to 'Architecture = i686' in /opt/arch32/etc/pacman.conf for installing packages using pacman from within the chroot environment.

dlin commented on 2012-11-06 12:55 (UTC)

will this support sytemd? As I know systemd will replace sysvinit in Jan. 2013.

Xyne commented on 2012-10-25 16:53 (UTC)

I honestly don't remember. I think the arch32 package installs a full base system whereas this one leaves everything up to the user (see the 32-bit chroot wikipage). I think that I also provide more functionality in the daemon and configuration files, plus the code is more robust and handles cases cleanly.

Schala commented on 2012-10-25 16:06 (UTC)

Can I ask what the difference is to the arch32 package? They seem the same, just that the other's older.

Schala commented on 2012-10-25 03:07 (UTC)

I'm casting my vote. Combined with the devtools package, this can really help out package maintainers

Xyne commented on 2012-10-25 02:11 (UTC)

@Thrall Sorry, that's my fault. I don't remember when exactly, but sometime in the past few weeks to months I made some minor tweaks to the configuration file and wondered if the nested mountpoints were useful (e.g. '/dev' '/dev/pts' '/dev/shm'), so I took them out and did some minimal testing. Everything seemed to work so I concluded that they were unnecessary. Culpa mea. I'll have to look into why that doesn't work one day, out of curiosity if nothing else.

commented on 2012-10-24 16:50 (UTC)

Not sure to what extent this might be user error, etc., but: After switching to systemd, I got: error: GPGME error: Inappropriate ioctl for device whenever I try to install/upgrade a package using pacman inside the chroot. I solved this by adding /dev/pts to ARCH32MOUNT in /etc/arch32d.conf . I believe /dev/pts was once listed in the defaults (As a matter of fact, the arch32-light man page still lists it as default). Is there a good reason why it is no longer a default in arch32d.conf? I can't help wondering if there are others in my situation who might benefit from a line of explanation about /dev/pts in this file (assuming mounting /dev/pts is the correct solution?).

ngoonee commented on 2012-10-23 00:33 (UTC)

Hey, you don't owe any of us anything =). RL comes first, after all.

Xyne commented on 2012-10-22 17:58 (UTC)

I did make it an optdep at first, but then I noticed that the daemon sources the file so I changed it to a dep instead. I really am sorry about the delay for the unit files. My life has been hectic lately and I haven't had the time to risk system breakage with the systemd upgrade, let alone write the files themselves (yeah, it will probably be smooth, but I would be deeply f*#%@$ if I borked the system right now).

ngoonee commented on 2012-10-21 23:40 (UTC)

Ah, I was hoping the update included a systemd service file. Technically speaking, isn't initscripts an optdep? I'm using a pure systemd system and it seems my simple ExecStart=/etc/rc.d/arch32d start service file works fine without initiscripts....

Xyne commented on 2012-10-21 20:31 (UTC)

@mmendez done, thanks Incidentally, I can't use patches for my own packages because the PKGBUILDs are generated from my own custom JSON files.

mmlb commented on 2012-10-19 18:00 (UTC)

Can you add initscripts to the depends array so that pure systemd users will be ok. --- PKGBUILD 2012-10-19 13:59:49.636336560 -0400 +++ PKGBUILD.new 2012-10-19 13:59:17.476326093 -0400 @@ -6,7 +6,7 @@ arch=(any) license=(GPL) url="http://xyne.archlinux.ca/projects/arch32-light" -depends=(diffutils 'pacman>=3.4.0' 'pacman-mirrorlist>=20100621') +depends=(diffutils 'pacman>=3.4.0' 'pacman-mirrorlist>=20100621' initscripts) optdepends=('xorg-xhost: for host xorg support') conflicts=(arch32) backup=(etc/arch32.conf etc/arch32d.conf)

Xyne commented on 2012-09-03 22:11 (UTC)

I plan to create service files for all of my packages right after I convert to systemd, which I hope to do in a few days. I can't guarantee any timeframe though, only that it's creeping up on my todo list.

ngoonee commented on 2012-09-03 09:18 (UTC)

Thanks, just wanted to confirm that was the only change. Doesn't seem to cause any problems (the old way) for me so I'll keep that for now. On a separate note, I guess it'd be too much work to convert /etc/rc.d/arch32d to a systemd service?

Xyne commented on 2012-09-03 09:02 (UTC)

@ngoonee I removed nested mountpoints from the default ARCH32MOUNT array in /etc/arch32d.conf. For example, the previous array included "'/proc', '/proc/bus/usb'". It now only includes "'/proc'". Check if the upgrade created /etc/arch32d.conf.pacnew and either merge the changes (i.e. remove the nested mountpoints) or just delete the pacnew file if everything works as is. I removed the nested mountpoints because I saw no reason to keep them and because I recently encountered an error with them. I only added them initially because the first version of this package was just an encapsulation of what was in the wiki. I never gave it any thought until now.

ngoonee commented on 2012-09-03 02:18 (UTC)

Hi Xyne, saw this update, just wondering what's been updated?

ngoonee commented on 2012-02-09 12:44 (UTC)

Hi Xyne, I haven't used chroots in a while since [multilib] came out but now I need one for testing some software and I realize /etc/rc.d/arch32d doesn't actually unmount anything. The problem is that line 1 (picked out from $_mounted) doesn't contain line 2 (which is what its being tested with, $_mountline). Any suggestions? For now I just remove the test, but of course that's a bad idea (tm). Line 1 - ::proc on /home/arch32/proc type proc (rw,nosuid,nodev,noexec,relatime):: Line 2 - ::/proc on /home/arch32/proc type none (rw,bind)::

commented on 2011-07-31 03:02 (UTC)

@codeinject Same problem on me by using bash. I fix the problem by replacing 'x86_64' to '$arch' in /etc/pacman.d/mirrorlist You might check whether the archecture is hard coded in the file.

Xyne commented on 2011-07-18 23:17 (UTC)

@codeinject The error seems to be generated by pacman itself. It's invoked at the end of the pacman32 script, after which any errors are a pacman issue. If you find anything that zsh can't handle before that (including anything in arch32.conf), let me know and I'll try to find a solution that works in both bash and zsh.

commented on 2011-07-17 23:22 (UTC)

Small bug report: :: I use zsh for root and user. :: When I do the following: root% pacman32 -Sy bash coreutils filesystem grep gzip licenses sed I get: :: Starting Arch32 Daemon [DONE] :: Synchronizing Files [DONE] non-network local connections being added to access control list :: Synchronizing package databases... core 35.6K 245.0K/s 00:00:00 [############################################] 100% extra 466.9K 792.7K/s 00:00:01 [############################################] 100% community 445.9K 766.6K/s 00:00:01 [############################################] 100% :: But then I get the following message: error: failed to prepare transaction (package architecture is not valid) :: package bash-4.2.010-1-x86_64 does not have a valid architecture :: package coreutils-8.12-3-x86_64 does not have a valid architecture :: package grep-2.9-1-x86_64 does not have a valid architecture :: package gzip-1.4-2-x86_64 does not have a valid architecture :: package sed-4.2.1-3-x86_64 does not have a valid architecture Not 100% sure if its a bug or my own stupidity that overlooked something. Just a light heads up that not everybody uses bash. I'll look for what happened exactly tomorrow.

Xyne commented on 2010-12-23 19:21 (UTC)

fixed

waxar commented on 2010-12-23 09:04 (UTC)

Error while trying to install the package with the above tarball. ==> Retrieving Sources... -> Downloading arch32-light-2010.11.14.1.tar.gz... --2010-12-23 12:02:48-- http://xyne.archlinux.ca/src/arch32-light-2010.11.14.1.tar.gz Resolving xyne.archlinux.ca... 69.89.25.172 Connecting to xyne.archlinux.ca|69.89.25.172|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2010-12-23 12:02:49 ERROR 404: Not Found. ==> ERROR: Failure while downloading arch32-light-2010.11.14.1.tar.gz Aborting...

Xyne commented on 2010-09-22 14:05 (UTC)

I've created a utilities package for arch32-light: http://xyne.archlinux.ca/projects/arch32-light-utils/ Contributions and suggestions are welcome. :)

stativ commented on 2010-08-23 06:12 (UTC)

Xyne: thanks

Xyne commented on 2010-08-23 00:10 (UTC)

@stativ I've bypassed `whoami` and used '[ "$EUID" == "0" ]' instead. :)

stativ commented on 2010-08-22 19:23 (UTC)

Could you use `whoami` instead of $USER when checking whether the user is root in arch32initialize? When I use su to switch to root the $USER still contains the name of the casual user.

Xyne commented on 2010-08-18 21:02 (UTC)

I've made several important changes. You can find a changelog on the project page.

Xyne commented on 2010-08-18 03:35 (UTC)

added missing "d" to message ;)

Svenstaro commented on 2010-08-18 02:31 (UTC)

Install script says '-> You should probably add "arch32" to your DAEMONS array in /etc/rc.conf too.' but the daemon is actually named arch32d. Is this a bug?

Xyne commented on 2010-06-24 04:05 (UTC)

Thanks, Pete. I've updated the install script. I've also added "--arch i686" to the pacman32 script to be sure. Existing installations will require intervention to set the architecture. A warning should be displayed during the upgrade. I'll eventually remove /opt/arch32/etc/pacman32.d/mirrorlist and use the default one now that it supports "$arch".

shetland_breeder commented on 2010-06-23 21:22 (UTC)

Sorry, Meant the arch-light.install script ;) Pete

shetland_breeder commented on 2010-06-23 21:18 (UTC)

The arch32.install script no longer works with pacman 3.4.2. The mirrorlist uses the $arch variable intead of having the architecture hardwired. Instead the Architecture = auto line in pacman.conf should be changed to Architecture = i686 in /opt/arch32/etc/pacman.conf and the mirrorlist just copied across Pete

Xyne commented on 2010-05-29 07:17 (UTC)

What's the output of "sudo which chroot"?