Call for testing: pkgbase support in 15.0

Is the meta package for X or for Wayland or both? Thanks
x11/kde - trying to run both

FreeBSD Handbook reference

I’ve been testing a lot of components from base system development.

Looks like I am unable to scale my machine to match the specs on my monitor’s resolution.

I’m dumping drm and modesetting logs to check how my settings are resolving at desktop environment runtime from the command line
sh:
bat /var/log/Xorg.0.log | grep -i modes > gpu_driver_logs.txt

bat gpu_driver_logs.txt

bat(1) is awesome at the command line
 
Hey everyone I have an update on pkgbase development.

KDE Plasma Desktop version 6.4.5.25.08.1

References
FreeBSD Handbook - X Window System LinuxKPI, drm-mod, pciconf(8), vt(4), Xorg(1), xorg.conf(5), KDE/FreeBSD initiative

I can confirm my Dell Precision mobile workstation has to be manually programmed to map its GPU and required GPU drivers correctly to:

1. Detect applicable gpu devices including required gpu drivers, firmware, and kernel modules.
2. Scale correctly to screen’s resolution without a black screen.
3. Launch KDE Plasma Desktop directly from the terminal.

It’s a frame buffering issue that causes segmentation violations.

So I am running the Wayland compositor with the traditional X11 backend. I have been able to reproduce this bug consistently so far but most importantly how to map out my gpu correctly. My settings are set at

sh:
/usr/local/etc/X11/xorg.conf.d/

To reproduce a programmable solution to confirm my machine is working correctly I manually load gpu’s from base system to test my settings

sh:
sudo kldload i915kms # replace with your specific gpu

For future readers in the community I recommend following the handbook and official community resources if you are unsure.
 
Following up from catching up on this pkgbase move. If it’s breaking ZFS encryption including with geli(8) at installation time, I can see why there is cause for concern in the community.
 
Remove third-party packages
maybe :

pkg query '%n' | awk 'BEGIN{n=0} {n++} END{print n " total"}'


pkg query '%n %R' | awk '$2=="FreeBSD-ports"{print $1}' > /root/ports.pkgs

Read file!!

and see the number

wc -l /root/ports.pkgs

and destroy third-party packages

xargs -a /root/ports.pkgs pkg delete -y

I haven't tested this in a BE lab yet
 
There is discussion about pkgbase at Blogs and News Feeds

I’ll look into running more tests. My conjecure then is if pkgbase is the community’s general consensus have it be the ABI layer or bridge between base system and third-party packages.

That is probably the idea but I’m not with the cool kids group in the community hehe

I’ll isolate an image of 15.0-RELEASE-p1 into a new VM on bare metal 15.0-RELEASE-p1 that I am running

I learn something new about base system everyday. So it looks like geli(8) goes all the way back to FreeBSD 6.0 correct me if I’m wrong here
 
I would get 'origin' instead.

Code:
root@bsd15:~ # pkg query '%o %R' | awk '$2=="FreeBSD-ports" {print $1}'
sysutils/beadm
sysutils/lsblk

The xargs(1) command on FreeBSD does not support -a option:

Code:
root@bsd15:~ # man xargs | grep -- '-a'
     -n number, --max-args=number

So I would use something like that instead:

Code:
root@bsd15:~ # pkg query '%o %R' | awk '$2=="FreeBSD-ports" {print $1}' | xargs -n1 echo pkg delete -f -y
pkg delete sysutils/beadm
pkg delete sysutils/lsblk

Remove the echo(1) safety switch to make it work.
 
Yes xarg -a is bad

#> xargs -a /root/ports.pkgs pkg delete
xargs: invalid option -- a
usage: xargs [-0opt] [-E eofstr] [-I replstr [-R replacements] [-S replsize]]
[-J replstr] [-L number] [-n number [-x]] [-P maxprocs]
[-s size] [utility [argument ...]]
 
I would get 'origin' instead.

Code:
root@bsd15:~ # pkg query '%o %R' | awk '$2=="FreeBSD-ports" {print $1}'
sysutils/beadm
sysutils/lsblk

The xargs(1) command on FreeBSD does not support -a option:

