gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.09 is released! https://discourse.nixos.org/t/nixos-19-09-release/4306 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
ris has quit [Ping timeout: 240 seconds]
justanotheruser has quit [Ping timeout: 248 seconds]
justanotheruser has joined #nixos-dev
Scriptkiddi has quit [Remote host closed the connection]
das_j has quit [Remote host closed the connection]
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
<gchristensen> I made a little thing like howoldis except it uses prometheus for its data source: https://jsfiddle.net/tnxojucv/1/
<gchristensen> this makes it easier to deploy to nixos.org, for example
drakonis has quit [Quit: WeeChat 2.7]
lovesegfault has quit [Ping timeout: 248 seconds]
deadloko has quit [Quit: WeeChat 2.6]
MichaelRaskin has quit [Quit: MichaelRaskin]
justanotheruser has quit [Ping timeout: 248 seconds]
justanotheruser has joined #nixos-dev
FRidh has joined #nixos-dev
<Taneb> gchristensen: that's pretty neat!
<domenkozar[m]> gchristensen:
<domenkozar[m]> :shipit:
avn has quit [Ping timeout: 260 seconds]
drakonis has joined #nixos-dev
<gchristensen> domenkozar[m]: perfect!
orivej has quit [Ping timeout: 265 seconds]
<domenkozar[m]> :nixparot:
<domenkozar[m]> rr*
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
FRidh has quit [Quit: Konversation terminated!]
drakonis has quit [Ping timeout: 240 seconds]
__monty__ has joined #nixos-dev
tilpner_ is now known as tilpner
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<gchristensen> domenkozar[m]: check it out now: https://jsfiddle.net/tnxojucv/6/
<thefloweringash> the '+' in the query params for start and now isn't being escaped, and prometheus is parsing it as a ' '
<gchristensen> there is no + ?
<thefloweringash> "error":"invalid parameter 'start': cannot parse \"2019-12-30T11:49:46/09:00\" to a valid timestamp"
<thefloweringash> oh, oops, that was me poking
<thefloweringash> "error":"invalid parameter 'start': cannot parse \"2019-12-30T11:49:46 09:00\" to a valid timestamp"
<thefloweringash> query_range?query=hydra_job_failed&start=2019-12-30T11:49:46+09:00
<gchristensen> oh cool, localization
<gchristensen> wait, what
<gchristensen> ooh
<gchristensen> thefloweringash: try https://jsfiddle.net/tnxojucv/7/
<thefloweringash> fixed!
<gchristensen> cool :)
<gchristensen> the cool improvement over what I sent last night is look at the link to Hydra for nixos-19.09
<domenkozar[m]> for some reason that fiddle doesn't render
<domenkozar[m]> ah, 7 does
<domenkozar[m]> gchristensen: I think I'd color the whole row in one color + staleness
<domenkozar[m]> and write a custom sort function like howoldis does
<domenkozar[m]> unstable, then all releases
<gchristensen> yeah a custom sort function is later
<domenkozar[m]> but none of this is really necessary
<domenkozar[m]> I think it's good to be online
<gchristensen> the the bit on the right though is the state of the linked job, which I think is probably useful
<gchristensen> (over time0
<domenkozar[m]> that it's disabled?
<gchristensen> no
<domenkozar[m]> ah, the semaphore for it
<gchristensen> the 19.09/tested link for example shows that it was passing for a while and then failed for a while and is passing again
<gchristensen> the other ones indicate that they've been passing or failing consistently
FRidh has joined #nixos-dev
<domenkozar[m]> I would never figure that out from the colors :)
<gchristensen> red and gren don't indicate that well?
<domenkozar[m]> didn't notice it's a gradient :D
<gchristensen> ah, it'll be more obvious once it has more than 12h of data to work from
<gchristensen> but if it isn't obvious, it can be removed
<domenkozar[m]> let's get more samples
<domenkozar[m]> could be I'm an outlier
<domenkozar[m]> either way it's more value to have it than not, can fix UX later
<gchristensen> let's get more samples in both axis: more than 12 hours of data being shown, and then after that more people
<domenkozar[m]> k
<gchristensen> domenkozar[m]: https://jsfiddle.net/tnxojucv/14/
layus[m] has quit [Quit: User has been idle for 30+ days.]
<Taneb> gchristensen: beautiful
xeji has quit [Quit: WeeChat 2.2]
<FRidh> please abort the following two eval https://hydra.nixos.org/eval/1562546
<FRidh> ignore the two
<gchristensen> handled
MichaelRaskin has joined #nixos-dev
lovesegfault has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
lovesegfault has quit [Quit: WeeChat 2.7]
lovesegfault has joined #nixos-dev
ris has joined #nixos-dev
avn has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7]
<infinisil> Is there a reason why gitMinimal doesn't have perlSupport = false?
<infinisil> perl is a huge dependency in its closure
<infinisil> I guess I'll make a PR to see if anybody complains
<gchristensen> not sure if it is still true, but git didn't function without perl
<gchristensen> I wonder how much of git requires it now
<infinisil> Seems to only be for snv and sendEmail support now
<infinisil> Judging from the expression
ixxie has joined #nixos-dev
<gchristensen> libexec/git-core/.git-add--interactive-wrapped
<infinisil> Aw damn
<infinisil> So the nix expression is a bit misleading
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
drakonis has joined #nixos-dev
<infinisil> Well actually no
<infinisil> When you build it without perl support that file doesn't exist
<gchristensen> does `git add -i` work?
<infinisil> Nope: fatal: git was built without support for git-add--interactive (NO_PERL=1).
<samueldr> what does "gitMinimal" mean here? if it's "for automation and stuff" --interactive is not really needed I figure
<samueldr> though if it's been added meaning "useful for end-users, but slim", that's different
<gchristensen> anyone want to make a favicon for status.nixos.org?
<infinisil> samueldr: Yeah maybe this would be alright for automation and stuff
<infinisil> However, I just found out that apparently there's a native interactive add cooking: https://public-inbox.org/git/pull.175.git.1576968120.gitgitgadget@gmail.com/
<infinisil> I believe that's what that means at least
<samueldr> it's way too late for that, but it would have been cool to have nixpkgs split in plumbing, and porcelain packages, with the main attrset being the porcelain one
<infinisil> :O add.interactive.useBuiltin
<samueldr> so you know that if you change plumbing.git it's not expected to be used by end-users, but by software
<MichaelRaskin> We kind of have this. It is called stdenv
<samueldr> MichaelRaskin: it's a limited subset :)
<MichaelRaskin> Maybe if you want to draw black and white picture, that's where the border should lie. What I want to say is, obviously, stop hoping for black and white picture having exactly the correct nuance.
<infinisil> The add.interactive.useBuiltin btw seems to not be in current stable git
drakonis has quit [Quit: WeeChat 2.7]
drakonis has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
ixxie has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 265 seconds]
FRidh has quit [Quit: Konversation terminated!]
drakonis has joined #nixos-dev
<infinisil> So um, do we have a plan for how to move from docbook to something else?
<infinisil> Is there anybody in the lead for this?
<drakonis> there's a channel for that
<drakonis> ah, nevermind, no irc channel but there's a group of people that were looking into it
<gchristensen> basically we need to do the impossible task, and then the easy task
<drakonis> ah they're based on #nixos-wiki
<drakonis> not a specialized channel for docs
<niksnut> first we should decide *whether* to move from docbook...
<gchristensen> niksnut: I thought we decided we should at nixcon?
<niksnut> no we didn't
<niksnut> you tried to convince me :p
<infinisil> I don't think whether is a question anymore
<gchristensen> iirc your answer was yeah we probably should :)
<niksnut> I remember predicting that the discussion would once again get stuck in bikeshedding over which markup language to use
<gchristensen> that was the impossible task
<infinisil> I think it's important to bikeshed over that, as a huge amount of work is involved
<gchristensen> besides, that is solved -- markdown is the answer
<niksnut> if markdown is the answer, what was the question?
<MichaelRaskin> Right, all the tooling switches should always go to the worst designed contender
<MichaelRaskin> Git, Markdown…
<gchristensen> exactly
<infinisil> I'm not sure about markdown, asciidoc is another loved candidate
<gchristensen> well if we're going to stick with docbook, asciidoc sounds good
<gchristensen> unfortunately asciidoctor is probably a nonstarter
<infinisil> Maybe Sphinx would be good as a generator. It works with both markdown and rst
<infinisil> Sphinx with markdown would be the best for convenience really
<gchristensen> how is the output?
<infinisil> And ultimately convenience and ease-of-use should be the most important quality
<infinisil> All the readthedocs pages are generated with it
<gchristensen> o
<gchristensen> probably a good bet is to experiment: convert the XML to a few formats and try a few tools and demo the results
<infinisil> I mean everybody knows what readthedocs and markdown look like already
<infinisil> A demo for asciidoc[tor] might be more useful
<gchristensen> I'm not sure I/anyone knows what readthedocs would look like for a project our size
<infinisil> How does the size matter?
<gchristensen> we have a lot of docs
<gchristensen> and may not suit readthedocs' format or tooling
<infinisil> Like the build-time for them?
<gchristensen> yeah, or the rendering or search
<gchristensen> or other things we may not even guess might be a problem
<infinisil> Do we have more docs than the linux kernel? https://www.kernel.org/doc/html/latest/index.html
<gchristensen> oh cool
<infinisil> More projects that use sphinx: https://www.sphinx-doc.org/en/master/examples.html
<infinisil> Including like 20 books!
<gchristensen> (books isn't a good sales pitch :P) at any rate, working code is pretty compelling
<infinisil> Books for size
* gchristensen points to docbook
<infinisil> Well yes, but you had worries that sphinx is too slow for big docs. The fact that some books are written with it tells us something about how fast it can be
<drakonis> well, it lets you do books, right? it makes a nix book possible/easy
<drakonis> and the above
<gchristensen> my messagesaying a good bet is to experiment
<gchristensen> sounds like size won't be a problem, let's try it
<infinisil> Hm, domenkozar[m]'s comment here makes me reconsider markdown: https://discourse.nixos.org/t/documentation-format/4650/12?u=infinisil
<infinisil> They apparently use https://antora.org/
<infinisil> "No matter how many git repositories you use, Antora can retrieve and aggregate all the content from them to assemble a documentation site. "
<infinisil> That looks like something we'd want!
<samueldr> asciidoc is extremely powerful
<samueldr> from my experience with documentation ecosystems, moving off from docbook to asciidoc is probably the wisest choice, to not lose features
<samueldr> oh, I also have a note for documentation about actively looking at a module that does markdown->asciidoc, and evaluate what's gained/lost with it
<gchristensen> samueldr: that sounsd good
<samueldr> so the existing bits of markdown in our docs can probably keep being markdown until rewritten
<infinisil> Yeah I'm starting to get convinced of asciidoc again
<gchristensen> is there an asciidoctor with a run-time closure of closer to 50MB than 1,000MB?
<samueldr> I think as of now, the main stumbling block seems to be the gargantuan build closure (comparativeley)
<samueldr> we'd need the ruby team to assemble to look into the issues
<samueldr> I wonder if ruby's dependency on gcc can be split in a split output
<infinisil> Is that really a big problem though?
<samueldr> yes as docs are built on end-user's systems
<infinisil> I think it's vastly overshadowed by our other doc issues
<infinisil> Aren't docs in the cache by default?
<samueldr> right now docbook has a REALLY smaller closure iirc
<samueldr> 2.6M
<samueldr> as of right now, asciidoctor brings in deps from X11
<infinisil> But who builds docs on their own machine without having 1GB free?
<samueldr> me
<samueldr> my laptop is always on the verge of 100%
<infinisil> And why are the docs not cached for you?
<samueldr> you didn't ask if they were cached, but who builds docs on their own machine without having 1GB free
<samueldr> if I write docs, I build docs
<infinisil> Ah yeah
<samueldr> and I never verified whether docs were cached or not
<samueldr> 948.9M for asciidoctor, vs. 2.6M for docbook5 (as an easily quotable line)
<infinisil> I'd guess most people won't be bothered by that tbh
<samueldr> I think niksnut would :)
<samueldr> an order of magnitude smaller: I think it's likely fine
<samueldr> (but would still not be ideal)
<infinisil> I think this is a very much secondary issue and it shouldn't prevent us from choosing any format
<infinisil> The gains we'll have from better documentation are so much more worth
<niksnut> no, that's absolutely a blocker
<samueldr> oh hi
<niksnut> there is no way we're making nixos dependent on gigabytes of asciidoctor crap
<infinisil> It's not NixOS, it's just the people who write docs and need to build them
<samueldr> I'm sure that there are optimizations to do within the ruby ecosystem and asciidoctor builds here
<niksnut> for example, it would mean that asciidoctor would be pulled in any time the nixos manpages have to be regenerated (which is almost every time)
<gchristensen> infinisil: like I was saying other times, it is absolutely a blocker :P
<infinisil> Then we agree to disagree
<samueldr> I am sure that asciidoctor is the better contender here, but there are fixes to do for it to be considered
<infinisil> I and many other people couldn't care less about disk usage
<niksnut> but don't interpret this to mean I'm only opposed because of the closure size
<samueldr> and I believe it would be a well spent effort in actually putting eyse on that issue
<niksnut> asciidoc is just a loathsome as every other markdown language
<infinisil> niksnut: How so?
<niksnut> because they all have a crappy, poorly specified do-what-I-mean syntax that's fine for writing reddit posts but not for technical documentation
<niksnut> I can never remember which magic sequence of special characters accomplishes a given effect in the markdown language I happen to be using
<niksnut> as opposed to say latex where it's easy to remember \chapter{...}
<samueldr> in markdown I know that <b>hi</b> is boldened :)
<samueldr> (what, your parser doesn't keep html?? it's a broken parser!)
<gchristensen> what does it do when converted to man pages? :P
<samueldr> no one reads those archaic things!
<gchristensen> help
<niksnut> anyway, I've been triggered enough :-)
<samueldr> These shell commands are defined internally. Type `help' to see this list.
__monty__ has quit [Quit: leaving]
<infinisil> This do-what-i-mean syntax is exactly what makes them easy to write and read though, and this is why they're so loved
<infinisil> And asciidoc is at least well-defined
<infinisil> Asciidoc was created to make writing docbook easier to write iirc
<niksnut> it's not easy to write, I find it very hard to write
justanotheruser has quit [Ping timeout: 248 seconds]
<infinisil> You find *docbook* easy to write?
<niksnut> yes, much easier
<infinisil> Then you're one of *very* few with that opinion
<gchristensen> this is why I prefer markdown actually. it is trivial to write even if it isn't great for technical documentation. everybody already knows how to write it to some degree at least.
<samueldr> maybe it's time the technology sector embraces an openly defined format for technical writing like .docx
<niksnut> and markdown languages aren't easy to read either, because of the adhoc-ness of the syntax
<gchristensen> yes, samueldr!
<infinisil> gchristensen: I'm very split between markdown and asciidoc.. markdown because everybody is familiar with it, but asciidoc for a better future
<niksnut> the technology sector should just give up on bikeshedding syntax and store data as ASTs
<samueldr> niksnut++
<{^_^}> niksnut's karma got increased to 14
<niksnut> then everybody can use whatever editing formalism they want
<samueldr> (I was extremely fascetious in that .docx remark)
<MichaelRaskin> samueldr: fortunately we are protected from choosing docx by the fact has zipped references
<niksnut> basically all of this is a consequence of still being stuck in a punch card formalism
<gchristensen> niksnut: I tried to get oXygen to gift us like 100 free licenses but they didn't bite
<infinisil> > paragraphs = [ "This is a paragraph and this is a ${bold "bold"} word" ]
<{^_^}> paragraphs defined
<MichaelRaskin> Mmm, is a SmallTalk rewrite of Nix coming?
joko has quit [Ping timeout: 265 seconds]
drakonis has quit [Ping timeout: 240 seconds]
<infinisil> Maybe we should have a vote on what doc format to use, after discussing them
<MichaelRaskin> samueldr: I think Docbook is the closest of storing the parse tree of the document! And no, saying «just store an AST» does not really define the format…
<gchristensen> ideally also after demos
<niksnut> democracy doesn't work :p
<MichaelRaskin> Indeed, we have a decision making process!
<MichaelRaskin> Based on actual deliberation!
<samueldr> (is democracy choosing after a demo?)
<infinisil> Alternatively, let everybody vote on how important different aspects are of the format. E.g. Alice says she gives closure size importance 3 while it being familiar has importance 5
<MichaelRaskin> I wonder if one RFC per proposed format will just jam the process
<infinisil> And after that we let everybody decide on how good each aspect is for each format
<gchristensen> MichaelRaskin: sounds doomed
<infinisil> Then we calculate their total goodness by weighting each aspect
<gchristensen> niksnut: good grief
<simpson> If it can evaluate nixpkgs better than Nix, then it can replace Nix~ King of the hill is surely a viable technique that won't lead to gamesmanship~
<MichaelRaskin> I think having parallel competing RFCs would actually lead to more complicated decision-making than Debian has, no?
<niksnut> don't think so, you just have a ranked vote at the end
<MichaelRaskin> We should try. We might even adopt two contraictory RFCs in the end
<infinisil> What I don't like about choosing votes or ranked votes is that it does'nt say how much better each candidate is than the other
<infinisil> Which is why I suggested a weight-based approach
<gchristensen> we haven't even tried any
<gchristensen> how can we vote on it if we haven't tried them
<samueldr> your preferred or most hyped horse in the game
<infinisil> And if we vote based on aspects, there's no way for people to go "I like this one the most because it's the only one I know"
<infinisil> And it should be a "what's the best", not a "what's the most popular"
<infinisil> (my major gripe with almost all votings ^)
<gchristensen> the ugly truth is there aren't bests
<gchristensen> and if this is trying to get around requirements like run-time closure size via vote, it is probably not a great approach to the problem
<infinisil> If something is a blocker then it won't be an option to vote for
<gchristensen> cool
<infinisil> Well
<infinisil> If something is impossible then it won't be an option
<infinisil> A blocker could not be a blocker later on
<gchristensen> anyway discussing process is fun and all