gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.03 release managers: fpletz and vcunat | https://logs.nix.samueldr.com/nixos-dev
<samueldr> I feel I'm right in assuming the way nix-build's and nix-shell's argument parsing are combined makes for surprising behaviour
<samueldr> stuff like `nix-build --command "test" release.nix` not failing due to unknown args
<samueldr> (and conversely nix-build's args on nix-shell)
<gchristensen> O.o
<{^_^}> nix#1982 (by lheckemann, 21 weeks ago, open): nix-build: --add-root ignored
<{^_^}> nix#2208 (by goodwillcoding, 9 weeks ago, open): nix-shell dependencies can be garbage collected any time now / persistent nix-shell envs
<samueldr> part of their surprising behaviour could come from the fact that they don't error out
<samueldr> and also, the fact that --add-root just sets a variable and (apparently?) does nothing with it
<samueldr> hahaha, or the funnier `nix-build --impure ./release.nix -A build.x86_64-linux`
<samueldr> (for which the argument is a no-op)
<samueldr> oof, `nix-shell ./shell.nix` !== `echo 'import ./shell.nix' | nix-shell -`
<samueldr> (I could move this elsewhere, but uh, I kind of feel it's more relevant here for serious business stuff)
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 272 seconds]
lassulus_ is now known as lassulus
pie__ has joined #nixos-dev
pie_ has quit [Read error: Connection reset by peer]
sir_guy_carleton has joined #nixos-dev
Drakonis has quit [Remote host closed the connection]
<clever> perl depends on bootstrap-tools in the latest unstable...
<clever> but not on master...
<clever> ah, old master
<clever> i'll just stop talking till i pin down the details, lol, new master is also good
Drakonis has joined #nixos-dev
<clever> this leaks a texinfo that depends on the bootstrap perl
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-dev
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-dev
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-dev
garbas has quit [Quit: WeeChat 2.1]
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-dev
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-dev
Drakonis has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
Drakonis has joined #nixos-dev
Drakonis has quit [Remote host closed the connection]
sir_guy_carleton has quit [Quit: WeeChat 2.0]
orivej has quit [Ping timeout: 256 seconds]
init_6 has joined #nixos-dev
init_6 has quit [Ping timeout: 240 seconds]
Drakonis has joined #nixos-dev
Drakonis has quit [Quit: Leaving]
timokau has quit [Quit: WeeChat 2.2]
timokau has joined #nixos-dev
orivej has joined #nixos-dev
aanderse has joined #nixos-dev
<timokau[m]> Just opened my first RFC, I hope it won't go nowhere fast :D
<{^_^}> rfcs#30 (by timokau, 8 minutes ago, open): Formalize review workflow
<MichaelRaskin> Sigh. I think there are additional effects about reviewer switching, not just discoverability.
<timokau[m]> Please leave a comment with your opinion, I'm sure it can be improved :)
<MichaelRaskin> I am not sure it is something that is easy to improve in the RFC, which is why I don't want to start the discussion with hard-to-fix pessimistic remarks
<MichaelRaskin> Ooohh the long dream of the ofBorg merge workflow
<timokau[m]> If keeping the same reviewer would be preferred, we could mark prs as `has:reviewer` or make use of githubs assignments. We could then automatically remove that assignment after some time without a review. That way it would stay one reviewer in most cases while still solving (2).
<timokau[m]> The `build-and-merge` is not a prerequisite for this of course.
<gchristensen> MichaelRaskin: it is coming! https://www.patreon.com/posts/timeouts-nix-ci-20643198 read "Where have I been?"
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-dev
<MichaelRaskin> timokau: single reviewer is not desirable in principle, but in specific cases people often want the original commenter to evaluate how the issues raised were addressed in an updated version of the PR
<MichaelRaskin> Something like lost:reviewer could serve as an encouragement
<MichaelRaskin> gchristensen: I mostly meant my comment as «this is coming some day, and this is needed, and these claims are true independently of the RFC»
<gchristensen> aye :)
<timokau[m]> MichaelRaskin: I think in most cases the comments are relatively straightforward nitpicks. But it probably doesn't hurt much to keep to one reviewer for most cases.
<jtojnar> dtz[m]: do you have something I can reproduce the meson build failure with?
<timokau[m]> MichaelRaskin: do you still think that your concern shouldn't be added to the PR discussion?
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
<MichaelRaskin> timokau: I have some pessimism, and some things that I would prefer to discuss once some definitely-planned ofBorg features land
<timokau[m]> Given the time the rfc process usually takes, I think it makes sense to start discussion now. You can do it however you prefer of course :)
<MichaelRaskin> Let there be some less jaded comments than mine
<MichaelRaskin> At least to set the initial tone
<timokau[m]> MichaelRaskin: very considerate :D Anyways, I'll be away for a while now.
<MichaelRaskin> Good luck in case anything in the process can benefit form luck!
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
<aanderse> MichaelRaskin: are you raskin from maintainers.raskin?
<aanderse> if so... would you mind looking at https://pastebin.com/6sSrHJKm
<aanderse> you're listed as the openscenegraph maintainer
<aanderse> it needs a version bump, and i made it a bit more configurable
<MichaelRaskin> aanderse: yes, and I have mass-packaged a lot of stuff by dependency-walking, so I am very willing to add extra maintainers
<MichaelRaskin> (and I am not very good at finding relevant notifications from GitHub unless direct-mentioned as @7c6f434c )
<MichaelRaskin> gchristensen: good that surgery does help…
<aanderse> MichaelRaskin: will submit and mention you then
<MichaelRaskin> Did you try more than one support combination?
<aanderse> i tried compiling with all on, all off, and default
<aanderse> all 3 cases compiled
<MichaelRaskin> did they actually have different closures?
<aanderse> well... in hindsight that seems like an obvious check :( i checked the result/ dir to make sure the list of plugins was different
<aanderse> but
<aanderse> yeah... should have checked that first
<aanderse> i mean... one implies the other
<aanderse> but still
<aanderse> <- still learning
<MichaelRaskin> No, checking difference in plugin list is also fine
<MichaelRaskin> I just don't remember specifics, so I ask for a generic check; specific check is perfectly fine when applicable
orivej has quit [Ping timeout: 256 seconds]
<aanderse> ok, confirmed different hashes... though it appears lua sneaks in regardless of luaSupport being false
<aanderse> it must include the source inside osg or something
<MichaelRaskin> Hashes will always be different, runtime dependency list is the interesting question
* aanderse removes luaSupport flag
<MichaelRaskin> Yes, honesty is nice.
<aanderse> hmm... same for zip support
<aanderse> baked in
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
<aanderse> MichaelRaskin: rebuilt everything with the 2 options removed, going to make a pull and mention you now
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
aanderse has quit [Ping timeout: 240 seconds]
garbas has joined #nixos-dev
Drakonis has joined #nixos-dev
<gchristensen> the most inconvenient part of having such a large community around the world is there is no obviously convenient time to shut down ofborg for 30min
<gchristensen> not entirely true: 20:00 - 02:00 America/New_York seems like the best time
<MichaelRaskin> Having a few morning people (I mean those rising early in the morning, not those up until morning! — although if you have the former, you probably also have the latter…) does that inside a single timezone!
<MichaelRaskin> 20:00 seems to be so-so from US-East point of view?
<gchristensen> yeah
<MichaelRaskin> 02:00 New York is 09:00 MSK, right?
<gchristensen> sounds likely
<MichaelRaskin> I think we have people from Beijing…
<MichaelRaskin> Then again, when my builder with regular 20h of down time turned out to be the only one, it was investigated like a month later
<MichaelRaskin> So 30 minutes of downtime, if RabbitMQ just holds the messages to use later, could be not that much of an impact
<gchristensen> that is the problem, rabbitmq will be going down for it
<LnL> it's rabbitmq itself, not the rest of the infra isn't a big deal
<gchristensen> to make it easier to add more rabbitmq nodes
<MichaelRaskin> I wonder if there is something ready-made that can be started to replace RabbitMQ and just write down all the requests into files
<gchristensen> a good idea
<gchristensen> it wouldn't be so hard to make the github ingestion program write to a file, on a new server, for an hour
<MichaelRaskin> You are not obliged to reply in a sensible way, right?
<MichaelRaskin> So it can basically be socat instance
<gchristensen> right
<LnL> ah you already found it
<MichaelRaskin> Hm. So if socat just dumps every connection into a file, then these files can be later replayed by a similar trivial socat abuse, right?
<gchristensen> MichaelRaskin: github would prefer I send back an http 200 :P
<MichaelRaskin> Sigh.
<MichaelRaskin> Still not too complicated, but complicated enough to wonder if there is a ready script for that.
<gchristensen> the final option is we can just drop them on the floor
<gchristensen> it wouldn't be the first time
<MichaelRaskin> That's true
<MichaelRaskin> But having a recorder would also be nice for the future planned downtime
<gchristensen> for sure
<MichaelRaskin> Argh, Java, do not want
<gchristensen> nooope
<MichaelRaskin> Are requests POST or PUT?
<gchristensen> POST
<gchristensen> there is another option I hadn't considered
<gchristensen> don't upgrade the node at all, just point new traffic to a new node and migrate workers over.
<MichaelRaskin> That sounds like a natural solution…
goibhniu has joined #nixos-dev
orivej has joined #nixos-dev
<sphalerite> niksnut: any chance of getting https://github.com/NixOS/nixos-channel-scripts/pull/21 merged and deployed?
<{^_^}> nixos-channel-scripts#21 (by lheckemann, 3 weeks ago, open): Add netboot files
<gchristensen> ooooOOoooOooooh
gchristensen has quit [Ping timeout: 268 seconds]
gchristensen has joined #nixos-dev
<samueldr> I don't think the 'nut is a week-end person :/
<{^_^}> nix#2208 (by goodwillcoding, 9 weeks ago, open): nix-shell dependencies can be garbage collected any time now / persistent nix-shell envs
<samueldr> you seem knowledgeable, `nix-shell ... --add-root ...` is it supposed to work?
<samueldr> nix-shell takes the parameter... and apparently does nothing with it
<LnL> it's probably nix-build only
<samueldr> doesn't either
<samueldr> search gcRoot, it's declared earlier, set there and... nothing uses it afterward
<samueldr> unless I'm mistaken and there's some C++ magic
<LnL> oh, hmm compatibility?
<samueldr> (I was looking into fixing the arguments parsing weirdness in both tools yesterday)
<LnL> thought it did, similar to nix-instantiate
<samueldr> LnL: I'm not even sure, have to re-check, but IIRC the param wasn't there previously
<samueldr> and when it was added, it was added like that
* samueldr re-checks now
<gchristensen> samueldr: 15 years is a long time :)
<LnL> since nix-build is mostly like nix-store --realise $(nix-instantiate) it does make sense for it to take all the flags of those commends
<samueldr> that file has a surprisingly small history
<samueldr> yeah, I was wrong, it did exist earlier
<LnL> but ideally it would actually use them ofcorse :p
<samueldr> LnL: it's documented in the manual that it does take a bunch of "other flags"
<samueldr> and passes them to nix-store --realise
<LnL> nice
<samueldr> (also fixing that at the same time)
<samueldr> All options not listed here are passed to nix-store --realise, except for --arg and --attr / -A which are passed to nix-instantiate.
<samueldr> (except it *also* passes -E to nix-instantiate :)
<clever> originally, it was a perl script that had to split things up like that, but now its all c++
<samueldr> yes, and far from me to knock it, it's more of a "am I crazy or are thing just unused?" and "should it work?"
<samueldr> as I said yesterday, I like how `nix-build --impure ./release.nix -A build.x86_64-linux` is a valid command, where --impure is a no-op :)
Lisanna has quit [Remote host closed the connection]
goibhniu has quit [Ping timeout: 260 seconds]
Lisanna has joined #nixos-dev
Lisanna has quit [Remote host closed the connection]
Lisanna has joined #nixos-dev
timokau has quit [Quit: WeeChat 2.2]