gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
yl has quit [Ping timeout: 257 seconds]
jasongrossman has joined #nixos-chat
lassulus has quit [Ping timeout: 246 seconds]
iqubic has quit [Ping timeout: 268 seconds]
<gchristensen> dtz does cool stuff
iqubic has joined #nixos-chat
lassulus has joined #nixos-chat
<nh2> clever: I've currently hit a significant roadblock on my quest of implementing strace in Haskell: When I compile with `-threaded`, then infrequently, random `ptrace()` calls randomly fail with `No such process`. Doesn't happen on non`-threaded`
<clever> nh2: if your strace your stracer, what does strace say? lol
<clever> nh2: and does ptrace have any rules on calling it from the same host thread?
drakonis has quit [Quit: WeeChat 2.3]
<nh2> clever: I couldn't find any such rule in the man page, but given that the main consumer of ptrace() is strace and single-threaded, people may not have explored that a lot. I'm currently exploring strace'ing my Haskell tracing program, but it's not easy because I can't use -f (that'd result in the innermost program being traced by 2 programs and that seems impossible)
<clever> nh2: -b syscall If specified syscall is reached, detach from traced process. Currently, only execve(2) syscall is supported. This option is useful if you want to trace multi-threaded process and there‐
<clever> though that may still conflict with your haskell code trying to ptrace its child before the child execve's
<nh2> clever: yeah, I use the approach where I fork(), the child does ptrace(PTRACE_TRACEME), then raise(SIGSTOP) so the parent can wait for it, then execve()
<nh2> it also currently still triggers an error case in my code, might be due to that
<nh2> clever: that said, I do see the ptrace() calls I expect even when using strace without -f on my Haskell process; I wonder why that works
<nh2> the man page says that `-p` attachess all threads of the process even without `-f`, but I'm not using `-p`
<nh2> clever: I managed to observe now in strace what's happening: https://pastebin.com/ra4LDKVk
<nh2> clever: quite odd: I successfully PTRACE_GETREGS the child, and then the next ptrace fails with `No such process` -- I didn't even do anything in between (no waitpid() or nothing)
<nh2> it's as if it just disappeared
endformationage has quit [Quit: WeeChat 2.3]
lassulus_ has joined #nixos-chat
lassulus has quit [Ping timeout: 258 seconds]
lassulus_ is now known as lassulus
iqubic has quit [Remote host closed the connection]
<clever> nh2: *looks*
<clever> A tracee first needs to be attached to the tracer. Attachment and subsequent commands are per thread: in a multithreaded process, every thread can be individually attached to a (potentially different) tracer, or left not attached and thus not
<clever> debugged. Therefore, "tracee" always means "(one) thread", never "a (possibly multithreaded) process". Ptrace commands are always sent to a specific tracee using a call of the form
<clever> nh2: the way i parse this, is that when you attach to a remote thread, the attachment is specific to the local thread
<clever> and when ghc roams you to another thread, everything breaks
<clever> ESRCH The specified process does not exist, or is not currently being traced by the caller, or is not stopped (for requests that require a stopped tracee).
<clever> `or is not currently being traced by the caller` thread, i think?
srhb- has joined #nixos-chat
qyliss^work_ has joined #nixos-chat
srhb has quit [Ping timeout: 246 seconds]
qyliss^work has quit [Ping timeout: 246 seconds]
qyliss^work_ is now known as qyliss^work
kgz has quit [Ping timeout: 258 seconds]
LnL has quit [Ping timeout: 245 seconds]
kgz has joined #nixos-chat
ninjin has quit [Ping timeout: 256 seconds]
<jD91mZM2> Welp, just bought dvorak stickers from amazon :)
ninjin has joined #nixos-chat
ninjin has quit [Ping timeout: 256 seconds]
jasongrossman has quit [Remote host closed the connection]
jasongrossman has joined #nixos-chat
emily has quit [Ping timeout: 264 seconds]
emily has joined #nixos-chat
Guest34980 has joined #nixos-chat
jasongrossman has quit [Remote host closed the connection]
__monty__ has joined #nixos-chat
ninjin has joined #nixos-chat
srhb- is now known as srhb
Guest34980 is now known as LnL
<tilpner> Huh, ofborg alone has 15.14% percent of all shares on hydra.nixos.org
<tilpner> While nixpkgs:trunk just has 0.02%
<tilpner> Is that to make sure smaller projects don't get delayed forever in favor of random nixpkgs jobs?
Guanin has joined #nixos-chat
<joepie91> have an utterly useless inferred type annotation: https://i.imgur.com/aRFAOEh.png
<__monty__> Imagine if GHC just went "Infer it yourself!" all the time : )
<LnL> tilpner: the share configuration is a bit hand-wavy, doesn't do much given the low amounts of jobs it builds
<tilpner> LnL: Low amount of jobs? How does hydra.nixos.org build a low amount of jobs?
<joepie91> __monty__: yeah, this definitely felt like a "ha, screw you" from tsc :P
<LnL> the ofborg jobset only has a few jobs
<tilpner> LnL: But arent't shares global, divided up between all projects?
<tilpner> I know nothing about how Hydra schedules builds, but wouldn't new build steps for the ofborg project be greatly preferred over new jobs from the nixpkgs project?
<gchristensen> the roughly 20 builds that ofborg has would be greatly preferred yes
<gchristensen> over the 40,000 of, say, trunk
<LnL> yes but 10 jobs / week is irrelevant compared to the rest
<tilpner> So that only works because ofborg has few builds and doesn't change a lot?
<gchristensen> right
<gchristensen> also it was probably a typo to get 15%
<tilpner> I wonder where the other 69% went
<gchristensen> curl -H "Accept: application/json" https://hydra.nixos.org/ will probably tell you
<LnL> the release jobs probably
<gchristensen> (ah maybe not)
<tilpner> Ohh, those are in nixos, not nixpkgs
<tilpner> release-17.03-small alone has 15.14%
<gchristensen> yeah
<gchristensen> not surprised
<tilpner> While I have you two Hydra experts here c.c
<tilpner> I'm seeing "warning: substituter ... does not have a valid signature for path ...", even though I have added to trusted-public-keys. Oddly, not all substitutions complain about this
<gchristensen> I don't think they really mean anything for our hydra, it isn't like our hydra isn't doing a lot of work almost all the time
<__monty__> tilpner: Trusting a key means nothing if the path isn't signed by that key though.
<tilpner> __monty__: Can I force a resign of those paths?
<__monty__> Yes.
<tilpner> I may have messed up the config while it built them, so even if it's fixed now, I might still have unsigned paths around
<__monty__> tilpner: Try nix --sign-paths /nix/store, or more specific paths.
<LnL> tilpner: nix path-info --store https://cache.nix.example.org --sigs <path> --option tarball-positive-ttl 0
<LnL> is the nar signed? otherwise it was probably uploaded without a signature
<tilpner> I don't think my "nix" has a --sign-paths
<tilpner> (2.2)
<__monty__> Oh, it's a command not an option.
<LnL> yeah, nix sign-paths ... not a flag
<tilpner> Oh, of course. I haven't used the nix cli much yet
<LnL> you'll also want to make sure hydra does this by default if you've not configured that
<tilpner> I haven't set binary_cache_dir at all, it doesn't have many users so I nix-serve them out of the store
<LnL> ah it's the local store, in that case
<tilpner> Oh? I can use the local store with store_uri?
<tilpner> I currently set binary_cache_secret_key_file and hope it does something
<tilpner> I don't know how to verify that though
<LnL> set secret-key-files in nix.conf and local builds will be signed automatically using that key
<LnL> not sure what that setting does, maybe for useSubstitutes?
<tilpner> Is there a manpage for hydra.conf that I'm missing? I usually grep the source, but that doesn't help with getting an overview
<tilpner> I'll try setting secret-key-files :)
<LnL> no idea, I stole everything from nixos-org-configurations
<tilpner> This is a bit concerning. I ran nix sign-paths --all -k /etc/nix/$(hostname)/secret, but there are still paths not signed with that key
<tilpner> More importantly, they are signed with a key that has my hostname as its name, but all are different keys
<tilpner> As determined by nix path-info --sigs --all | grep -vF $(cat /etc/nix/$(hostname)/public)
<LnL> with the command from earlier?
<LnL> err, that option doesn't exit
<LnL> --option narinfo-cache-positive-ttl 0
<tilpner> Something regenerated my key, huh
<tilpner> Could be Hydra, could be Nix
<tilpner> They are owned by hydra:hydra, so...
<LnL> yeah, but wha? substituting or
<tilpner> Sorry, I don't understand the question
<LnL> what's wrong, substituting or the result of path-info --sigs
<tilpner> The result of path-info --sigs is wrong
<LnL> with that extra option?
<tilpner> And hydra has overwritten my secret key, multiple times
<tilpner> I've now removed binary_cache_secret_key_file from hydra.conf
<LnL> nix caches narinfos by default and that includes the signatures
* LnL should make a pr
<tilpner> No, that was without setting narinfo-cache-positive-ttl
<tilpner> I'll make new keys, re-sign everything, and try again
<tilpner> I'm not sure sign-paths has any effect
<LnL> does the local path have a signature?
<tilpner> When I do nix path-info --sigs --option narinfo-cache-positive-ttl 0 /nix/store/zxi65ww7bws5lqlxgljq0p2j6pd4waiv-openssl-1.0.2q
<tilpner> it shows multiple signatures, for two hydra-generated keys, and the cache.nixos.org key
<tilpner> But not for current public key of the machine
<LnL> ah, did the signing run as a trusted user (or root)?
<tilpner> It ran as root, which is not part of the trusted-users list in nix.conf
<LnL> that's fine
<tilpner> The public key is shorter than the secret key, right?
<tilpner> Oh, duh
<tilpner> That was stupid
<tilpner> Of course path-info doesn't show the public keys a path was signed with
<tilpner> How else can one verify that all store paths are now signed with the proper key?
<__monty__> tilpner: Not a stupid question. RSA pub and priv keys are actually ~equal in length.
<tilpner> That's not what I called stupid
<__monty__> Ah.
<tilpner> For some reason I assumed that the public key would turn up in the path-info output
<tilpner> Which it doesn't
<tilpner> But because the signatures looked similar to the secret key representation, I jumped to the conclusion that they were keys, and the wrong ones too
<tilpner> Which is stupid
<tilpner> So, uhh, sorry :)
<tilpner> LnL: But $(cat pk) != example:RE5/sXRaTOYnbvq/2vKO7kaR4nZfm2+dbWEJyUErvTk0PDSMr8PDz0lgs/iqw6r8drqOWppAlsggVyREfBdqCg==
<LnL> and barfs if you use a wrong key
<tilpner> Because those are not keys
<LnL> ah yeah, look at the name
<LnL> the value is the actual signature
<tilpner> Which I now understand, sorry for all the confusion :)
<LnL> ok so, do we have signatures for the local paths now?
<tilpner> Well, I don't know how to verify these signatures against a public key
<tilpner> But at least they seem to have the right name now
<LnL> you probably can with openssl or something, but I wouldn't worry about that
<LnL> what about path-info --store <cache> --sigs --option narinfo-cache-positive-ttl 0 <path>
<tilpner> That just shows me the signatures, which all have the right name so far
<LnL> looks ok then, minus the caching issue
<tilpner> Thank you :)
<LnL> nix-store -r <path> --option narinfo-cache-positive-ttl 0 might be enough to invalidate that, not sure
MichaelRaskin has joined #nixos-chat
jasongrossman has joined #nixos-chat
drakonis has joined #nixos-chat
jasongrossman has quit [Remote host closed the connection]
jasongrossman has joined #nixos-chat
Guanin has quit [Remote host closed the connection]
iqubic has joined #nixos-chat
jasongrossman has quit [Ping timeout: 252 seconds]
jasongrossman has joined #nixos-chat
iqubic has quit [Ping timeout: 250 seconds]
iqubic has joined #nixos-chat
<samueldr> ofborg does it better
<samueldr> with the live update thing
<samueldr> the "View more details" on github actions only links to the actions documentation
<tilpner> samueldr: Does that run on Githubs servers?
<samueldr> yeah, I have no infra for that
<tilpner> Interesting, didn't notice they started doing CI too
<samueldr> don't know if anyone else made a nix-build action yet
<tilpner> Well, you did, so nobody else has to? c.c
<samueldr> more to the point: am I duplicating better made work?
<samueldr> :_)
<samueldr> oops, :)
<samueldr> it was reaaaaaally easy to do though
<samueldr> once I could figure out what the bad doc from github was lacking
<samueldr> (in reality, it lacks nothing, except it kinda muddles the line between *creating* and *using* an action)
<MichaelRaskin> samueldr: maybe the last step of the action should be pastebin-ing of the output and printing the link so it is visible in the GH summary?
<samueldr> definitely WIP L)
<samueldr> :) * dang cannot even emoticon properly today
<samueldr> though once built, the build log is made entirely available in the step https://github.com/samueldr/ROC-RK3399-PC-overlay/pull/1/checks?sha=f5ec3f2b21fc4c65e6f48049c88492948e401712
<samueldr> it's only during the build that there's not progress
<samueldr> oh, it's **not** entirely available
<samueldr> they keep the useless ### SARTED and then crop the end of the build :/
* samueldr sits back properly and straight to reduce typos
<__monty__> samueldr: You're breaking my github CSS >: o https://imgur.com/a/mHUIkWT
<samueldr> I would like to say it's done intentionally :)
<samueldr> so, using nix-build in github actions without a "branded" action is stupid easy
<samueldr> this is an example which will likely fail as it shows how one would use a specific channel using NIX_PATH
etu1 has joined #nixos-chat
etu1 has quit [Quit: WeeChat 2.2]
etu1 has joined #nixos-chat
etu has quit [Quit: WeeChat 2.3]
etu1 is now known as etu
<gchristensen> well I can't say I ever expected to buy windows
<colemickens> This post has lots of good critical feedback, but it gave me an idea: https://news.ycombinator.com/item?id=19177435
<colemickens> It'd be cool to have a "secure" profile that just blanket enables all of these that could be imported into a nixos configuration. Another nixos talking point maybe. I need to start a list of these.
<joepie91> colemickens: (you could use musnix as an example)
<gchristensen> never did I ever expect you could actually donload a windows ISO from microsoft.com ... man
<averell> hah. wait till you see WSL. it's actually usable.
<gchristensen> I ~probably won't try it, but maybe... :)
<gchristensen> I'm getting windows to run Nuance's Dragon
<averell> RSI combat? good luck.
<averell> I remember them from like 20 years ago with dragon naturally speaking or something. back then it was amazing for the time.
<gchristensen> that is the hope
<gchristensen> I think nuance is generally evil and anti-competitive, but as a result they're the best :|
__monty__ has quit [Quit: leaving]
jasongrossman has quit [Ping timeout: 252 seconds]