<domenkozar[m]>
gchristensen: what that discussion didn't address is will kernel_latest be bumped to 5.4 once 5.3 goes EOL during NixOS 19.09?
<domenkozar[m]>
I guess I'll have to write up the arguments
<domenkozar[m]>
not today though
<FRidh2>
users should be able to rely on versions not changing in stable.
<kl3>
clever: that still assumes people sign up with github - i get how everyone does it these days and people like me are the dying majority, but submitting via mail (anonymously) still has its value
<kl3>
er.. s/majority/minority/
orivej has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 268 seconds]
drakonis has joined #nixos-dev
FRidh2 has quit [Remote host closed the connection]
drakonis_ has quit [Read error: Connection reset by peer]
FRidh2 has joined #nixos-dev
ddima_ is now known as ddima
<aanderse>
what about a `automaticallyUpdateMyStateDataPlease` option on any services which require updating state data on version bumps?
<aanderse>
some of theweb devs reported some errors on their web apps after i upgraded to 19.09 in dev. i needed to run mysql_upgrade
<aanderse>
i know some people feel very strong against automatically upgrading state data
<aanderse>
but without that option my life is less automatic and awesome than it could be
<aanderse>
especially when you run a growing nixops network
<qyliss>
domenkozar[m]: kernel_latest will be bumped as soon as a kernel is announced, AAUI
<qyliss>
s/announced/release
drakonis1 has joined #nixos-dev
psyanticy has joined #nixos-dev
orivej has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.6]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 240 seconds]
<gchristensen>
anyone know of a something FOSS, which is like buildkite?
<clever>
gchristensen: buildbot?, though the config is fairly impure (its just raw python code, which can freely manipulate buildbot)
<gchristensen>
hm!
<adisbladis>
clever: Nice
<adisbladis>
I'm tempted to try it out
<gchristensen>
I ask because I use buildkite quite a lot, and would like to setup move some of my buildkite jobs to the nixos foundation
<Taneb>
Idea that isn't well thought through: we don't in general want modules to open holes in the firewall. How about modules instead can set part of something like a "ports which services would like to be open", which would be an attrset from ports to lists of strings containing reasons (lists in case two services want the same port). This can then be displayed somehow or asserted that the ports are in fact opened or similar by the user
justanotheruser has quit [Ping timeout: 240 seconds]
<qyliss>
Profpatsch: I’ll write the sub string match
ixxie has joined #nixos-dev
drakonis_ has quit [Ping timeout: 276 seconds]
ixxie has quit [Ping timeout: 250 seconds]
ixxie has joined #nixos-dev
ris has joined #nixos-dev
drakonis has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
<gchristensen>
niksnut: what do you think about having a new type of hydra jobset for less-used and less-well-supported architectures. The jobset would do the same scheduled evaluation as the current ones, but each time a new evaluation comes out, any jobs for the non-current evaluation are canceled? this way hydra could preload the cache with bootstrapping and stdenv and as much of the OS as possible, but never develop
<gchristensen>
a deep queue? thinking this could be interesting for armv7 (32 bit) (or riscv or freebsd if we manage to get sufficient interest)
<samueldr>
can I pre-emptively +1 that? :)
<drakonis>
^
<drakonis>
risc-v will gather enough interest as soon as a cheap sbc comes out
<tilpner>
Would it make sense to instead attempt to build the entire eval, but not queue additional jobs while it's building?
<tilpner>
Then if it's done (success or failure) it queues the most recent eval
<samueldr>
sounds like potato potato, same end-result, though yours sounds cleaner (no cancelled stuff in db)
<tilpner>
samueldr: No, it would skip some evals entirely, but the ones it does build would have higher coverage
<tilpner>
With some tooling, that could be more useful to users
<gchristensen>
I think the canceled one is more attractive to me in terms of architecture
<tilpner>
But it depends on how long a full build would take. How long would a single small machine take to build an entire eval?
<gchristensen>
s/architecture/turnaround time/
<tilpner>
Both approaches optimise for different audiences
<samueldr>
I figure nothing stops us to do the quick one first, and think about the ideal one next
<gchristensen>
my thinking is if we can get some rpi's hooked up to hydra, we can do armv7 builds. it would _never_ complete a full evaluation worth of jobs.
<samueldr>
armv6 for raspis?
<gchristensen>
oh right yeah
<drakonis>
does qemu not allow for armv7 builds?
<samueldr>
armv7 we can (maybe) get appropriate power to plw through
<gchristensen>
anyway, you're right
<samueldr>
plow though*
<gchristensen>
we can actually do both of these types through the API without any changes to hydra
<samueldr>
ugh, insert the R where appropriate, sorry
<samueldr>
drakonis: "qemu" does allow, but there's multiple ways to use qemu for it
<samueldr>
qemu-system will always allow it, on foreign or native
<samueldr>
on native, with armv8/aarch64 we can use kvm for close-to-native perfs
<drakonis>
there's also unicorn engine
<samueldr>
qemu-user could allow it, but it's likely not a good idea since it inserts weirdness in the builds
<samueldr>
some detection routines did (do?) weird stuff at build time with qemu-user
<samueldr>
any emulation, so without kvm, is likely not a good idea perfs-wise
<gchristensen>
which is probably exactly the performance characteristics we should expect out of whatever hardware we can scrap together!
<samueldr>
hm?
orivej has quit [Ping timeout: 240 seconds]
<gchristensen>
if I could get good performing hw, it wouldn't be the same conversation :P
<samueldr>
I was thinking armv7 compatible enthusiast boards vs. armv7 emulation on x86_64; in my experience the boards will end up faster, and use far less energy :)
<gchristensen>
nice
<samueldr>
and we maybe can get good performing hw for armv7, depending, because of kvm
<samueldr>
a big maybe
<gchristensen>
I still have these CM1s just sitting in my closet, making me feel sad
drakonis_ has joined #nixos-dev
drakonis_ has quit [Client Quit]
Nyanloutre[m] has joined #nixos-dev
<niksnut>
gchristensen: sounds good, but there is a one problem: if you cancel evals preemptively, then it's possible no eval ever finishes
<niksnut>
which is a problem if you use it for a channel
<Nyanloutre[m]>
hello
<Nyanloutre[m]>
I am trying to make plasma 5.17 work, does anyone have a bit of experience with it ?
<gchristensen>
niksnut: in my thinking there would be no channel for these types of builds. that it would let us do at least some building for platforms to help the community. possibly as a stepping stone to having full build farm support
<niksnut>
ok
<gchristensen>
niksnut: however maybe it would be better to do as tilpner suggested: issue one evaluation, and then not trigger another evaluation until that one was completely done
<tilpner>
gchristensen: Additional evaluations are fine, but their jobs are not queued
<niksnut>
yeah that's even easier to implement
<tilpner>
It would finish evaluations, but skip as many as necessary to not fall behind
<niksnut>
hm why would you do evals and not queue jobs?
<gchristensen>
tilpner: we can't evaluate without scheduling jobs :)
<gchristensen>
niksnut: right, it could even be as simple as a cronjob looking at the number of queued jobs
<niksnut>
just don't eval if there are jobs in the queue
<gchristensen>
right
<tilpner>
I figured eval would still be useful as a cheap sanity-check. If that's harder to do, ofborg almost does the same
<gchristensen>
samueldr: does that mean a possible next step is seeing if a armv6(?) VM can be made to work nicely on the community builder?
<samueldr>
armv7l? It can, 99% confirmed
<gchristensen>
samueldr: (this is a question with possibly 2 answers): what would be most useful to your project and rpi users?
<samueldr>
It's mostly a question of packaging it in a nice manner
<samueldr>
armv7l for phones/tablets, rpi2 and most other sbcs
<samueldr>
armv6 for raspi 1 and zeroes
<samueldr>
I don't know that kvm on aarch64 can do armv6
<gchristensen>
ah
<gchristensen>
samueldr: how about in the same fashion the MacMinis run macos?
<samueldr>
(armv7l) maybe multiple vms per host but yeah
<samueldr>
Depending on limitations
<samueldr>
Bbl, queued at the bank
psyanticy has quit [Quit: Connection closed for inactivity]
<worldofpeace>
Nyanloutre: I left a comment. we need a new patch because of the rewrite
<worldofpeace>
looking at the current patch, it's enormous
<worldofpeace>
some parts look like they could be unneeded though
<Nyanloutre[m]>
yes I was a bit lost in all the work that has been done on the Bash startup script
<worldofpeace>
I guess it would make the most sense for the author to consolidate this.
FRidh2 has quit [Quit: Konversation terminated!]
<worldofpeace>
you could try to 1:1 port the changes
<worldofpeace>
It's just mostly, set environment variables conditionally, create some files(not sure about gtkrc's though), and substitute hardcoded nix store paths into the sourcecode
<Nyanloutre[m]>
ok I can try
<worldofpeace>
cool, it doesn't look very easy as a packaging task. but I'm sure dtz and ttuegel will be very helpful
<worldofpeace>
(I'm gussing ttuegel is fluent in C++)
<gchristensen>
niksnut: are you thinking we'll leave email turned off for hydra, or is it a thing you haven't gotten around to turning back on?
orivej has joined #nixos-dev
ixxie has quit [Ping timeout: 240 seconds]
drakonis has quit [Quit: Leaving]
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
<niksnut>
I haven't thought about it
<gchristensen>
I think there are a good number of people who would like it back on