MichaelRaskin has quit [(Read error: Connection reset by peer)]
MichaelRaskin has joined joined #nixos-dev
page has quit [(Quit: leaving)]
Sonarpulse has joined joined #nixos-dev
<gchristensen>
anyone have feelings on srhb having merge permissions?
<gchristensen>
they know their limits and are pretty great contributors on IRC
page has joined joined #nixos-dev
<MichaelRaskin>
Hm. 15 PRs (all either accepted or superseded by parallel effort, which is a nice work completion track record, but a bit short) — but yeah, their IRC activity is quite large and useful, so probably a good idea.
<MichaelRaskin>
Also, under root it reports single-user setup, which is not literally true.
<gchristensen>
:$
<MichaelRaskin>
Because root has NIX_REMOTE= and locking magically works so why make root go through daemon?
<gchristensen>
do you have an alternate, effective way, to determine the status of multi-user?
<MichaelRaskin>
pgrep nix-daemon ?
<MichaelRaskin>
Also not fool-proof, of course…
<gchristensen>
and if nix is socket-activated and not yet used ... :)
<MichaelRaskin>
… then we cannot find out if it will start up succesfully on socket activation?
<MichaelRaskin>
(without trying)
<gchristensen>
this explains why nobody has built this tool yet
<gchristensen>
ok I have an idea, let me try a few things.
<MichaelRaskin>
And by the way root-owned single-user setup seems to be the same as multi-user setup with stopped nix-daemon!
<gchristensen>
if you run nix as root you must havebuild users in the group
<MichaelRaskin>
Maybe you ar easking the wrong person (or wrong questions).
<LnL>
that's why I was suggesting to check both /nix/var/nix/daemon-socket/socket and NIX_REMOTE and show something like 'unknown' if it's inconsistent
<gchristensen>
ohh I seee
<MichaelRaskin>
I have used Nix in many many ways, so I can break any script by a case from my experience.
<LnL>
like if it's in a state where the user might want to use the daemon but something is not configured properly yet
<MichaelRaskin>
Do we have any list of situations that come up on IRC/GH where there was a key piece of information about the user setup that could help?
<gchristensen>
MichaelRaskin: that is why you're useful here
<MichaelRaskin>
I mean, I have training in formal logic and I sometimes program like a person who has. If you want to build a tool I won't break easily, you are not going to have a release/
<gchristensen>
I know, but I'm okay with it being broken in certain ways
<gchristensen>
if it is broken it is still useful for diagnostics
<MichaelRaskin>
So maybe there are some actual cases from saner users that you definitely want to detect and these should be linked in the conversation?
<disasm>
gchristensen: -m outputs grep: /etc/nix/nix.conf: No such file or directory, probly want to 2> that to /dev/null
<gchristensen>
I don't have examples to cite at the moment
<MichaelRaskin>
Ro be honest, if a tool needs to be built by Nix, it is a drawback for debugging.
<MichaelRaskin>
And «break» is «make the tool confidently return strange and misleading data»
<MichaelRaskin>
I mean, if a user succeeds to run the tool, there is already little to debug.
<MichaelRaskin>
(you can tell me if you want me to stop being destructively negative)
<gchristensen>
yes please :)
<gchristensen>
I think this will help, and if it doesn't, we can do something different
<MichaelRaskin>
What about _prepending_ @path@ to PATH instead of replacing?
<MichaelRaskin>
Then a downloaded copy can report at least something.
<MichaelRaskin>
By the way, do we have a way to advertise some issue that requires little experience as «user help needed for a simple task»? Maybe we could ask users to search and link IRC logs and GH issues for installation problems, so the next release can be tested against these use cases?
<LnL>
the tool isn't really for installation issues, is it?
<MichaelRaskin>
Not sure, to be honest.
<MichaelRaskin>
If we care about multi-user/single-user, I assume we want to be able to detect common issues breaking nix-build
<LnL>
there's a bunch of cases where it's useful to know that
<LnL>
eg. when changing nix.conf you want to restart the daemon
<gchristensen>
that'd be great, MichaelRaskin
<LnL>
and other things like impureEnvVars behave differently
<disasm>
I think there's two things this tool is trying to do (and both I think are useful). 1) In IRC instead of having to explain to someone how to figure out what channel their on, whether they're multi-user, etc... just have them run the tool and paste the output, saving 1-2 minutes of time it would take to explain to them the commands they need to run to figure it out for themselves, and 2) save 30 seconds to
<MichaelRaskin>
> What about _prepending_ @path@ to PATH instead of replacing?
<disasm>
a minute for people filing issues frequently that collects all the information we ask for in the template instead of having to copy/paste back and forth between terminal and browser.
<gchristensen>
yeah, it is a fight even to get out if "unstable" means "nixpkgs-" or "nixos-"
<disasm>
exactly
<gchristensen>
it isn't to debug critically broken setups
<disasm>
and in that regard, I think complex setups that break the tool are going to be wielded by people that already know these answers :) This is more the typical I curl bashed installing nix and now I have a question, but don't know what you're asking me to tell you.
<gchristensen>
it isn't to provide a comprehensive review of why something is broken
<disasm>
like right now I'd really like to ask fearless kim in the other channel to run gchristensen tool :)
seppellll has quit [(Ping timeout: 260 seconds)]
phreedom has joined joined #nixos-dev
<fpletz>
so frustrating to see no automatic channel releases for 17.09 after neglecting to watch hydra for a few days :(
<fpletz>
lots of build hosts have problems, no free disk space, aborted jobs due to unreachability
<fpletz>
btw we need a new release manager for 18.03… any volunteers? :>
Sonarpulse has quit [(Remote host closed the connection)]
<fpletz>
niksnut: are you aware of the above mentioned hydra issues?
<fpletz>
gchristensen: since you added limitedSupportSystems, I'd like to remove nixos tests for limitedSupportSystems… any objections there?
<fpletz>
for instance the firefox i686 tests is failing because firefox fails to build but we need to get that new version out due to a security issue… and this delays the channel release for everyone o/
<fpletz>
gchristensen: sorry, wasn't precise… I'd like to remove the limitedSupportSystems tests from the tested job, so we still build them but they're not release-critical anymore
<fpletz>
niksnut: wendy is out of disk space
<LnL>
"You should not evaluate entire Nixpkgs"
<LnL>
is that new?
<MichaelRaskin>
Yes
<MichaelRaskin>
Relatively
<MichaelRaskin>
gchristensen talked me into adding it.
<LnL>
cool :)
<LnL>
I was running nix-build instead of nixos-rebuild
<MichaelRaskin>
I hope you are not the first one to admit in IRC encountering this check…
JosW has quit [(Quit: Konversation terminated!)]
<disasm>
ooh! Thanks MichaelRaskin :)
<disasm>
I don't know how many times I ran nix-build without a -A param and came back a few hours later and my laptop was still churning through a bunch of builds.
<MichaelRaskin>
no-no, it's all gchristensen's fault that this code exists.
<disasm>
haha, you don't like it?
<MichaelRaskin>
Technically, there is not enough code to like.
<MichaelRaskin>
I mean, there are 4 parsing tokens, including equality sign.
<MichaelRaskin>
OK, 5 if you include the comment.
<MichaelRaskin>
What colour does a single carbon atom have?
<disasm>
LnL: is that all of nixpkgs in that little tarball? kinda looks like it....
<LnL>
yep
<fpletz>
grahamc: the release announcement mail somehow didn't make it to the list anyway, I'll send another one shortly… note that we didn't really drop support, it's just not a high priority architecture for us. but you're right, not having some of the basic tests is unfortunate.
* disasm
is shocked nixpkgs is only 13 MB compressed
<fpletz>
grahamc: currently even some of those are failing because wendy is broken :(
<LnL>
I wonder how much of that is hackage-packages.nix / generated stuff
<fpletz>
disasm: gchristensen surely is qualified and I would love to have him… but the time investment is considerable, much more than I anticipated. and he's doing great work as inofficial community manager. :)
<fpletz>
grahamc: regarding the limited support flag, I'd like to keep it in for now because I anticipate that we might get some new architecture supported in 18.03 which might be limited at first
<gchristensen>
fpletz: I worry that without bootloader tests we're setting up the i686 users for a bad day
<disasm>
fpletz: mind if I PM you?
<fpletz>
gchristensen: yeah :( should we maybe add some "most basic" tests for limited archtectures to the tested job?
<fpletz>
disasm: no problem, go ahead :)
<gchristensen>
I would be okay with that and continuing to call it "limited" support :)
<fpletz>
ok, I'll come up with some tests and make a PR
<fpletz>
for now, I'd like to make a channel release quickly with all the security updates from the last few days
<gchristensen>
re: release manager, let's talk at nixcon :)
<fpletz>
this shouldn't impact basic nixos functions on i686
<gchristensen>
I agree
<fpletz>
sure ;)
<gchristensen>
MichaelRaskin: did you see my updated PR? it uses a much more correct test on if sandboxing is enabled
<MichaelRaskin>
Well, by now all my use cases are fringe cases, and I don't do that much IRC support, so I don't track the PR closely
<gchristensen>
ok
<MichaelRaskin>
Let me see…
<gchristensen>
(the sandbox test tries to curl nixos.org)
<gchristensen>
and the multi-user test checks to see if the build is run with the nixbld group
<MichaelRaskin>
I am not sure if I would prefer creating a temporary file in /tmp/ and trying to access it…
<MichaelRaskin>
Network is complicated and fragile.
<gchristensen>
hmmm that could probably work
<disasm>
gchristensen: haha, now the 2 second wait for the sandbox test makes sense :)
<gchristensen>
:)
<MichaelRaskin>
Yeah, /tmp/ access would fail faster, too!
<gchristensen>
many benefits!
<LnL>
that would make relaxed show up as no
<gchristensen>
oy
<MichaelRaskin>
What does «relaxed» block?
<gchristensen>
network only maybe?
<gchristensen>
If this option is set to relaxed, then fixed-output derivations and derivations that have the __noChroot attribute set to true do not run in sandboxes.
<MichaelRaskin>
That shouldn't affect the test
<LnL>
don't know the exact difference
<gchristensen>
relaxed shows up as yes
<LnL>
but we can't namespace /tmp for builds on darwin but we can block things like network access
<gchristensen>
oh /tmp is permitted on darwin always
<gchristensen>
awkward.
<LnL>
same on linux I think, but it's namespaced
<LnL>
that's why we had issues with the nix tests leaving stuff around in /tmp
<gchristensen>
yeah
<MichaelRaskin>
So on Darwin store enumeration is not blocked?
<MichaelRaskin>
(by sandbox)
<gchristensen>
well it seems curl is the way to go
<gchristensen>
LnL: anything else I could check with other than network?
<gchristensen>
it would be neat if we could easily discover the sandbox status via some nix-daeemon api
<LnL>
MichaelRaskin: I think it's explicitly allowed for each path
<gchristensen>
MichaelRaskin: is /Users/<user>/... not accessible with the sandbox on macos?
<LnL>
it shouldn't be
<gchristensen>
neat :)
<MichaelRaskin>
Frankly, if Nix profile directory can be accessed from a build, I would just call this not sandboxed by definition (I mean /nix/var/nix/profiles/)
<gchristensen>
hmm
<gchristensen>
should we assume /nix/var/nix/profiles ?
<LnL>
good point, nothing in /nix/var is allowed
<gchristensen>
"yes we should" because if they moved /nix we're going to be able to tell
<MichaelRaskin>
What happens with ls / ?
<gchristensen>
ok it just looks for a /nix/var/nix now
<MichaelRaskin>
You decided not to try recognizing store path and checking its ../var/nix ?
<gchristensen>
good thinking
<gchristensen>
I'll do that when I get back, in a few hours :)
<MichaelRaskin>
5B
<gchristensen>
(I didn't decide, no)
<gchristensen>
5B?
<MichaelRaskin>
Oops.
<MichaelRaskin>
MLterm reacts to some modifier-arrow combos with suspiciously reasonable-looking key sequences
<gchristensen>
oh ok
<MichaelRaskin>
And at some point I moved IRC screens to MLTerm because people were using too many emojis and full-Unicode emoticons
<LnL>
with a test sandbox profile I have laying around I get operation not permitted for ls /
<MichaelRaskin>
Hm.
<MichaelRaskin>
Under Linux I can ls /
<MichaelRaskin>
Although it is a bit emptyish
seppellll has joined joined #nixos-dev
seppellll has quit [(Ping timeout: 258 seconds)]
taktoa has quit [(Remote host closed the connection)]