<abathur>
side by side windows, didn't realize which my cursor was in
<gchristensen>
ah hehe
<gchristensen>
you might want to `realpath` $1 :)
<genesis>
^^
<abathur>
eh, trying to rewrite a test for oilshell that breaks on macos/nixos because it is asserting hard-paths
<abathur>
like
<genesis>
if you like abathur and review, i can propose you a PR :D
<genesis>
s/abathur shell
<abathur>
echo ~{/src,root}
<genesis>
(with a realpath $1 inside)
<abathur>
so I'm really just trying to figure out some way *other* than shell expansion to validate the platform-independent path that expanding the tilde is going to yield for the test
<abathur>
or some better arrangement of the words I just wrote
drakonis has quit [Ping timeout: 256 seconds]
drakonis has joined #nixos-dev
bhipple has quit [Ping timeout: 240 seconds]
bhipple has joined #nixos-dev
<genesis>
echo $HOME/src | jq -R '. | @sh'
bhipple has quit [Read error: Connection reset by peer]
<gchristensen>
aminechikhaoui, niksnut:adisbladis and I have some fairly minor (and yet, sort of major!) change to NixOps in a PR, and we'd like to talk about it some -- make sure we're on the same page -- synergising -- and other business metaphors before we go too far. can you both take a look? https://github.com/NixOS/nixops/pull/1245
<niksnut>
the documentation format has very little to do with the quality of the documentation
<niksnut>
infinisil: sure, and others (e.g. me) would be discouraged if we use markdown
<infinisil>
Which is why I'm pushing for a poll in that RFC, so we can know which format would be preferred by most :)
<infinisil>
Markdown probably won't be a candidate though, since the requirements are hardly met for it
<domenkozar[m]>
...> /nix/store/52ks4xs341kpzxlqf17jn8bqipx5cb62-grub-2.04/sbin/grub-install: error: cannot find a GRUB drive for /dev/xvda. Check your device.map.
<domenkozar[m]>
seems like ec2 deploys are broken with 20.03?
<infinisil>
domenkozar[m]: I personally at least am most bothered by the format
<infinisil>
But yeah tooling could definitely be better too
<infinisil>
Especially the thing about putting docs right next to the relevant code
<Profpatsch>
If the docs build were somewhat more granular we could switch to a nix-based build instead of that makefile thing that dumps files in-tree
<Profpatsch>
which then leads to stale files for the nix build if you forget to clean before running the nix build …
abathur has joined #nixos-dev
<genesis>
what about create some pkgs/top-level/appimages-packages.nix like pkgs/top-level/lua-packages.nix to manage short recipe as https://github.com/NixOS/nixpkgs/issues/38037#issuecomment-478687733 and don't poluate nixpkgs with such thing ? setting global unfree licence on it to prevent building/caching ?
abathur has quit [Ping timeout: 240 seconds]
phreedom has quit [Remote host closed the connection]
<aminechikhaoui>
gchristensen I like the idea in https://github.com/NixOS/nixops/pull/1245, I needed that sometimes at work, not for rollback but having targets to know when we run deploy and if it fails etc ..
<aminechikhaoui>
for me personally, I think getting the units dependencies right would be the challenge, but I have that problem in all systemd services setup
<aminechikhaoui>
maybe some NixOS tests to show the behavior on a couple of examples would be nice to have also
<infinisil>
aminechikhaoui: Yeah systemd dependencies I struggle with too..
<adisbladis>
aminechikhaoui: I have some units you can look at built on top of that PR
<edef>
hmm, i'm feeling profiles/headless.nix is a little confused about its purpose
<edef>
it's imported solely by profiles for cloud virtual machine targets
<edef>
which all set console=ttyS0 (except for Brightbox, but i think that's because it's an undermaintained fork of the EC2 code)
<edef>
it disables serial getty, which is then ~impossible to override cleanly, despite targeting places where serial can definitely be interactive (GCE)
ixxie has joined #nixos-dev
<edef>
it sets panic=1 and boot.panic_on_fail but most of the profiles that import it duplicate that themselves
<andi->
edef: I agree.. slightly different topic but I'd like to see proper serial-only support in nixpkgs. Right now I've to configure multiple locations with my desired baud rate and the serial interface that should be used.
<edef>
the division of responsibilities among the cloud stuff seems really weird in general
<edef>
all of them mess with sshd individually
<edef>
they also all have this thing of sticking an /etc/nixos/configuration.nix into the image, which is at best confusing on production deployments
<adisbladis>
Omg
<adisbladis>
That needs to die
<andi->
throw "this is not a real config"
<niksnut>
why shouldn't it be a real config?
<edef>
niksnut: { imports = [ <nixpkgs/nixos/modules/virtualisation/google-compute-image.nix> ]; } is certainly not "a real config"
<niksnut>
it's certainly the intent that you can create an EC2 instance and run nixos-rebuild inside it
<edef>
and i am not shipping my entire repository to a machine where i should be *getting paged* if libnixexpr is ever even invoked
<edef>
niksnut: i think of the EC2 images we ship with releases as something akin to the live CD
<edef>
niksnut: they're demo systems to some degree, they're not what i'll actually build my production systems off of
<andi->
I think for an EC2 instance that is supposed to be mutated by calling nixos-rebuild that is actually fine. If you intend to not have that file on your custom images you can override the `configFile` attribute to whatever you want.
<andi->
And that is what I meant with the throw line above
<niksnut>
right
<edef>
i'm obviously fine with the live CD coming with a neat little default /etc/nixos/configuration.nix, nicely commented to explain what things you might want to do with it, etc
<edef>
but even if you're just using nixops, libnixexpr shouldn't ever be invoked on the target system
<andi->
adisbladis: what is your concern about that file being there?
<yorick>
edef: also, the aws images do a nixos-rebuild from user data during boot
<edef>
i hope to never use that feature
<yorick>
but yeah, the nix evaluator memory requirements mean we have long given up on evaluating anything on ec2
<adisbladis>
andi-: Exactly what edef pointed out about the nixops case
<gchristensen>
infinisil: "The rollback behavior you described there is pretty much how I implemented it here" it doesn't seem to implement the one-time boot then confirm case?
<arianvp>
question about the new python test infra
<arianvp>
in the old perl stuff, I remember a call to wait_for_unit would implictly start the server
<arianvp>
is this still the case? I see in many tests the vm is explicity start with myvmtest.start()
<arianvp>
before claling myvmtest.wait_for_unit("defualt.targt")
claudiii has joined #nixos-dev
<rnhmjoj>
do you have any explanation for how a derivation depends directly on something which is not in the buildsInputs?
<rnhmjoj>
a recent bump of python3Packages.protobuf broke monero-gui, which doesn't have (explictly) a dependency on protobuf, let alone on the python bindings
<jtojnar>
rnhmjoj but if you link against a static library you need to also link against all the things it depends on
<jtojnar>
I would suggest building monero as dynamic library instead
<zimbatm>
edef: quick question; is the gerrit nixos module that you submitted in your PR something that's already running in prod for you?
<zimbatm>
feel free to PM me if you want to discuss a bit more about the implementation
<edef>
zimbatm: it is, yeah
<zimbatm>
I pushed a few changes on the PR, hope it's ok
<edef>
i was expecting that / hoping for that
<zimbatm>
I have a few more lined-up that I cherry-picked from my own branch
<zimbatm>
ok
<zimbatm>
in that case I will continue tomorrow and ping you when it's ready and we can then discuss on what to keep or not
<edef>
ack
<zimbatm>
ty
<edef>
i assume you're cool with me squashing stuff (probably tomorrow), i'll Co-authored-by you in
<edef>
so far i've only been running this in *prod* for a few days, with essentially 2 users
<edef>
there's def work to be done in terms of making this work with replicas etc
<zimbatm>
yeah no problem, I don't really care about ownership anyways
drakonis has joined #nixos-dev
<zimbatm>
on my side I have been running gerrit with ~20 users and CI pulling from it
<zimbatm>
we have a large repo with git-lfs
<zimbatm>
there's definitely some tuning to do on the JVM and also the number of threads available
<zimbatm>
I haven't touched replicas yet
<zimbatm>
we were using a docker container and it's starting to be annoying to manage => nixos!
<zimbatm>
we are using SSH quite a bit so I will have to add support for that
<zimbatm>
it's also running in Google cloud
<zimbatm>
too bad the Google LB doesn't support both HTTPS and TCP on the same instance
<edef>
hmm, damn
<edef>
i was hoping that'd be supported
<zimbatm>
there is a TCP load-balancer that supports TLS termination
<zimbatm>
which means no HTTP/2 negociation
drakonis has quit [Ping timeout: 256 seconds]
<edef>
i was considering using IAP rather than the Google OAuth plugin
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 256 seconds]
Jackneill has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
ris has joined #nixos-dev
psyanticy has quit [Quit: Connection closed for inactivity]
ixxie has quit [Ping timeout: 268 seconds]
<arianvp>
aszlig: ping
abathur has joined #nixos-dev
abathur has quit [Ping timeout: 256 seconds]
<arianvp>
question: Why do nixos tests only output the VM build log in nice html when the test _succeeds_ ?
<arianvp>
e.g. why does a failed test fail the build
<arianvp>
s/e.g./i.e./
<arianvp>
this means we never get to see that juicy html output to inspect a failed test
<arianvp>
niksnut: I git-blame'd my way through and saw you disabled it at some point to fix issues with hydra
<gchristensen>
it breaks the model to have a successful build which failed
<gchristensen>
kind of annoying
<samueldr>
there is/was something used for hydra-uses IIRC at one point
<arianvp>
yeh but it's also a shame that we have all this nice code to show pretty hierachical build logs
<arianvp>
and then I Cant view them when a test failed
<samueldr>
I agree
<arianvp>
(locally too)
<gchristensen>
I agree
<arianvp>
maybe we can add a flag to ignore failures locally or something?
<gchristensen>
how about --keep-failed, instead
<samueldr>
https://nixos.org/nix/manual/#ssec-relnotes-2.0 >> Failed build caching has been removed. This feature was introduced to support the Hydra continuous build system, but Hydra no longer uses it.
<arianvp>
TIL keep-failed
<samueldr>
what does hydra do now, with failed builds, if anything?
<gchristensen>
probably never attempts to redo them, since the database already has a record of that build failing
<niksnut>
didn't the hierarchical build logs get removed already?
<samueldr>
I meant to keep the VM logs
<arianvp>
keep-failed doesn't keep the outputs, it keeps the .drv buiild script it seems?
<arianvp>
niksnut: nope they're still there
<samueldr>
arianvp: should keep /tmp stuff
<gchristensen>
arianvp: it does keep the outputs in /nix/store until they're garbage collected, and it keeps the tmp dir in /tmp
<niksnut>
should get rid of them
<gchristensen>
niksnut: oh?
<niksnut>
we already deleted most support for nested logs (e.g. the gnu make patch)
<gchristensen>
huh
<niksnut>
and the support in nix
<arianvp>
im talking about hierachical test logs, not build logs
<arianvp>
or is that the same?
<niksnut>
that was more or less the same thing
<arianvp>
ah
<niksnut>
it used the same xslt hackery
<arianvp>
I liked it because currently with the linear nixos test logs it's really hard to figure out which test step failed
<arianvp>
but yeh if we dont feel like supporting it perhaps we should remove it
<arianvp>
(or come up with something better)
<gchristensen>
or add it back to GNU Make and other tools >:)
<arianvp>
hmm but it doesn't look that hacky to me at all?
<arianvp>
what part is hacky eelco
<arianvp>
only 136 lines of xslt >:)
<arianvp>
(no honestly; it doesn't actually look that bad to me. )
<arianvp>
gchristensen: keep-failed doesnt do the job, as the part that generates the log.xml and log.html isn't called when the vm test failes. alas
<aszlig>
arianvp, niksnut: ah, yeah, having access to the output paths of failed builds in hydra would be nice... especially in tests it would actually help a lot, eg. for providing test reports and/or videos
<aszlig>
for my deployment tests i usually work around this by touching nix-support/failed, but that makes it annoying to restart a failed build
bhipple has quit [Read error: Connection reset by peer]
bhipple has joined #nixos-dev
Jackneill has joined #nixos-dev
bhipple has quit [Read error: Connection reset by peer]
Jackneill has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
<jtojnar>
gchristensen do we want the maintainer teams to be first class?
<gchristensen>
jtojnar: I think that would be cool
<gchristensen>
though a bit trickier
<gchristensen>
for example, github can't request reviews from a team afaik