NanoBSD cust_pkgng problem....
Karl Denninger
karl at denninger.net
Thu Jun 20 19:32:24 UTC 2019
On 6/20/2019 13:44, mike tancsa wrote:
> On 6/20/2019 2:16 PM, Karl Denninger wrote:
>> I'm trying to rebuild 12-STABLE with current code with the following for
>> the PCEngines systems.
>>
>>
>> Failed to install the following 1 package(s):
>> /_.p/isc-dhcp44-server-4.4.1_4.txz
>
> Thats so strange. I saw that too. I did change defaults.sh
>
>
> # Early customize commands.
> NANO_EARLY_CUSTOMIZE=""
> @@ -776,6 +776,7 @@
> fi
>
> # Mount packages into chroot
> + mount -t devfs devfs ${NANO_WORLDDIR}/dev
> mkdir -p ${NANO_WORLDDIR}/_.p
> mount -t nullfs -o noatime -o ro ${NANO_PACKAGE_DIR}
> ${NANO_WORLDDIR}/_.p
>
> @@ -802,7 +803,7 @@
> )
>
> CR0 "${PKGCMD} info"
> -
> + umount ${NANO_WORLDDIR}/dev
> trap - 1 2 15 EXIT
> umount ${NANO_WORLDDIR}/_.p
> rm -rf ${NANO_WORLDDIR}/_.p
>
>
> to get rid of the dev/null complaints. I thought the pkg might be
> borked somehow in the poudriere build, so I rebuilt it and then it all
> worked. But I am not sure if that was just a fluke. I havent seen the
> issue since... But it was the same isc package that my build was borking
> on as well.
>
> ---Mike
I'm not building via poudriere; the packages are being grabbed from the
base 12-STABLE repo.
repo.conf in the package directory contains:
FreeBSD: {
url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
Adding "-d" to the pkg commands executed in the hope of getting an error
return that will actually mean something doesn't tell me anything useful...
Installing indexinfo-0.3.1...
the most recent version of indexinfo-0.3.1 is already installed
DBG(1)[95581]> release an exclusive lock on a database
+ CR 'env BATCH=YES ASSUME_ALWAYS_YES=YES PKG_DBDIR=/var/db/pkg
SIGNATURE_TYPE=n
one /usr/sbin/pkg -d add /_.p/isc-dhcp44-server-4.4.1_4.txz'
+ chroot /work/Crochet-work-AMD/obj/_.w /bin/sh -exc 'env BATCH=YES
ASSUME_ALWAY
S_YES=YES PKG_DBDIR=/var/db/pkg SIGNATURE_TYPE=none /usr/sbin/pkg -d add
/_.p/is
c-dhcp44-server-4.4.1_4.txz'
+ env 'BATCH=YES' 'ASSUME_ALWAYS_YES=YES' 'PKG_DBDIR=/var/db/pkg'
'SIGNATURE_TYP
E=none' /usr/sbin/pkg -d add /_.p/isc-dhcp44-server-4.4.1_4.txz
DBG(1)[95582]> pkg initialized
DBG(1)[95582]> want to get an exclusive lock on a database
Installing isc-dhcp44-server-4.4.1_4...
pkg: Cannot open /dev/null:No such file or directory
DBG(1)[95582]> release an exclusive lock on a database
Failed to install the following 1 package(s):
/_.p/isc-dhcp44-server-4.4.1_4.txz
+ umount /work/Crochet-work-AMD/obj/_.w/_.p
+ rm -rf /work/Crochet-work-AMD/obj/_.w/_.p
+ echo 'NANO RM -rf /work/Crochet-work-AMD/obj/_.w/_.p'
NANO RM -rf /work/Crochet-work-AMD/obj/_.w/_.p
+ uname -r
+ command rm -x -rf /work/Crochet-work-AMD/obj/_.w/_.p
Using "CR0" instead of "CR" in the defaults.sh script ignores the error
return and continues but when I look in the resulting build the binaries
*are not* there, so the package in fact did not install (that is,
whatever it is that's going on, it prevents anything from actually being
unpacked and stored.)
The "-d" switch tells me nothing and a "tar tvf" on the two targets
shows what appears to be a valid package; the target in question doesn't
appear on a facial basis to be corrupt.
root at NewFS:/work/PKG-AMD64-12 # ls -al pkg/ssm*
-rw-r--r-- 1 root wheel 20412 Jun 20 13:08 pkg/ssmtp-2.64_3.txz
root at NewFS:/work/PKG-AMD64-12 # tar tvf pkg/ssmtp*
-rw-r--r-- 0 root wheel 1612 Dec 31 1969 +COMPACT_MANIFEST
-rw-r--r-- 0 root wheel 3206 Dec 31 1969 +MANIFEST
-rw-r--r-- 0 root wheel 218 May 17 10:11
/usr/local/share/licenses/ssmtp-2.64_3/catalog.mk
-rw-r--r-- 0 root wheel 93 May 17 10:11
/usr/local/share/licenses/ssmtp-2.64_3/LICENSE
-rw-r--r-- 0 root wheel 758 May 17 10:11
/usr/local/share/licenses/ssmtp-2.64_3/GPLv2+
-r-xr-sr-x 0 root ssmtp 44008 May 17 10:11 /usr/local/sbin/ssmtp
-rw-r----- 0 root ssmtp 200 May 17 10:11
/usr/local/etc/ssmtp/revaliases.sample
-rw-r----- 0 root ssmtp 1286 May 17 10:11
/usr/local/etc/ssmtp/ssmtp.conf.sample
-r--r--r-- 0 root wheel 1097 May 17 10:11
/usr/local/man/man5/ssmtp.conf.5.gz
-r--r--r-- 0 root wheel 2714 May 17 10:11
/usr/local/man/man8/ssmtp.8.gz
drwxr-x--- 0 root ssmtp 0 May 17 10:11 /usr/local/etc/ssmtp/
root at NewFS:/work/PKG-AMD64-12 #
This worked perfectly well a few months ago when I last built this
specific release, and it's only these two packages (the ISC dhcp server
and ssmpt) that blow it up. Everything else -- including all the
dependencies -- install fine -- its just these two *specific* packages
that, if either is included, blows up the build.
I suppose I could set up another poudiere jail and build the required
packages from source if I absolutely must include pkg itself (I have to
for ARM32 targets since that's not a supported architecture with the
package system), but.... that shouldn't be in play here as we *are*
talking about AMD64, which is allegedly fully supported and further,
ought to be current and working for everyone who uses pkg rather than
ports......
Update: If I use -
root at NewFS:/work/PKG-AMD64-12 # more repo.conf
FreeBSD: {
url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly"
# url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
It works.
This implies that "latest" is borked, although exactly why I don't
know. The "pkg" package itself in quarterly, however, is different --
1.10.5_5 for the quarterlies .vs. 1.11.1. Given that the other packages
appear to be valid it looks like the pkg command *itself* in "latest" is
causing the problem.
--
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
More information about the freebsd-embedded
mailing list