Linux ports in FreeBSD is very outdated. Time to create new ports with newer GLIBC. For base we can get Rocky Linux (AlmaLinux?) 8 or even 9. Or Ubuntu 22.04. I can't create all work self - too complicated, but I can help with some parts.
You could start working on this in a branch on GitHub and post the link there. I'll certainly help you at some point.
I don't even know where to start…
(In reply to VVD from comment #2) I'd start with adding "c8" support into Mk/Uses/linux.mk. Go through the file, extend current ".if ${linux_ARGS} == c7" blocks with new ".elif ${linux_ARGS} == c8". Add appropriate MASTER_SITES. Then try creating emulators/linux_base-c8 port by looking at existing linux_base-c7. After that we can start iterating over existing linux_* ports.
CentOS is "dead". It became rolling. There is no point in switching to CentOS 8. IMHO, time to move to Rocky Linux.
CentOS 8 is not yet rolling, from what I can tell? It is CentOS Stream that became a rolling one?
Even more - CentOS 8 is EOL already. https://www.centos.org/centos-linux-eol/ https://www.mail-archive.com/centos-announce@centos.org/msg11991.html
Oh, hum. Then yes, we need something else. Ubuntu LTS?
I also agree that the Centos environment is very outdated. My opinion, among the different versions of Linux, I would prefer to use Ubuntu. Because the use of the Ubuntu environment has already been tested many times. For example, https://forums.freebsd.org/threads/linuxulator-how-to-install-brave-linux-app-on-freebsd-13-0.78879/. I myself have also repeatedly tested several applications in the Ubuntu environment https://ulbsd.ru/shop/view/article/175.
(In reply to Serge Volkov from comment #8) > pkg install debootstrap pulseaudio With pulseaudio my sound is broken. And use 22.04, not 20.04.
(In reply to VVD from comment #9) I installed the Yandex browser a few days ago. And updated the instructions at this link https://ulbsd.ru/shop/view/article/175. With my configs and settings, the sound in the Yandex browser works. Perhaps this is due to the fact that I did not install the package on a clean FreeBSD, but on ULBSD. It has several hundred different packages installed. But the base system is FreeBSD 13.1 RELEASE-p7, latest KDE Plasma 5. And I also set the Ubuntu 22.04 (jammy) environment.
Another candidate is https://rockylinux.org which is a continuation of CentOS 7 philosophy. Red Hat packets, not a rolling release, support until 2027. Switching to it should also be a matter of changing MASTER_SITES and bumping ports versions.
FWIW, a long time ago I've started the https://reviews.freebsd.org/D30788 to add emulators/linux_base-ubuntu; it might be useful as a starting point. The main problem, from what I remember, is that most Linux apps we care about, like Steam, are still 32-bit only, and I can't say I understand Ubuntu's idea of handling 32 bit libraries.
Not that I can contribute anything, because I am not a developer, but the problem is definitely there and affects not just "some software", but probably a lot of Linux games, if not to say all of them, which are a bit newer. The other day I just wanted to check out this one: https://unvanquished.net/ and I got a glibc error using the Linux installer and also the binary. I also assume that many Linux games from Steam do not start either because of this. So as an end user, I definitely support the idea here to implement another Linuxulator. Ideally, it should be able to install and run the official Linux Steam binary directly. Apparently, Steam officially supports Ubuntu LTS, so maybe that would be the way to go?
I've started work on bringing in Rocky Linux. My WIP branch is here [1]. Testers and contributors are welcome. [1] https://github.com/arrowd/freebsd-ports/tree/rocky
Great! Can you please provide instructions for testing, assuming the creation and utilization of a 13.2-RELEASE virtual machine?
I would like to propose to base on Debian Stable https://www.debian.org. It's a completely community-driven distribution.
Re: (a) current options and uncertainties and (b) ultimate decision-making – and everything that might fall between (a) and (b) – I'm not sure that a single bug report in Bugzilla will be ideal for what might become a sprawling discussion. I'll have a chat in #freebsd-bugs about this one. The compat-linux alias and the tracking keyword might move to a different report in due course.
The addition of Rocky Linux 9 ports is posted in this PR: https://github.com/freebsd/freebsd-ports/pull/255 Tijl, would you mind looking at it?
I'm not tijl, but I'm the one who wrote (years ago) the base of the linux userland stuff which we have today (which has a lot of good improvements since then). What I looked at: - the Mk files - if source rpms are in the distinfo - if config files are "fall through to FreeBSD config where possible" What I noticed: - pulseaudio doesn't use the FreeBSD config, I assume due to the disable of shm. I suggest a pkg-message to notify the user that the config is not fall-through (and why). - libtracker-sparql has no src rpm listed in the distinfo - nspr has no src rpm listed - libglvnd has etc config dirs instead of a fall through to FreeBSD, on purpose or an oversight? - ca-certificates: the etc part needs to be fall through, having the stock CAs there in case the user has modified stuff in the corresponding FreeBSD side is security relevant. - nss: don't know what the etc part specifies, but maybe likewise to the ca-certificates comment - fontconfig: etc and var/db/fontconfig fall through is missing - libusb: I'm surprised about .if ${ARCH} == amd64 && ${FLAVOR:Mc7} ONLY_FOR_ARCHS+= i386 I would have expected a +=i386 in the c7 case alone. Am I misunderstanding something that this doesn't make sense to me? - openal-soft: no fall through. I'm on the edge here. A part of me agrees to no fall through, a part of me doesn't. Something like pulseaudio is sort of mainstream and may already be installed on the FreeBSD side (= fall through), openal doesn't look mainstream and a missing config may lead to a bad user experience. - dbus-libs and some others: PORTREVISION is set, for some of them I see a correlation with the rpm name (some kind of package revision there too), but it is handled inconsistently and will diverge in case some port stuff needs to be fixed. If this is for your local install and it will go away on a version increment: ignore this comment. - linux-r19: the comment says it's centos - vulkan: no fall through - libvdpau: no fall through. - r7-office + linux-chrome: I suggest to do a separate commit for this, not as part of the r19 introduction into the ports tree. Generic note: we don't install the corresponding FreeBSD port if we have a config fall through. This only matters if the actual software is used instead of simply part of the linux base. Personally I didn't care much about this case, when I needed something I simply installed it, but maybe we want to rethink what we do here (I do not consider this in-scope of this PR, I simply mention it for completeness).
(In reply to Alexander Leidinger from comment #19) I forgot: I didn't give this a try on a machine, but I didn't see an obvious issue in the Mk files.
(In reply to Alexander Leidinger from comment #19) Thanks for the review. > pulseaudio doesn't use the FreeBSD config, I assume due to the disable of shm. I suggest a pkg-message to notify the user that the config is not fall-through (and why). That's correct and I don't think this deserves any explanation. The config's content itself makes it obvious why is it needed. > libtracker-sparql has no src rpm listed in the distinfo Fixed. > nspr has no src rpm listed Fixed. > libglvnd has etc config dirs instead of a fall through to FreeBSD, on purpose or an oversight? I have no idea, to be honest, but I fixed that. > ca-certificates: the etc part needs to be fall through, having the stock CAs there in case the user has modified stuff in the corresponding FreeBSD side is security relevant. I don't have /usr/local/etc/pki and I don't remember having it ever. FreeBSD native nss package doesn't install this directory either. This port also follows its c7 counterpart in this regard. So, I believe, this package should not fallthrough. > nss: don't know what the etc part specifies, but maybe likewise to the ca-certificates comment Likewise, I don't think it should fallthrough. > fontconfig: etc and var/db/fontconfig fall through is missing It follows what c7 port does > libusb: I'm surprised about > ... Fixed. > openal-soft: no fall through. I'm on the edge here. A part of me agrees to no fall through, a part of me doesn't. Something like pulseaudio is sort of mainstream and may already be installed on the FreeBSD side (= fall through), openal doesn't look mainstream and a missing config may lead to a bad user experience. Yes, I also not sure what to do in all these cases. All I know is that all this stuff is arrange correctly enough to run such heavy applications as Linux Chrome and R7 Office. I'd leave it as it is for now until we bump into problems/bug reports. > dbus-libs and some others: PORTREVISION is set, for some of them I see a correlation with the rpm name (some kind of package revision there too), but it is handled inconsistently and will diverge in case some port stuff needs to be fixed. No, there is no correlation. We've been running these ports for a long time at $WORK and decided to upstream this now. I spent a lot of time grooming the history and squashing commits, so these PORTREVISIONs are the remnants of this process that I missed. But they don't hurt anyways. > linux-r19: the comment says it's centos Fixed. > vulkan: no fall through > libvdpau: no fall through. Didn't change that for the same reasons. > r7-office + linux-chrome: I suggest to do a separate commit for this, not as part of the r19 introduction into the ports tree. These are already separate commits in the pull request.
IMO: commit it. Any issues can be fixed afterwards (it's not the default linux base). Again IMO: - fontconfig should fall through (no matter if centos or rocky). It was in the past, got changed after the versions diverged too much (binary incompatibility of something generated stuff), and should fall through when compatible. - certs may have not a pki directory, but we install the cert bundle (to LOCALBASE/share/certs/ca-root-nss.crt) and we have the trusted/... stuff in /etc/. I'm sure there is the possibility to fall through. But see the next point. - I fully agree with you to commit it in the same state as c7.
Fixed with addition of Rocky Linux 9 ports.