Penned by Anthony J. Bentley on 20260908 6:41.09, we have: | Todd T. Fries writes: | > Bumped to 1.0.1 | > | > Thanks, | > | > Penned by Todd T. Fries on 20260804 7:59.33, we have: | > | Bumped to 0.2.119 .. | > | | > | 1) does it work? | > | | > | ... yes | > | | > | 2) is it /usr/ports ready | > | | > | ... getting there, but not yet | > | | > | 3) has anyone tried it yet? | > | | > | ... crickets | > | | > | 4) is it in openbsd-wip? | > | | > | ... yes | > | | > | ... | > | | > | Feedback welcomed, whatever flavor. | | I took a look at it. I have no objection to porting this software, but | the port itself needs work. It is way too complicated for the poor ports | devs who will inevitably have to dig into it in the future.
It indeed is very much a scaffolding of attempting to get it to work. I'll likely start cleanup next week. You can track my work in openbsd-wip if you know about that. | There are 22 patches and 2 new files/, all of which look AI-generated | (by which I mean, they are VERBOSE). We package all kinds of bloated | crap software, but the ports tree should not contain large diffs of | paragraphs of comments just to change "Linux" to "Linux and OpenBSD". | This software gets updated often, patches often fail to apply when a | port gets updated and need to be manually updated, a lot of chunks of | these patches are unnecessary and will lead to a lot of painful review | during updates, over and over. I did have lots of grok-build help creating and maintaining the grok-build port. I hear and ack the verbosity needs dialed way back to OpenBSD standards. | The unveil code looks wrong. If I read the Rust right (I don't know | Rust) it intentionally avoids readonly unveil of / (an accepted pattern) | in favor of many separate unveils for /bin /sbin /usr and so on (a bad | pattern, because each individual unveil costs system resources). | | The pledge contains inet and exec and rpath wpath cpath. If a process | can't have a narrower promise, it usually is a sign that it's fighting | against pledge. Why not just run this software as an unprivileged user | and let unix permissions do the work? Fair point. The concept of a sandbox could be enhanced with pledge/unveil, but until it is a full fledged support system as opposed to an attempt to fit a square peg with a round hole, I get it. It'll disappear before I submit another iteration to ports@. | The "memeic" flavor is apparently for experimentation and uses your | personal fork... does this flavor really need to be in the ports tree? | The port is already so complicated, the flavor adds PATCH_LIST which | I have literally never seen in a port before in 15 years... Yes, it's my attempt to bolt on a memory solution that context compaction causes. If there was any hope of the ports tree accepting any version of grok-build I can excise it in a heartbeat. Right now, the xAI crew release grok-build updates nearly daily, some days it's tweaks but most days bugs are squashed and features are added. Aka it's a fast moving target, if it escapes openbsd-wip to the ports tree I fear it will be very dated very quickly. I wanted to solicit feedback, which you're providing, so thank you for that ;-) | Adds a weird build knob for GROK_LOW_MEM, surely this is not necessary. I have an 8GB ram vm that builds it, and without this, it goes to swap. I'll explore if there are ways to influence the rust build process without resorting to Makefile trappings. | Makefile is 215 lines long, verbose verbose verbose. Please, simplify | this port. Roger, wilco, loud and clear. ... separate tangent, has anyone ever explored building rust crates as individual packages vs building them all every time with every rust program in the tree? ... I have, and would like to discuss with someone who's interested and capable of giving advice. -- Todd T. Fries [email protected] 𝕏:@unix2mars github:toddfries pgp:3F42004A
