<Profpatsch>
And Github apparently now moves on to it’s Extinguish phase! Nice.
<Profpatsch>
*its
<niksnut>
what's going to be extinguished?
Dezgeg has joined #nixos-dev
<vcunat>
I've just skimmed these changes, but so far my understading is that they just add another API that allows the checker to make line annotations.
<jtojnar>
and also mark check as neutral (useful for e.g. timeouts)
<jtojnar>
and the checks can be delegated to the checks tab, no longer spamming the comments section
<vcunat>
that's actually one of very few things that was criticised on ofborg
<srhb>
Yeah, it *is* convenient to reserve comments for actual human (or sufficiently convincing AI) content.
<srhb>
Is it possible to also trigger things with these checks instead of polluting the comments with commands?
<MichaelRaskin>
srhb: why bother? It is enough to trigger ofborg only on comment deletion
<srhb>
MichaelRaskin: I failed to parse that.
<MichaelRaskin>
Well, right now if you _delete_ an ofborg-invoking comment, ofborg will process it as a new command again
<MichaelRaskin>
If ofborg would handle _only_ comment deletion, and immediately report a neutral check with a plan of actions, the invokations would not clutter the comment tab
<srhb>
MichaelRaskin: Oooh, good point.
<timokau[m]>
It would still send emails though
orivej has joined #nixos-dev
Jackneilll has quit [Quit: Leaving]
Jackneill has joined #nixos-dev
<MichaelRaskin>
timokau: I am not sure whether this is actually a plus
<copumpkin>
anyone here used the initrd ssh module? is there an easy way I can stop the machine from booting altogether and always just pause in the initrd to SSH around?
<copumpkin>
(this is to help debug the M5 AWS NixOS bootup issue, which is proving very annoying)
<aminechikhaoui>
copumpkin: isn't possible to do some stuff with the serial console ?
<copumpkin>
not on AWS :)
<copumpkin>
you can see the output of it
<copumpkin>
but you can't interact with it
<aminechikhaoui>
oh, yeah don't know, I only played with that on Google cloud
<aminechikhaoui>
I'm sure ikwildrpepper or niksnut should have some tricks for initrd debugging :)
<srhb>
copumpkin: can't you stop it with any of the *commands at whatever stage?
<srhb>
iirc that's what all the ssh-to-unlock-filesystem setups do.
<copumpkin>
yeah, I can inject stuff in there
<copumpkin>
I just don't know how to pause it without causing a restart
<copumpkin>
I want it to stick around so I can SSH nicely
<srhb>
Oh, it restarts automatically? I didn't realize.
<copumpkin>
rather than make it crash and restart :)
<srhb>
I thought a wait loop waiting for you to send whatever "go-on" command would work.
<copumpkin>
well, that's the main issue I'm trying to debug right now
<copumpkin>
if the root volume doesn't appear in time, it tries to mount it anyway, fails, and then restarts
<copumpkin>
so I want to stop stuff before we get there
<copumpkin>
maybe! I don't really know my way around the early NixOS boot stuff
<aminechikhaoui>
maybe you should use boot.debug1devices ?
<aminechikhaoui>
also headless.nix sets boot.kernelParams = [ "panic=1" "boot.panic_on_fail" ];
<timokau[m]>
MichaelRaskin: Yeah, you might be right. Maybe ofBorg could even delete the comment itself, as long as it only contains an ofBorg command.
<aminechikhaoui>
copumpkin: so that causes any failure to trigger a kernel panic as far as I remember
<copumpkin>
oh I see
<aminechikhaoui>
so maybe better to do boot.kernelParams = lib.mkOverride 0 [.. ]
<copumpkin>
so if I just turn that off, then inject a bogus command in the stage1 init
<copumpkin>
then it should get stuck in the initrd and let me SSH around in peace
<aminechikhaoui>
right, that's what I did with the GCP stuff
<MichaelRaskin>
timokau: there are arguments against letting ofborg itself ever delete human comments… mostly correctness/debugging/risk arguments
<MichaelRaskin>
timokau: eventually ofborg would be a GitHub-authenticated site with its own UI
<MichaelRaskin>
One day…
<timokau[m]>
MichaelRaskin: Yeah its hard to get right, but when its done right I don't see an issue with it. It would only remove commands containing exclusively ofBorg commands and whitespace and would add those removals to its log.
<timokau[m]>
I don't see much advantage with the web-ui. You could no longer trigger ofborg per email for example.
<MichaelRaskin>
Well, incoming email handling is not that hard to add. Ofborg just needs its own command line, without messing with the GitHub comments as an obviously unsuitable medium
<timokau[m]>
MichaelRaskin: Why is it obviously unsuitable?
<MichaelRaskin>
Well, once you agree that adding and immediately deleting GitHub comments sounds like a good idea, this should be a string hint that maybe there is some hammering square pegs into round holes
<MichaelRaskin>
a strong hint
<MichaelRaskin>
insta-deletion workflow is less messy but a bit annoying
<timokau[m]>
MichaelRaskin: Yeah its not ideal, but I'm not sure if its bad enough to warrant its own ui.
<timokau[m]>
You have more experience using it than I do of course
rsa has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
drakonis has joined #nixos-dev
drakonis has quit [Remote host closed the connection]
<dtz>
shlevy: "morally pure"?! :D
<dtz>
"plugins blessed by the virgin mother"
<dtz>
:P
<dtz>
but awesome work, grats on the release, look forward to exploring it! :)
<dtz>
aww I didn't RTFM, you explain what you mean by "morally pure" :D. Darn you being thorough. :D
<shlevy>
dtz: Heh, only because a coworker called me out on it during internal pre-open source review :D
<dtz>
xD
taktoa has quit [Remote host closed the connection]
<copumpkin>
wondering if that might have something to do with my myterious nvme issues
<Dezgeg>
I presume the problem is fsck tries to open the device for exclusive access the same time udev has it open for probing filesystems and such on it
<Dezgeg>
I think it's the same that makes the nixos installer tests fail every now and then which is quite annoying
<copumpkin>
hmm
<copumpkin>
and if we don't want fsck running at startup anyway :)
<Dezgeg>
well, you kinda do want it
<copumpkin>
and I'm having weird issues with the device not showing up at all ever
<copumpkin>
perhaps killing udev might be related
<Dezgeg>
it could explain /dev/disk/by-* not appearing
<Dezgeg>
I guess that should be replaced with a udevadm settle or something
<copumpkin>
yeah, wondering why niksnut didn't do that or if it breaks in some other way if you d
<copumpkin>
it looks like we already have a settle in there
<copumpkin>
so not sure, maybe they were added at different times
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 255 seconds]
<dtz>
i have to say I love Nix 2's memory fixes, tyvm niksnut ^_^
Sonarpulse has joined #nixos-dev
<dtz>
(was just looking for memory leak and noticed my ongoing builds copying all the things to/from used less memory than many other programs I'm running, haha, which is pretty neat ^_^)
<Sonarpulse>
Dezgeg: not sure if you saw my PR, but stdenv.isArm should work again on release-18.03 and master
<Sonarpulse>
sorry for the breakage
<copumpkin>
dezgeg, niksnut: looks like that udevadm --exit thing might actually be the culprit of this evil nvme bug!
<Synthetica>
is pkgs/development/lisp-modules/quicklisp-to-nix.nix auto-generated?
<MichaelRaskin>
Synthetica: indeed
<MichaelRaskin>
The generating code lives nearby
<Sonarpulse>
Synthetica MichaelRaskin: now that we have builtins.fetchgit
<Sonarpulse>
I feel like I want all generated code to live in seprate repo(s)
<Sonarpulse>
as a step towards IFD in nixpkgs
<Sonarpulse>
mixing generated and manual code in one repo is very dangerous
<Synthetica>
I was just running some fairly dumb code repetition analysis (compare raw and gzipped file size), and it popped up as the worst offender, by far
<Synthetica>
Sonarpulse:
<Synthetica>
Sounds reasonable
<Sonarpulse>
:)
<Sonarpulse>
good work
<MichaelRaskin>
It is mainly because we never cleaned up to use callPackage
<MichaelRaskin>
Sonarpulse: care to provide an argument for your claim about actual danger?
<MichaelRaskin>
Take into account, that NixOS repo got moved in directly, not as a submodule
<MichaelRaskin>
And a submodule would be a fine replacement for builtin fetchgit
<MichaelRaskin>
Also, large evaluation-time fetchgits are going to make our «evaluations crazily expensive» problem even worse
<dtz>
is there an analysis/write-up of evaluation performance, suspected problems, etc. somewhere? Just curious :)
<dtz>
I know things like RFC22 ("minimal module list") and some bits on memoization have cropped up but not sure if there's anything else :)
<Sonarpulse>
MichaelRaskin: submodule is fine
<Sonarpulse>
the point is just to segregated manual from autogenerated data
<Sonarpulse>
I sed all of nixpkgs a lot
<Sonarpulse>
I never want to change auto-generated data when doing that
<Sonarpulse>
right now one has no idea
<Synthetica>
Even a list of auto-generated packages would help
<Sonarpulse>
and developing new versions of automatic tools
<Synthetica>
s/packages/files/
<Sonarpulse>
there's like manual-nixpkgs * too-version states
<Sonarpulse>
manual-nixpkgs * tool-version states
<Sonarpulse>
so 2d / O(n^2) final states
<Sonarpulse>
but vendoring in one in the other obscures the 2 dimensional nature of that
<Sonarpulse>
basically all vendoring and committing generated code is really danagerous
<MichaelRaskin>
Sonarpulse: we could do submodules long before, but we don't
vcunat has quit [Quit: Leaving.]
<Sonarpulse>
and multiple is the best we can do to at least easily fake the 2d with something easy as pointer swap
<Sonarpulse>
MichaelRaskin: probably because the git submodule implementation is very bad
<Sonarpulse>
or just nobody cared too
<MichaelRaskin>
fetchgit will be costly no matter what
<MichaelRaskin>
Also, double-commits all the time
<Sonarpulse>
e.g. I'd like to try using angerman's stuff to replace the existing haskell infra
<MichaelRaskin>
They are a problem, too
<Sonarpulse>
right now separating the manual stuff from (hackage|cabal)2nix autogenerated
<Sonarpulse>
is not easy
<Sonarpulse>
also there is a opam2nix that I'd like to make better
<Sonarpulse>
and make official
<MichaelRaskin>
I would say that blind sed will break things even if you separate the generated files
<Sonarpulse>
well we have ofborg for that :)
<MichaelRaskin>
Updates to separated files are in lockstep with manually edited files in most of the cases, though
<MichaelRaskin>
We do not
<Synthetica>
Ofborg doesn't check for everything
<Synthetica>
I mean; it can't
<MichaelRaskin>
I think there is currently _no_ tool that enumerates all derivations accessible as attribute paths from Nixpkgs
<MichaelRaskin>
Hint: it is a much more complicated question than it seems (and than ofborg does, and than Hydra does)
<MichaelRaskin>
Then there are relatively often-used overrides
<MichaelRaskin>
Then even for ofborg partial enumeration there is no reasonable chance to actually build all that stuff with a finite feedback loop — Hydra rebuilds take days, @oxij sometimes reports on private rebuilds taking a couple of weeks
<MichaelRaskin>
Could we please stop pretending we can auto-check massive non-local changes?
<MichaelRaskin>
(This is even before the fact that we do not have sane tests for things like LibreOffice)
<MichaelRaskin>
And we will not have them in any reasonable timeframe, because NixOS tests are too annoying to try to debug, and pure-Nixpkgs integration tests for GUI applications get rejected because duplication of infrastructure.
<MichaelRaskin>
Also, if your edit is safe to make on hand-written code, it cannot break anything in auto-generated code, because for every piece of generated code there is a strictly more complicated hand-written example somewhere in the repository.
<Sonarpulse>
MichaelRaskin: as to the last
<Sonarpulse>
e.g. say I didn't do back-compat on isArm -> isAarch32
<Sonarpulse>
now some tool that is *not* in nixpkgs
<Sonarpulse>
will generated more isArm
<Sonarpulse>
clobber what I sedded
<Sonarpulse>
and then break
<MichaelRaskin>
And how this being a fetchgit away will help?
<Sonarpulse>
my sed wouldn't change the ones in the fetchgit
<Sonarpulse>
and then it would immediately break
<MichaelRaskin>
Right
<MichaelRaskin>
So it will just break
<Sonarpulse>
just as with IFD it would also immediate break
<Sonarpulse>
immediate breakage is much better than an accident waiting to happen next regen
<Sonarpulse>
even worse is people not regenerating because they want to preserve "valuable" manual edits
<MichaelRaskin>
Again: try writing a tool that finds all reachable derivations
<MichaelRaskin>
Without that, that «immediate» breakage is not immediate at all
<Sonarpulse>
well you are saying tool + more repos is necessary?
<Sonarpulse>
or tool on its own is also necessary?
<Sonarpulse>
*also sufficient?
<MichaelRaskin>
I say that tool will occupy you long enough that maybe a better idea on demarcation will appear in the meanwhile, and it will be useful anyway
<MichaelRaskin>
quicklisp-to-nix.nix is actually a database (all the interesting stuff is outside, all the custom stuff is in -overrides), which just seems natural to keep in Nix
<Sonarpulse>
MichaelRaskin: alternatively we can say that whatever ofborg or similar doesn't excise is not a stable interface anyways
<Sonarpulse>
like some top-levelish thing should transatively cause everything that matters to be evaluated
<Sonarpulse>
that might be a bit extreme
<MichaelRaskin>
We have a lot of generated «plain databases»
<Sonarpulse>
but point is there's work to be done codifying stable vs unstable vs totally-accidental interfaces
<MichaelRaskin>
But apparently some things generate more complicated code
<Sonarpulse>
that's true
<MichaelRaskin>
Semantically, there is a single action when updating generated part and manual counterparts
<MichaelRaskin>
From the point of view of sanity, any departure from «single commit» has costs
<Sonarpulse>
right but that single action would be with the *generator* not *generated*
phreedom_ has quit [Remote host closed the connection]
<Sonarpulse>
and no-one has proposed vendoring e.g. cabal2nix in nixpkgs
<MichaelRaskin>
I dunno about cabal2nix
phreedom has joined #nixos-dev
<MichaelRaskin>
I know that when you update Quicklisp database version, at the same point you need to regenerate, at the same point you need to update overrides to make sure native dependencies and package-specific tricks match
<MichaelRaskin>
I know that update to LibreOffice and its autogenerated fetchlist must be a single commit
<gchristensen>
Profpatsch: _sleepily_ whoa, cool!
<Profpatsch>
Maybe? idk
<Profpatsch>
gchristensen: It looks to me like github is now starting their close-up.
<Profpatsch>
Since that feature is only for “Github Apps”
<Synthetica>
close-up?
<Profpatsch>
Synthetica: The Extend/Extinguish phase of EEE
<Synthetica>
They say that's "for now", in the beta
<Synthetica>
I guess time will tell
<MichaelRaskin>
Everybody lies like that
<MichaelRaskin>
GitHub Apps need manual approval?
<Sonarpulse>
MichaelRaskin: that makes sense
<Sonarpulse>
so it is possible (though annoying) to make that atomic
<Sonarpulse>
really the separate repo thing is most important for huge swaths of code like the language-specific stuff
<MichaelRaskin>
Well, Lisp stuff comes with enough overrides to want to have single commit for update and for updating overrides…
<Sonarpulse>
MichaelRaskin: so it's ok to first update the autogen repo with an *unreferenced* commit
<Sonarpulse>
then update nixpkgs to use that commit
<Sonarpulse>
nobody need concern themselves with commit history in the autogenerate repos, for example
<Sonarpulse>
they could even be all orphan commits
<MichaelRaskin>
Erm
<MichaelRaskin>
That what you just never do
<gchristensen>
Profpatsch: ofborg really should be an app, it isn't hard to be an app, I think
<MichaelRaskin>
I mean, what you describe is annoying enough without orphan commits…
<MichaelRaskin>
Orphan commits mean that it is also annoying to even look at the autogenerated repository on its own
<MichaelRaskin>
At that point I say that you propose to add a lot of hoops and a lot of nonobvious repository behaviour
<MichaelRaskin>
All for what? For doing more search-replace on Nixpkgs?
<Dezgeg>
you can't fetch orphan commits from github btw.
<MichaelRaskin>
I mean, what about simpler solutions, like asking that autogenerated stuff should live an a subtree with .nixpkgs-autogenerated file at the top?
<Sonarpulse>
Dezgeg: I posted a patch in the issue tracker
<Sonarpulse>
I guess I'll send more emails too
<Sonarpulse>
binutils did build fine, to be clear?
<Dezgeg>
probably
<Sonarpulse>
Dezgeg: good point re eabi
<Sonarpulse>
arm-linux-gnu fails too
<Sonarpulse>
Dezgeg: the armv7l "l" is just little endian?
<Sonarpulse>
is there anything better we can do with that?
<Sonarpulse>
armv7ael or something?
<Sonarpulse>
I wonder what llvm has there for exmple
Dezgeg has quit [Ping timeout: 265 seconds]
<angerman>
Sonarpulse: give it a try ;-) and let me know when it breaks ;-)
Sonarpulse has quit [Ping timeout: 256 seconds]
<gchristensen>
Profpatsch: I don't see the Github Apps thing as being a E