Package Details: arch32-light 2015-1

Git Clone URL: (read-only, click to copy)
Package Base: arch32-light
Description: Lightweight 32-bit chroot intended for 64-bit systems.
Upstream URL:
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
Last Updated: 2015-06-21 02:27

Latest Comments

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

Xyne commented on 2012-10-25 02:11

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.

Anonymous comment on 2012-10-24 16:50

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

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

Xyne commented on 2012-10-22 17:58

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

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

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

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
+++ 2012-10-19 13:59:17.476326093 -0400
@@ -6,7 +6,7 @@
-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')
backup=(etc/arch32.conf etc/arch32d.conf)

Xyne commented on 2012-09-03 22:11

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

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

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.