Code:
root@bsd15:~ # man xargs | grep -- '-a'
     -n number, --max-args=number

So I would use something like that instead:

Code:
root@bsd15:~ # pkg query '%o %R' | awk '$2=="FreeBSD-ports" {print $1}' | xargs -n1 echo pkg delete -f -y
pkg delete sysutils/beadm
pkg delete sysutils/lsblk

Remove the echo(1) safety switch to make it work.
I tested with the following commands and got a good result:
list:

pkg query '%n %R' | awk '$2!="FreeBSD-base"{print $1}' | less



last look

pkg query '%n %R' | awk '$2!="FreeBSD-base"{print $1}' | xargs pkg delete -n


and remove Ports & kmods

pkg query '%n %R' | awk '$2!="FreeBSD-base"{print $1}' | xargs pkg delete -n
 
Remove third-party packages
pkgbase(7):
Code:
DESCRIPTION
       The  FreeBSD  base system may be	installed as a set of pkg(8) packages,
       which supersedes	the traditional	 method	 of  installing	 using	tar(1)
       archives.

       All  base packages have names beginning with the	string "FreeBSD-", and
       have an origin beginning	with "base/*".
You can use either base/* or ^FreeBSD- as the discriminator. Given that the command line can handle quite a few bytes on the command line:
Code:
# sysctl -d kern.argmax; sysctl -h kern.argmax
kern.argmax: Maximum bytes of argument to execve(2)
kern.argmax: 524288
you very well might get along without using xargs(1) alltogether, resulting in cutting out all middle men.

Using base/*:
pkg delete -n `pkg query -e '%o !~ base/*' '%o'`

or, using the more modern variant of command substitution:
pkg delete -n $( pkg query -e '%o !~ base/*' '%o' )

Note: if you have defined additional 'local' repositories, in addition to FreeBSD-ports and FreeBSD-ports-kmods, these will also be deleted.
 
I want to test out mail(1) functionality. I know some want to move fast with the other communities out there and that's fine I guess. I guess some of us will take our time and test base system that goes all the way back to Unix version 1.0! See mail(1) reference.

Also I was wondering with the rush to modernize FreeBSD. Will there be a new community homepage.

References

Demo
 
IMHO like that it looks a lot better:
 

Attachments

  • freebsd-new-page.png
    freebsd-new-page.png
    507.8 KB · Views: 75
FreeBSD-15.0-RELEASE-amd64-zfs.qcow2.xz running on native Arch Linux boots with minor quirks setting up the virtual machine. It's fairly straightforward if you have a bit of programming experience 👍

I'm running a dual boot of FreeBSD 15.0-RELEASE-p1 and a native Arch Linux distribution

1767076274252.png
 
So for a user who's not on pkgbase, will it automatically switch you to pkgbase when you upgrade to 15 or 16 later? How does this switchover happen for an existing installation?

I'm a bit curious. I thought there was meaning in the way things were at FreeBSD. Is there no longer meaning in the way things were done before pkgbase? It feels like there's meaning in having kernel NOT pkg based, where you just go to source, compile and bam - and can package it separately if you need to.

I'm sure this has already been discussed at length somewhere?
 
So for a user who's not on pkgbase, will it automatically switch you to pkgbase when you upgrade to 15 or 16 later? How does this switchover happen for an existing installation?

I'm a bit curious. I thought there was meaning in the way things were at FreeBSD. Is there no longer meaning in the way things were done before pkgbase? It feels like there's meaning in having kernel NOT pkg based, where you just go to source, compile and bam - and can package it separately if you need to.

I'm sure this has already been discussed at length somewhere?
Maybe the discussion (beginning at #287) in this thread between T-Daemon, Erichans and I could be a reference for custom built kernel in pkgbase. It's not supported for the moment.
 
pkgbase is just like you do a "make installworld" in /usr/src .
It contains files like /bin/sh , or /usr/bin/su
But not /usr/local/bin/bash or /boot
 
It looks like the official handbook 26.7 Updating FreeBSD with packages confirms this


Is this a 1 to 1 mirror of the traditional implementation at 26.6 Updating FreeBSD from Source
 
Back
Top