Nixpkgs Stdenv - Public Room Timeline

	Nixpkgs Stdenv	218 Members
		69 Servers

Load older messages

Sender	Message	Time
24 Nov 2024
emily	honestly even 18 could probably go if the next `staging-next` goes okay. we've not had that bad a time fixing `char_traits` stuff	22:59:27
Tristan Ross	In reply to @emilazy:matrix.org I think things below 18 can go. Yeah, I agree. It's just things which are relatively newer and it's probably easier to handle conflicts and removing version checks when it's older first.	23:11:04
emily	the older ones tend to be the harder ones to remove	23:12:14
emily	since stuff stuck on very old LLVMs is harder to make work on new ones	23:12:23
Tristan Ross	Hmm then we probably will have problems either way	23:14:42
emily	I don't think it's that hard to remove version checks for a specific version?	23:16:12
emily	it's just a gap	23:16:14
emily	we have lots of packages with non-contiguous versions, e.g. Boost.	23:16:23
25 Nov 2024
Philip Taron (UTC-8)	In reply to @rosscomputerguy:matrix.org emily John Ericson Philip Taron (UTC-8) Randy Eckenrode & Artturin: have you guys seen this post (https://discourse.nixos.org/t/community-team-updates/56458) should we do a meeting to discuss things to add for a reply to the post or do we just want to message in here? I'm up for a Zoom or other video meetup. Here's the list of things I'm tracking in stdenv world. `__structuredAttrs` https://github.com/NixOS/nixpkgs/issues/205690. Mostly driven by @wolfgangwalthier. Thank you! Various improvements to fetchgit,fetchGitHub, etc, mostly around `rev` vs. `tag` to increase the expressiveness of the function. Improvements to `nixpkgs` configuration options to document and regularize those options (https://github.com/NixOS/nixpkgs/pull/330753, but the PR author has left nixpkgs) Structured logging (`@nix { "action": "msg", "level": "1", "msg": ...}`) support in the stdenv. https://github.com/NixOS/nixpkgs/pull/331794 Thorough removal of `substituteAll` in the nixpkgs codebase: https://github.com/NixOS/nixpkgs/issues/237216 Continued progress on clarifying what the environment is and what guarantees are possible across "releases". Linters and checkers (like `nixpkgs-vet`) that assist with in-tree and out-of-tree users to provide diagnostics and migrations for necessary changes. Breaking apart the knot of bootstrapping on every platform to enable a stdenv that's "bootstrap-free" -- not strangely constrained by bootstrap concerns, but able to be changed without breaking bootstrap. Making sense of how cross-compilation depends and does not depend on stdenv. (This is a personal goal, since I just don't understand it today.) There are other small things, but this is the majority effort.	00:21:05
emily	what do you mean by #8?	00:35:36
Tristan Ross	In reply to @philiptaron:matrix.org I'm up for a Zoom or other video meetup. Here's the list of things I'm tracking in stdenv world. `__structuredAttrs` https://github.com/NixOS/nixpkgs/issues/205690. Mostly driven by @wolfgangwalthier. Thank you! Various improvements to fetchgit,fetchGitHub, etc, mostly around `rev` vs. `tag` to increase the expressiveness of the function. Improvements to `nixpkgs` configuration options to document and regularize those options (https://github.com/NixOS/nixpkgs/pull/330753, but the PR author has left nixpkgs) Structured logging (`@nix { "action": "msg", "level": "1", "msg": ...}`) support in the stdenv. https://github.com/NixOS/nixpkgs/pull/331794 Thorough removal of `substituteAll` in the nixpkgs codebase: https://github.com/NixOS/nixpkgs/issues/237216 Continued progress on clarifying what the environment is and what guarantees are possible across "releases". Linters and checkers (like `nixpkgs-vet`) that assist with in-tree and out-of-tree users to provide diagnostics and migrations for necessary changes. Breaking apart the knot of bootstrapping on every platform to enable a stdenv that's "bootstrap-free" -- not strangely constrained by bootstrap concerns, but able to be changed without breaking bootstrap. Making sense of how cross-compilation depends and does not depend on stdenv. (This is a personal goal, since I just don't understand it today.) There are other small things, but this is the majority effort. Ok, we can schedule based on availability. I think there's the crab fit thing which can be used to track availability.	00:39:25
Tristan Ross	Could do a meeting over jitsi	00:40:33
Philip Taron (UTC-8)	In reply to @emilazy:matrix.org what do you mean by #8? It’s sort of mixed up with #9. I worked for a short while with John Ericsson on breaking apart the GCC derivations into multiple derivations instead of one giant derivation. Stuff like your patch that needed lib.getExe in order not to break cross compilation. Making sense of what exactly the cc wrapper is and does.	00:54:54
Philip Taron (UTC-8)	I notice basically everyone who tackles something with bootstrap breaks something. Why? What can we do to make this less common?	00:55:46
Philip Taron (UTC-8)	In reply to @philiptaron:matrix.org I notice basically everyone who tackles something with bootstrap breaks something. Why? What can we do to make this less common? Something = a meaningful change rather than just keeping the lights on.	00:56:17
Philip Taron (UTC-8)	The lower the thing on the list, the less I understand it, btw.	00:56:45
Philip Taron (UTC-8)	So this is pretty far into “something in this general direction” rather than “being worked on by someone”	00:57:21
Philip Taron (UTC-8)	Hope that clarifies rather than obfuscates.	00:58:13
Randy Eckenrode	In reply to @emilazy:matrix.org I think things below 18 can go. Does Wine build on staging? I haven’t tried building it yet, but it was broken with Clang 18. Unlike other `.cfi_startproc` usage, Wine’s changes would be non-trivial.	01:19:28
emily	I believe I built it. I'm not sure.	01:19:46
emily	could be misremembering	01:19:47
@trofi:matrix.org	In reply to @philiptaron:matrix.org I notice basically everyone who tackles something with bootstrap breaks something. Why? What can we do to make this less common? My experience is that everyone has their own vision of how bootstrap is supposed to work in `nixpkgs`. Everyone's vision is usually slightly flawed in one way or another (as in does not achieve basic goals like "no references to the bootstrap tools (or copies) in the final `stdenv`", or does not actually deliver fully working `gcc`, or does not allow mixing `gcc`s, etc.).	16:55:40
Philip Taron (UTC-8)	Yes, trofi, exactly this. What we have today works but requires a large seed, is quite entangled with the actual tools themselves, and has pitfalls of many specified and unspecified varieties. I don't have a vision of my own. I'm just the poor sod in the meme who says we should improve matters somewhat. I hope (at some unspecified future time) to put my labor into trying to define what better looks like and to making it so.	18:47:28
K900	We have the minimal bootstrap work	18:51:13
K900	That's very good and just needs someone to get everything in place to ship it	18:51:30
Philip Taron (UTC-8)	"just" is doing a lot of load-bearing work in that sentence!	18:52:22
Philip Taron (UTC-8)	For sure: minimal bootstrap's path has been paved substantially, not least of which by GUIX.	18:52:50
emily	it exists in-tree	18:56:27
@trofi:matrix.org	I personally think minimal bootstrap is an orthogonal effort to bootstrap structure: minimal bootstrap changes how binary seed is provided, but does not change the way how it's used to get an up-to-date toolchain. For example it does not magically untangle circular dependency between `g++` and `libstdc++.so`.	21:33:46
Alex	Dealing with circular dependencies seems like a part of shrinking a binary seed though? Because otherwise you need to include one of the dependencies in the seed.	21:43:01

Show newer messages

Back to Room ListRoom Version: 9