FreeBSD Kommunity Edition

Is there demand for a "FreeBSD Kommunity Edition"?

  • Yes, sure

    Votes: 21 19.6%

  • Likely

    Votes: 12 11.2%

  • Maybe

    Votes: 10 9.3%

  • Doubtfully

    Votes: 10 9.3%

  • No

    Votes: 44 41.1%

  • Don't know

    Votes: 10 9.3%
  • Total voters
    107
Any package can "disappear" any time. There's no way to ensure every single port always builds successfully, so when creating a repository, you need a strategy to handle that. FreeBSD's strategy is to just ignore the failed port and its dependencies (avoiding the risk that would come with mixing older builds of the same package into the newer repository).

So, when a package is missing, it will normally be back at most a few days later.
 
grahamperrin said:
Needs exist.
Click to expand...
You are correct, Sir.

I was one of those people in need of a preinstalled desktop when I started. I stated with Linux and ran the disco circuit for a time, but I wasn't a disco boy.

I was a newly hatched nerdling who wanted to use FreeBSD. It being linked to UNIX and Ma Bell was impressive to me. And chicks dig guys who wear pocket protectors. But the installer intimidated me and looked beyond my skillset. Which it wouold have been once I hit the terminal.

In 2005 while browsing Live CD Operating Systems I spotted one based on FreeBSD that came with KDE installed by default. Yumpin Yimminy, that's just what I needed and once I got to the desktop I joined the forums and became a beta tester.

I'm not opposed to FreeBSD ready rolled desktop spinoffs at all. I just don't want it forced on me by it being introduced into the base system. Chicks dig my pocket protector.
 
It is back in the packages. I installed it, 433 packages.
It certainly is beautiful. And loads of things you can configure.
Really, it is a bit over the top and unnecessary. Think I'll do without it.
But I did get a cup of tea.
 
astyle said:
That's Xorg, right? What are we gonna do when Wayland gets stabilized? Or when KDE finally migrates to QT 6?
Click to expand...
According to this, Qt6 still supports X11

Qt for Linux/X11 | Qt 6.8

Platform support for Linux/X11.
doc.qt.io doc.qt.io

I doubt that support will be dropped any time soon. Although it is hard to say when Wayland from what I understand just got a lot more stable recently on FreeBSD, so much so you can have a decent session that actually runs now.
 
Samuel Venable said:
According to this, Qt6 still supports X11

Qt for Linux/X11 | Qt 6.8

Platform support for Linux/X11.
doc.qt.io doc.qt.io

I doubt that support will be dropped any time soon. Although it is hard to say when Wayland from what I understand just got a lot more stable recently on FreeBSD, so much so you can have a decent session that actually runs now.
Click to expand...
Just tootin' my own horn here :P. My point is, with those major migrations happening, maintenance will quickly become a headache, even with all the possible automation assistance.
 
Thanks,

Samuel Venable said:
… dd img of FreeBSD 13.0-RELEASE + KDE Plasma on a 64gb usb stick …
Click to expand...

How might I try the image file with VirtualBox?

VBoxManage convertfromraw …, maybe? <https://www.virtualbox.org/manual/ch08.html#vboxmanage-convertfromraw>

Code: 
% cd /Volumes/t500
% du -h FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img.xz
7.4G    FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img.xz
% sha256 FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img.xz
SHA256 (FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img.xz) = 9933cbbaa57784d559d14ad6958b2fd4e1ec2d09080fcd74d0aba1eae89cbf2f
% du -h VirtualBox/BSD/FreeBSD/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img
9.2G    VirtualBox/BSD/FreeBSD/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img
% ls -hl VirtualBox/BSD/FreeBSD/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img
-rw-r--r--  1 grahamperrin  grahamperrin    57G 22 May 02:02 VirtualBox/BSD/FreeBSD/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img
% zfs get compression Transcend Transcend/VirtualBox
NAME                  PROPERTY     VALUE           SOURCE
Transcend             compression  zstd-15         local
Transcend/VirtualBox  compression  zstd-10         local
%
 
