Conversation
There was a problem hiding this comment.
This package should probably be moved into the pythonPackages set and use the buildPythonPackage function. Other than that it looks good to me.
There was a problem hiding this comment.
I did this because it's actually not really a python package itself but an alternative to the python interpreter, such as pyrex (it is actually a fork of that). It generates C code (and after that a .so) out of a python file with special syntax/annotations, such as C type annotations/defines.
There was a problem hiding this comment.
@aszlig Your reasoning makes sense to me for why this isn't in pythonPackages, but wouldn't buildPythonPackage still help here?
This is because the original version is no longer in development, as stated on the website at http://code.google.com/p/partiwm/wiki/xpra: "This project is in deep hibernation; I haven't had time to devote for several years now. If you are looking for xpra, you may prefer Antoine Martin's fork, which receives more support. It is available at: http://xpra.org/" So I guess its safe to switch over to that fork.
Cython is not required in order to run XPRA, so we now explicitly specify what should be put into PYTHONPATH instead of using the PYTHONPATH which is set during build time. That way we don't get unnecessary stuff in /nix/store, like the mentioned cython compiler/interpreter.
This is not needed to run XPRA, but gets rid of a few nasty errors. XPRA is using the notify library to display nice desktop notifications, so there might be users who actually like to have those funny things.
|
Okay, rebased the branch and added a fix to avoid that unnecessary paths (like those of cython) get added to PYTHONPATH. |
New version of Xpra from the fork
Merge upstream master
# This is the 1st commit message: set CrossCompiling when cross compiling # The commit message #2 will be skipped: # jk, be conservative though ;) # The commit message #3 will be skipped: # 'quick' not perf-cross? # The commit message NixOS#4 will be skipped: # cross: no terminfo # The commit message NixOS#5 will be skipped: # ghc822: quick-cross
Maybe same problem as on Darwin, unsure. From gdb: > Thread 1 (process 23820): > #0 0x00007ffff7dab684 in __syscall_cp_c () from target:/nix/store/66m5z7marjbs7pa3gv8sf5j1qrqjacfj-musl-1.1.19/lib/ld-musl-x86_64.so.1 > #1 0x00007ffff7daac69 in __timedwait_cp () from target:/nix/store/66m5z7marjbs7pa3gv8sf5j1qrqjacfj-musl-1.1.19/lib/ld-musl-x86_64.so.1 > #2 0x00007ffff7daad17 in __timedwait () from target:/nix/store/66m5z7marjbs7pa3gv8sf5j1qrqjacfj-musl-1.1.19/lib/ld-musl-x86_64.so.1 > #3 0x00007ffff7dacaf4 in pthread_mutex_timedlock () from target:/nix/store/66m5z7marjbs7pa3gv8sf5j1qrqjacfj-musl-1.1.19/lib/ld-musl-x86_64.so.1 > NixOS#4 0x00007ffff781e409 in _gpgrt_lock_lock () from target:/nix/store/f7qid95jabfr665qc1kbcl6adf48gq7w-libgpg-error-1.28/lib/libgpg-error.so.0 > NixOS#5 0x00007ffff7b035d5 in lock_rng () at ./rndjent.c:212 > NixOS#6 0x00007ffff7b036ab in _gcry_rndjent_poll (add=0x0, origin=RANDOM_ORIGIN_INIT, length=0) at ./rndjent.c:268 > NixOS#7 0x00007ffff7b038cf in _gcry_rndjent_get_version (r_active=0x7fffffffc800) at ./rndjent.c:339 > NixOS#8 0x00007ffff7a44f7f in print_config (fp=0x6026e0, what=0x0) at global.c:391 > NixOS#9 _gcry_get_config (mode=mode@entry=0, what=<optimized out>, what@entry=0x0) at global.c:420 > NixOS#10 0x00007ffff7a456a3 in _gcry_vcontrol (cmd=<optimized out>, arg_ptr=<optimized out>) at global.c:652 > NixOS#11 0x00007ffff7a41689 in gcry_control (cmd=cmd@entry=GCRYCTL_PRINT_CONFIG) at visibility.c:79 > NixOS#12 0x0000000000400ec3 in main (argc=<optimized out>, argv=<optimized out>) at version.c:160
concourse: Support boolean flags
buildRustCrate: support rlib dependency type
Update to last nixpkgs.
kexec build process was broken in ff3c8c3
Strongly inspired by the forgejo counterpart[1], for the following
reasons:
* The feature is broken with the current module and crashes on
authentication with the following stacktrace (with a PAM service
`gitea` added):
server # Stack trace of thread 1008:
server # #0 0x00007f3116917dfb __nptl_setxid (libc.so.6 + 0x8ddfb)
server # #1 0x00007f3116980ae6 setuid (libc.so.6 + 0xf6ae6)
server # #2 0x00007f30cc80f420 _unix_run_helper_binary (pam_unix.so + 0x5420)
server # #3 0x00007f30cc8108c9 _unix_verify_password (pam_unix.so + 0x68c9)
server # #4 0x00007f30cc80e1b5 pam_sm_authenticate (pam_unix.so + 0x41b5)
server # #5 0x00007f3116a84e5b _pam_dispatch (libpam.so.0 + 0x3e5b)
server # #6 0x00007f3116a846a3 pam_authenticate (libpam.so.0 + 0x36a3)
server # #7 0x00000000029b1e7a n/a (.gitea-wrapped + 0x25b1e7a)
server # #8 0x000000000047c7e4 n/a (.gitea-wrapped + 0x7c7e4)
server # ELF object binary architecture: AMD x86-64
server #
server # [ 42.420827] gitea[897]: pam_unix(gitea:auth): unix_chkpwd abnormal exit: 159
server # [ 42.423142] gitea[897]: pam_unix(gitea:auth): authentication failure; logname= uid=998 euid=998 tty= ruser= rhost= user=snenskek
It only worked after turning off multiple sandbox settings and adding
`shadow` as supplementary group to `gitea.service`.
I'm not willing to maintain additional multiple sandbox settings for
different features, especially given that it was probably not used for
quite a long time:
* There was no PR or bugreport about sandboxing issues related to
PAM.
* Ever since the module exists, it used the user `gitea`, i.e. it had
never read-access to `/etc/shadow`.
* Upstream has it disabled by default[2].
If somebody really needs it, it can still be brought back by an overlay
updating `tags` accordingly and modifying the systemd service config.
[1] 07641a9
[2] https://docs.gitea.com/usage/authentication#pam-pluggable-authentication-module
Co-authored-by: @seanrmurphy
Co-authored-by: @seanrmurphy
nixosTests.cryptpad started failing recently. Investigating the issue shows that seccomp has become problematic during the init phase, (e.g. this can be reproduced by removing the customize directory in /var/lib/cryptpad): machine # [ 10.774365] systemd-coredump[864]: Process 756 (node) of user 65513 dumped core. machine # machine # Module libgcc_s.so.1 without build-id. machine # Module libstdc++.so.6 without build-id. machine # Module libicudata.so.74 without build-id. machine # Module libicuuc.so.74 without build-id. machine # Module libicui18n.so.74 without build-id. machine # Module libz.so.1 without build-id. machine # Module node without build-id. machine # Stack trace of thread 756: machine # #0 0x00007ff951974dcb fchown (libc.so.6 + 0x107dcb) machine # #1 0x00007ff95490d0c0 uv__fs_copyfile (libuv.so.1 + 0x150c0) machine # #2 0x00007ff95490d89a uv__fs_work (libuv.so.1 + 0x1589a) machine # #3 0x00007ff954910c76 uv_fs_copyfile (libuv.so.1 + 0x18c76) machine # #4 0x0000000000eb8a39 _ZN4node2fsL8CopyFileERKN2v820FunctionCallbackInfoINS1_5ValueEEE (node + 0xab8a39) machine # #5 0x0000000001cda5e2 Builtins_CallApiCallbackGeneric (node + 0x18da5e2) [...] machine # [ 10.877468] cryptpad[685]: /nix/store/h4yhhxpfm03c5rgz91q7jrvknh596ly2-cryptpad-2024.12.0/bin/cryptpad: line 3: 756 Bad system call (core dumped) "/nix/store/fkyp1bm5gll9adnfcj92snyym524mdrj-nodejs-22.11.0/bin/node" "/nix/store/h4yhhxpfm03c5rgz91q7jrvknh596ly2-cryptpad-2024.12.0/lib/node_modules/cryptpad/scripts/build.js" nodejs 20.18 rightly did not require chown when the source and destination are the same owner (heck, the script does not run as root so even if it is not blocked there is no way it'd work with a different owner...) For now just allow chown calls again, this is not worth wasting more time. Fixes #370717
nixosTests.cryptpad started failing recently. Investigating the issue shows that seccomp has become problematic during the init phase, (e.g. this can be reproduced by removing the customize directory in /var/lib/cryptpad): machine # [ 10.774365] systemd-coredump[864]: Process 756 (node) of user 65513 dumped core. machine # machine # Module libgcc_s.so.1 without build-id. machine # Module libstdc++.so.6 without build-id. machine # Module libicudata.so.74 without build-id. machine # Module libicuuc.so.74 without build-id. machine # Module libicui18n.so.74 without build-id. machine # Module libz.so.1 without build-id. machine # Module node without build-id. machine # Stack trace of thread 756: machine # #0 0x00007ff951974dcb fchown (libc.so.6 + 0x107dcb) machine # NixOS#1 0x00007ff95490d0c0 uv__fs_copyfile (libuv.so.1 + 0x150c0) machine # NixOS#2 0x00007ff95490d89a uv__fs_work (libuv.so.1 + 0x1589a) machine # NixOS#3 0x00007ff954910c76 uv_fs_copyfile (libuv.so.1 + 0x18c76) machine # NixOS#4 0x0000000000eb8a39 _ZN4node2fsL8CopyFileERKN2v820FunctionCallbackInfoINS1_5ValueEEE (node + 0xab8a39) machine # NixOS#5 0x0000000001cda5e2 Builtins_CallApiCallbackGeneric (node + 0x18da5e2) [...] machine # [ 10.877468] cryptpad[685]: /nix/store/h4yhhxpfm03c5rgz91q7jrvknh596ly2-cryptpad-2024.12.0/bin/cryptpad: line 3: 756 Bad system call (core dumped) "/nix/store/fkyp1bm5gll9adnfcj92snyym524mdrj-nodejs-22.11.0/bin/node" "/nix/store/h4yhhxpfm03c5rgz91q7jrvknh596ly2-cryptpad-2024.12.0/lib/node_modules/cryptpad/scripts/build.js" nodejs 20.18 rightly did not require chown when the source and destination are the same owner (heck, the script does not run as root so even if it is not blocked there is no way it'd work with a different owner...) For now just allow chown calls again, this is not worth wasting more time. Fixes NixOS#370717
fluent-bit 3.2.7, 3.2.8 and 3.2.9 are segfaulting when used in combination with the systemd input. Lets revert to 3.2.6 for now. Upstream bug: fluent/fluent-bit#10139 Note that fluent-bit-3.2.7 fixes two high CVEs which we are now reintroducing. However they are only exploitable if you are using the OpenTelemetry input or the Prometheus Remote Write input. OpenTelemetry input: [CVE-2024-50609](https://nvd.nist.gov/vuln/detail/CVE-2024-50609) Prometheus Remote Write input: [CVE-2024-50608](https://nvd.nist.gov/vuln/detail/CVE-2024-50608) The problem is as follows: 3.2.7 started vendoring a copy of `libzstd` in tree and statically linking against it. Also, the fluent-bit binary exports the symbols of static libraries it links against. This is a problem because `libzstd` gets `dlopen()`ed by `libsystemd` when enumerating the journal (as journal logs are zstd compressed). and `libzstd` in Nixpkgs is built with `-DZSTD_LEGACY_SUPPORT=0` which causes `struct ZSTD_DCtx` to be 16 bytes smaller than without this flag https://github.com/facebook/zstd/blob/dev/lib/decompress/zstd_decompress_internal.h#L183-L187 `libsystemd` calls [`sym_ZSTD_createDCtx()`](https://github.com/systemd/systemd/blob/1e79a2923364b65fc9f347884dd5b9b2087f6e32/src/basic/compress.c#L480) which calls the function pointer returned by `dlsym()` which is calling into the `libzstd` that comes with `nixpkgs` and thus allocates a struct that is 16 bytes smaller. Later then `sym_ZSTD_freeDCtx()` is called. However because fluent-bit has `zstd` in its global symbol table, any functions that `sym_ZSTD_freeDCtx()` calls will be calls to the functions in the vendored fluent-bit version of the library which expects the larger struct. This then causes enough heap corruption to cause a segfault. E.g. the subsequent calls to `ZSTD_clearDict(dctx)` and `ZSTD_customFree(dctx->inBuff)` in https://github.com/facebook/zstd/blob/dev/lib/decompress/zstd_decompress.c#L324 will be working on a struct that is 16 bytes smaller than the one that was allocated by `libsystemd` and will cause a segfault at some point and thus are probably modifying pieces of memory that they shouldn't (gdb) bt #0 0x00007f10e7e9916c in __pthread_kill_implementation () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 #1 0x00007f10e7e40e86 in raise () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 #2 0x00007f10e7e2893a in abort () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 #3 0x000000000046a938 in flb_signal_handler () #4 <signal handler called> #5 0x00007f10e7ea42b7 in unlink_chunk.isra () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 #6 0x00007f10e7ea45cd in _int_free_create_chunk () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 #7 0x00007f10e7ea5a1c in _int_free_merge_chunk () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 #8 0x00007f10e7ea5dc9 in _int_free () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 #9 0x00007f10e7ea8613 in free () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 #10 0x00007f10e80ad3b5 in ZSTD_freeDCtx () from /nix/store/wy0slah6yvchgra8nhp6vgrqa6ay72cq-zstd-1.5.6/lib/libzstd.so.1 #11 0x00007f10e8c90f6b in decompress_blob_zstd () from /nix/store/b2cfj7yk3wfg1jdwjzim7306hvsc5gnl-systemd-257.3/lib/libsystemd.so.0 #12 0x00007f10e8bf0efe in journal_file_data_payload () from /nix/store/b2cfj7yk3wfg1jdwjzim7306hvsc5gnl-systemd-257.3/lib/libsystemd.so.0 #13 0x00007f10e8c00f74 in sd_journal_enumerate_data () from /nix/store/b2cfj7yk3wfg1jdwjzim7306hvsc5gnl-systemd-257.3/lib/libsystemd.so.0 #14 0x00000000004eae2f in in_systemd_collect () #15 0x00000000004eb5a0 in in_systemd_collect_archive () #16 0x000000000047aa18 in flb_input_collector_fd () #17 0x0000000000495223 in flb_engine_start () #18 0x000000000046f304 in flb_lib_worker () #19 0x00007f10e7e972e3 in start_thread () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 #20 0x00007f10e7f1b2fc in __clone3 () from /nix/store/rmy663w9p7xb202rcln4jjzmvivznmz8-glibc-2.40-66/lib/libc.so.6 Reverts 7310ab3 Reverts 4fbc6cf
CMakeLists: add find_package YAMLCPP
Markdown formatting for titles
On my systems there is a path in the fonts list that looks like
/nix/store/<hash>-<font>.ttf. The previous code assumed that every font path
contains at least one more slash which isn't the case here.
The code matched on the / after the $out path of the derivation:
/nix/store/<hash>-<name>/share/X11/fonts/...
^
That slash only exists if the font lives in a subdirectory, which
isn't strictly required. In my case I've a few font files that are
located at /nix/store/<hash>-<name>.ttf and are assembled into a
folder as symlinks. (See example below)
Any attempt at calling realpath(3) on them (potentially recursively)
will result in the single file entry in the store being returned.
Whenever that font is being loaded flatpak segfaulted like so:
```
(gdb) bt
#0 0x00005583b3673763 in get_nix_closure ()
#1 0x00005583b3673711 in get_nix_closure ()
#2 0x00005583b36737dc in add_nix_store_symlink_targets ()
#3 0x00005583b36749a8 in add_font_path_args ()
#4 0x00005583b367b3f4 in flatpak_run_app ()
#5 0x00005583b35e4f08 in flatpak_builtin_run ()
#6 0x00005583b35a5970 in main ()
(gdb) x/5i $rip
=> 0x5583b3673763 <get_nix_closure+307>: movb $0x0,(%rax)
0x5583b3673766 <get_nix_closure+310>: call 0x5583b35a46a0 <g_hash_table_add@plt>
0x5583b367376b <get_nix_closure+315>: jmp 0x5583b3673699 <get_nix_closure+105>
0x5583b3673770 <get_nix_closure+320>: xor %edi,%edi
0x5583b3673772 <get_nix_closure+322>: lea 0x30475(%rip),%rsi # 0x5583b36a3bee
(gdb) x/s $rsi
0x5583e92d2180: "/nix/store/<hash>-A.ttf"
(gdb) print $rax
$1 = 0
```
RAX pointing to 0 here corresponds to the pointer `p` in the source
code. So the code attempted to dereference a null pointer as no further
slash (the return value of strchr(3)) could be found.
The modification in this commit ensures that we check for `p != 0` so
we don't run into this situation again.
Adding the path to the closure will still be done, even if no further
slash can be found, as that still points to a valid store path.
----
Nix code for custom fonts:
```nix
let
files = [
./A.ttf
./B.ttf
];
in
runCommandNoCC "custom-fonts" {} ''
mkdir -p $out/share/fonts/truetype
cd $out/share/fonts/truetype
${ lib.concatStringsSep "\n" (map (file: "ln -s ${file} ${baseNameOf file}") files)}
''
```
Some tcl checks fail for pkgsLLVM.sqlite. sqlite-x86_64-unknown-linux-gnu> Time: misc4.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: misc5.test 30 ms sqlite-x86_64-unknown-linux-gnu> Time: misc6.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: misc8.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: misuse.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mjournal.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap1.test 76 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap2.test 79 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap3.test 9 ms sqlite-x86_64-unknown-linux-gnu> Time: mmapcorrupt.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mmapwarm.test 23 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex.test 292 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex2.test 51 ms sqlite-x86_64-unknown-linux-gnu> SQLite compiled without SQLITE_ENABLE_8_3_NAMES. Skipping tests multiplex3-*. sqlite-x86_64-unknown-linux-gnu> Time: multiplex3.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex4.test 8 ms sqlite-x86_64-unknown-linux-gnu> Time: mutex1.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: nan.test 24 ms sqlite-x86_64-unknown-linux-gnu> Time: nockpt.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: nolock.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: normalize.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: notify1.test 123 ms sqlite-x86_64-unknown-linux-gnu> Running sqlite3_blocking_step test for 5 seconds sqlite-x86_64-unknown-linux-gnu> libgcc_s.so.1 must be installed for pthread_exit to work sqlite-x86_64-unknown-linux-gnu> make: *** [/build/sqlite-src-3510200/main.mk:1852: tcltest] Aborted (core dumped) ``` Module libunwind.so.1 without build-id. Module libz.so.1 without build-id. Module libtcl8.6.so without build-id. Stack trace of thread 1636: #0 0x00007ffff7b70bac __pthread_kill_implementation (libc.so.6 + 0x98bac) NixOS#1 0x00007ffff7b19526 raise (libc.so.6 + 0x41526) NixOS#2 0x00007ffff7b01305 abort (libc.so.6 + 0x29305) NixOS#3 0x00007ffff7b02347 __libc_message_impl.cold (libc.so.6 + 0x2a347) NixOS#4 0x00007ffff7b641d9 __libc_fatal (libc.so.6 + 0x8c1d9) NixOS#5 0x00007ffff7b6ff84 pthread_exit (libc.so.6 + 0x97f84) NixOS#6 0x00007ffff7f7ec2c TclpThreadExit (libtcl8.6.so + 0x188c2c) NixOS#7 0x00007ffff7f5b1c4 Tcl_ExitThread (libtcl8.6.so + 0x1651c4) NixOS#8 0x0000555555607b65 n/a (/build/sqlite-src-3510200/testfixture + 0xb3b65) NixOS#9 0x00007ffff7b6edf0 start_thread (libc.so.6 + 0x96df0) NixOS#10 0x00007ffff7bedfbc __clone3 (libc.so.6 + 0x115fbc) ```
Some tcl checks fail for pkgsLLVM.sqlite. sqlite-x86_64-unknown-linux-gnu> Time: misc4.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: misc5.test 30 ms sqlite-x86_64-unknown-linux-gnu> Time: misc6.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: misc8.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: misuse.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mjournal.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap1.test 76 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap2.test 79 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap3.test 9 ms sqlite-x86_64-unknown-linux-gnu> Time: mmapcorrupt.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mmapwarm.test 23 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex.test 292 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex2.test 51 ms sqlite-x86_64-unknown-linux-gnu> SQLite compiled without SQLITE_ENABLE_8_3_NAMES. Skipping tests multiplex3-*. sqlite-x86_64-unknown-linux-gnu> Time: multiplex3.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex4.test 8 ms sqlite-x86_64-unknown-linux-gnu> Time: mutex1.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: nan.test 24 ms sqlite-x86_64-unknown-linux-gnu> Time: nockpt.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: nolock.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: normalize.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: notify1.test 123 ms sqlite-x86_64-unknown-linux-gnu> Running sqlite3_blocking_step test for 5 seconds sqlite-x86_64-unknown-linux-gnu> libgcc_s.so.1 must be installed for pthread_exit to work sqlite-x86_64-unknown-linux-gnu> make: *** [/build/sqlite-src-3510200/main.mk:1852: tcltest] Aborted (core dumped) Module libunwind.so.1 without build-id. Module libz.so.1 without build-id. Module libtcl8.6.so without build-id. Stack trace of thread 1636: #0 0x00007ffff7b70bac __pthread_kill_implementation (libc.so.6 + 0x98bac) NixOS#1 0x00007ffff7b19526 raise (libc.so.6 + 0x41526) NixOS#2 0x00007ffff7b01305 abort (libc.so.6 + 0x29305) NixOS#3 0x00007ffff7b02347 __libc_message_impl.cold (libc.so.6 + 0x2a347) NixOS#4 0x00007ffff7b641d9 __libc_fatal (libc.so.6 + 0x8c1d9) NixOS#5 0x00007ffff7b6ff84 pthread_exit (libc.so.6 + 0x97f84) NixOS#6 0x00007ffff7f7ec2c TclpThreadExit (libtcl8.6.so + 0x188c2c) NixOS#7 0x00007ffff7f5b1c4 Tcl_ExitThread (libtcl8.6.so + 0x1651c4) NixOS#8 0x0000555555607b65 n/a (/build/sqlite-src-3510200/testfixture + 0xb3b65) NixOS#9 0x00007ffff7b6edf0 start_thread (libc.so.6 + 0x96df0) NixOS#10 0x00007ffff7bedfbc __clone3 (libc.so.6 + 0x115fbc)
Some tcl checks fail for pkgsLLVM.sqlite. sqlite-x86_64-unknown-linux-gnu> Time: misc4.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: misc5.test 30 ms sqlite-x86_64-unknown-linux-gnu> Time: misc6.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: misc8.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: misuse.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mjournal.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap1.test 76 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap2.test 79 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap3.test 9 ms sqlite-x86_64-unknown-linux-gnu> Time: mmapcorrupt.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mmapwarm.test 23 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex.test 292 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex2.test 51 ms sqlite-x86_64-unknown-linux-gnu> SQLite compiled without SQLITE_ENABLE_8_3_NAMES. Skipping tests multiplex3-*. sqlite-x86_64-unknown-linux-gnu> Time: multiplex3.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex4.test 8 ms sqlite-x86_64-unknown-linux-gnu> Time: mutex1.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: nan.test 24 ms sqlite-x86_64-unknown-linux-gnu> Time: nockpt.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: nolock.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: normalize.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: notify1.test 123 ms sqlite-x86_64-unknown-linux-gnu> Running sqlite3_blocking_step test for 5 seconds sqlite-x86_64-unknown-linux-gnu> libgcc_s.so.1 must be installed for pthread_exit to work sqlite-x86_64-unknown-linux-gnu> make: *** [/build/sqlite-src-3510200/main.mk:1852: tcltest] Aborted (core dumped) Module libunwind.so.1 without build-id. Module libz.so.1 without build-id. Module libtcl8.6.so without build-id. Stack trace of thread 1636: #0 0x00007ffff7b70bac __pthread_kill_implementation (libc.so.6 + 0x98bac) NixOS#1 0x00007ffff7b19526 raise (libc.so.6 + 0x41526) NixOS#2 0x00007ffff7b01305 abort (libc.so.6 + 0x29305) NixOS#3 0x00007ffff7b02347 __libc_message_impl.cold (libc.so.6 + 0x2a347) NixOS#4 0x00007ffff7b641d9 __libc_fatal (libc.so.6 + 0x8c1d9) NixOS#5 0x00007ffff7b6ff84 pthread_exit (libc.so.6 + 0x97f84) NixOS#6 0x00007ffff7f7ec2c TclpThreadExit (libtcl8.6.so + 0x188c2c) NixOS#7 0x00007ffff7f5b1c4 Tcl_ExitThread (libtcl8.6.so + 0x1651c4) NixOS#8 0x0000555555607b65 n/a (/build/sqlite-src-3510200/testfixture + 0xb3b65) NixOS#9 0x00007ffff7b6edf0 start_thread (libc.so.6 + 0x96df0) NixOS#10 0x00007ffff7bedfbc __clone3 (libc.so.6 + 0x115fbc)
Some tcl checks fail for pkgsLLVM.sqlite. sqlite-x86_64-unknown-linux-gnu> Time: misc4.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: misc5.test 30 ms sqlite-x86_64-unknown-linux-gnu> Time: misc6.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: misc8.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: misuse.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mjournal.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap1.test 76 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap2.test 79 ms sqlite-x86_64-unknown-linux-gnu> Time: mmap3.test 9 ms sqlite-x86_64-unknown-linux-gnu> Time: mmapcorrupt.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: mmapwarm.test 23 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex.test 292 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex2.test 51 ms sqlite-x86_64-unknown-linux-gnu> SQLite compiled without SQLITE_ENABLE_8_3_NAMES. Skipping tests multiplex3-*. sqlite-x86_64-unknown-linux-gnu> Time: multiplex3.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: multiplex4.test 8 ms sqlite-x86_64-unknown-linux-gnu> Time: mutex1.test 5 ms sqlite-x86_64-unknown-linux-gnu> Time: nan.test 24 ms sqlite-x86_64-unknown-linux-gnu> Time: nockpt.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: nolock.test 6 ms sqlite-x86_64-unknown-linux-gnu> Time: normalize.test 4 ms sqlite-x86_64-unknown-linux-gnu> Time: notify1.test 123 ms sqlite-x86_64-unknown-linux-gnu> Running sqlite3_blocking_step test for 5 seconds sqlite-x86_64-unknown-linux-gnu> libgcc_s.so.1 must be installed for pthread_exit to work sqlite-x86_64-unknown-linux-gnu> make: *** [/build/sqlite-src-3510200/main.mk:1852: tcltest] Aborted (core dumped) Module libunwind.so.1 without build-id. Module libz.so.1 without build-id. Module libtcl8.6.so without build-id. Stack trace of thread 1636: #0 0x00007ffff7b70bac __pthread_kill_implementation (libc.so.6 + 0x98bac) NixOS#1 0x00007ffff7b19526 raise (libc.so.6 + 0x41526) NixOS#2 0x00007ffff7b01305 abort (libc.so.6 + 0x29305) NixOS#3 0x00007ffff7b02347 __libc_message_impl.cold (libc.so.6 + 0x2a347) NixOS#4 0x00007ffff7b641d9 __libc_fatal (libc.so.6 + 0x8c1d9) NixOS#5 0x00007ffff7b6ff84 pthread_exit (libc.so.6 + 0x97f84) NixOS#6 0x00007ffff7f7ec2c TclpThreadExit (libtcl8.6.so + 0x188c2c) NixOS#7 0x00007ffff7f5b1c4 Tcl_ExitThread (libtcl8.6.so + 0x1651c4) NixOS#8 0x0000555555607b65 n/a (/build/sqlite-src-3510200/testfixture + 0xb3b65) NixOS#9 0x00007ffff7b6edf0 start_thread (libc.so.6 + 0x96df0) NixOS#10 0x00007ffff7bedfbc __clone3 (libc.so.6 + 0x115fbc)
This is because the original version is no longer in development, as stated on
the website at http://code.google.com/p/partiwm/wiki/xpra:
"This project is in deep hibernation; I haven't had time to devote for several
years now. If you are looking for xpra, you may prefer Antoine Martin's fork,
which receives more support. It is available at: http://xpra.org/"
So I guess its safe to switch over to that fork.