<colemickens>
Is it possible for py qt5 apps like that to be split into two packages (if the project were to do so?). IT seems like it would make it easier to use buildPythonPackage and the usual mkDerivation for the py and qt5 parts of it.
orivej has joined #nixos-dev
<ckauhaus>
garbas: Hi, do you have a Jitsi available?
<ckauhaus>
if not, we could go to our company jitsi
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
zarel has joined #nixos-dev
<ckauhaus>
garbas: ping?
__monty__ has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
zarel has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
<LnL>
oh and requesting reviews, I think everything else goes through the checks api
WilliButz has quit [Quit: bye]
WilliButz has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 260 seconds]
<jtojnar>
colemickens you can just use format = "other" for `buildPythonApplication`
<jtojnar>
I assume Qt is used trough pyotherside, which is just another qt library
<jtojnar>
s/qt library/python library/
orivej_ has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
alp has quit [Ping timeout: 264 seconds]
terrorjack has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
teozkr_ has quit [Ping timeout: 260 seconds]
manveru has quit [Ping timeout: 260 seconds]
aria has quit [Ping timeout: 260 seconds]
aria has joined #nixos-dev
teozkr_ has joined #nixos-dev
terrorjack has joined #nixos-dev
manveru has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
orivej_ has joined #nixos-dev
alp has joined #nixos-dev
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
orivej_ has joined #nixos-dev
drakonis1 has quit [Read error: Connection reset by peer]
drakonis_ has joined #nixos-dev
<clever>
nbp: you about?
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
<hyperfekt>
Here we go, the PR for the script to regenerate the Hackage package set is ready for review. It's out of my hands now.
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
<gchristensen>
is ther a reason we have to pivot away from the initrd?
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
<MichaelRaskin>
What do you mean? We already use initramfs
<MichaelRaskin>
However we call it
<julm>
gchristensen: the initrd/initramfs is optional, it's there to avoid too much modules beeing built in the kernel image, and to find the final / ; but if you have enough RAM, a root with a fixed path, and take the pain to built in all your required kernel modules, you can boot without initrd/initramfs
<julm>
gchristensen: if all your system fits into RAM and you don't need that RAM in production, I guess you may just pack it in an initrd/initramfs and run on it in production without pivoting the root
<MichaelRaskin>
And to free the RAM we remove all the initramfs content on pivot; we could remove _most_ of the stuff without pivoting
<MichaelRaskin>
Actually we do not pivot_root, as pivot_root does not work with initramfs
<MichaelRaskin>
switch_root is different
<MichaelRaskin>
It's some special magic type of chroot that does not forbid future mount namespaces
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<niksnut>
but is there an advantage to supporting a non-initrd code path?
<emily>
running without initramfs is increasingly marginal these days imo. there's plenty of common root mounting options that kernel parameters simply can't set up
<clever>
luks, zfs
<emily>
even just lvm
<clever>
yeah, lvm is a weird mix of kernel and userland
<nbp>
clever: me about?
<clever>
nbp: having more trouble building rust stuff with naersk
<clever>
nbp: i think the issue is 2 Cargo.toml files, and sub-submodules
<nbp>
I honestly did not tried, I only tried to investigate based on the source content
<clever>
let me grab the current error...
<gchristensen>
I wish I could tell nix that no, really, I don't want you to do automatic run-time dependency discovery
<rnhmjoj>
i'm trying to improve the description of some nixos options types. do you have any idea how to deal with the "list of list of intss" situation?
<clever>
failed to read `/build/dummy-src/chain-deps/cardano-legacy-address/Cargo.toml`
* infinisil
is for deprecating lists
<clever>
nbp: the first layer problem i run into, is that naersk doesnt seem to deal with recursive? Cargo.toml files, and having one project depend on another larger project, is that how its working?
<clever>
nbp: i believe the nix code is parsing the Cargo.toml file, and building a builtins.filterSource based on that
<rnhmjoj>
infinisil: there is always "attrset of attrset of stringss"
<clever>
nbp: so, as a hack, i just changed the members= of Cargo.toml, to list all of the deps...
<clever>
error: no matching package named `jemalloc-ctl` found
<LnL>
gchristensen: like allowedReferences = []; ?
<clever>
required by package `imhamt v0.1.0 (/build/dummy-src/chain-deps/imhamt)`
<clever>
nbp: how it fails like this, and i'm just lost entirely
<rnhmjoj>
i can think of adding parenthesis like "list of (list of int)" but it would produce "list of (int)", which is pretty ugly, if the list types are not nested
<gchristensen>
LnL: I don't want it to prevent references, the references will be there -- I want to tell Nix to let them dangle :)
<LnL>
yeah, but then you have stuff that will break... at some point
<gchristensen>
I know
<LnL>
might be interesting to have something like nuke references builtin
<gchristensen>
I don't want to nuke them either
<clever>
gchristensen: discard context?
<LnL>
euh... :p
<gchristensen>
for example, I'm making an initrd. I want Nix to not consider the output to depend on anything
<clever>
gchristensen: compression is about the only way to do that reasonably
<clever>
or encryption, even xor with a constant
<gchristensen>
that doesn't work either.
<gchristensen>
so, I'm `rev`ing theoutput
<gchristensen>
but: I wish I could tell nix that no, really, I don't want you to do automatic run-time dependency discovery
<rnhmjoj>
infinisil: uhm, i've never thought about how "Show" works. well, it looks like i have to pass around a nesting level
<clever>
nbp: let me confirm the output...
<julm>
rnhmjoj: you can pass a precedence to put parenthesis or not, so that when showing something you put parenthesis around it iif. the inherited precedence is greater or equal to the precedence of what you're currently showing, while recursing the type (hence showing "int" will not, but showing a "list of" inside a "list of", will), indeed it would be like the usage of showParen in Text.Show
<clever>
nbp: ah, its not using filterSource, its using runCommand
<julm>
rnhmjoj: it's not a nesting level, it's a precedence, an intrinsic property of the operator you're showing
<nbp>
clever: You realize that I have no insight in naersk project?
<gchristensen>
LnL: I want to do meta-operations on every store path in a closure, individually, and it becomes tricky because I need to recreate them later
<clever>
nbp: yeah, i'm more wondering about how rust/cargo would deal with a project split across 2 repos, and what the best way to merge them is
<nbp>
clever: rust/cargo like to "vendor" its dependencies.
<nbp>
clever: then I have no idea what this would mean in this case.
<rnhmjoj>
julm: thanks, i think i get the idea. i could indeed try something like this
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-dev
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
orivej_ has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
cole-h has joined #nixos-dev
orivej has joined #nixos-dev
orivej_ has quit [Ping timeout: 256 seconds]
justanotheruser has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
justanotheruser has joined #nixos-dev
drakonis has quit [Quit: WeeChat 2.8]
drakonis has joined #nixos-dev
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
alp has quit [Ping timeout: 265 seconds]
ckauhaus has quit [Quit: WeeChat 2.7.1]
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-dev
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
alp has joined #nixos-dev
janneke has quit [Quit: janneke quits Mes'sing]
janneke has joined #nixos-dev
orivej has joined #nixos-dev
orivej_ has quit [Ping timeout: 264 seconds]
ashkitten has quit [Quit: WeeChat 2.8]
ashkitten has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
<cole-h>
Just a note: ofborg evals are down at the moment due to a recent deploy. The offending commit will be reverted shortly while we investigate.
orivej_ has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-dev
<gchristensen>
cole-h++
<{^_^}>
cole-h's karma got increased to 61
janneke has quit [Remote host closed the connection]
janneke has joined #nixos-dev
<cole-h>
Update: revert deploy going out, evals should be back up Soon™.
<gchristensen>
cole-h++
<{^_^}>
cole-h's karma got increased to 62
<cole-h>
Update #2: that didn't fix it.
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
<cole-h>
Update #3: The problem appears to have come from a dependency bump. A fix is forthcoming.
<cole-h>
Update #4: That's exactly what it was. We've downgraded the dependency to before this problematic update and are deploying it now. Fingers crossed this is the last necessary update.