leungbk has quit [Quit: ERC (IRC client for Emacs 27.1)]
evanjs has quit [Ping timeout: 264 seconds]
evanjs has joined #nixos-dev
justanotheruser has quit [Ping timeout: 272 seconds]
angerman has quit [Ping timeout: 240 seconds]
angerman has joined #nixos-dev
claudiii has quit [Ping timeout: 240 seconds]
sgrunert has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
claudiii has joined #nixos-dev
georgyo has quit [Ping timeout: 260 seconds]
georgyo has joined #nixos-dev
__monty__ has joined #nixos-dev
<ehmry>
drakonis: the non-linux nixos stuff
grw1 has quit [Ping timeout: 272 seconds]
justanotheruser has joined #nixos-dev
alp has joined #nixos-dev
ris has quit [Ping timeout: 240 seconds]
<ivan>
removing rsync from systemPackages in 20.09 is a bad idea, rsync is pretty essential to copying things between servers and some people's things will explode because the remote will lack it
<ivan>
I oppose strace removal too but the collateral damage is just annoying the operator rather than getting into a bad situation
saschagrunert has joined #nixos-dev
sgrunert has quit [Ping timeout: 258 seconds]
<niksnut>
strace removal? :o
<ma27[m]>
niksnut: it's only removed from the default systemPackages that are available on each NixOS, the package is still there %)
<clever>
ivan: id say if rsync has to be installed by default, make it something like programs.rsync.enable = mkDefault true; so you can still choose to get rid of it, without having to override rsync = null;
<ivan>
sure
<clever>
ivan: removing things from a list option is rather difficult, and mkForce just makes systemPackages even worse
<niksnut>
ma27[m]: I don't like that, strace to me is an indispensable debugging tool
justanotheruser has quit [Ping timeout: 260 seconds]
<niksnut>
it gives off macOS vibes to make the system undebuggable by default
<ma27[m]>
niksnut: feel free to open a PR that re-adds it, I'm not the author of this change (and don't have a strong opinion about this), just wanted to make sure there's no confusion :-)
rajivr has joined #nixos-dev
FRidh has joined #nixos-dev
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined #nixos-dev
ky0ko has quit [Quit: killed]
ky0ko has joined #nixos-dev
<Mic92>
macos had strace?
<Mic92>
I thought they had something dtrace-based.
orivej has joined #nixos-dev
<infinisil>
I'm in favor of strace removal because it's really not essential for a normal user
<sphalerite>
urkk: oh, though the conditions might prevent that from happening..?
<sphalerite>
urkk: nix-build -E 'with import <nixpkgs> {}; runCommandNoCC "testptmx" {} "stat -L /dev/ptmx"' ← this shows me that for me, its permissions are 0666
<sphalerite>
which kernel are you using?
niksnut has joined #nixos-dev
<clever>
Ericson2314: i think i need gcc to build its libstdc++.a with -mlongcall, how would i properly route that thru the cross-compile framework?
<clever>
Ericson2314: it may be better to just have it apply to every build
<Ericson2314>
clever: sorry, as this the thing you mentioned earlier?
<clever>
Ericson2314: yeah, esp32 support
<clever>
i think without -mlongcall, libstdc++.a cant properly link to newlib's libc.a, due to the binaries being too big
alp has joined #nixos-dev
<Ericson2314>
clever: i this -mlongcall analogous to like 8286 long calls?
<clever>
i think its to decide between 8bit relative or full 32bit addressing
<clever>
Ericson2314: maybe you havent seen the esp-idf build system yet...
<taktoa[c]>
lmao
<taktoa[c]>
esp-idf is sick and wrong
<taktoa[c]>
two build systems, a smattering of kconfig, and a big pile of python (which has bugs on the latest versions of its dependencies)
<pie_>
domenkozar[m]: woudl it be possible to have fetchers for cachix to use cachix without actually needing to add it to trusted users?
<pie_>
or maybe we already have something like that?
<domenkozar[m]>
fetchers for cachix?
<pie_>
domenkozar[m]: i mean something that will download stuff from cachix, like fetchGit or such, and extract it into an output directory
<cole-h>
Doesn't cachix really only host outputs anyways? I don't see it being used as a general file store
<domenkozar[m]>
not really, that's an api inside Nix
<pie_>
i always mix up wether its fetchGit of fetchgit
<pie_>
ok fine, so fetchfromgithub or whatever
__monty__ has quit [Quit: leaving]
<Ericson2314>
clever: :D yes I know nothing about this stuff
tazjin has quit [Remote host closed the connection]
tazjin has joined #nixos-dev
eyJhbV2 has joined #nixos-dev
eyJhbV2 is now known as eyJhb
orivej has quit [Ping timeout: 244 seconds]
eyJhb has joined #nixos-dev
eyJhb has quit [Changing host]
orivej has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
<sorear>
(what's the scope of the esp32 and or1k things?)
<samueldr>
the or1k thing for me is mostly about building crust, a firmware that can be used on allwinner platforms, the main interesting one being the pinephone
<samueldr>
(it doesn't work, yet, it might be needing the next binutils bump, or something else)
<clever>
sorear: we now have an esp32 spinning up an example access-point, using firmware built entirely by nix, using a gcc built by nix
<taktoa[c]>
the goal of the esp32 project is to make it as easy to develop for the esp32 as it is to just write a normal C library
<taktoa[c]>
and maybe to get a rust toolchain working afterwards
<sorear>
so it's just a couple of toolchains?
<taktoa[c]>
right now, I have a PR out adding a Nix cross compile toolchain for the xtensa/esp32 platform
<taktoa[c]>
and we are currently working on making a package for esp-idf
<taktoa[c]>
which is a framework for making esp32 apps that use RTOS, wifi, bluetooth, etc.
<taktoa[c]>
the key thing is that esp-idf is really set up as a framework
<taktoa[c]>
whereas we want to turn it into just a bunch of libraries
<taktoa[c]>
that you can easily link against in C or other languages
<taktoa[c]>
without using their build system, their deployment tools, etc.