Docker build fails with Unable to locate package spicy
Closed this issue · 5 comments
I'm trying to build using docker, but docker build --tag n64sdkmod-docker . fails with E: Unable to locate package spicy
I'm using osx mojave 10.14.6 and docker desktop 2.3.0.3.
Below is part of the log output before the error:
make[2]: Leaving directory '/usr/local/n64chain/gcc-build/mips64-elf/libgcc'
make[1]: Leaving directory '/usr/local/n64chain/gcc-build/mips64-elf/libgcc'
/bin/bash ../gcc-source/mkinstalldirs /usr/local/n64chain /usr/local/n64chain
make[1]: Entering directory '/usr/local/n64chain/gcc-build/mips64-elf/libgcc'
/bin/bash ../../../gcc-source/libgcc/../mkinstalldirs /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0
/usr/bin/install -c -m 644 libgcc.a /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/
chmod 644 /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/libgcc.a
/usr/local/n64chain/mips64-elf/bin/ranlib /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/libgcc.a
/usr/bin/install -c -m 644 libgcov.a /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/
chmod 644 /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/libgcov.a
/usr/local/n64chain/mips64-elf/bin/ranlib /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/libgcov.a
parts="crtbegin.o crtend.o crti.o crtn.o"; \
for file in $parts; do \
rm -f /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/$file; \
/usr/bin/install -c -m 644 $file /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/; \
case $file in \
*.a) \
/usr/local/n64chain/mips64-elf/bin/ranlib ../.././gcc/$file ;; \
esac; \
done
/bin/bash ../../../gcc-source/libgcc/../mkinstalldirs /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/include
/usr/bin/install -c -m 644 unwind.h /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/include
/bin/bash ../../../gcc-source/libgcc/../mkinstalldirs /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/include
/usr/bin/install -c -m 644 ../../../gcc-source/libgcc/gcov.h /usr/local/n64chain/lib/gcc/mips64-elf/10.1.0/include
make[1]: Leaving directory '/usr/local/n64chain/gcc-build/mips64-elf/libgcc'
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease
Hit:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Ign:5 https://coneyislanddiscopalace.xyz/apt ./ InRelease
Ign:6 https://coneyislanddiscopalace.xyz/apt ./ Release
Get:7 https://coneyislanddiscopalace.xyz/apt ./ Packages [3558 B]
Fetched 92.3 kB in 3s (27.6 kB/s)
Reading package lists...
Building dependency tree...
Reading state information...
All packages are up to date.
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
libnustd n64sdk-common
The following NEW packages will be installed:
libnustd n64sdk n64sdk-common
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 1187 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 https://coneyislanddiscopalace.xyz/apt ./ libnustd 1.3.2 [54.6 kB]
Get:2 https://coneyislanddiscopalace.xyz/apt ./ n64sdk-common 2.0.L-4 [16.1 kB]
Get:3 https://coneyislanddiscopalace.xyz/apt ./ n64sdk 2.0.L-4 [1116 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 1187 kB in 4s (321 kB/s)
Selecting previously unselected package libnustd.
(Reading database ... 14079 files and directories currently installed.)
Preparing to unpack .../libnustd_1.3.2_all.deb ...
Unpacking libnustd (1.3.2) ...
Selecting previously unselected package n64sdk-common.
Preparing to unpack .../n64sdk-common_2.0.L-4_all.deb ...
Unpacking n64sdk-common (2.0.L-4) ...
Selecting previously unselected package n64sdk.
Preparing to unpack .../n64sdk_2.0.L-4_all.deb ...
Unpacking n64sdk (2.0.L-4) ...
Setting up n64sdk-common (2.0.L-4) ...
Warning: You need to set the N64_CC, N64_AS etc enviroment variables to your proper compiler programs for this toolset to work.
Setting up libnustd (1.3.2) ...
Setting up n64sdk (2.0.L-4) ...
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package spicy
The command '/bin/sh -c dpkg --add-architecture i386 && apt-get update && apt-get -y install build-essential git wget libmpfr-dev libmpc-dev libgmp-dev flex bison && apt-get clean && git clone https://github.com/CrashOveride95/n64chain.git ./n64chain && cd n64chain && ./build-posix64-toolchain.sh && mkdir -p gcc-source/libgcc/config/mips && touch gcc-source/libgcc/config/mips/t-mips64 && cd gcc-build && make all-target-libgcc CC_FOR_TARGET=$N64_TOOLCHAIN/mips64-elf-gcc CFLAGS_FOR_TARGET="-D_MIPS_SZLONG=32 -D_MIPS_SZINT=32 -mabi=32 -march=vr4300 -mtune=vr4300 -mfix4300" && make install-target-libgcc && echo "deb [trusted=yes] https://coneyislanddiscopalace.xyz/apt ./" > /etc/apt/sources.list.d/coneyisland.list && apt update && apt-get -y install n64sdk && apt-get -y install spicy && apt-get -y install makemask && apt-get -y install root-compatibility-enviroment' returned a non-zero code: 100
bash-3.2$
This is very weird, I just tried a sudo apt update on WSL and spicy appears to still be on the repo..
EDIT: Nope, just tried installing from scratch, it's not there? I must have screwed something up when pushing, will be fixed shortly
I will investigate further tommorow
For some reason (??????????) when I was pushing new versions of some packages, spicy decided to not build. I have just pushed to the server, and can confirm that spicy is on the repo. Whenever possible could you please retry?
@CrashOveride95 now it works. Thanks!
I had another problem which I was able to fix but I am curious to know if this is expected. In order to build https://github.com/CrashOveride95/n64-sdk-demo I had to install 2 additional packages libnusys and libkmc. Should those dependencies be also listed in the Dockerfile?
The docker is only intended to install absolutely needed packages. libkmc is deprecated, I plan on updating the repo to use libgcc+nustd later.
I'm closing this issue since the initial problem was fixed. Thanks!