rpi fbsd 12 wrong file permissions on package files

It's not my week :-(

I should say the PI is running fbsd12, using the version 11 packages.

Having sorted the boot problems, I did a 'pkg install xorg'. The file permissions are largely wrong.

Eg in /usr/local/lib, I see in particular

--w-rwSr-x 1 root wheel 9224 Jan 1 1970 libxkbui.a l-w-rwSrw- 1 root wheel 17 Jan 1 1970 libxkbui.so -> libxkbui.so.1.0.0 l-w-rwSrwx 1 root wheel 17 Jan 1 1970 libxkbui.so.1 -> libxkbui.so.1.0.0

--w-rws--- 1 root wheel 15528 Jan 1 1970 libxkbui.so.1.0.0

If I manually unpack the libxkbuiXXX.txz file (on a linux box), the permissions within the original package look OK:

mike@spock ~ $ ls -l '/tmp/usr/local/lib' total 28

-rw-r--r-- 1 mike mike 9224 Mar 30 04:53 libxkbui.a lrwxrwxrwx 1 mike mike 17 Mar 30 04:53 libxkbui.so -> libxkbui.so.1.0.0 lrwxrwxrwx 1 mike mike 17 Mar 30 04:53 libxkbui.so.1 -> libxkbui.so.1.0.0

-rwxr-xr-x 1 mike mike 15528 Mar 30 04:53 libxkbui.so.1.0.0

In fact, the permissions appear often nonsensical; eg elsewhere:

--wx---r-x 1 root wheel 570498 Jan 1 1970 libpixman-1.a l-wx---rw- 1 root wheel 21 Jan 1 1970 libpixman-1.so -> libpixman-1.so.0.34.0 l-wx---rwx 1 root wheel 21 Jan 1 1970 libpixman-1.so.0 -> libpixman-1.so.0.34.0

--wx--x--- 1 root wheel 431584 Jan 1 1970 libpixman-1.so.0.34.0

The dates are unset too - shouldn't the installed files have the packaged file date?

Decidedly wie^D^Deird.

Any thoughts please?

--
Mike Scott (unet2  [deletethis] scottsonline.org.uk) 
Harlow Essex 
"The only way is Brexit" -- anon.
Reply to
Mike Scott
Loading thread data ...

It seems that simply untarring the package files gives correct results. Therefore it's presumably pkg that's messing with file permissions on the extracted files.

Anyone else seen this? It's only on the rpi that I'm having issues, been fine on i386.

--
Mike Scott (unet2  [deletethis] scottsonline.org.uk) 
Harlow Essex 
"The only way is Brexit" -- anon.
Reply to
Mike Scott

The problem doesn't appear when using pkg-static instead of pkg.

So I've listed the packages with pkg, and done a pkg-static install -y -f on the whole lot, and all looks well.

I did rebuild pkg from the ports tree just on the offchance, but it automatically undoes any installation complaining about OS version differences. However, running the rebuilt version from within the ports tree shows the same: pkg fails while pkg-static works correctly.

At least there's a work-around; maybe I should make pkg a link to pkg-static.

BTW, does anyone know of a vnc server that will run in freeebsd on the ARM?

--
Mike Scott (unet2  [deletethis] scottsonline.org.uk) 
Harlow Essex 
"The only way is Brexit" -- anon.
Reply to
Mike Scott

Have you seen this page?

formatting link

Currently there are no packages for the 12 (HEAD) branch on arm64, so you will have to use the packages for 11.x (STABLE).

Your image is probably newer than what's on the site, but still use the same pacakges.

Also, take a look at:

formatting link

Reply to
sean

Thanks for your reply. I am aware that the V11 packages are needed, and I've done the pkg boot stuff as described somewhere on those pages, to make sure pkg picks up the V11 stuff.

There is a followup post to the effect that the problem seems to affect pkg, but not pkg-static. This applies both to whatever the system has supplied, and the fresh versions I built within the ports tree. I'm using pkg-static for now; I'd love to take the code apart and understand what's happening, but not right now :)

Otherwise it's running well enough - with pkg-static, I've got X11 installed, and the rpi is surprisingly speedy. I'd rather have a replacement for tightvnc though (which is written with assembly code :-( )

--
Mike Scott (unet2  [deletethis] scottsonline.org.uk) 
Harlow Essex 
"The only way is Brexit" -- anon.
Reply to
Mike Scott

What raspberry pi version are you running - 2 or 3? TightVNC is written with assembly code??

Reply to
sean

  1. Uses x86 assembler according to the 'package is broken' message from the ports tree. I've not looked (yet), I admit.

--
Mike Scott (unet2  [deletethis] scottsonline.org.uk) 
Harlow Essex 
"The only way is Brexit" -- anon.
Reply to
Mike Scott

Just looked.... it has assembler code for 4 architectures to do efficient stippling: stipmips.s stipple68k.s stipsparc.s stipsprc32.s

but no fallback for other architectures.

--
Mike Scott (unet2  [deletethis] scottsonline.org.uk) 
Harlow Essex 
"The only way is Brexit" -- anon.
Reply to
Mike Scott

Although the real culprit seems to be compiler.h, chock full of __ASM__ directives for various architectures. Beyond my means to fix :-{

--
Mike Scott (unet2  [deletethis] scottsonline.org.uk) 
Harlow Essex 
"The only way is Brexit" -- anon.
Reply to
Mike Scott

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.