grahamperrin said:
Thanks,



How might I try the image file with VirtualBox?

VBoxManage convertfromraw …, maybe? <https://www.virtualbox.org/manual/ch08.html#vboxmanage-convertfromraw>

Code: 
% cd /Volumes/t500
% du -h FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img.xz
7.4G    FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img.xz
% sha256 FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img.xz
SHA256 (FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img.xz) = 9933cbbaa57784d559d14ad6958b2fd4e1ec2d09080fcd74d0aba1eae89cbf2f
% du -h VirtualBox/BSD/FreeBSD/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img
9.2G    VirtualBox/BSD/FreeBSD/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img
% ls -hl VirtualBox/BSD/FreeBSD/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img
-rw-r--r--  1 grahamperrin  grahamperrin    57G 22 May 02:02 VirtualBox/BSD/FreeBSD/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img
% zfs get compression Transcend Transcend/VirtualBox
NAME                  PROPERTY     VALUE           SOURCE
Transcend             compression  zstd-15         local
Transcend/VirtualBox  compression  zstd-10         local
%
Click to expand...
As long as you extracted the xz file convertfromraw should work. Either that or convertdd. I'm not sure which one is more correct. To be warned, it has a few extra things installed like neofetch, java, zenity, and several other things I threw in there for my specific needs/preferences. But it's not a huge or noticeable difference. All the KDE settings are mostly default, though I forced hibernate/sleep to not happen automatically when idle. If you want to have sleep enabled you'll need to turn that back on.

The default driver I am using is scfb. So if that happens to not be the right driver fro your machine /usr/local/etc/X11/xorg.conf.d/scfb-driver.conf iirc is the file that should be removed and replaced with the appropriate driver. VirtualBox works with the default xorg driver so removing that file should be enough.

virtualbox-ose-guest-addtions also needs to be installed/configured for mouse stuff. If you want I can convert it with all that setup so you won't need to do so.
 
Samuel Venable said:
… convertfromraw should work …
Click to expand...

It did (below).

I have some additional comments, however this topic will soon reach eight pages, much of which was off-topic from KDE so (given the milestone) here's a spin-off:

forums.freebsd.org

Solved - FreeBSD-13.0-RELEASE-amd64-KDE-Plasma (2021-05-22)

Spun off from , thanks in particular to: Mjölnir for beginning the discussion Samuel Venable for creating the disk image. General comments and questions hald_enable="YES" can be removed from /etc/rc.conf – HAL is retired. I'm curious about the 311 M given to the EFI system partition...
forums.freebsd.org forums.freebsd.org

Thanks again.


For reference only, a record of conversion from .img to .vhd (plus file system compression levels, and so on):

Code: 
% pwd
/Volumes/t500/VirtualBox/BSD/FreeBSD/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma
% ls -hl
total 9469
-rw-r--r--  1 grahamperrin  grahamperrin    57G 22 May 02:02 FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img
-rw-------  1 grahamperrin  grahamperrin   2.1K 22 May 03:26 FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vbox
-rw-------  1 grahamperrin  grahamperrin   2.3K 22 May 03:26 FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vbox-prev
% zfs get compression Transcend Transcend/VirtualBox
NAME                  PROPERTY     VALUE           SOURCE
Transcend             compression  zstd-15         local
Transcend/VirtualBox  compression  zstd-19         local
% time VBoxManage convertfromraw ./FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vdi
Converting from raw image file="./FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img" to file="FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vdi"...
Creating dynamic image with size 61530439680 bytes (58680MB)...
11.070u 47.558s 57:02.79 1.7%   1055+177k 205481+222316io 4pf+0w
% ls -hl FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.v
FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vbox       FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vbox-prev  FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vdi      
% ls -hl FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vdi
-rw-------  1 grahamperrin  grahamperrin    22G 22 May 04:24 FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vdi
% du -h FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vdi
9.1G    FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.vdi
% sudo zfs set compression=zstd-10 Transcend/VirtualBox
grahamperrin's password:
% rm FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img
% cd
% du -h /Volumes/t500/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img.xz
7.4G    /Volumes/t500/FreeBSD-13.0-RELEASE-amd64-KDE-Plasma.img.xz
%
 
