-
-
Notifications
You must be signed in to change notification settings - Fork 15k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libbacktrace: Add support for NIX_DEBUG_INFO_DIRS #207611
Conversation
Verified that this works well in conclusion with #200971. By applying preCheck = ''
export NIX_DEBUG_INFO_DIRS=${glib.debug}/lib/debug:${gtk4.debug}/lib/debug
export LD_PRELOAD=${libsegfault}/lib/libsegfault.so
export SEGFAULT_SIGNALS=all
''; I got
compared to the following (without this patch set):
|
This should target staging IMHO. Putting in draft to avoid mass pings. |
Why do you want to target staging? It is not very many rebuilds. |
Sorry, confused 500+ and 101-500. Nevermind my comment. |
deca8d7
to
dffbaec
Compare
- Prefix version with “unstable-” as per contributing guide - Do not use rec pointlessly - Use `lib.enableFeature` - Add update script - Format the expression - Remove unused callPackage input
Only on Linux since they will fail on Darwin: dsymutil btest error: cannot parse the debug map for 'btest': The file was not recognized as a valid object file make[1]: *** [Makefile:2584: btest.dSYM] Error 1
Also fix tests.
pname = "libbacktrace"; | ||
version = "2020-05-13"; | ||
version = "unstable-2022-12-16"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this version is intended to be stable. I'm not sure exactly what to do about this as libbacktrace has weird version semantics: as the author said,
This is version 1.0. It is likely that this will always be version 1.0.
I'm not entirely sure how to fit this into the nixpkgs versioning scheme, but unstable
doesn't seem to be it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a nixpkgs convention: https://nixos.org/manual/nixpkgs/stable/#sec-package-naming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what I'm saying is that this is (notionally) a release. The initial release in that repository is release 1.0, and all commits on top of it are (unhelpfully named) patch versions of that release.
@@ -0,0 +1,42 @@ | |||
From a3b7510e4c9e7201a4301f2a45d8569b06354607 Mon Sep 17 00:00:00 2001 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't seen many patches in nixpkgs that include email metadata, but maybe someone else would like to weigh in on whether this is okay style or not. I don't really see the harm in it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It’s just what Git spits out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like there are a fair few patches in nixpkgs with author metadata (about 15%), so I guess it's fine.
|
||
# Support NIX_DEBUG_INFO_DIRS environment variable. | ||
./0004-libbacktrace-Support-NIX_DEBUG_INFO_DIRS-environment.patch | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we're adding patches, could we include ianlancetaylor/libbacktrace#92? This would be helpful for other nixpkgs packages to depend on libbacktrace without relying on the cc-wrapper include path generation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would not other software need to rely on this for it to be useful? I would not expect other projects to rely on it until it is supported upstream (unless the developer does not realize they are relying on their distro’s patches).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a non-Nix context pkgconfig is often not required because the libraries are in global directories, but within Nix I find that pkgconfig is very helpful to decouple packages' output structures.
I don't expect non-nixpkgs packages to expect pkgconfig for this, but rather it might be helpful for other nixpkgs packages that want to depend on libbacktrace. I've previously had to generate a pkgconfig manually for it and overrideAttrs
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a non-Nix context pkgconfig is often not required because the libraries are in global directories
Right, and in Nixpkgs, the cc-wrapper plays a similar role.
I don't expect non-nixpkgs packages to expect pkgconfig for this, but rather it might be helpful for other nixpkgs packages that want to depend on libbacktrace.
We are usually trying to keep packages in Nixpkgs as close to upstream as possible. This typically means limiting patches to build or security fixes and Nix compatibility fixes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, seems sensible.
@ofborg eval |
Description of changes
Clean up the expression, update and apply some patches to fix tests and make it work better on NixOS.
ianlancetaylor/libbacktrace@9b7f216...da7eff2
Includes two unmerged upstream patchsets:
cc @Twey
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes