pkg 2.0.0 problems

Not precise.
kmod ports like graphics/drm-*-kmod installs kernel modules in /boot/modules/.
And firmware ports like sysutils/cpu-microcode-intel installs firmwares in /boot/firmware/.
These are because of possible problem on dedicated /usr/local partition.

And Linuxulator ports and anything running under Linuxulater are usually installed in /compat/linux/.

And more, if pkgbase become default, FreeBSD base components are installed using pkg, too (except src upgrades).

Things are going to be more complexed.
There's lots of other details that automated upgrading fails to account for. Especially when they are added much later after the fresh install. This is why automated utilities are not to be really trusted. This is why I recommend going for a fresh reinstall every time. This is true in Linux camp as well. Just something that all Open Source OS users learn to live with and tolerate the consequences.
 
There's lots of other details that automated upgrading fails to account for. Especially when they are added much later after the fresh install. This is why automated utilities are not to be really trusted. This is why I recommend going for a fresh reinstall every time. This is true in Linux camp as well. Just something that all Open Source OS users learn to live with and tolerate the consequences.
If I recall correctly, at start, ports framework considered (almost) fresh installation only.
The introduction of portupgrade drastically changed the situation (it was like a dream at the moment), but as things went more and more complexed, it got behind, unfortunately.
Other tools like portmaster popped in, but it was "race conditions" within ports framework and upgrading tools.
I think this is not yet drastically improved (improving slower than ports framework).
 
im not sure its related, but:
Code:
~ sudo pkg install vscode
Updating FreeBSD repository catalogue...
Fetching data.pkg: 100% 10 MiB 5.3MB/s 00:02
Processing entries: 100%
FreeBSD repository update completed. 35847 packages processed.
All repositories are up to date.
The following 31 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
krb5: 1.21.3
libb2: 0.98.1_1
vscode: 1.96.4_3
Installed packages to be UPGRADED:
FreeCAD: 1.0.0_1 -> 1.0.0_2
boost-libs: 1.86.0_1 -> 1.87.0_1
harfbuzz-icu: 10.2.0 -> 10.2.0_1
icu: 74.2_1,1 -> 76.1,1
libcdr01: 0.1.8 -> 0.1.8_1
libcmis: 0.6.2_3 -> 0.6.2_4
libe-book: 0.1.3_28 -> 0.1.3_29
libixion: 0.19.0_3 -> 0.19.0_4
libmspub01: 0.1.4_24 -> 0.1.4_25
liborcus: 0.19.2_3 -> 0.19.2_4
libqxp: 0.0.0_24 -> 0.0.0_25
libreoffice: 25.2.0.3 -> 25.2.0.3_2
librewolf: 134.0.2_1 -> 135.0_1
libvisio01: 0.1.8 -> 0.1.8_1
libzmf: 0.0.2_29 -> 0.0.2_30
poppler: 24.02.0_2 -> 24.12.0
poppler-glib: 24.02.0_2 -> 24.12.0
poppler-utils: 24.02.0_2 -> 24.12.0
postgresql16-server: 16.6 -> 16.7_1
qt5-core: 5.15.16p130 -> 5.15.16p130_1
qt6-base: 6.8.2 -> 6.8.2_2
raptor2: 2.0.16_3 -> 2.0.16_4
vte3: 0.78.2 -> 0.78.2_1
webkit2-gtk_40: 2.46.5_2 -> 2.46.5_3
Installed packages to be REINSTALLED:
cups-filters-1.28.17_6 (required shared library changed)
Installed packages to be REMOVED:
deluge: 2.1.1_2,2
deluge-cli: 2.1.1_3
py311-libtorrent-rasterbar: 1.2.20,2
Number of packages to be removed: 3
Number of packages to be installed: 3
Number of packages to be upgraded: 24
Number of packages to be reinstalled: 1
The process will require 344 MiB more space.
475 MiB to be downloaded.
Have no idea why ... have no idea why deluge is being removed ... allowed to carry on - yep, deluge is gone !