My frustration is inability to upgrade KDE without reinstalling the entire system from scratch. I only have one FreeBSD system, no $ to build another. With the way the ports system is organized, chasing down the errors that result from trying to upgrade an existing install - it's more than I have the time and patience for. Installing for the first time - that goes sweet and easy, deps get chased down by scripts. But upgrading - that invites dependency hell. One way to deal with that (that has been suggested elsewhere on these forums) was to use prebuilt packages from another compatible system. But if I want to compile my own - I'll need to build another system of my own, and set it up to spit out upgrade packages that I install with pkg-ng. Short of spinning up a VM to do the building, I don't see a good way to do an easy upgrade of KDE. Any suggestions?
 
Do you even have issues when you using the latest repository after installing and follow the weekly updates?

I can image that some configuration can get minimal broken if the version is too far away.

But even if there is such a case is should be enough to clean the files under $HOME.
 
Alexander88207 said:
Do you even have issues when you using the latest repository after installing and follow the weekly updates.

I can image that some configuration can get minimal broken if the version is too far away.
Click to expand...
Thing is, I want to download and compile using the ports. The prebuilt stuff is compiled with minimal options, and that doesn't work for me.
 
Alexander88207 said:
Do you like to describe more the case?
Click to expand...
yeah... I have just one FreeBSD system (A rig with nice specs that I made from aftermarket parts). I used portsnap and some strategic ZFS snapshotting to bring in a ports snapshot from July 2. That snapshot contains KF5 v. 5.82 and Plasma5 v. 5.22.1. Trouble is, while Plasma5 v. 5.22.1 compiled and installed just fine, it keeps crashing when I try to start Wayland. I did some research on the issue, and figured out that upgrading to Plasma5 v.5.23.3 (which by now is in packages, and therefore definitely in ports) should solve my issue. Unfortunately, just using portsnap to update the entire ports tree on my system was not what I needed to do. I assumed that the make scripts will chase down the deps for me as usual - no go. It was unpredictable which already-installed packages/config files would be accepted by Make - and which ones would result in a failure.

FWIW, it takes my processor (Ryzen 5 1400, 3.4 Ghz) about 24 hours of compiling to get to even a basic Plasma Wayland desktop. And that does not include the time spent downloading the proper sources, which add up to about 30GB worth of tarballs. In total, about 3 days' work goes down the drain.
 
astyle said:
Short of spinning up a VM to do the building, I don't see a good way to do an easy upgrade of KDE. Any suggestions?
Click to expand...
This is an ideal use-case for a FreeBSD Jail.

Building from ports outside of a Jail tends to spam your system with "build-time" packages which you don't need to just run the software. You are also more likely to run into non-deterministic build errors where some ratty build script has detected an optional component so has utilised it without registering the dependency in the package metadata. Maintainers try to guard against this (often by dragging in all possible software features / dependencies) but it still is very easy to get missed.
 
kpedersen said:
This is an ideal use-case for a FreeBSD Jail.

Building from ports outside of a Jail tends to spam your system with "build-time" packages which you don't need to just run the software. You are also more likely to run into non-deterministic build errors where some ratty build script has detected an optional component so has utilised it without registering the dependency in the package metadata. Maintainers try to guard against this (often by dragging in all possible software features / dependencies) but it still is very easy to get missed.
Click to expand...
Looks like playing with FreeBSD's jails until I get a good handle on them is my next time-waster ;)
 
astyle said:
Looks like playing with FreeBSD's jails until I get a good handle on them is my next time-waster ;)
Click to expand...
Heh. They often sound boring at first but once you have put together a couple of scripts to quickly create and destroy instances you start to appreciate how fantastic they function. Like VMs but with zero overhead, can pass through graphics natively and can share the exact same filesystem. They are the future! (since 1999...).
 
