<supersandro2000>
we should use github actions or something to automatically do this once a day or twice a week or something
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
<hexa->
I have a patch that only updates a submodule in a git repo, I tried applying it as a patch via fetchpatch, but since it's not a regular file that does not work
<{^_^}>
#105202 (by colemickens, 14 minutes ago, open): fetchhg just started failed with SSL errors?
<adisbladis>
colemickens: Works for me?
<adisbladis>
colemickens: You're not using a proxy by any chance?
<colemickens>
adisbladis: that's what I was afraid of.
<colemickens>
adisbladis: I'd better not be.
<colemickens>
(the cert works in firefox too? so strange)
<colemickens>
I made sure I wasn't in a nix-shell to rule out something on my end messing with any cert env vars.
<adisbladis>
Or actually, it shouldn't matter
<adisbladis>
But that's the only impurity that comes to mind
<samueldr>
is fetchhg like fetchgit, and runs at eval time?
<samueldr>
because then it may matter
<adisbladis>
samueldr: Nope, it's a FOD
<samueldr>
(to answer my question: no)
<colemickens>
unless something strange has happened, my clock is accurate. It's a LE cert, which shouldn't be an issue, but I'm bumping NSS all the same, because I'm out of ideas.
<adisbladis>
colemickens: The other thing that comes to mind is store corruption
<samueldr>
>> an attempt was made to load CA certificates but none were loaded
<samueldr>
this seems odd
<samueldr>
(out of scope, maybe, but I did get a different sha256 in a repl)
<colemickens>
samueldr: yeah, that's nix-prefetch executing, so that's expected.
<adisbladis>
samueldr: Exactly why I thought maybe store corruption
<samueldr>
tbf I didn't run that through that nix-prefetch tool
<adisbladis>
Me neither, but that shouldn't matter I think
<colemickens>
(It executes it with the old, known bad hash, it scrapes the output to give you the new hash.)
<samueldr>
and we don't know the Nixpkgs revision you used as an input (or do we?)
<colemickens>
!! yes, we know. Flakes! 2247d824fe07f16325596acc7faa286502faffd1
<colemickens>
current nixos-unstable.
<samueldr>
but you never specified that in the issue :)
<samueldr>
I guess that's from your nixpkgs-wayland?
<colemickens>
updated. and yes.
<colemickens>
I need a shame bell that I can let select irc users trigger than rings a bell at me for a minute or something.
<samueldr>
you know what you did
<samueldr>
and that's enough
<samueldr>
seems to have worked on my end
<samueldr>
I did "nix-shell -I nixpkgs=channel:nixos-unstable -p nix-prefetch" then ran your command verbatim
<colemickens>
unfortunately this aligns with my expectations. I guess it's time to start looking for more esoteric or concerning causes.
<colemickens>
(/etc/ssl/ looks right too, not as if I accidentally clobbered a bunch of important symlinks or anything)
<samueldr>
anyway, if it uses FOD, wouldn't it not care about /etc/ssl ?
<colemickens>
I guess so, yeah
<supersandro2000>
does @ofborg eval and @GrahamcOfBorg eval work?
peelz has joined #nixos-dev
<samueldr>
always use @ofborg, the other is the former name
<supersandro2000>
okay thanks
<colemickens>
oh god, I pinned mercurial to an old version of mercurial recently because it broke on unstable-small (:|)
<colemickens>
let's uh, undo that, and see what happens
<colemickens>
wait, that was a different branch. ugh.
peelz has quit [Remote host closed the connection]
alp has quit [Ping timeout: 256 seconds]
ris has joined #nixos-dev
alp has joined #nixos-dev
LnL has quit [Ping timeout: 240 seconds]
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
LnL has joined #nixos-dev
<andi->
shouldn't all the builders be rebooted daily? gchristensen: 11162819.packethost.net appears to have been up for a while and is now running out if disk space ^
AlwaysLivid has quit [Remote host closed the connection]
<gchristensen>
ehhh that one seems to be ofborg ... hrm.
<dhess>
Any idea why that wouldn't choose one of my x86_64-linux builders?
<gchristensen>
(snark) maybe it is because your x86_64-linux machines all have non-integer maxjobs
<gchristensen>
that is weird
<dhess>
ooooh gchristensen I don't understand your snark but I'm glad you're here. Sir I have questions.
<dhess>
got a few minutes?
* gchristensen
scurries away
<dhess>
anyway it did occur to me that maybe it's the extra i686-linux setting, if that's what you mean?
<gchristensen>
in the list of available machines the format is "(systems, maxjobs," and both the x86_64 linux machines pattern match to: (x86_64-linux, i686-linux, and (x86_64-linux, i686-linux
<dhess>
right
<gchristensen>
no, the snark is that I'm being "sql"-injected by malformed output
<dhess>
I'll remove that and see if it helps. However, it's only *some* jobs that have this problem
<gchristensen>
that is definitely not the problem
<gchristensen>
just a weird UX thing
<dhess>
In fact, it appears to be the ones that don't actually build a derivation but just generate a config file
<gchristensen>
what are your questions? :P
<dhess>
like pkgs.writeText etc
<gchristensen>
oh I think those prefer local building
<dhess>
gchristensen: I'll send a full build log in a sec, let's chat about this other issue first
<dhess>
as that's how I arrived at this situation
<dhess>
so Big Sur broke Python ctypes support, so now there are a few things that I can't build on my Big Sur Macs. nixops is one of them.
<dhess>
There's a backport fix already for Python 3.9, in 3.9.1rc1 which was just released. I
<dhess>
I'm trying to use that with nixops but running into some trouble with poetry
<dhess>
it's almost like wheel used to be part of the default build and now it isn't or something?
<dhess>
I added it to pyproject.toml and also did a `poetry update` to update the lock file etc. That fixed some of the problems, but not all.
<dhess>
Hmm wonder if I put it in the wrong section in pyproject.toml
<dhess>
Nope. Still broken.
<gchristensen>
you maybe need to do pkgs.python39.pkgs.poetry2nix but I'm not sure
<gchristensen>
sorry ... definitely not my wheelhouse
<dhess>
ok I'll try that, good idea
<dhess>
also: ignore the nixFlakes issue. I was missing an SSH key for a remote builder. That showed up as a warning at the start of the build, but wasn't shown at the end of the build, where it simply said "no builder could be found" etc.
<dhess>
so that was just me being stupid.
alp has quit [Ping timeout: 272 seconds]
<dhess>
gchristensen: FYI that attr doesn't exist, looks like poetry2nix is built as a top-level package. But I can work with that, anyway.
<{^_^}>
#105113 (by adisbladis, 1 day ago, open): python: Propagate packageOverrides to pythonForBuild
<FRidh>
it got broken when we added splicing to python-packages.nix for cross-compilation
<dhess>
FRidh: cool thanks!
<Ericson2314>
FRidh: I looking at 105155
<Ericson2314>
are there python implementation that are self-hosting?
<Ericson2314>
i.e. need some sort of different boot python in the native case?
<Ericson2314>
because we would want to have the "heterogenous" pythonForBuild in that cases
<Ericson2314>
* because we would want to have the "heterogenous" pythonForBuild in that case
<FRidh>
Ericson2314: haven't actually tested it yet
<FRidh>
do you mean as in they can build themselves?
<Ericson2314>
FRidh: yes, or rather a python is needed to build them. (I think of it more of a debt than an asset as far as bootstrapping is concerned)
<Ericson2314>
i thought i saw that pypy or cython or one of those needed a python at build time
<Ericson2314>
so needs to be bootstrapped from cpython
<FRidh>
pypy needs python as nativeBuildInput
<FRidh>
but I think I did the renaming correct (that's what it is, in the end, that PR)
<{^_^}>
#105113 (by adisbladis, 1 day ago, open): python: Propagate packageOverrides to pythonForBuild
<FRidh>
I was under the impression the splicing was already done, but does it mean that actually, the overrides need to be spliced as well. @adisbladis needs to add some hooks (nativeBuildInputs) to the package set
mkaito has quit [Quit: WeeChat 2.9-dev]
<Ericson2314>
FRidh: yeah I'll need to think more about that one
<Ericson2314>
and how the "original" overrides are spiced
<Ericson2314>
splicing plus overriding / making new package sets is not fun
<Ericson2314>
FRidh: other thing in your PR is pythonForBuild went from being a `python` to `pythonPackages` in some places I think?
<Ericson2314>
I might make a PR against is as it won't let me submit sugggestions far away
eyJhb has quit [Quit: Clever message]
<FRidh>
oh did I miss some
eyJhb has joined #nixos-dev
eyJhb has joined #nixos-dev
<Ericson2314>
FRidh: left some comments if you want to take a look first
<Ericson2314>
FRidh: oh I'm realizing my original PR might have been messed up
<Ericson2314>
it was doing `asdf.${pythonAttr}` not `asdf.${pythonAttr}.pkgs`
<FRidh>
Maybe. what I do know for sure is the naming is very confusing. pythonPackagesBuildHost, I thought that was the pythonPackages set for buildHost, but it is the main pkgs set for BuildHost
cole-h has joined #nixos-dev
<Ericson2314>
FRidh: I meant for it to be the former
<Ericson2314>
FRidh: maybe we can rename `pythonPackagesXxYy` to `pythonOnXxForYy` (nice and clear) and then do `pythonForBuild = pythonOnBuildForBuild`
<Ericson2314>
and `selfXxYy = pythonOnXxForYy.pkgs`
<Ericson2314>
(I'm also realizing as I write this that the `pythonForBuild` changes for the better)
<FRidh>
renaming pythonForBuild is not really an option anymore, but the rest, yes
<Ericson2314>
err `pythonForBuild` isn't renamed, but `pythonPackagesXxYy` (the thing I just made in previous PR) gets new name and meaning (the python, not the python packages)
<FRidh>
yes
<FRidh>
ohh but then see otherSplices
alp has quit [Ping timeout: 272 seconds]
<FRidh>
we are passing that derivations
<FRidh>
shouldn't those then be sets?
<Ericson2314>
FRidh: yeah exactly
<Ericson2314>
`selfXxYy = pythonOnXxForYy.pkgs` I meant for `otherSplices`
<FRidh>
Right
<Ericson2314>
<FRidh "I'm curious to see https://githu"> oh it was total shit, we'd need a better way to do a unionWith for attrsets
<FRidh>
Ericson2314: whoa, fixing the splicing extension modules now built without needing another patch that I reverted
<Ericson2314>
FRidh: oh!
<Ericson2314>
wasn't that patch patching python code, though?
<FRidh>
yea hold on, I am wrong here. Its something that succeeds on aarch64-multiplatform, but fails on raspberryPi. Didn't change after all. Oh well
<Ericson2314>
FRidh: well that is at least more in line with what i would expect
<{^_^}>
#105155 (by FRidh, 1 day ago, open): Python: use pythonPackagesBuildHost instead of pythonForBuild
<Ericson2314>
FRidh: ok checking
<Ericson2314>
FRidh: For and On should be reversed
<Ericson2314>
(or the "arguments" to them reversed)
<Ericson2314>
like pkgsXxOnYy is on Xx for Yy
<FRidh>
ugh
<Ericson2314>
otherewise looks good though!
<FRidh>
so we get `pythonForBuild = pythonOnBuildForHost;` ?
<FRidh>
yes, that makes sense
<FRidh>
by the way, is there not something like a `python3.__splices.buildHost` so we don't need to check what attribute it has
<Ericson2314>
FRidh: I think OnBuildForBuild
<Ericson2314>
which is different than before
<Ericson2314>
but that's on me
<FRidh>
its buildPackages.python
<FRidh>
when used in nativeBuildInputs
<Ericson2314>
here's were it gets really really subtle
<Ericson2314>
with interpreters
<Ericson2314>
so the interpreters themselves are host == target by definition
<Ericson2314>
so it doesn't matter
<Ericson2314>
but the package sets it could
<Ericson2314>
if e.g. one shells out for a targetSpecific library
<FRidh>
yes and in case of extension modules
<Ericson2314>
so while pkgsXxYy.python.outPath == pkgsXxZz.python.outPath
<Ericson2314>
so while pkgsXxYy.python.pkgs != pkgsXxZz.python.pkgs
<Ericson2314>
* it's possible that pkgsXxYy.python.pkgs != pkgsXxZz.python.pkgs
<Ericson2314>
(s/so while//c second time)
<Ericson2314>
FRidh: aren't the extension modules always loaded by the interpreter though?
<FRidh>
yes
<Ericson2314>
anyways back to what I'm saying, ugh... I think the build time package should be OnBuildForHost, but then the name pythonForBuild (or PYTHON_FOR_BUILD) doesn't really make sense
<FRidh>
ok, humans are not made for cross-compilation :P
<Ericson2314>
so i guess you can keep it pythonForBuild = pythonOnBuildForHost`
<Ericson2314>
* so i guess you can keep it `pythonForBuild = pythonOnBuildForHost`
<Ericson2314>
<FRidh "ok, humans are not made for cros"> certainly not cross compilation with interpeters!
* Ericson2314
shakes head
<Ericson2314>
`*_FOR_XX` assumes that everything is on build (compilers)
<Ericson2314>
I guess the next crusade is `*_ON_XX` for interpeters
<Ericson2314>
`PYTHON_ON_BUILD` that makes sense
<Ericson2314>
so that's a problem for another day
jonringer has joined #nixos-dev
<FRidh>
Right
<FRidh>
Its a small rename, but surely will break some peoples code. That's not such a big problem, if at least the fix is correct
<FRidh>
pushed again
<Ericson2314>
ok
<Ericson2314>
FRidh: 2 tiny things about comments
<FRidh>
you beat me to them. Alright, thank you.
<FRidh>
Let's hope this now fixes the cross issue with poetry2nix
alp has joined #nixos-dev
cole-h has quit [Ping timeout: 264 seconds]
<Ericson2314>
FRidh: well whew just waiting for ofborg now
<Ericson2314>
I will try to chip away at cleaning this stuff
<Ericson2314>
more than i have in the past
<Ericson2314>
(make it easier to do the splicing makeScope everywhere)
maljub01 has quit [Read error: Connection reset by peer]
maljub01 has joined #nixos-dev
FRidh has quit [Ping timeout: 265 seconds]
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined #nixos-dev
eyJhb has quit [Quit: Clever message]
eyJhb has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
alp has joined #nixos-dev
jonringer has quit [Ping timeout: 244 seconds]
mkaito has quit [Quit: WeeChat 2.9-dev]
justanotheruser has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
tilpner has quit [Quit: tilpner]
<samueldr>
I'm confused, what is the name for "generations" in NixOS? The term `generation` is being used only two times in the NixOS manual
<samueldr>
or is it that the concept is not defined in the manual?
v0|d has joined #nixos-dev
<Ericson2314>
samueldr: maybe there's something about profiles