NixOS CUDA - Public Room Timeline

	NixOS CUDA	288 Members
	CUDA packages maintenance and support in nixpkgs \| https://github.com/orgs/NixOS/projects/27/ \| https://nixos.org/manual/nixpkgs/unstable/#cuda	59 Servers

You have reached the beginning of time (for this room).

Sender	Message	Time
10 Feb 2025
stick	I think we should use this instead (not only for cuda-samples but for all nixpkgs)	00:13:19
	@me:caem.dev joined the room.	00:48:53
ruro	AFAIC, FreeImage is "undead". I think I read that the original devs insist that it is still being maintained, but they are stubbornly stuck on SourceForge and the last official release was in 2018. :sigh:	02:59:55
ruro	I guess, the relevant questions would be: Is it backwards compatible with the older official versions of FreeImage? Is there some sort of consensus around this fork being a good replacement? Which CVEs does this fork fix? Are these fixes verified / documented by whatever authorities published the original CVEs?	03:04:46
ruro	Taking a cursory look at that repository, it seems that the original author just commited the whole SVN repo instead of importing the history from SVN, which is kind of annoying/problematic.	03:08:43
ruro	* Taking a cursory look at that repository, it seems that the original author just commited the whole SVN repo in the initial commit instead of importing the history from SVN, which is kind of annoying/problematic.	03:09:06
stick	another option would be to just remove `freeImageInteropNPP` from the cuda-samples build	08:19:23
stick	* another option would be to just remove `freeImageInteropNPP` sample from the cuda-samples build	08:19:34
stick	by changing `SAMPLE_ENABLED := 1` to `SAMPLE_ENABLED := 0` here: https://github.com/NVIDIA/cuda-samples/blob/9c688d7ff78455ed42e345124d1495aad6bf66de/Samples/4_CUDA_Libraries/freeImageInteropNPP/Makefile#L284	08:22:11
stick	or maybe even that is not necessary and the build correctly detects that FreeImage is not available and skips that sample	08:23:19
ruro	I was under the impression that there were a lot more samples that depended on FreeImage. If this is indeed the only sample that requires FreeImage, then I will simply remove it since I am already going to remove a few broken samples that don't have easy fixes.	09:40:54
ruro	* I was under the impression that there were a lot more samples that depended on FreeImage. If this is indeed the only sample that requires FreeImage, then I will simply remove it since I am already planning to remove a few broken samples that don't have easy fixes.	09:41:03
ruro	* Nice catch! I was under the impression that there were a lot more samples that depended on FreeImage. If this is indeed the only sample that requires FreeImage, then I will simply remove it since I am already planning to remove a few broken samples that don't have easy fixes.	09:41:12
SomeoneSerge (back on matrix)	They're both aarch64, it can build both, just it doesn't have the runtime	13:29:37
SomeoneSerge (back on matrix)	Afaik, the official hydra builders don't build insecure packages, so I am kind of against setting Yeah but honestly I see no reason for that	13:30:47
SomeoneSerge (back on matrix)	I still think that we should just change freeimage to That would be lies though?	13:31:27
SomeoneSerge (back on matrix)	Message deleted by NixOS Moderation Bot o_0	13:32:39
ruro	I think that only 5 samples actually depend on `freeimage` - `FilterBorderControlNPP`, `boxFilterNPP`, `cannyEdgeDetectorNPP`, `freeImageInteropNPP` and `histEqualizationNPP`. That's not that many (given that there are like 200 total or something), so I am probably going to throw my over-engineered `freeimage.overrideAttrs` chicanery out of the window and just disable these samples by default.	13:56:04
ruro	On a related note, can somebody tell me: Should I prefer linking to `libglvnd` instead of `libGL`? Is it bad if I end up having both `libGL` and `libglvnd` in the same closure? It seems that `libglvnd` doesn't provide `libGLU` or `libglut`. Is there an equivalent vender-neutral dispatch mechanism for those libraries?	14:02:59
ruro	* ~~On a related note, can somebody tell me: Should I prefer linking to `libglvnd` instead of `libGL`? Is it bad if I end up having both `libGL` and `libglvnd` in the same closure? It seems that `libglvnd` doesn't provide `libGLU` or `libglut`. Is there an equivalent vender-neutral dispatch mechanism for those libraries?~~	14:03:16
ruro	* On a related note, can somebody tell me: Should I prefer linking to `libglvnd` instead of `libGL`? Is it bad if I end up having both `libGL` and `libglvnd` in the same closure? It seems that `libglvnd` doesn't provide `libGLU` or `libglut`. Is there an equivalent vender-neutral dispatch mechanism for those libraries? Edit: nvm, I am blind. `libGL` is an alias for `libglvnd`	14:03:56
ruro	* ~~On a related note, can somebody tell me:~~ Should I prefer linking to `libglvnd` instead of `libGL`? Is it bad if I end up having both `libGL` and `libglvnd` in the same closure? It seems that `libglvnd` doesn't provide `libGLU` or `libglut`. Is there an equivalent vender-neutral dispatch mechanism for those libraries? Edit: nvm, I am blind. `libGL` is an alias for `libglvnd`	14:04:04
ruro	* ~On a related note, can somebody tell me:~ Should I prefer linking to `libglvnd` instead of `libGL`? Is it bad if I end up having both `libGL` and `libglvnd` in the same closure? It seems that `libglvnd` doesn't provide `libGLU` or `libglut`. Is there an equivalent vender-neutral dispatch mechanism for those libraries? Edit: nvm, I am blind. `libGL` is an alias for `libglvnd`	14:04:12
ruro	* ~~On a related note, can somebody tell me:~~ Should I prefer linking to `libglvnd` instead of `libGL`? Is it bad if I end up having both `libGL` and `libglvnd` in the same closure? It seems that `libglvnd` doesn't provide `libGLU` or `libglut`. Is there an equivalent vender-neutral dispatch mechanism for those libraries? Edit: nvm, I am blind. `libGL` is an alias for `libglvnd`	14:05:15

Show newer messages

Back to Room ListRoom Version: 9