astyle said:
My frustration is inability to upgrade KDE without reinstalling the entire system from scratch. I only have one FreeBSD system, no $ to build another. With the way the ports system is organized, chasing down the errors that result from trying to upgrade an existing install - it's more than I have the time and patience for. Installing for the first time - that goes sweet and easy, deps get chased down by scripts. But upgrading - that invites dependency hell. One way to deal with that (that has been suggested elsewhere on these forums) was to use prebuilt packages from another compatible system. But if I want to compile my own - I'll need to build another system of my own, and set it up to spit out upgrade packages that I install with pkg-ng. Short of spinning up a VM to do the building, I don't see a good way to do an easy upgrade of KDE. Any suggestions?
Click to expand...
Another version a jail ?
 
astyle said:
jails
Click to expand...

sysutils/mkjail

kpedersen said:
This is an ideal use-case for a FreeBSD Jail. …
Click to expand...

I'd use ports-mgmt/poudriere-devel, would you?

Then (for example):

Code: 
root@mowa219-gjp4-8570p:~ # poudriere ports -u
[00:00:00] Updating portstree "default" with git+https... done
root@mowa219-gjp4-8570p:~ # poudriere bulk -b latest -j main -c x11/kde5
[00:00:00] Creating the reference jail... done
[00:01:03] Mounting system devices for main-default
[00:01:03] Stashing existing package repository
[00:01:03] Mounting ccache from: /var/cache/ccache
[00:01:03] Mounting ports from: /usr/local/poudriere/ports/default
[00:01:03] Mounting packages from: /usr/local/poudriere/data/packages/main-default
[00:01:03] Mounting distfiles from: /usr/local/poudriere/ports/default/distfiles
[00:01:03] Copying /var/db/ports from: /usr/local/etc/poudriere.d/main-options
[00:01:04] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
/etc/resolv.conf -> /usr/local/poudriere/data/.m/main-default/ref/etc/resolv.conf
[00:01:04] Starting jail main-default
[00:01:05] Logs: /usr/local/poudriere/data/logs/bulk/main-default/2021-07-16_00h54m32s
[00:01:05] Loading MOVED for /usr/local/poudriere/data/.m/main-default/ref/usr/ports
[00:01:06] Ports supports: FLAVORS SELECTED_OPTIONS
[00:01:06] Gathering ports metadata
[00:01:29] Calculating ports order and dependencies
[00:01:30] (-c) Cleaning all packages... done
[00:01:31] Trimming IGNORED and blacklisted ports
[00:01:31] Prefetching missing packages from pkg+http://pkg.FreeBSD.org/${ABI}/latest
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, please wait...
[main-default] Installing pkg-1.16.3...
[main-default] Extracting pkg-1.16.3: 100%
Updating FreeBSD repository catalogue...
[main-default] Fetching meta.conf: 100%    163 B   0.2kB/s    00:01   
[main-default] Fetching packagesite.txz: 100%    6 MiB   6.5MB/s    00:01   
Processing entries: 100%
FreeBSD repository update completed. 30718 packages processed.
All repositories are up to date.
Updating database digests format: 100%
The following packages will be fetched:

New packages to be FETCHED:
        Imath: 3.0.5 (110 KiB: 0.01% of the 2 GiB to download)
…
        zziplib: 0.13.72_1 (103 KiB: 0.01% of the 2 GiB to download)

Number of packages to be fetched: 876

The process will require 2 GiB more space.
2 GiB to be downloaded.
[main-default] Fetching kdepim-21.04.3.txz: 100%    1 KiB   1.4kB/s    00:01   
…
 
I think if some sort of special interests group was formed with enough people in it; a vanilla FreeBSD/KDE release could be fostered and maintained. Thats a lot of work, however.
 
You must log in or register to reply here.
Back
Top