Code:
➜  ~ sudo pkg install deluge
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'deluge' have been found in the repositories
➜  ~ sudo pkg install net-p2p/deluge
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'net-p2p/deluge' have been found in the repositories
I thought its automatically updated/upgraded but no ..
Code:
➜  ~ sudo pkg update
Updating FreeBSD repository catalogue...
pkg: Repository FreeBSD has a wrong packagesite, need to re-create database
Fetching meta.conf: 100%    179 B   0.2kB/s    00:01
Fetching data.pkg: 100%   10 MiB   5.3MB/s    00:02
Processing entries: 100%
FreeBSD repository update completed. 35847 packages processed.
All repositories are up to date.
➜  ~ sudo pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (515 candidates): 100%
Processing candidates (515 candidates): 100%
The following 21 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        aom: 3.11.0 -> 3.12.0
        binutils: 2.43.1,1 -> 2.44,1
        chromium: 132.0.6834.159 -> 132.0.6834.159_1
        cpu-microcode-intel: 20241112 -> 20250211
        drm-61-kmod: 6.1.92.1402501_3 -> 6.1.128.1401000
        exiv2: 0.28.3,1 -> 0.28.4,1
        gpgme: 1.24.1 -> 1.24.2
        gpgme-cpp: 1.24.1 -> 1.24.2
        libpsl: 0.21.5_1 -> 0.21.5_2
        lp_solve: 5.5.2.5 -> 5.5.2.5_1
        mesa-devel: 25.0.b.479 -> 25.0.b.664
        nss: 3.107 -> 3.108
        openldap26-client: 2.6.9 -> 2.6.9_1
        openssl: 3.0.15_1,1 -> 3.0.16,1
        postgresql16-client: 16.6_1 -> 16.7_1
        py311-boost-libs: 1.86.0 -> 1.87.0
        qpdf: 11.9.1 -> 11.10.0
        qt6-multimedia: 6.8.2 -> 6.8.2_1
        sqlite3: 3.46.1,1 -> 3.46.1_1,1
        vm-bhyve-devel: 1.6.2.4 -> 1.6.2.15
        wayland-protocols: 1.39 -> 1.40

Number of packages to be upgraded: 21

The process will require 6 MiB more space.
199 MiB to be downloaded.

P.s pkg is from latest ... if i do quarterly - some apps going to be deleted
 
pkg v.2.0.6 fails to upgrade with multiple repositories specified on the command line on my 14.2-RELEASE.
Tested with net/realtek-re-kmod and graphics/drm-61-kmod.

Can anyone confirm this?

pkg 2.0 NEWS and /usr/local/share/doc/pkg/NEWS:
Code:
- pkg: -r command can be used multiple times to only enable
  the specified repositories.

commit - ports-mgmt/pkg: update to 2.0.0 (Jan 22):
Code:
   -r now always enable the repository mentioned

I expected #1 (one upgrade command) and #2 (sequence of two upgrade commands) to have the same result*:
  1. pkg upgrade -r FreeBSD -r FreeBSD-kmods drm-61-kmod
  2. pkg upgrade -r FreeBSD drm-61-kmod
    pkg upgrade -r FreeBSD-kmods drm-61-kmod
However, #1 fails and #2 succeeds in upgrading drm-61-kmod from:
drm-61-kmod-6.1.128.1401000_1
to:
drm-61-kmod-6.1.128.1402000_1

Same results in attempt to upgrade:
realtek-re-kmod-1100.00.1401000_1
to:
realtek-re-kmod-1100.00.1402000_1

The following command sequence details the failed and succeeded upgrade attempts:
Rich (BB code):
[1-0] # date -u; uname -a; pkg -v
Sat Mar  1 13:40:58 UTC 2025
FreeBSD q210 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC amd64
2.0.6
[2-0] # pkg inf | grep -E  '(realtek-re-kmod|drm-61-kmod)'
drm-61-kmod-6.1.128.1402000_1  DRM drivers modules
realtek-re-kmod-1100.00.1402000_1 Kernel driver for Realtek PCIe Ethernet Controllers
[3-0] # pkg delete realtek-re-kmod drm-61-kmod        # <- delete packages to create a clean start    
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 2 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        drm-61-kmod: 6.1.128.1402000_1
        realtek-re-kmod: 1100.00.1402000_1

Number of packages to be removed: 2

The operation will free 18 MiB.

