| 22 Jan 2024 |
 raitobezarius | It was not clear you were answering to 2nd line | 18:30:39 |
| raitobezarius | but yeah I understand that there were a separation because it was natural | 18:31:43 |
| raitobezarius | I wonder if it still makes sense to keep that separation | 18:31:48 |
| raitobezarius | as in, do anyone get meaningful advantage from overriding libcxxabi without touching the rest | 18:31:58 |
 a-n-n-a-l-e-e | right -- that sums up my question. if i end up combining them for darwin the code would be easier if i could do the same for all platforms. | 18:36:12 |
| raitobezarius | I'm definitely not competent enough to answer it, alas | 18:36:40 |
| a-n-n-a-l-e-e | thanks for chiming in. perhaps it is best if i also create an issue though, except for you approving and merging a backport (thanks), i haven't had any feedback from any llvm maintainers pinged in previous issue or PR, though perhaps that is just due to them being darwin only. | 18:44:41 |
| raitobezarius | Yeah, for Darwin, Reckrenode is more the person for LLVM | 18:47:52 |
| raitobezarius | I prefer to work on the x86/RISC-V/UEFI (lol) aspect of LLVM and I don't have a deep understanding like many other maintainers | 18:48:25 |
| a-n-n-a-l-e-e | ok -- we've been communicating in macos channel. | 18:48:33 |
| raitobezarius | The maintainer field is kinda misleading on this subsystem of nixpkgs | 18:48:34 |
| raitobezarius | Everyone has their area of interests / competence and people tends to be really busy until something happens | 18:48:49 |
| raitobezarius | Feel free to move on with the things you deem important for Darwin and ping me if you need more buy-in from a larger LLVM audience | 18:49:06 |
| raitobezarius | You and Reckrenode are clearly our domain experts in that matter :) | 18:49:23 |
| a-n-n-a-l-e-e | i don't have any love for darwin, just setup a hackintosh vm to fix bugs in ZHF 23.11 and it started segfaulting so just been fixing bugs related to that. prior to that was getting darwin to boot in a vm in 2002 or so due to their use of 32 bit address space in a 16 bit segment. | 18:51:16 |
| raitobezarius | Amazing! :D | 18:51:38 |
| raitobezarius | I really cannot muster the energy to work on a proprietary platform on a volunteer perspective, so props to those who can | 18:51:53 |
| a-n-n-a-l-e-e | but i'd like to take these bugs to their conclusion since already started on it. | 18:52:04 |
| a-n-n-a-l-e-e | Redacted or Malformed Event | 18:52:35 |
| 23 Jan 2024 |
 Puna | anyone who could give https://github.com/NixOS/nixpkgs/pull/255451 a look, maybe even someone who could upload the files to tarballs.nixos.org 👀? | 20:10:46 |
| 26 Jan 2024 |
 ris_ | https://discourse.nixos.org/t/future-design-of-hardening-flags/38826 | 00:31:10 |
 trofi | Fun fact: some of the current hardening flags are already not compatible with some (exotic) targets. For example stack-protector is a no-op with a warning from a compiler driver on alpha/ia64/hppa. Causes build failures on -Werror. | 07:15:47 |
| 27 Jan 2024 |
| ris_ | this is true | 12:54:49 |
| 29 Jan 2024 |
|  Sam Lehman joined the room. | 11:02:00 |
| Sam Lehman set a profile picture. | 11:06:02 |
| 31 Jan 2024 |
|  Federico Damián Schonborn changed their profile picture. | 03:36:06 |
| Federico Damián Schonborn changed their profile picture. | 06:21:42 |
| 2 Feb 2024 |
 Alyssa Ross | Should we set -DFILE_OFFSET_BITS=64 in stdenv? | 21:05:39 |
| trofi | Sounds reasonable if opt-out will be added as well. Some packages will certainly break on i686 when symbols change. | 22:55:20 |
| trofi | I carry a few -DFILE_OFFSET_BITS=64 locally to make i686 builds survive 64-bit inodes: qt5.qtbase, graphviz and doxygen. It looks like cmake does not have a well-established way to flip it on and thus cmake-based packages are most likely to be affected. | 22:59:38 |
