On Sat, Oct 01, 2016 at 11:45:24AM -0700, patrick keshishian wrote:
> Hi,
> 
> This is on a current system (fresh install):
> 
> # sysctl kern.version
> kern.version=OpenBSD 6.0-current (GENERIC.MP) #2510: Fri Sep 30
> 09:49:52 MDT 2016
>     [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> 
> I am trying to build some ports using dpb(1).
> 
> All dependency packages built by dpb(1) required for further builds
> are installed fine by the "workflow".
> 
> # pkg_info -L yasm
> Information for inst:yasm-1.3.0p1
> 
> Files:
> /usr/local/bin/vsyasm
> /usr/local/bin/yasm
> /usr/local/bin/ytasm
> ...
> /usr/local/man/man7/yasm_objfmts.7
> /usr/local/man/man7/yasm_parsers.7
> # echo $?
> 0
> 
> 
> However, other packages built but not installed by the dpb(1)
> (workflow) seem to cause issues with the system pkg_* tools:
> 
> # pkg_info -L xpdf
> Error from file:./xpdf-3.04p1.tgz
> unsigned package
> Can't call method "is_signed" on an undefined value at
> /usr/libdata/perl5/OpenBSD/PkgInfo.pm line 392.
> 
There's indeed an error.

> Above reference to "is_signed" makes me wonder if this is a fallout
> from Espie's change(s)[1]
> 
> 
> # pkg_info -L ./xpdf-3.04p1.tgz
> # echo $?
> 1
> 
> 
> Even for yasm, if I point pkg_info to the tgz file, supposed source of
> the installed package, acts "funny":
> 
> # pkg_info -L ./yasm-1.3.0p1.tgz
> # echo $?
> 1
> 
> 
> Here is how pkg_add(1) reacts:
> 
> # pkg_add -vvvv ./xpdf-3.04p1.tgz
> Can't find ./xpdf-3.04p1.tgz
> Can't load quirk: Can't locate OpenBSD/Quirks.pm in @INC (you may need
> to install the OpenBSD::Quirks module) (@INC contains:
> /usr/local/libdata/perl5/site_perl/amd64-openbsd
> /usr/libdata/perl5/site_perl/amd64-openbsd
> /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl
> /usr/libdata/perl5/amd64-openbsd/5.20.3
> /usr/local/libdata/perl5/amd64-openbsd/5.20.3 /usr/libdata/perl5
> /usr/local/libdata/perl5 .) at /usr/libdata/perl5/OpenBSD/AddDelete.pm
> line 280.

This stuff is more or less normal. Those packages are unsigned.  pkg_info
does not know where they come from, so it won't trust that path, by
default.

pkg_info -Dunsigned -L ... will work.

I *might* tweak things slightly so that some directories are trusted
by default, that looks like a good thing.

I want to be very careful with that.  Unpacking info from an unknown source
without checking turns out to be a fairly bad idea.

I am cleaning things up, I haven't got to pkg_info yet... It's about next
on my list though.

Reply via email to