Proceed with deinstalling packages? [y/N]: y
[1/2] Deinstalling drm-61-kmod-6.1.128.1402000_1...
[1/2] Deleting files for drm-61-kmod-6.1.128.1402000_1: 100%
[2/2] Deinstalling realtek-re-kmod-1100.00.1402000_1...
[2/2] Deleting files for realtek-re-kmod-1100.00.1402000_1: 100%
[4-0] # pkg autoremove
Checking integrity... done (0 conflicting)
Nothing to do.
[5-0] #    # after disabling the 'kmods' repository (in order to install the 14.1-RELEASE specific packages):
[6-0] # pkg repositories
FreeBSD: {
    url             : "pkg+https://pkg.freebsd.org/FreeBSD:14:amd64/latest",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
FreeBSD-kmods: {
    url             : "pkg+https://pkg.freebsd.org/FreeBSD:14:amd64/kmods_latest_2",
    enabled         : no,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
[7-0] # pkg install drm-61-kmod
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        drm-61-kmod: 6.1.128.1401000_1 [FreeBSD]

Number of packages to be installed: 1

The process will require 17 MiB more space.
3 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching drm-61-kmod-6.1.128.1401000_1.pkg: 100%    3 MiB   3.7MB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Installing drm-61-kmod-6.1.128.1401000_1...
[1/1] Extracting drm-61-kmod-6.1.128.1401000_1: 100%
=====
Message from drm-61-kmod-6.1.128.1401000_1:

--
The drm-61-kmod port can be enabled for amdgpu (for AMD
GPUs starting with the HD7000 series / Tahiti) or i915kms (for Intel
APUs starting with HD3000 / Sandy Bridge) through kld_list in
/etc/rc.conf. radeonkms for older AMD GPUs can be loaded and there are
some positive reports if EFI boot is NOT enabled.

For amdgpu: kld_list="amdgpu"
For Intel: kld_list="i915kms"
For radeonkms: kld_list="radeonkms"

Please ensure that all users requiring graphics are members of the
"video" group.

Please note that this package was built for FreeBSD 14.1.
If this is not your current running version, please rebuild
it from ports to prevent panics when loading the module.
[8-0] # pkg install realtek-re-kmod
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        realtek-re-kmod: 1100.00.1401000_1 [FreeBSD]

Number of packages to be installed: 1

The process will require 1 MiB more space.
129 KiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching realtek-re-kmod-1100.00.1401000_1.pkg: 100%  129 KiB 132.5kB/s    00:01
Checking integrity... done (0 conflicting)
[1/1] Installing realtek-re-kmod-1100.00.1401000_1...
[1/1] Extracting realtek-re-kmod-1100.00.1401000_1: 100%
=====
Message from realtek-re-kmod-1100.00.1401000_1:

--
Add the following lines to your /boot/loader.conf
to override the built-in FreeBSD re(4) driver.

if_re_load="YES"
if_re_name="/boot/modules/if_re.ko"

By default, the size of allocated mbufs is enough
to receive the largest Ethernet frame supported
by the card.  If your memory is highly fragmented,
trying to allocate contiguous pages (more than
4096 bytes) may result in driver hangs.
For this reason the value is tunable at boot time,
e.g. if you don't need Jumbo frames you can lower
the memory requirements and avoid this issue with:

hw.re.max_rx_mbuf_sz="2048"

To enable Wake on LAN (WoL) support you might need
to set the following tunables:

hw.re.s5wol="1"
hw.re.s0_magic_packet="1"

If you experience network hangs with IPv6 enabled,
you might need to disable the checksum offloading
by adding the following parameters to the related
ifconfig line in your /etc/rc.conf file:

-rxcsum -txcsum -rxcsum6 -txcsum6
[9-0] #     # after enabling 'kmods' repository:
[10-0] # pkg repositories
FreeBSD: {
    url             : "pkg+https://pkg.freebsd.org/FreeBSD:14:amd64/latest",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
FreeBSD-kmods: {
    url             : "pkg+https://pkg.freebsd.org/FreeBSD:14:amd64/kmods_latest_2",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
[11-0] # pkg upgrade -r FreeBSD -r FreeBSD-kmods drm-61-kmod      #   upgrade fails:
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating FreeBSD-kmods repository catalogue...
FreeBSD-kmods repository is up to date.
FreeBSD, FreeBSD-kmods are up to date.
Checking integrity... done (0 conflicting)
Your packages are up to date.
[12-0] # pkg upgrade -r FreeBSD drm-61-kmod
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
FreeBSD is up to date.
Checking integrity... done (0 conflicting)
Your packages are up to date.
[13-0] # pkg upgrade -r FreeBSD-kmods drm-61-kmod
Updating FreeBSD-kmods repository catalogue...
FreeBSD-kmods repository is up to date.
FreeBSD-kmods is up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        drm-61-kmod: 6.1.128.1401000_1 -> 6.1.128.1402000_1 [FreeBSD-kmods]

Number of packages to be upgraded: 1

Proceed with this action? [y/N]: y
[1/1] Upgrading drm-61-kmod from 6.1.128.1401000_1 to 6.1.128.1402000_1...
[1/1] Extracting drm-61-kmod-6.1.128.1402000_1: 100%
[14-0] # pkg upgrade -r FreeBSD -r FreeBSD-kmods realtek-re-kmod      #   upgrade fails:
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating FreeBSD-kmods repository catalogue...
FreeBSD-kmods repository is up to date.
FreeBSD, FreeBSD-kmods are up to date.
Checking integrity... done (0 conflicting)
Your packages are up to date.
[15-0] # pkg upgrade -r FreeBSD realtek-re-kmod
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
FreeBSD is up to date.
Checking integrity... done (0 conflicting)
Your packages are up to date.
[16-0] # pkg upgrade -r FreeBSD-kmods realtek-re-kmod
Updating FreeBSD-kmods repository catalogue...
FreeBSD-kmods repository is up to date.
FreeBSD-kmods is up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        realtek-re-kmod: 1100.00.1401000_1 -> 1100.00.1402000_1 [FreeBSD-kmods]

Number of packages to be upgraded: 1

Proceed with this action? [y/N]: y
[1/1] Upgrading realtek-re-kmod from 1100.00.1401000_1 to 1100.00.1402000_1...
[1/1] Extracting realtek-re-kmod-1100.00.1402000_1: 100%
[17-0] # pkg inf | grep -E  '(realtek-re-kmod|drm-61-kmod)'
drm-61-kmod-6.1.128.1402000_1  DRM drivers modules
realtek-re-kmod-1100.00.1402000_1 Kernel driver for Realtek PCIe Ethernet Controllers
[18-0] #

___
* Edit: To be clear, for each pair of two commands
pkg upgrade -r FreeBSD -r FreeBSD-kmods drm-61-kmod
pkg upgrade drm-61-kmod
and more generally:
pkg upgrade -r FreeBSD -r FreeBSD-kmods
pkg upgrade
these should have the same result when both the FreeBSD and FreeBSD-kmods repository are enabled.
 
Likely related to PR 284902.
I actually don't treat that as a bug...

I look at it as 'scope of dependency resolution'. Like, in the screenie above, 19 steps were initially identified to completely resolve dependencies for a package. But in step 17, sysutils/xxd and editors/vim were recursively identified as dependencies that need to be resolved. Step 17 was not over until those two packages were taken care of.
 
I actually don't treat that as a bug...

I look at it as 'scope of dependency resolution'. Like, in the screenie above, 19 steps were initially identified to completely resolve dependencies for a package. But in step 17, sysutils/xxd and editors/vim were recursively identified as dependencies that need to be resolved. Step 17 was not over until those two packages were taken care of.
I thought it was related to dependencies in the same way, but still the behavior is strange and if it's not a bug, then it's a very strange implementation.
FreeBSD somehow always implies more explicit behavior - it's just a regular message listing.
:)
 
I just started a package upgrade, and had to stop it:
Code:
[gunsynd.152] $ sudo pkg upgrade
...
Installed packages to be REMOVED:
    iridium-browser: 2024.11.131.1_1
    qt5-webkit: 5.212.0.a4_16

Number of packages to be removed: 2
Number of packages to be installed: 4
Number of packages to be upgraded: 67
Number of packages to be reinstalled: 4
[gunsynd.157] $ date -u
Wed Mar  5 22:31:03 UTC 2025
[gunsynd.158] $ freebsd-version -kru
13.4-RELEASE-p3
13.4-RELEASE-p3
13.4-RELEASE-p4
[gunsynd.159] $ pkg -v
2.0.6
[gunsynd.160] $ pkg info | grep iridium-browser
iridium-browser-2024.11.131.1_1 Iridium browser
[gunsynd.161] $  pkg search iridium
[gunsynd.162] $  # note: nothing found by search
There are many packages that I don't know whether I need them or not. But I do know that I want and need iridium.

Does anyone know why the iridium-browser package would be gratuitously removed?

It's quite annoying to have to watch pkg like a hawk. It simply can't be trusted. That's a bad thing.
 
iridium-browser-2024.11.131.1_1 Iridium browser
By the looks of iridium-packages - freshports it seems iridium is in the process of switching to a '2025-like' version. On my 14.2R I can confirm this:
Code:
[2-0] # date -u; uname -a; pkg -v
Thu Mar  6 01:10:31 UTC 2025
FreeBSD q210 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC amd64
2.0.6
[3-0] # pkg sea iridium
iridium-browser-2025.02.133.1_1 Iridium browser
   <snap switching to quarterly>
[7-0] # pkg sea iridium
iridium-browser-2025.02.133.1  Iridium browser
I guess you're on 13.4/latest, and then some patience seems required.
 
It's quite annoying to have to watch pkg like a hawk. It simply can't be trusted. That's a bad thing.
Yeah, I'm itching to try some new ports, because there's news that KDE 6 finally ironed out Wayland kinks on FreeBSD. But with this pkg mess still going on, I'm kind of reluctant to spin up a new machine - what if I miss the opportunity to say no to upgrading from 1.21 to 2.0.x and have to restart my installation all over again? Basically, I'm reluctant to waste my time like that. My priority is KDE 6, not pkg.

Well, one way to ameliorate that mess is to switch to compiling things from scratch using the ports framework. For me, that is a succeful strategy, and you normally don't mess with success.
 
Yeah, I'm itching to try some new ports, because there's news that KDE 6 finally ironed out Wayland kinks on FreeBSD. But with this pkg mess still going on, I'm kind of reluctant to spin up a new machine - what if I miss the opportunity to say no to upgrading from 1.21 to 2.0.x and have to restart my installation all over again? Basically, I'm reluctant to waste my time like that. My priority is KDE 6, not pkg.

Well, one way to ameliorate that mess is to switch to compiling things from scratch using the ports framework. For me, that is a succeful strategy, and you normally don't mess with success.
Not to go too off topic, but this march KDE upgrade hosed falkon loading here and it will not compile: /usr/ports/www/falkon/work-kf6/falkon-24.12.3/src/lib/tools/aesinterface.cpp:100:15: error: use of undeclared identifier "EVP_PKEY_MO_ENCRYPT' [ also ..._DECRYPT' ] and
I did a few hours of checking online and I think some .h file needs headers? Two threads started already and I do not know where else to post it... firefox works as well but, one issue is it not playing sound...
 
Not to go too off topic, but this march KDE upgrade hosed falkon loading here and it will not compile: /usr/ports/www/falkon/work-kf6/falkon-24.12.3/src/lib/tools/aesinterface.cpp:100:15: error: use of undeclared identifier "EVP_PKEY_MO_ENCRYPT' [ also ..._DECRYPT' ] and
I did a few hours of checking online and I think some .h file needs headers? Two threads started already and I do not know where else to post it... firefox works as well but, one issue is it not playing sound...
Don't go mixing ports and packages. There's been some debate about how safe that is. There's some consensus that it's reasonably safe if the versions are not too far apart, but still plenty of caveats and other details to pay attention to.

A good general strategy is to decide from get-go (like at time of a fresh installation) if you're gonna be on ports or packages. If you go with pkg from get-go, then using pkg-upgrade is relatively safe and easy to solve. But if you want to use ports - then stick with ports. If you go between the two, you're gonna end up in a proverbial train wreck of endlessly resolving incompatibilities, which will only pile up recursively.

Linux suffers from the exact same dependency hell, BTW. Upgrading anything at all on a Linux or a BSD machine - that really means a fresh reinstall of the entire machine. I personally stick to ports, I have my reasons for that preference.
 
Well, now I do have a complaint about pkg 2.0.6.

I was in the middle of compiling my way into KDE 6. A few things that were dependencies of x11/xorg did not compile. Namely devel/spirv-llvm-translator and
devel/libclc. So I used pkg(8) 2.0.6 (which is what I ended up with) to do pkg fetch. That actually went fine, I was able to fetch and install those deps.

Problem is:

When I got to deve/qca, it did not compile for me. (I'm using a ports snapshot from March 6). I thought I'd do pkg fetch deve/qca-qt6, and got hit by the following errors:
Code:
pkg: An error occured while fetching package: Unknown error
pkg: An error occured while fetching package: Unknown error
repository FreeBSD has no meta file, using default settings
pkg: An error occured while fetching package: Unknown error
pkg: An error occured while fetching package: Unknown error
pkg: An error occured while fetching package: Unknown error
pkg: An error occured while fetching package: Unknown error
Unable to update repository FreeBSD
Error updating repositories!

Thing is, using pkg successfully was just a few hours prior to the error messages! I did not edit pkg.conf or /etc/pkg/FreeBSD.conf. I have a hard time believing that the online repo's meta file has disappeared in just a few hours. Even if it needed to be refreshed on my end of things. But maybe refreshing that metafile is somehow messed up with pkg 2.0.x?

I was able to resolve the compilation error by making the package on another 14.2-RELEASE machine, but this is making me plenty suspicious of pkg 2.0.x... 😩
 
I was able to resolve the compilation error by making the package on another 14.2-RELEASE machine, but this is making me plenty suspicious of pkg 2.0.x... 😩
Well it could be worst ... i have freshly installed 14.2 STABLE - only sudo and drm-515-kmod installed ... i want to install xf86-video-amdgpu and pkg is forcing me to download 5GB and and install 122 packages .
pkg install xf86-video-amdgpu
Code:
root@kodasBSD:/usr/ports/graphics/drm-515-kmod # pkg install xf86-video-amdgpu
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 122 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
...

Number of packages to be installed: 122

The process will require 5 GiB more space.
813 MiB to be downloaded.

Proceed with this action? [y/N]:

Code:
root@kodasBSD:/usr/ports/ports-mgmt/pkg # pkg info -a -o
bsddialog-1.0.4                devel/bsddialog
drm-515-kmod-5.15.160.1402504_3 graphics/drm-515-kmod
gettext-runtime-0.23.1         devel/gettext-runtime
gettext-tools-0.23.1           devel/gettext-tools
gmake-4.4.1                    devel/gmake
gpu-firmware-amd-kmod-navi14-20230625.1401000_2 graphics/gpu-firmware-amd-kmod
indexinfo-0.3.1_1              print/indexinfo
libffi-3.4.6                   devel/libffi
libtextstyle-0.23.1            devel/libtextstyle
mpdecimal-4.0.0                math/mpdecimal
pkg-2.0.6                      ports-mgmt/pkg
pkgconf-2.3.0,1                devel/pkgconf
portconfig-0.6.2               ports-mgmt/portconfig
python311-3.11.11              lang/python311
readline-8.2.13_2              devel/readline
sudo-1.9.16p2_1                security/sudo

Reinstall of pkg wont help.
 
Well it could be worst ... i have freshly installed 14.2 STABLE - only sudo and drm-515-kmod installed ... i want to install xf86-video-amdgpu and pkg is forcing me to download 5GB and and install 122 packages .
pkg install xf86-video-amdgpu
Code:
root@kodasBSD:/usr/ports/graphics/drm-515-kmod # pkg install xf86-video-amdgpu
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 122 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
...

Number of packages to be installed: 122

The process will require 5 GiB more space.
813 MiB to be downloaded.

Proceed with this action? [y/N]:

Code:
root@kodasBSD:/usr/ports/ports-mgmt/pkg # pkg info -a -o
bsddialog-1.0.4                devel/bsddialog
drm-515-kmod-5.15.160.1402504_3 graphics/drm-515-kmod
gettext-runtime-0.23.1         devel/gettext-runtime
gettext-tools-0.23.1           devel/gettext-tools
gmake-4.4.1                    devel/gmake
gpu-firmware-amd-kmod-navi14-20230625.1401000_2 graphics/gpu-firmware-amd-kmod
indexinfo-0.3.1_1              print/indexinfo
libffi-3.4.6                   devel/libffi
libtextstyle-0.23.1            devel/libtextstyle
mpdecimal-4.0.0                math/mpdecimal
pkg-2.0.6                      ports-mgmt/pkg
pkgconf-2.3.0,1                devel/pkgconf
portconfig-0.6.2               ports-mgmt/portconfig
python311-3.11.11              lang/python311
readline-8.2.13_2              devel/readline
sudo-1.9.16p2_1                security/sudo

Reinstall of pkg wont help.
You might want to re-read the messages a bit more carefully:
The process will require 5 GiB more space. 813 MiB to be downloaded.
813 MB worth of stuff will be actually downloaded. Once installed, that's when it will take up 5 GB of HDD/SSD space.

But if you have only the listed stuff (16 packages) installed, then yeah, the Xorg driver for amdgpu (x11-drivers/xf86-video-amdgpu) will want to pull in everything it needs. Even the basic Xorg install on FreeBSD (with TWM, XTerm, and the like) willl be over 200 packages total. This is just how dependency resolution works, it's normal.
 
You might want to re-read the messages a bit more carefully:

813 MB worth of stuff will be actually downloaded. Once installed, that's when it will take up 5 GB of HDD/SSD space.

But if you have only the listed stuff (16 packages) installed, then yeah, the Xorg driver for amdgpu (x11-drivers/xf86-video-amdgpu) will want to pull in everything it needs. Even the basic Xorg install on FreeBSD (with TWM, XTerm, and the like) willl be over 200 packages total. This is just how dependency resolution works, it's normal.
Yeah, my bad ... i read one i wrote something else lol.
Oh, i never thought about amd drivers pulling xorg.
 
Oh, i never thought about amd drivers pulling xorg.
Well, name of the package should be a hint. Xorg needs that specific package to be able to run (x11-drivers/xf86-video-amdgpu). That package is for Xorg to interface correctly with amdgpu.ko driver that is installed bygraphics/drm-kmod. There are a few more x11-drivers/xf86-video-NNN drivers in existence, they were written at a time when GPU drivers were simpler and less diverse. If you run Wayland, you don't need the x11-drivers/xf86-video-NNN drivers. If you run Xorg, you do, and the correct one depends on the GPU you have.
 
Not to go too off topic, but this march KDE upgrade hosed falkon loading here and it will not compile: /usr/ports/www/falkon/work-kf6/falkon-24.12.3/src/lib/tools/aesinterface.cpp:100:15: error: use of undeclared identifier "EVP_PKEY_MO_ENCRYPT' [ also ..._DECRYPT' ] and
I did a few hours of checking online and I think some .h file needs headers? Two threads started already and I do not know where else to post it... firefox works as well but, one issue is it not playing sound...
That errror resolved by uninstalling
security/boringssl ... still remains to see if the port build will fix it. Taking a good while. [ a dependency that is, for falkon that
gdb caught from the
falkon.core I gave it... for which no package was available ]
 
That errror resolved by uninstalling
boringssl ... still remains to see if the port build will fix it. Taking a good while. [ a dependency that is, for falkon that
gdb caught from the
falkon.core I gave it... for which no package was available ]
it's not [PORT] boringssl [/PORT], but [PORT]security/boringssl[/PORT]...

And this is another reason why I do ports - I can specify in /etc/make.conf to compile everything with OpenSSL (security/openssl), and override the flags specified in pre-compiled packages.
 
Well, name of the package should be a hint. Xorg needs that specific package to be able to run (x11-drivers/xf86-video-amdgpu). That package is for Xorg to interface correctly with amdgpu.ko driver that is installed bygraphics/drm-kmod. There are a few more x11-drivers/xf86-video-NNN drivers in existence, they were written at a time when GPU drivers were simpler and less diverse. If you run Wayland, you don't need the x11-drivers/xf86-video-NNN drivers. If you run Xorg, you do, and the correct one depends on the GPU you have.
I run Xorg but I do not have installed x11-drivers/xf86-video-amdgpu few years and everything works.
 
Well it could be worst ... i have freshly installed 14.2 STABLE - only sudo and drm-515-kmod installed ... i want to install xf86-video-amdgpu and pkg is forcing me to download 5GB and and install 122 packages .
pkg install xf86-video-amdgpu
Code:
[/QUOTE]
I have drm-61-kmod and I do not need tons of packages.[ATTACH type="full" size="1059x561"]21910[/ATTACH]
 

Attachments

  • p.gif
    p.gif
    35.3 KB · Views: 25
I run Xorg but I do not have installed x11-drivers/xf86-video-amdgpu few years and everything works.
How about tear-free rendering? or anti-aliasing of fonts? or YT? In Xorg, graphics are a lot smoother if you install that Xorg driver. The x11-drivers/xf86-video-amdgpu is used to offload a lot of graphical tasks to the GPU via amdgpu.ko. Just because everything works without that driver doesn't mean it's useless. And, as you mentioned, the Xorg driver is just 63 KiB...
 
Back
Top