!lymvtcwDJ7ZA9Npq:lix.systems

Lix Development

423 Members
(Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel.143 Servers

Load older messages


SenderMessageTime
29 Jul 2025
@emilazy:matrix.orgemily which would result in libarchive creating a file like /private/tmp/nix-build-libarchive-3.8.1.drv-6tar.md.CvYd75, which is fine because the permissions are less locked down. comedy 17:00:17
@raitobezarius:matrix.orgraitobezarius
In reply to @emilazy:matrix.org
(I mean it is an upstream bug)
what is upstream here
17:04:45
@emilazy:matrix.orgemily libarchive 17:04:53
@raitobezarius:matrix.orgraitobezariusah ok17:04:56
@emilazy:matrix.orgemilyand maybe anything else similarly dumb17:04:59
@emilazy:matrix.orgemilyit's not worth worrying about I think17:05:06
@emilazy:matrix.orgemilygiven it would cause issues on Linux too (it was in a macOS-only code path in this case), and was already behaving wrong pre-CVE-fixes17:05:29
@emilazy:matrix.orgemily FWIW something seems screwy about Unix sockets in /tmp in the Darwin sandbox even after fixes: https://github.com/NixOS/nixpkgs/pull/429415 17:30:12
@emilazy:matrix.orgemilybut I'm not sure exactly what/how17:30:21
@emilazy:matrix.orgemilyand it may be an okay regression because we should really be closing that off anyway…17:30:32
@raitobezarius:matrix.orgraitobezariusi cannot understand what is screwy17:31:21
@raitobezarius:matrix.orgraitobezariuswhat behavior do you see17:31:27
@raitobezarius:matrix.orgraitobezariusah you're not exactly sure neither17:31:38
@emilazy:matrix.orgemily bind fails on /tmp/blah 17:34:40
@emilazy:matrix.orgemily I don't know, libuv regularly breaks in the Darwin sandbox, so maybe it wasn't related to the CVE stuff 17:35:07
@emilazy:matrix.orgemilybut it seems suspicious (but I can't figure out why it'd have become screwier)17:35:18
@emilazy:matrix.orgemilyRedacted or Malformed Event19:02:32
@emilazy:matrix.orgemilyRedacted or Malformed Event19:02:45
@emilazy:matrix.orgemilyRedacted or Malformed Event19:03:03
@emilazy:matrix.orgemily(my bad, my own dev env was messed up :P)19:05:32
@raitobezarius:matrix.orgraitobezariusawesome work, thanks emily!19:59:09
@emilazy:matrix.orgemilydon't test me, I might remove more things from the packaging 😈19:59:48
@raitobezarius:matrix.orgraitobezarius nix develop --phase testPhase emily 20:01:42
@emilazy:matrix.orgemily fwiw, I'm happy to re-add the flag for https://gerrit.lix.systems/c/lix/+/3833/5. but since internal-api-docs apparently takes 32 seconds on CI, I think it would only be for closure, not for build speed 20:02:53
@emilazy:matrix.orgemily and the closures of doxygen and rapidcheck are small 20:03:47
@emilazy:matrix.orgemilyhmmm20:14:20
@emilazy:matrix.orgemily I notice that the derivation in Nixpkgs already did this devdoc stuff and I just wasted a non-trivial amount of time :) 20:14:37
@emilazy:matrix.orgemilyis there no systematic sync between those two?20:14:44
@emilazy:matrix.orgemily I'll leave what I have up since it's an improvement over HEAD, but it seems like it would be good to minimize the drift between those two to avoid redundant work. 20:16:09
@marie:marie.cologneMariehi, I do a applyPatches thing to apply PR's to my nixpkgs and I've been getting really annoyed that lix copies nixpkgs into the store on every invocation, even though it is already in the store. From googling around this seems to be a known issue. If I call my patched thing "source" the problem goes away. Does anyone know if there is a good reason to only allow "source" here: https://git.lix.systems/lix-project/lix/src/commit/93acdd40f6c3eab1a25ea03d7a160433ed551677/lix/libfetchers/path.cc#L13821:57:17

Show newer messages


Back to Room ListRoom Version: 10