<ajs124>
at least the applications I care about aren't broken in master, but I'm kind of hesitant to backport a major release for grafana-loki and syncthing also has had a whole bunch of releases since then.
<samueldr>
knownVulnerabilities are about known _vulnerabilities_
<samueldr>
is there a known CVE or something for go 1.14?
<gchristensen>
^
<samueldr>
and even for master, the road forward is dropping go 1.14, not keeping it around with that mark of shame
<{^_^}>
#113054 (by zowoq, 6 days ago, merged): go_1_14: set knownVulnerabilities
<gchristensen>
+1 to revert
<samueldr>
I totally get why this was done for unstable... while I do not agree with the mechanisms used
<samueldr>
a "hey, this is EOL and you're still using it" message isn't a bad idea
<samueldr>
but bringing this to the stable branches, that's not good
<sterni>
EOL should maybe be a warning
<sterni>
altough trace hasn't good UX
<sterni>
also I guess with the ofborg policy of it preventing a clean ofborg check it's not really viable as long as other stuff still depends on in in master
<samueldr>
looking at the current state, I think it's the main thing that would cause slight irritations in integrating with the website, everything else AFAICT generates good enough markup
<samueldr>
and even then, if pressed, it would be as trivial as patching mmdoc for the website build, or doing other manipulations to the DOM while building
<samueldr>
other than issues with narrow viewport, that's a good initial implementation ryantm
<samueldr>
there's nothing else for now that I've seen quickly
orivej has joined #nixos-dev
<sterni>
ryantm: have you ever had a look at lowdown? I'm not sure if you're still targeting the nixpkgs manual with mmdoc as an end goal, but I could imagine porting the markdown rendering to lowdown could be interesting at some point
<sterni>
ryantm: because looks like the next nix version will depend on it anyways for rendering markdown to the terminal for :doc
<sterni>
(when we're already at the topic of reducing nixpkgs manual closure size :p)
<sterni>
hm okay epub could be a bit of a challenge depending on how you do it
<ryantm>
No, I hadn't seen it. I think cmark is pretty good though.
<ryantm>
sterni: The main reason I'm writing mmdoc is for the NixOS manual, because it needs to have a small closure size. Apparently the nixpkgs manual does not.
<ryantm>
It would be nice if it was suitable for all three manuals.
<sterni>
ryantm: haven't looked into cmark or even cmark vs. lowdown at all actually, I was just thinking that lowdown could be interesting in regards to closure size as it would already be in the nix closure size
<sterni>
but also potentially just bikeshedding as cmark is probably also very small
<ryantm>
sterni: Right that's certainly interesting and I'm happy you pointed it out to me!
<ryantm>
I like how cmark lets you traverse and edit the markdown AST.
<sterni>
I'm not sure if that is possible / intended with lowdown
<sterni>
also I suspect lowdown is not as tried and tested as cmark for library purposes
<sterni>
I think nix is like the second major program to use it
<sterni>
where the first one is the lowdown cli
<ryantm>
sterni: So the reason to use lowdown for nix is it has the terminal output feature?
<sterni>
ryantm: I don't know what eelcos reasoning was exactly, I think they dug it up originally, but I assume so lowdown's terminal rendering is the only thing it is used for in nix currently
<ryantm>
samueldr: Got the titles in the search working.
<samueldr>
ryantm++
<{^_^}>
ryantm's karma got increased to 35
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
davidak[m] has joined #nixos-dev
<samueldr>
uuuh... a friend of mine realized their github fork of nixpkgs is spamming them with (failing) actions from the default actions that serves to merge branches automatically
<ryantm>
GitHub sent me a message about actions being disabled on my fork since I hadn't pushed to it in a while.
<sterni>
samueldr: I think you can disable actions for forks somehow or be more restrictive in the action .yml
<sterni>
samueldr: someone™ should probably figure out what to change
<samueldr>
what I mean to bring up is that this is not a good experience for our users, what can we do to help them without having them do more things?
<sterni>
seems either people forking have to disable actions
<sterni>
or we add if: github.repository == 'Nixos/nixpkgs' to our actions
<sterni>
which would be preferrable right?
<ryantm>
Right
<samueldr>
seems so, especially those staging merge workflows, they don't really make sense for other repos