worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ | | | 20.09 RMs: worldofpeace, jonringer |
stigo has joined #nixos-dev
SuperSandro2000 is now known as supersandro2000
supersandro2000 has quit [Disconnected by services]
supersandro20008 has joined #nixos-dev
jonringer has quit [Remote host closed the connection]
rajivr has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 258 seconds]
tilpner_ is now known as tilpner
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 265 seconds]
tilpner_ is now known as tilpner
supersandro20008 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
Emantor has quit [Quit: ZNC -]
Emantor has joined #nixos-dev
mkaito has quit [Quit: WeeChat 3.0]
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
mkaito has joined #nixos-dev
mkaito has quit [Client Quit]
BaughnLogBot has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 256 seconds]
maljub01 has quit [Quit: maljub01]
maljub01 has joined #nixos-dev
<supersandro2000> Should we use "${pkgs.package}/lib/" or "${lib.getLib pkgs.packages}/lib/" ?
<siraben> I suppose if unzip is used in runtime, the software would have to pick it from HOST_PATH anyway?"
<samueldr> not sure where else it's being used, but it's a feature of stdenv
<siraben> samueldr: so should I be more aggressive with putting unzip in nativeBuildInputs?
<siraben> it's not clear when it's needed at runtime
<samueldr> I don't know
<symphorien[m]> <samueldr "not sure where else it's being u"> HOST_PATH is used in patchShebang --host
<samueldr> yeah, I meant else than this specific file
<samueldr> (which mentions patchShebangs)
<samueldr> but looks like, from a quick grep, that it is not used elsewhere
abathur has quit [Quit: abathur]
cole-h has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 264 seconds]
tilpner_ is now known as tilpner
tilpner has quit [Quit: tilpner]
cole-h has joined #nixos-dev
eyJhb has quit [Quit: Clever message]
eyJhb has joined #nixos-dev
eyJhb has joined #nixos-dev
eyJhb has quit [Changing host]
dottedmag has joined #nixos-dev
<sterni> ekleog: ping regarding #107322 :) it has been two months now pretty much
<{^_^}> (by sternenseemann, 8 weeks ago, open): fetchFromGitHub: also use git if deepClone or leaveDotGit is used
<sterni> supersandro2000: I think it is a better practive to use getLib, but I think the output list is pretty stable for most packages
<sterni> supersandro2000: also it seems to me that multi output packages are frowned upon unless absolutely necessary
zimbatm[m] has joined #nixos-dev
__monty__ has joined #nixos-dev
<ris> would be good to get some eyes on #110893
<{^_^}> (by risicle, 3 weeks ago, open): cpython: add separateDebugInfo v2
<ris> (oh i see it actually got some attention 3h ago)
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
mkaito has quit [Client Quit]
mkaito has joined #nixos-dev
BaughnLogBot has joined #nixos-dev
Raito_Bezarius has quit [Ping timeout: 272 seconds]
tilpner has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
orivej has quit [Ping timeout: 256 seconds]
Raito_Bezarius has joined #nixos-dev
<siraben> Any thoughts on ? Should we remove packages from Nixpkgs after 1+ year of being marked broken?
<siraben> Possibly could be an RFC
<ajs124> do we normally set pkgs as insecure on stable, if things depend on them?
<gchristensen> yes
BaughnLogBot has quit [Ping timeout: 264 seconds]
<samueldr> or get them updated in a secure manner
BaughnLogBot_ has joined #nixos-dev
<ajs124> the specific commit I'm wondering about is, which broke the eval if your system has syncthing, grafana-loki, caddy or some other stuff.
BaughnLogBot_ is now known as BaughnLogBot
<samueldr> uh, that seems not exactly right, here
<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
* samueldr checks the actual PR
<{^_^}> #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
<sterni> (which is also good I guess?!)
<ryantm> samueldr: I've been working on the mmdoc styling:
<samueldr> ryantm: any consideration for templating? mainly make those kind of chunks somewhat configurable by the users?
<samueldr> (users being software using mmdoc)
<ryantm> samueldr: Nothing yet
<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
<ryantm> Yeah there's some overlapping on mobile
FRidh has quit [Quit: Konversation terminated!]
<samueldr> would be nice to have the section title here, rather than file paths:
<samueldr> (I can open issues if you prefer)
<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
<sterni> this is the only usage currently:
<V> lowdown is good, I use it for all my markdown generation needs
<V> can recommend
<ryantm> V: Does it support adding additional extensions?
<ryantm> Like it looks like maybe it doesn't support tables.
<V> ryantm: file extension or markdown extension
<ryantm> Markdown
<sterni> ryantm: you can set it in options
<V> it supports some stuff from GFM, including tables
<V> there's a bunch of options
<ryantm> Cool, yeah, I missed that. Looks like it might support admonitions, I'm curious if it has an extension mechanism.
<V> it also lets you use jekyll-style frontmatter attributes, which can then be extracted with -X
<ryantm> it might not*
<V> I'm not aware of a more dynamic extension mechanism
<sterni> ryantm: I don't think it has an extension mechanism, but I think upstream is pretty open to patches
<sterni> (especially if it is more stuff from commonmark)
<sterni> ryantm: oh, nixUnstable also uses lowdown for generating its man pages
<sterni> ryantm: but I see that relatively critical, upstream advises against it and the results are not really great
<sterni> ryantm: which is to be expected since markdown can't be mapped to a man page satifyingly
<sterni> (e. g. man 1 nix has some leftover markdown links in unstable at the moment which is pretty shocking)
<ryantm> Right, cmark outputs man too, but it doesn't provide the tools necessary to modify the man page output, like it does for HTML.
<sterni> how do you generate the epub output? is that a custom cmark backend?
<ryantm> No, cmark's html output was written to be compatible with XHTML/epub. So you can take the HTML output and then put it into a epub.
<ryantm> I had to figure out the epub format and make a zip file
<ryantm> I know barely anything about epubs, it's most just copied from wikipedia.
<sterni> okay something like that should also be possible for lowdown
<sterni> was wondering if that was a blocker
<ryantm> Yeah, assuming the lowdown authors have written the HTML to be XHTML compliant.
<ryantm> My Kobo e-reader seems picky about the XHTML document being well-formed.
<samueldr> (and html5, by design, may not be xhtml compliant)
<sterni> ryantm: seems like lowdown emits a subset of HTML5 that is xhtml compliant (at least when not using standalone mode)
<sterni> ryantm: since it is compatible with which uses xhtml
__monty__ has quit [Quit: leaving]
<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