gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.09 release managers: vcunat and samueldr | https://logs.nix.samueldr.com/nixos-dev
<ekleog> (triage) suggest closing https://github.com/NixOS/nixpkgs/issues/33604
<{^_^}> #33604 (by sjau, 43 weeks ago, open): brotlipy not building
Lisanna has quit [Ping timeout: 252 seconds]
pxc has quit [Ping timeout: 252 seconds]
pxc has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 252 seconds]
lassulus_ is now known as lassulus
pxc has quit [Ping timeout: 252 seconds]
aminechikhaoui has quit [Quit: The Lounge - https://thelounge.github.io]
aminechikhaoui has joined #nixos-dev
teto has quit [Quit: WeeChat 2.2]
drakonis has quit [Ping timeout: 252 seconds]
garbas has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-dev
sir_guy_carleton has quit [Quit: WeeChat 2.2]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 240 seconds]
Lisanna has joined #nixos-dev
garbas has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
{^_^} has quit [Remote host closed the connection]
<Profpatsch> gchristensen: You know what would be way cool? Giving ofborg log output lines ids and generating permalinks.
{^_^} has joined #nixos-dev
<gchristensen> :O
<gchristensen> paging samueldr (even though it is very early still)
<Profpatsch> I’m afraid it would make the rendering even slower though if we added more elements.
<gchristensen> can't we just give them all IDs?
<Profpatsch> But at least giving each div an id field should work.
<gchristensen> yea
<Profpatsch> Normally one would have some hover permalink symbol so it’s discoverable.
<gchristensen> Did You Know you can easily create a CLI tool to tail logs? :)
<Profpatsch> But it’s already slow as is with so many divs.
<gchristensen> how does Travis stay fast
<Profpatsch> Oh wait, I think only the Dev Console is slow, the log itself is pretty snappy.
<Profpatsch> gchristensen: CircleCI logs are incredibly janky in Chromium
<Profpatsch> They manage to make the one thing they sholud do well laggy m(
<gchristensen> it is a hard problem....butyeah
<Profpatsch> Well, your log output is snappy.
<gchristensen> all thanks to samueldr
<Profpatsch> gchristensen: Do you have an easy way to look up whether all aarch builds for haskell packages are broken?
<Profpatsch> GHC 8.4.4 is at least.
<gchristensen> hmm no, no idea
<gchristensen> I'm not much of an aarch64 user or haskell user :')
<Profpatsch> Because I’m afraid ofborg is trying to build GHC 8.4.4 for each Haskell package on aarch and fails somewhere in the middle
<Profpatsch> https://logs.nix.ci/?key=nixos/nixpkgs.49997&attempt_id=66ad9cab-1319-4b11-992a-16ae39675d62#8626
<Profpatsch> for example
<gchristensen> just trying to build psc-package
<Profpatsch> Sure, but failing in the build of GHC
<Profpatsch> with an internal compiler bug apparently.
<gchristensen> surely not every haskell package,because it should only be building the deps for psc-package
<gchristensen> ofborg isn't doing anything but nix-build . -A psc-package
<Profpatsch> I know, but I assume that if the ofborg build for psc-package fails in GHC, it will fail in GHC for all packages.
<Profpatsch> And also try to rebuild GHC for all of them.
<Profpatsch> Lots of wasted build time on aarch
<gchristensen> aah
<Profpatsch> gchristensen: Can I tell ofborg to try a build without opening a PR?
<Profpatsch> Maybe inside an issue?
<gchristensen> no, but you could get access to the aarch64 builder
<{^_^}> nix-community/aarch64-build-box#40 (by Profpatsch, 11 seconds ago, open): add @Profpatsch as Profpatsch
<Profpatsch> gchristensen: Where do I find the source to the log interface?
<Profpatsch> From a quick skim it’s not in the ofborg repo, right?
<gchristensen> it'd be cool if github had a way to indicate a commit was deployed, and have it show for every PR since the previous deploy
<gchristensen> ok Profpatsch you should be good now
<Profpatsch> gchristensen: The authenticity of host 'aarch64.nixos.community (2604:1380:0:d600::7)' can't be established.
<Profpatsch> ED25519 key fingerprint is SHA256:iPNPF+wdJezn9hz9tn02ONpwALemteTvq5Nz5xdsNa8.
<Profpatsch> That’s not the one listed in the README, but it could just be a different format
<LnL> you can use ssh-keyscan -t <type> to get a specific fingerprint
<gchristensen> sounds like the docs need an update :)
<samueldr> linking to a particular line is hard*er* since the log isn't loaded until well after the page is fully loaded
<samueldr> this means the browser can't do its magic and scroll to an anchor
<samueldr> though it should be possible to implement it ourselves right after load, as we anyway jump to the end
<Profpatsch> samueldr: Is there no “jump to anchor” function? As you are saying, you are jumping anyway.
<Profpatsch> And the browser will not jump if it can’t find the ID when it loads the page.
<samueldr> unless I missed something glaringly obvious, there's no function in JS to jump to an anchor programatically, other than the dubious "create a link, click it artificially"
<samueldr> the scrolling to the bottom is basically "set the scroll to the length of the element"
<samueldr> it overshoots, but the browser clamps
<Profpatsch> Is "#anchor" not a valid link?
<samueldr> it is
<Profpatsch> So granted you can parse the anchor from the current URL, that sounds totally fin.e
<Profpatsch> (to me)
<Profpatsch> gchristensen: thx btw, I have access to the aarch builder
<samueldr> yeah, what you said and asked is 100% good and vaild, just need a little bit of code wrangling
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
<ekleog> ugh wow, so investigating the nixos test system led me to discover it does I don't know what with its `nixpkgs` argument and thenn just goes forward with `import ../..` which just re-imports it o.O
drakonis_ has joined #nixos-dev
<domenkozar> yes, nbp spend quite some time implementing a test to make sure we never reimport nixpkgs, but iirc it never landed
<ekleog> well, here it's even just *all* tests in `release.nix` will trigger a nixpkgs re-import :(
<ekleog> … wait, does nixos-build-vms actually work? I can't get it to build its own manpage example
<nbp> domenkozar: I do not recall implementing this test
<nbp> domenkozar: However, I always wondered if our test suite ever run anywhere.
<nbp> domenkozar: such as our lib test suite.
<domenkozar> nbp: didn't you write a test that assures only one fixed point is used?
<Profpatsch> Can’t we implement the “cheap” solution of evaluating nixpkgs and measuring memory usage? And then cap it at +20% of that?
<nbp> domenkozar: I don't think I did.
<nbp> domenkozar: I wrote some tooling to count the number of fix-point you were going through
<Profpatsch> Then we immediately notice regressions when the test fails (e.g. because of a re-import)
<nbp> domenkozar: but I could not land any such test case because it would have broken in most packages.
<Profpatsch> ofborg also has some statistics of memory usage, which should notice jumps.
domenkozar has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
orivej has joined #nixos-dev
<gchristensen> Profpatsch: % is tough, because we can go up 19.9% and then a new package pushes it to 20% and then oh noes :)
<Profpatsch> gchristensen: Can you query the prometheus data about recent evaluation memory sizes, compare them against the current one and warn on the github PR when it’s a jump?
<gchristensen> unfortunately we don't actually collect that data yet X)
<gchristensen> but, we _could_ indeed! and probably should!
<manveru> samueldr: you can jump to an element given the id, which is what anchors do
<Profpatsch> I thought I remembered something, but I was thinking about evaluation time.
<Profpatsch> Which is another such indicator that the PR does something wrong.
<manveru> samueldr: `document.getElementById("divFirst").scrollIntoView()`
<gchristensen> ah yeah
drakonis has quit [Quit: WeeChat 2.3]
<gchristensen> ideally measure master then measure PR and compare, so the samples are obviously comparable and not subject to system variations
<samueldr> manveru: "unless I'm missing something obvious" :)
<samueldr> thanks!
<manveru> :D
<Profpatsch> gchristensen: We have multiple evaluators if I interpret that correctly?
<samueldr> (though I may still implement custom scrollin to *center* the line, and allow linking to a range of lines)
<gchristensen> we do :)
<Profpatsch> gchristensen: “Last evaluation of nixpkgs on the same evaluator” might be a good metric
<Profpatsch> And maybe cap if the last evaluation is older than a day.
<gchristensen> oh so each PRevaluation evalates the target branch, merges, then evaluates again, so we have very fresh data always:)
<Profpatsch> or like that
drakonis has joined #nixos-dev
<gchristensen> I wonder how long github caches images linked in issues
drakonis_ has quit [Ping timeout: 240 seconds]
<gchristensen> the Checks API is still beta
pxc has joined #nixos-dev
<Profpatsch> Does it need need an image?
<gchristensen> I want to stop posting comments so I can provide more info
<gchristensen> but basically that is the blocker: I have tons of info, but need to provide the info I have in a different way
<Profpatsch> I see. Wouldn’t the memory-check go into the “checks” section at the bottom of the PR?
<gchristensen> but that is a big hill to climb, means making a website and stuff :P
<gchristensen> checks only really make sense for definitely boolean things.
<gchristensen> but the new Checks API provides a "neutral" disposition which is good
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
tilpner has quit [Remote host closed the connection]
<gchristensen> I'd better roll up my sleaves and try the checks api. it looks great.
drakonis_ has joined #nixos-dev
tilpner has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
aminechikhaoui has quit [Quit: The Lounge - https://thelounge.github.io]
drakonis_ has joined #nixos-dev
<yl[m]> gchristensen: do you think it's possible for the bot to flag trailing whitespaces in PRs? I keep seeing new trailing whitespaces in the top-level/all-packages that I have to work around because my editor automatically trim them
<gchristensen> sure
<yl[m]> thx, that would be awesome
<gchristensen> please open an issue? :)
drakonis has quit [Ping timeout: 252 seconds]
<yl[m]> gchristensen: https://github.com/NixOS/nixpkgs/pull/50057 this PR removes the current one
<{^_^}> #50057 (by kalbasit, 17 seconds ago, open): trim trailing whitespace from top-level/all-packages
<yl[m]> gchristensen: sure
pxc has quit [Ping timeout: 250 seconds]
<infinisil> yl[m]: Eh, this happens occasionally, just put the change into your PR for an actual update
<infinisil> Like, if you add a package, nobody will complain about you also fixing the trailing whitespaces
<yl[m]> infinisil: my first PR ever, someone did complain and had to remove them :)
<infinisil> yl[m]: I think gchristensen meant to open an issue for ofborg to discuss the bot feature
<infinisil> yl[m]: Link?
<gchristensen> ofborg could comment with a new suggestion comment removing the trailing space
<yl[m]> infinisil: I already did. https://github.com/NixOS/ofborg/issues/268
<infinisil> I'd like to complain personally to the person telling you that :P
<{^_^}> ofborg#268 (by kalbasit, 7 seconds ago, open): Feature request: Fail PRs that introduce trailing whitespace
<yl[m]> infinisil: haha :)
<yl[m]> gchristensen: yes that would be great
<samueldr> (it was linked about 10 lines earlier)
<infinisil> Hahah, whoops
<samueldr> one personal addendum: big files like that one are not "the code you found", unless things were touched around the removed trailing space, I personally would argue towards not touching it :/ *looks at the bike shed*
<infinisil> I mean, we have a .editorconfig file which is supposed to enforce this, editors apply it automatically
<samueldr> if configured*
<infinisil> Yeah
domenkozar has joined #nixos-dev
<infinisil> But this is such a small change, I wouldn't mind these being applied by whoever has it configured
<infinisil> Otherwise it will just annoy more people
<infinisil> But yeah, an ofborg check for that would be nice
<infinisil> I once ran editorconfig through all nixpkgs files to fix them up...
<infinisil> It's amazing how many files don't conform to it
<samueldr> yeah, I'm annoyed to no end by things like trailing spaces and such, but more in the camp of the most minimal changes possible :/
<domenkozar> why would you waste someone's time for extra whitespace
<infinisil> Select a bunch of lines in it
<domenkozar> what's the problem? :)
<infinisil> Spaces, spaces everywhere!
<domenkozar> that's a fact not a problem :P
<samueldr> *rant that won't continue but should be in *-chat* the problem is programming languages are still an abstract representation of a thing that will become an AST, while the source files should probably be the AST and the editor present the document as desired by the author
<infinisil> I mean yeah, it's not gonna cause any problems or so, but my OCD is troubled
<gchristensen> omg haha what happened there
<samueldr> gchristensen: 10$ on block selection copy from a terminal
<gchristensen> :D
<yl[m]> the problem only shows up when two PRs conflict due to whitespace issues
<infinisil> yl[m]: Hmm that's a good point
<infinisil> samueldr: Yes! I very much hope that's how it will be in the future
<samueldr> (which is why I prefer the miminal change approach, reduces the risks of conflicts, but also hate whitespace issues)
<gchristensen> autoformat both branches before the merge :)
<yl[m]> what I think we really need is a nixfmt (ala gofmt style)
* yl[m] duck & cover for mentioning Go :)
<yl[m]> do we have an auto formatter?
<gchristensen> no
<infinisil> Didn't jD<blabla> start working on some nixfmt thing?
<samueldr> some work, not sure if anything tangible, though did the hard work needed first: a parser!
<yl[m]> I found https://github.com/Gabriel439/nixfmt but not sure if it works
<samueldr> a lossless parser!
<infinisil> yl[m]: The only thing we have is editorconfig, which could indeed be applied to all files, for whitespaces and such
<yl[m]> and I would like to submit a PR once the bot is capable of flagging it
<yl[m]> so moving forward we will be traling whitespace less :)
<infinisil> I did actually apply this to all files at some point, it was like a 1000 file change
<yl[m]> do you still have the script you used?
<infinisil> Nope, but it really was just find + vim xD
<yl[m]> oh, makes sense
<infinisil> That is, open vim, save the file, exit vim, next file
<infinisil> Didn't find a better way..
<yl[m]> simple enough yea
<infinisil> The terminal flicker was a bit annoying though
<infinisil> My proudest mass refactor was probably this one: https://github.com/NixOS/nixpkgs/pull/42676
<{^_^}> #42676 (by Infinisil, 19 weeks ago, merged): treewide: http -> https sources
<infinisil> Had to write a decently complicated haskell program to make it work
<yl[m]> oh nice
drakonis has joined #nixos-dev
pxc has joined #nixos-dev
disasm has joined #nixos-dev
ckauhaus has quit [Quit: WeeChat 2.2]
drakonis has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-dev
timokau has quit [Quit: WeeChat 2.3]
init_6 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 264 seconds]