- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 10 2023
Oct 9 2023
No longer needed, especially after the openssl crates have finally been updated in Cargo.lock for the past couple releases now. Also the syncing process is rather involved.
add comment to upstream patches noting LLVM 17 compatibility fixes
Oct 8 2023
- silence REINPLACE_CMD and clean up _RUST_BUILD_WASM
Oct 7 2023
In D32654#960813, @diizzy wrote:What's the real life approach with this change?
Saving cycles by using an external LLVM rather than compiling the entire bundled copy.
Are we going to stick to using default version in ports tree of LLVM?
The bundled LLVM remains the default option, this is merely a use-at-own-risk convenience for those who want/have to build themselves.
If doable is that supported by upstream and if not who is going to take care of fallouts? If not, are we going to track upstream instead and is it worth the effort of unbundling LLVM as there like will be a handful of ports depending on the same (recent) version of LLVM?
The situation has changed drastically when this option was removed. Back then, which was during the LLVM 6.0/7.0 era, rust tracked LLVM trunk and was thus more sensitive to interactions between them, as evidenced with the small API breakage that eventually lead to the option removal. Starting with LLVM 8.0 and the advent of llvm-wrapper, rust switched to tracking releases with cherry-picking existing bug fix commits, much like we do with our base LLVM. Concurrently and consequently, external LLVM support has improved, with upstream tracking which LLVM version ranges work with each rust release.
Oct 5 2023
Sep 28 2023
Sep 26 2023
update/add LLVM 17 support/pieces
Sep 25 2023
rename back to PORT_LLVM, not least because USES=llvm claims the variable name. Per upstream, minimum external LLVM supported is 14; next major Rust version (1.73) bumps to 15. For this version (1.72), two upstream commits included to fix LLVM 17 API compatibility.
got it to work (consumers included), incoming
Sep 17 2023
Sep 14 2023
Sep 12 2023
Sep 4 2023
Sep 3 2023
Aug 31 2023
Aug 26 2023
Aug 24 2023
use merge request patch + missed spot
Aug 18 2023
Aug 5 2023
Aug 1 2023
Jul 25 2023
Jul 18 2023
Jul 13 2023
Jul 7 2023
Jun 28 2023
Jun 27 2023
Jun 26 2023
And PORTNAME should match that, without deviation.
Not a good idea. I deliberately left something like this out for conformance and security/integrity reasons.
Jun 25 2023
Jun 24 2023
Jun 19 2023
bad arc bad
- devel/wasi-{compiler-rt,libcxx}16: sync with devel/llvm16 16.0.6
In D40568#924210, @rene wrote:The fact that USES=python skips 2.7 is a bit of inside knowledge.
Jun 18 2023
- gecko-esr: limit to LLVM 15 due to old proc-macro2 crate
- MOVED: remove stray conflict mark
- devel/wasi-libc: update to wasi-sdk-20
- devel/wasi-{compiler-rt,libcxx}16: sync with devel/llvm16
- devel/wasi-libcxx: fix LICENSE_FILE location
- bsd.gecko.mk: remove LLVM version restriction
Jun 15 2023
For stuff that is declared compatible (upstream that is) with at least our (soon-to) minimum Python version, we may be better off discarding the explicit USES=python:3.8+ etc, since it will have already been defined in python.mk.
Jun 10 2023
bad arcanist bad
update to 6.0.2, update messages and comments
Jun 9 2023
Jun 7 2023
Jun 3 2023
May 26 2023
May 25 2023
May 24 2023
May 23 2023
May 20 2023
May 18 2023
May 14 2023
- www/librewolf: adjust WASI dependencies
Superseded by D40098
Superseded by D40098
Superseded by D40098
Superseded by D40098
- MOVED: add forgotten devel/wasi-compiler-rt11
12 is the minimum supported LLVM version.
May 7 2023
Also works with Intel/modesetting only on the PRIME-capable machine after updating libudev-devd. Still need to see about actually configuring PRIME on it, but that's a separate thread.
Yeah I was indeed using a libudev-devd from a revision newer than 0.5.0 but not 0.5.1. The single Intel GPU machine, a Seeedstudio Odyssey, which has HDMI as its only video out, works after updating. Still need to test the other machine.
May 6 2023
Even on Linux there were no files in xorg.conf.d (or xorg.conf for that matter) necessary for modesetting to work by default on an Intel GPU. Back when I ran Linux on the PRIME-capable machine, I had a very skeleton xorg.conf like so to enable PRIME offloading:
Section "Module"
Load "modesetting"
EndSectionNeither of these systems have xorg.conf, and should never have one if only using modesetting on the Intel GPU. Nothing in xorg.conf.d either. Shipping 20-intel.conf may be a good idea, but users should not be creating files for a default configuration that has worked for time.
May 5 2023
Also fails on a system with only one GPU, an Intel integrated:
[ 76.839]
X.Org X Server 1.21.1.8
X Protocol Version 11, Revision 0
[ 76.839] Current Operating System: FreeBSD lehman 14.0-CURRENT FreeBSD 14.0-CURRENT #4 main-n262658-b347c2284603: Sat Apr 29 09:15:44 EDT 2023 root@lehman:/usr/obj/usr/src/amd64.amd64/sys/ODYSSEY amd64
[ 76.839]
[ 76.839] Current version of pixman: 0.42.2
[ 76.839] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 76.840] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 76.841] (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 5 18:03:36 2023
[ 76.841] (==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
[ 76.842] (==) No Layout section. Using the first Screen section.
[ 76.842] (==) No screen section available. Using defaults.
[ 76.842] (**) |-->Screen "Default Screen Section" (0)
[ 76.842] (**) | |-->Monitor "<default monitor>"
[ 76.843] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 76.843] (==) Automatically adding devices
[ 76.843] (==) Automatically enabling devices
[ 76.844] (==) Automatically adding GPU devices
[ 76.844] (==) Automatically binding GPU devices
[ 76.844] (==) Max clients allowed: 256, resource mask: 0x1fffff
[ 76.844] (==) FontPath set to:
/usr/local/share/fonts/misc/,
/usr/local/share/fonts/TTF/,
/usr/local/share/fonts/OTF/,
/usr/local/share/fonts/Type1/,
/usr/local/share/fonts/100dpi/,
/usr/local/share/fonts/75dpi/,
catalogue:/usr/local/etc/X11/fontpath.d
[ 76.844] (==) ModulePath set to "/usr/local/lib/xorg/modules"
[ 76.844] (II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 76.844] (II) Module ABI versions:
[ 76.844] X.Org ANSI C Emulation: 0.4
[ 76.844] X.Org Video Driver: 25.2
[ 76.844] X.Org XInput driver : 24.4
[ 76.845] X.Org Server Extension : 10.0
[ 76.856] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 76.856] (II) Platform probe for /dev/dri/card0
[ 76.868] (--) PCI:*(0@0:2:0) 8086:3185:8086:2212 rev 3, Mem @ 0xa0000000/16777216, 0x90000000/268435456, I/O @ 0x0000f000/64, BIOS @ 0x????????/65536
[ 76.868] (II) LoadModule: "glx"
[ 76.869] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[ 76.872] (II) Module glx: vendor="X.Org Foundation"
[ 76.872] compiled for 1.21.1.8, module version = 1.0.0
[ 76.872] ABI class: X.Org Server Extension, version 10.0
[ 76.872] (==) Matched intel as autoconfigured driver 0
[ 76.872] (==) Matched modesetting as autoconfigured driver 1
[ 76.872] (==) Matched scfb as autoconfigured driver 2
[ 76.872] (==) Matched vesa as autoconfigured driver 3
[ 76.872] (==) Assigned the driver to the xf86ConfigLayout
[ 76.872] (II) LoadModule: "intel"
[ 76.874] (WW) Warning, couldn't open module intel
[ 76.874] (EE) Failed to load module "intel" (module does not exist, 0)
[ 76.874] (II) LoadModule: "modesetting"
[ 76.874] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
[ 76.876] (II) Module modesetting: vendor="X.Org Foundation"
[ 76.876] compiled for 1.21.1.8, module version = 1.21.1
[ 76.876] Module class: X.Org Video Driver
[ 76.876] ABI class: X.Org Video Driver, version 25.2
[ 76.876] (II) LoadModule: "scfb"
[ 76.877] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
[ 76.877] (II) Module scfb: vendor="X.Org Foundation"
[ 76.877] compiled for 1.21.1.8, module version = 0.0.5
[ 76.877] ABI class: X.Org Video Driver, version 25.2
[ 76.877] (II) LoadModule: "vesa"
[ 76.878] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so
[ 76.878] (II) Module vesa: vendor="X.Org Foundation"
[ 76.878] compiled for 1.21.1.8, module version = 2.5.0
[ 76.878] Module class: X.Org Video Driver
[ 76.878] ABI class: X.Org Video Driver, version 25.2
[ 76.879] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 76.879] (II) scfb: driver for wsdisplay framebuffer: scfb
[ 76.879] (II) VESA: driver for VESA chipsets: vesa
[ 76.879] (--) Using syscons driver with X support (version 2.0)
[ 76.879] (--) using VT number 9This seems to break setups with an additional video card designed for but not yet configured for PRIME:
(EE) Fatal server error: (EE) AddScreen/ScreenInit failed for gpu driver 0 -1
All without any xorg.conf.