Pkgadd taking a long time to install
by budrz89 from LinuxQuestions.org on (#5509T)
Hi,
I'm trying to install CRUX's pkgutils as my package manager for my LFS project, version 9.1, sysvinit. Using the original Pkgfile for pkgutils-5.40.7 as a template, I copied and pasted the commands shown in chapter 6.7 "Linux API Headers" into the "build" function and executed "pkgmk" to build the package. The pkgmk executed successfully but issuing pkgadd to it is taking a long time (more than 25 minutes) and I'm not sure why. It actually appears to be stuck.
Some packages that I've installed to my temporary system in addition to the LFS packages:
Code:Berkeley DB 5.3.28
util-linux 2.35.1
zlib 1.2.11
libarchive 3.4.2
libcap 2.31
pkg-config 0.29.2
fakeroot 1.24I also wanted to mention that I've followed the security advisories as listed on linuxfromscratch.org website and have downloaded the latest 5.5.x kernel (5.5.9), so these are installed to my temporary system as well:
Code:Python 3.8.3
OpenSSL 1.1.1g
Perl 5.30.3I'm not sure if some of these packages are required for pkgutils to work properly but I installed some of them because I was kind of following https://github.com/benvd/lfs-pacman/ (except with pkgutls) -- I figured I could follow it because I thought that the packaging systems are similar (I could be wrong). The only other thing was that I installed Berkeley DB (with TCL dep) and Util-Linux as LFS user, and for libarchive, I had to change "--disable-shared" to "--enable-share" in order for the following commands to work.
I've only found one thread discussing pkgutils on LFS: https://www.linuxquestions.org/quest...ls-4175501725/
Since I wanted to install to my temporary system, I had to modify pkgutils Makefile from usr to tools so I issued
Code:sed -e 's/usr/tools/g' -i MakefileFollowing the LQ thread above, I also did:
Code:sed -e 's/--static//g' -i Makefile
sed -e 's/-static//g' -i Makefilefollowed by a "make install". Pkgutils installed without any errors or warnings. I wanted to store sources and packages in dedicated directories so following https://crux.nu/Wiki/FaqPkgUtils I edited /etc/pkgmk.conf accordingly.
Also, if it helps, here is my partition layout:
Code:Table: GPT
Number mount Size Code Name
1 none 1024.0 KiB EF02 BIOS boot partition
2 /boot/efi 512.0 MiB EF00 EFI System
3 / 40.0 GiB 8300 Linux filesystem
4 none 16.0 GiB 8200 Linux swap
5 /var 10.0 GiB 8300 Linux filesystem
6 /usr 30.0 GiB 8300 Linux filesystem
7 /opt 50.0 GiB 8300 Linux filesystem
8 /home 102.0 GiB 8300 Linux filesystemIs there anything that I'm missing here or am doing wrong? Or does it take a long time to install the Linux API headers? I'm on a 6-core machine (i7, 2.6 GHz each) with hyper-threading, I feel like it shouldn't be taking this long.
If there's any other info that you want me to provide or clear up to help solve this problem, let me know. Hints and suggestions would be helpful.
** EDIT **
It's now well over 4 hours so I definitely think that pkgadd is stuck. I can't even kill it with Ctrl+C but can stop it with Ctrl+Z -- looks like I'm going to have to force restart my host system.
I'm trying to install CRUX's pkgutils as my package manager for my LFS project, version 9.1, sysvinit. Using the original Pkgfile for pkgutils-5.40.7 as a template, I copied and pasted the commands shown in chapter 6.7 "Linux API Headers" into the "build" function and executed "pkgmk" to build the package. The pkgmk executed successfully but issuing pkgadd to it is taking a long time (more than 25 minutes) and I'm not sure why. It actually appears to be stuck.
Some packages that I've installed to my temporary system in addition to the LFS packages:
Code:Berkeley DB 5.3.28
util-linux 2.35.1
zlib 1.2.11
libarchive 3.4.2
libcap 2.31
pkg-config 0.29.2
fakeroot 1.24I also wanted to mention that I've followed the security advisories as listed on linuxfromscratch.org website and have downloaded the latest 5.5.x kernel (5.5.9), so these are installed to my temporary system as well:
Code:Python 3.8.3
OpenSSL 1.1.1g
Perl 5.30.3I'm not sure if some of these packages are required for pkgutils to work properly but I installed some of them because I was kind of following https://github.com/benvd/lfs-pacman/ (except with pkgutls) -- I figured I could follow it because I thought that the packaging systems are similar (I could be wrong). The only other thing was that I installed Berkeley DB (with TCL dep) and Util-Linux as LFS user, and for libarchive, I had to change "--disable-shared" to "--enable-share" in order for the following commands to work.
I've only found one thread discussing pkgutils on LFS: https://www.linuxquestions.org/quest...ls-4175501725/
Since I wanted to install to my temporary system, I had to modify pkgutils Makefile from usr to tools so I issued
Code:sed -e 's/usr/tools/g' -i MakefileFollowing the LQ thread above, I also did:
Code:sed -e 's/--static//g' -i Makefile
sed -e 's/-static//g' -i Makefilefollowed by a "make install". Pkgutils installed without any errors or warnings. I wanted to store sources and packages in dedicated directories so following https://crux.nu/Wiki/FaqPkgUtils I edited /etc/pkgmk.conf accordingly.
Also, if it helps, here is my partition layout:
Code:Table: GPT
Number mount Size Code Name
1 none 1024.0 KiB EF02 BIOS boot partition
2 /boot/efi 512.0 MiB EF00 EFI System
3 / 40.0 GiB 8300 Linux filesystem
4 none 16.0 GiB 8200 Linux swap
5 /var 10.0 GiB 8300 Linux filesystem
6 /usr 30.0 GiB 8300 Linux filesystem
7 /opt 50.0 GiB 8300 Linux filesystem
8 /home 102.0 GiB 8300 Linux filesystemIs there anything that I'm missing here or am doing wrong? Or does it take a long time to install the Linux API headers? I'm on a 6-core machine (i7, 2.6 GHz each) with hyper-threading, I feel like it shouldn't be taking this long.
If there's any other info that you want me to provide or clear up to help solve this problem, let me know. Hints and suggestions would be helpful.
** EDIT **
It's now well over 4 hours so I definitely think that pkgadd is stuck. I can't even kill it with Ctrl+C but can stop it with Ctrl+Z -- looks like I'm going to have to force restart my host system.