<colemickens>
clever: taktoa[c] could you eventually effectively build up a better esphome with it over time?
<taktoa[c]>
it would be useful for building esphome-compatible widgets or reflashing your esphome stuff
alp has quit [Ping timeout: 240 seconds]
<clever>
colemickens: currently, it can build any of the esp32 examples, and with a bit more work, it can likely build anything using the esp32 build framework, but it builds the whole esp-idf every time, like the older rust stuff
<taktoa[c]>
I guess if you mean "an esphome that doesn't require you to screw around with esp-idf", then the answer is yes
<taktoa[c]>
having to live inside someone else's repo/build system is just... uncomfortable, and that's basically what esp-idf expects you to do
<clever>
i think using IFD_PATH you can live outside
<taktoa[c]>
yeah you might be able to make it work as a submodule
<taktoa[c]>
but you're still beholden to their build system
<clever>
thats why i wanted an example project that isnt in the repo, to try building
<clever>
linux kernel modules are the same
<taktoa[c]>
yeah it's clear they based esp-idf on the linux kernel
<taktoa[c]>
and like, if you live in a world where cross toolchains are a huge pain in the ass to set up, I can understand wanting a batteries included experience like that
<taktoa[c]>
but with nix, cross-compilation isn't a huge pain in the ass
<taktoa[c]>
I guess my real complaint about esp-idf is that as soon as you step outside the set of libraries they give to you, it stops working well
<taktoa[c]>
because you have to make your own cmake wrapper stuff for it
<taktoa[c]>
whereas a nix store path full of .a/pkgconfig/header files is really easy to integrate with any build system you want
<clever>
we also need to investigate the bootloader and partition stuff more
<clever>
to find out why the example code didnt work until we did all 3 files
<taktoa[c]>
yeah
<taktoa[c]>
right now I'm just working on fixing the nits that linus pointed out in the PR
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
marek has joined #nixos-dev
<taktoa[c]>
hmmmmmm, so I have a gcc/8/xtensa.nix that contains a function like
<taktoa[c]>
oh wait, I think I should be screwing with the `gccFun = ...` and `gcc = ...`
<taktoa[c]>
since that's where I was messing around before
<taktoa[c]>
to force gcc8 usage
rajivr has joined #nixos-dev
disasm has quit [Ping timeout: 246 seconds]
<taktoa[c]>
hmmmm, that led to infinite recursion
das_j has quit [Quit: killed]
ajs124 has quit [Quit: killed]
Scriptkiddi has quit [Quit: killed]
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner_ has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
<taktoa[c]>
hmm sphalerite
<taktoa[c]>
oops, sent that message too early
<taktoa[c]>
what exactly did you mean by "using the overridden version to define the stdenv for this platform"?
<taktoa[c]>
I don't see any place in all-packages.nix where platform-specific stdenvs are defined, maybe this is done somewhere I'm not aware of in the guts of nixpkgs?
<taktoa[c]>
pretty hard to grep for "stdenv" in nixpkgs :)
tilpner_ is now known as tilpner
disasm has joined #nixos-dev
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
sgrunert has joined #nixos-dev
alp has joined #nixos-dev
alp has quit [Ping timeout: 240 seconds]
<garbas>
infinisil: sorry i was already afk, but commented on the RFC#72 once i got pinged by zimbatm. in general i can not make it before 21:00CEST (kids). I'll read the minutes from meeting #2 and then we can chat (if needed ofcourse).
<garbas>
infinisil: looks like the minutes of meeting 2 are very sparse ... lets chat when you can. ping me i'll be until 15:00CEST and then again after 21:00CEST
cole-h has quit [Quit: Goodbye]
sgrunert has quit [Quit: Leaving]
alp has joined #nixos-dev
sgrunert has joined #nixos-dev
<urkk>
sphalerite: sorry for the delay, kernel 4.4.49, permissions 0000 with the `stat -L` test
<urkk>
sphalerite: no, I cannot change the kernel in this machine
<sphalerite>
yeah, just wondering where the kernel is from because this issue is probably dependent not only on the kernel version but its config too
<urkk>
So it does a bind mount mount("/dev/ptmx", "/nix/store/4mxy1s63hg0nfsidi2gpgp9skr6r9jql-testptmx.drv.chroot/dev/ptmx", 0x7f362e1464fe, MS_BIND|MS_REC, NULL) = 0
<urkk>
Oh, I have this mountpoint in my machine: devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
<sphalerite>
hm, and is ptmx a symlink to pts/ptmx in the root namespace?
<urkk>
Maybe that is the problem, the ptmxmode
<sphalerite>
oh yes, that looks like it
<urkk>
ptmx is a char device
<urkk>
thanks! I will take a look
<sphalerite>
#96259 channel blocker fix, if anyone cares to take a look :)
<infinisil>
garbas: Yeah meeting notes are pretty sparse, but there wasn't a lot to talk about and everybody was pretty happy already. mboes will amend the PR with the two things I wrote down
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-dev
orivej has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
FRidh has joined #nixos-dev
AlwaysLivid has quit [Read error: Connection reset by peer]
<tilpner>
ajs124: That is restricted to committers, and doesn't handle maintainers
<ajs124>
ah, right. does the RFC say anything about that? I always felt like the whole "maintainer" concept in nixpkgs is quite different from other distributions anyways.
<V>
Yeah, this is concerning unmaintained/broken packages
<ajs124>
right. when in doubt, drop? or are the packages important (by some magical metric)?
<V>
No, I don't think anyone has been using this for quite some time