worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ | | | 20.09 RMs: worldofpeace, jonringer |
orivej has joined #nixos-dev
supersandro2000 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
julm has quit [Quit: Reconnecting]
julm has joined #nixos-dev
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
LnL has quit [Ping timeout: 260 seconds]
LnL has joined #nixos-dev
justanotheruser has quit [Ping timeout: 240 seconds]
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
justanotheruser has joined #nixos-dev
rajivr has joined #nixos-dev
ris has quit [Ping timeout: 256 seconds]
Emantor has quit [Quit: ZNC -]
Emantor has joined #nixos-dev
<siraben> Where can I see the current blockers for nixpkgs-unstable?
<siraben> It hasn't been updated in 4 days :/
<samueldr> you can get to there by flicking on the link in the "hydra job for tests" column here
<samueldr> alternatively, clicking rather than flicking
<samueldr> >> running test tests/ [FAIL]
<samueldr> for nix on darwin
<samueldr> mac7-guest with /nix/store/0bggwk2zabl3nmd8hqr3ssmmcx59crdj-nix-2.3.9.drv
<samueldr> and thunderbird timing out
* samueldr kicks the build
<samueldr> kicking as in restarting
<siraben> samueldr: so i'm at , where do I go?
<samueldr> either the constituents tab, or open th latest build and go to _its_ constituents tab
<samueldr> the first option will give you an overview of the last few builds
red[evilred] has joined #nixos-dev
<red[evilred]> andi- (IRC): - if you could take another peek at #101893 I'd sure appreciate it. I'm not entirely sure what you're looking for. I don't understand
<{^_^}> (by redvers, 3 weeks ago, open): eyewitness: init at v20201021.1
<samueldr> red[evilred]: you have `runHook postInstall` but not `runHook preInstall` in the `installPhase`
<siraben> samueldr: I see. Ah, thunderbird is blocking the channel!
<hexa-> nixpkgs-review lgtm
<red[evilred]> I guess because I didn't populate it? but I should still execute it?
<hexa-> thunderbird times out
<samueldr> red[evilred]: uh? you didn't populate postInstall either
<red[evilred]> oh - fair
<samueldr> red[evilred]: it's not for use inside the derivation, but for consumers overriding it
<red[evilred]> but there is something out....
<red[evilred]> bingo
<siraben> Why is thunderbird in the constituents for nixpkgs?
<red[evilred]> thank you
<red[evilred]> now I understand
<red[evilred]> :-)
<siraben> The rest seems to be essential packages, inkscape and thunderbird are large
<samueldr> siraben: a couple of "canary" packages like this that are generally useful can show that things are failing when they shouldn't
<siraben> samueldr: I see.
<samueldr> siraben: though look more carefully, there is also `nixpkgs-review` that's failing, thunderbird is not alone
<samueldr> thunderbird is (apparently) a time out, so I restarted it
<samueldr> but I find it odd that it timed out at only 2h33
<samueldr> there might be something more subtle to look at, but the easy first thing to do is restart the build
<siraben> heh, only 2h33? How long does it usually take?
<samueldr> according to this, 54 minutes
<samueldr> on the particular builder it built on
alp has quit [Ping timeout: 240 seconds]
<siraben> Interesting
<samueldr> indeed
<hexa-> oh, well. it's nixpkgs-review *on darwin*
<hexa-> and it looks like a test in nix is failing?
<samueldr> yes
<siraben> So it's unrelated to thunderbird?
<hexa-> two separate issues really
<samueldr> thunderbird is part of the problem too
<samueldr> two issues
<siraben> "This is getting out of hand, now there are two of them!"
<siraben> installing 'foo-1.0'
<siraben> error: unexpected EOF reading a line
<siraben> Is that the error?
<red[evilred]> Okay - can I ask a workflow question?
<red[evilred]> I'm trying to cherrypick from master... so I need to look at the log for master at the same time that I have my branch checked out
<red[evilred]> I'm guessing maintaining two separate repos isn't the right way to be doing this
<red[evilred]> and somehow I'm missing some tooling
<red[evilred]> (or just git log master)
<red[evilred]> nm
<V> just git log master :p
<red[evilred]> I think I just need to watch streams of people work for a while
<hexa-> reported the nix issue here
<{^_^}> nix#4270 (by mweinelt, 14 seconds ago, open): 2.3.9: tests/ failing on Darwin
<red[evilred]> since i"m several years in and only just learned about tools like nixpkgs-review and hub
<samueldr> there's probably as many ways to do work correctly as there are people doing the work
<samueldr> so at the very least, don't expect one individual to hold all the "right" answers
<siraben> red[evilred]: maintaining two separate repos of what?
<siraben> FWIW, one thing that I've found very useful when hacking on nixpkgs is git worktree
<samueldr> I can wholeheartedly agree here, git worktree is a gem
<hexa-> uh yeah, without worktrees … rip
orivej has quit [Ping timeout: 272 seconds]
<siraben> before worktrees i can't believe i put up with stashes etc.
<siraben> for that notion of "working simultaneously"
<qyliss> there are also git namespaces, which are similar but let you have per-worktree branch namespaces, essentially
<red[evilred]> git worktrees?
<red[evilred]> honestly, right now I'm trying to make sense of a cherry-pick I'm trying to do from a merge
<red[evilred]> and foir some reason - I seem to be picking the 1000+ file merge instead
<red[evilred]> instead of the one
<red[evilred]> so git log --graph d93c4e2
<red[evilred]> I just want to pull this one: "ant: 1.10.2 -> 1.10.8"
<hexa-> c7224f12c37bc90b452591cd597e1ac8f160d9c9
<red[evilred]> but c7224f is the entire tree underneath it right
<hexa-> uh, but you'd only be pikcing the single commit
<hexa-> git cherry-pick -x c7224f12c37bc90b452591cd597e1ac8f160d9c9
<red[evilred]> warning: inexact rename detection was skipped due to too many files.
<red[evilred]> etc
<hexa-> so?
<hexa-> where are you picking this one to?
<red[evilred]> my local copy of redvers:update_ant_20.03-1.10.9
<red[evilred]> that I've reverted back one commit
<hexa-> so release-20.03
<red[evilred]> yes
<red[evilred]> it complains that I havce unmerged paths
<hexa-> because the patch doesn't apply cleanly
<red[evilred]> so there must be anotehr patch before it on the same file?
<hexa-> check the history for the package on master and cherry-pick the other commits you are missing
<red[evilred]> oh - now I see the issue
<red[evilred]> apparently a bot breezed past and eitehr removed or added quotes to that file
<red[evilred]> so I have to find that patch too now
<red[evilred]> thanks
<red[evilred]> Okay - I don't see how it's possible to do what I'm being asked to do
<red[evilred]> So - I must cherry-pick from master
<red[evilred]> but I can't cherry-pick the patches I need because the state of the file before the patch I need to apply was altered by " treewide: Per RFC45, remove all unquoted URLs"
<red[evilred]> which is 9,648 changed files
<red[evilred]> I guess I can't cherry-pick a single file change from a commit
<red[evilred]> since that would make an even bigger mess
<samueldr> *what* was asked of you?
<red[evilred]> #102838
<{^_^}> (by redvers, 2 weeks ago, open): [20.03] ant: 1.10.2 -> 1.10.9 [20.03]
<red[evilred]> You should pick each of them (in order) individually instead of trying
<red[evilred]> to pick the merge commit.
<red[evilred]> the problem is that theydon't seem to apply
jonringer has quit [Remote host closed the connection]
<red[evilred]> I could ignore it for 7 days and then it won't matter (since it's 20.03)
<red[evilred]> but I kinda want to understand what's happening
<samueldr> I don't see where in the contributing guidelines it's asked to backport all version bumps
<samueldr> though yeah, it's for the best when possible
<samueldr> or ask for more specific help (sorry not from me at the moment); we all shouldn't assume everyone is well-acquainted with the intricacies of all tools
<red[evilred]> no worries - I'll ask who is reviewing
<red[evilred]> I do appreciate your help thus far
orivej has joined #nixos-dev
<red[evilred]> When I'm in a nix-shell nixpkgs -A packageImWorkingOn environment
<red[evilred]> and I'm followiong all the commands in the installPhase one by one (because it's borked)
<red[evilred]> and I reach:
<red[evilred]> ln -s ${lib.getLib systemd}/lib/ $out/opt/brackets/lib/
<red[evilred]> how do I evaluate lib.getLib systemd in this context?
<red[evilred]> oh - I can just echo $installPhase I guess
<red[evilred]> nm
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
kalbasit has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-dev
cole-h has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 260 seconds]
bpye has joined #nixos-dev
dstzd has quit [Quit: ZNC -]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
alp has joined #nixos-dev
<FRidh> domenkozar[m]: can you fix
<{^_^}> #104475 (by FRidh, 7 minutes ago, open): Evaluation error on master related to Cachix
supersandro2000 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
tilpner has joined #nixos-dev
dstzd has quit [Quit: ZNC -]
Graypup_ has quit [Ping timeout: 272 seconds]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
Graypup_ has joined #nixos-dev
dstzd has joined #nixos-dev
orivej has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
<danderson> I could use some wisdom on . It's a package for InfluxDB 2.0. There is already a package for InfluxDB 1.x, but 2.0 is a breaking upgrade (requires manual migration).
<{^_^}> #104484 (by danderson, 12 minutes ago, open): influxdb2: init at v2.0.2
<danderson> So, my instinct is to create a completely separate package and NixOS module, so that people can upgrade at their own pace by manually switching services. Then in a future release InfluxDB 1.x could be removed.
<danderson> Thoughts? Is this best practice for breaking changes to packages? Or should I just overwrite the existing 1.x package?
ris has joined #nixos-dev
<gchristensen> is the configuration for v2 sufficiently different?
<qyliss> the other option would be using stateVersion
<qyliss> which is how we handle e.g. postgres upgrades
<danderson> the upgrade process is complex and non-declarative:
<danderson> in particular, the upgrade process tries to rewrite its own config file, which isn't going to work here
<gchristensen> ow!
<danderson> it also breaks a bunch of old features they didn't want to move over
<gchristensen> since it is a config format change, probably a new module is the best option
<danderson> I'm actually genuinely not sure that it can even be upgraded cleanly. I don't have an influx 1.x install, so it's a bit moot for me, but...
<danderson> they do seem to have treated 2.0 as a big do-over for everything
<danderson> which, y'know, I respect, they're doing 2.0 right... But ow :)
<gchristensen> yeah it sounds like a totally different thing, just happens to have a similar name
<danderson> pretty much
<danderson> one of its flagship "features" is that it's bundled what were previously 3.5 services into a single binary
<danderson> (which made the build hilariously terrible to get into nix, 3 different languages all trying to snarf packages non-hermetically)
<gchristensen> :(
<MichaelRaskin> This makes me wonder if they also mess up the foreign-function interfaces inside that binary…
<danderson> it's mostly okay. It's a Go program that calls into a Rust library via cgo (boring dynamic linking), and bundles a pile of compiled typescript for the web UI
<danderson> so the end result is a Go program that makes some C FFI calls, and serves some embedded js files
<MichaelRaskin> OK, if C FFI calls are incoming to Rust and the Rust oart does not need to keep state across calls, then it should not be too bad
<danderson> yeah, should be okay. At least, Nix isn't adding any complication there
<danderson> I do find it mildly bizarre to embed a Rust library into Go, but hey, not my code not my circus :)
<MichaelRaskin> But single executable!
<danderson> the Rust package is a query language they invented called Flux. Allegedly, they wrote it in Rust so they could compile it both to a dynamic library for calling from go, and to wasm for client-side use
<danderson> so the language parser running in the web UI's editor is the same code as the stuff running server-side
<gchristensen> neat
<danderson> it's pretty cool, although my personal feeling is it would have been simpler to write two implementations and comparative testing
<danderson> unless it's C++ levels of language complexity, what do I know :
<danderson> :)
<MichaelRaskin> I think given that at some point no two JSON parsers actually agreed…
<danderson> having this rust dual-wielding thing forced them to do absolutely awful things to the build system, like create a `pkg-config` binary that pretends to be the normal pkg-config, but if you ask it for libflux it on the sly sets up a rust build env, compiles the rust library, and makes up the pkgconfig for it on the fly
<MichaelRaskin> You either need to use a proper grammar definition formalism, or just indeed cross-cmpile the same stuff
<danderson> ... I did not use any of that build system shenanigans for the nix derivation.
<MichaelRaskin> Wow, Slick.
<MichaelRaskin> Responsible choice!
<danderson> after peeling apart the onion, turns out it's just a .so library, and a pkg-config pointing at it. So I just made nix do that :)
<MichaelRaskin> I started wondering whether compiling Go to WebAssembly would be that bad, but then remembered that Go compilation doesn't even try to make sense so maybe yes
<danderson> that's sort of the weird thing... `GOOS=js GOARCH=wasm go build ...` and you're done
<MichaelRaskin> Ah, they did implement it
<danderson> I guess either that wasn't ready when they embarked on influx 2.0, or rust brought something else to the table
<gchristensen> go was really ahead of the curve on the goose trend
<danderson> (or two people on the team reeaaaaaallly wanted to write rust)
<gchristensen> probably that had a thing to do with it, hehe
<MichaelRaskin> Or they wanted to use a parser combinator library
<MichaelRaskin> I would easily buy that browser target + enough flexibility for a parser combinator library more or less forces your hand towards Rust or Clojure?
<danderson> possibly. Although then the Go code also has go:generate blocks to generate parsers for other bits and pieces
<danderson> so, what was so magical about that one parser?
<danderson> I'm sure it makes sense if you know the project. I just wanted to play with influx 2.0 and encountered the "not packaged in nix yet" boss
<gchristensen> yeah, nice work danderson
<danderson> thanks. There is an ofborg failure I don't understand, if you want to advise :)
<gchristensen> target branch error?
danderson has quit [Remote host closed the connection]
danderson has joined #nixos-dev
<danderson> well that was weird, irssi stopped accepting my input.
<danderson> gchristensen: what I was trying to paste:
<danderson> it has a long trace, but afaict doesn't tell me what's actually wrong :(
<danderson> and nix-build works fine for me
<danderson> anyway, I have to head to sleep, it's way past my bedtime. Happy weekend!
__monty__ has joined #nixos-dev
alp has joined #nixos-dev
ehmry has quit [Quit: - Chat comfortably. Anywhere.]
justanotheruser has quit [Ping timeout: 240 seconds]
dstzd has quit [Quit: ZNC -]
dstzd has joined #nixos-dev
AlwaysLivid has quit [Ping timeout: 260 seconds]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Client Quit]
AlwaysLivid has joined #nixos-dev
bgamari has quit [Ping timeout: 256 seconds]
bgamari has joined #nixos-dev
ehmry has joined #nixos-dev
ehmry has quit [Quit: - Chat comfortably. Anywhere.]
<andi-> Looking at the aarch64 backlog over the last few days/weeks I wonder what the long term strategy is :/ What are our options to obtain more builders?
<gchristensen> I could take a look at the current aarch64 spot order and see if we can't get more
<andi-> gchristensen: that would be nice. Any chance you can get me the error message of the hydra reexporter from I'd like to fix that so we have details in grafana again.
<andi-> nvm that, it is probably this error
<gchristensen> KeyError: 'memoryTokensInUse'
<andi-> was already fixed but probably not deployed:
<{^_^}> nixos-org-configurations#130 (by thefloweringash, 5 days ago, merged): hydra-queue-runner-reexporter: remove memory_tokens_in_use
<gchristensen> I can help with that
<gchristensen> it'd be good to get people like you the ability to deploy and log in to systems like this
<andi-> maybe, how are things being deployed right now? Just randomly and the only to a few boxes or just to every single box every time?
<gchristensen> I think a few boxes at a time
<andi-> s/maybe/strong yes so I can fix the v6 on that box…/
<gchristensen> buildGo112Module has been removed
<gchristensen> :/
<andi-> it is fairly dated, no?
<gchristensen> I dunno, when did version one hundred and thirteen come out (...) but anyway looks like I can't deploy until that gets updated
<andi-> the cost of downstream packaging... I'll look into it
<gchristensen> a cost and benefit :)
<andi-> gchristensen: what nixpkgs revision is that machine using? 20.09?
<gchristensen> I think so
ehmry has joined #nixos-dev
<{^_^}> nixos-org-configurations#132 (by andir, 15 seconds ago, open): delft/prometheus/packet-sd: update to newer buildGoModule
FRidh has quit [Remote host closed the connection]
lejonet has joined #nixos-dev
<lejonet> infinisil: ofc just because I poked you about it, it doesn't give me that error, but that could be because we changed the type of types.listOf format.type
typetetris has joined #nixos-dev
<supersandro2000> it is go version 1.13
<lejonet> infinisil: because it would seem like setting listOf in types and the attrsToList function I wrote (without mkdefault) was the solution
<__red__> if only there was a way to deploy trusted versions of hydra
<infinisil> I'd recommend not using the attrsToList function, and just inserting a list directly in the config section
<__red__> that has to be a solvable problem
<lejonet> infinisil: yeah, now that we've defined the type to actually be a listOf, the function is entirely redundant
<__red__> (trusted meaning that we could trust a swarm of community deployed build resources witout fear of a malicious actor)
<infinisil> (Well it was redundant before too actually, because it was just used once in the local scope)
alp has quit [Ping timeout: 272 seconds]
<lejonet> infinisil: Yeah, that was the problem I was seeing about solving, because I, probably misremembered, remembered that we for some reason decided against making the type to listOf because of it causing immutability, and the function was my attempt to trying to let the user define a attrset of attrsets that would then be made into a list of attrsets
<__red__> I guess it's considered bad form to want to completely re-write a package definition as part of a security-related version bump huh?
<__red__> brb, applying the wall functor against my head
<infinisil> lejonet: Yeah that won't work unfortunately. lists just don't work well with defaults, can't change that
<lejonet> infinisil: indeed, and it would seem like packetbeat does the "right thing" in that if a type is defined twice, with the exact same ports list, the latter will take precedence, so doing listOf and just using a list gets the intended functionatily of the user-definability and overridability
<infinisil> lejonet: Ah, then maybe we want a `mkBefore` for the defaults
<infinisil> Then the users definitions will come after those
<lejonet> infinisil: ah, that would be a better way to ensure it than just implicitly trusting the merging rules to put em before the user definitions
<infinisil> Yeah, list merging rules don't give any guarantee about ordering really
<lejonet> infinisil: which is understandable
<infinisil> (which is my other issue with lists, they're kinda non-deterministic)
<lejonet> and trusting implicit functionality is always going to bite you in the ass someday
<infinisil> lejonet: Yeah, e.g. :2
<{^_^}> #77088 (by Infinisil, 45 weeks ago, merged): nixos/systemd: Explicitly put default path packages after othe…
<lejonet> infinisil: sweet, I'll hammer this out, test it locally on my system, do a rebase and forced push to remove the commit with the attrsToList function and maybe we can get somewhere with the module :P
janneke has quit [Ping timeout: 260 seconds]
AlwaysLivid has quit [Ping timeout: 264 seconds]
AlwaysLivid has joined #nixos-dev
<lejonet> infinisil: fixed and pushed to the PR
janneke has joined #nixos-dev
<infinisil> lejonet: (just wrote a short review of the PR)
<infinisil> In particular running the service as root irks me
<lejonet> infinisil: yeah, sadly I think that is a requirement due to how the service is built, I guess it maybe could be manhandled with CAP_NET_ADMIN (I think that is the cap for network stuff) because it has to be able to inspect the network buffers and so
<infinisil> I think it's worth trying to make that work
<lejonet> its certainly worth a shot
FRidh has joined #nixos-dev
<lejonet> infinisil: A small googling around make it seem like with CAP_NET_RAW, it should work together with DynamicUser
<lejonet> I will give that a go
<infinisil> lejonet: DynamicUser is actually probably in conflict with stateDir
<infinisil> So unless that option can be removed, maybe just a regular user after all
<lejonet> infinisil: let me double check what it actually dumps in stateDir, could be that the stuff there is actually ephemeral
<infinisil> Yeah, if so DynamicUser would work great
<lejonet> It would seem like its just some metadata it puts there, but from what I can tell from this blog post:, StateDir does interact nicely with DynamicUser
<lejonet> infinisil: well, it seems like I've figured out that it only needs CAP_NET_RAW and CAP_NET_ADMIN for doing the sniffing, but just setting it in the CapabilitiesBoundingSet of the service doesn't seem to be enough to satisfy it
<infinisil> Maybe check what other services in nixpkgs do
<lejonet> infinisil: I checked sshguard, that seems to need the same capabilites, and it just sets the CapabilityBoundingSet
<lejonet> Ah, setting it in AmbientCapabilites seems to have worked
<lejonet> Yep, I get logs from packetbeat as expected, and the service didn't error out
<lejonet> infinisil: only thing left to address is the YAML in a string part, and as I noted as a comment to your request, I don't know how I'd represent a YAML expression in Nix
<lejonet> infinisil: or maybe its just a list, that the beat turns into some type of action internally, I dunno, I'll dig a bit in the beats code
alp has joined #nixos-dev
<lejonet> infinisil: a simple way to solve this is to not try and 1:1 map the default config that packetbeat is shipped with, and then just let the user figure it out if they need a conditional processor
AlwaysLivid has quit [Quit: We are a collection of 7 billion codependent atoms. Stop hating based on constructs and come along for the ride.]
AlwaysLivid has joined #nixos-dev
<infinisil> lejonet: You can always convert yaml to json
<infinisil> To see what it means
<lejonet> infinisil: Yeah, I just stared a bit more on the config and also read some of the code that parses the config and realized that its probably just a very nestled object
cole-h has joined #nixos-dev
<lejonet> infinisil: the thing that made my head just go blargh was the fact that I didn't realize that the then and else parts aren't "standalone", they're actually objects whose value is a list
<lejonet> infinisil: yeah, converting it to JSON proves that I was on the right path, I'll soon push a commit with the final fixes
<maralorn> domenkozar: I can see you are chipping away at getting servant to run? I am nearly finished with getting cachix on 8.8.4 to compile again.
<domenkozar[m]> maralorn: servant compiles on master now via 8.10.2
<maralorn> Ah, great!
<domenkozar[m]> I haven't marked it as not broken because there's no way to do that without adding those overrides manually and reverting them again
<domenkozar[m]> thanks for fixing cachix!
<domenkozar[m]> and for kind and swift reponse :)
<maralorn> Hm, now I wonder if it would be easier to fix cachix on 8.10.2 or on 8.8.4. Still some trouble to get dhall to compile with this packageset and an old haskeline … /o\
<domenkozar[m]> I'm making that effort at
<{^_^}> cachix/cachix#331 (by domenkozar, 10 weeks ago, open): Ghc 8.10
<maralorn> I had the feeling with a temporary protolude override the current cachix version would also work.
<domenkozar[m]> yeah, although I had to change the way cxx is handled in cabal
<domenkozar[m]> most probably related to GHC 8.10 changes, not sure.
<domenkozar[m]> but that's one search&replace
<maralorn> We really need a way that we only mark really broken packages as broken and dependent packages automatically get disabled by hackage2nix …
<maralorn> I really hope that we can improve the workflow enough before the ghc 9.0.x bump.
alp has quit [Ping timeout: 272 seconds]
<maralorn> I think we should strive to have a "blessed" subset of Haskell packages and I guess if switching ghc breaks that we need to freeze the stackage revision for a while.
<gchristensen> we do in the sense that if certain packages break the channel won't move forward
<maralorn> Yeah, that's true. But that seems more like a last ressort for really important packages. I think the set of actively maintained haskell packages ought to be a little big bigger.
<maralorn> In a first brainstorming our idea was to support everything on stackage + packages someone volunteers as maintainer for. And being a maintainer would be fairly low barrier. You can just say "Hey, I want that package" and then we compile it for you. When it breaks we notify you and then you can still decide if you wanna try to fix it or just drop it.
alp has joined #nixos-dev
<maralorn> domenkozar: Are you just waiting for CI to merge your PR? Because I don‘t think I can reasonably fix it faster than that.
AlwaysLivid has quit [Remote host closed the connection]
<domenkozar[m]> maralorn: we did have cachix in release jobset :D
<domenkozar[m]> but none of it helps if you deliberately break things
<domenkozar[m]> maralorn: as mentioned on discourse, I don't think the problem was that the issue wasn't noticed, but that it was ignored
<maralorn> domenkozar: I agree. I wouldn‘t have dared to press that merge button.
<domenkozar[m]> and it's a classical interaction with Peter Simons, now he'll just ignore me
<domenkozar[m]> so there's really no room to improvement
<maralorn> domenkozar: I’ll at least try to nudge the process in that direction.
<maralorn> domenkozar: And if you would have been informed about the build fail last Monday morning (which we should be able to ensure via tooling) this would have been a lot less bumpy.
<domenkozar[m]> yeah, a week is not ideal, but that gives me a fair chance :)
<domenkozar[m]> there's a script for NixOS releases that show broken packages and ping maintainers
<domenkozar[m]> maybe it could be adapted to be used for haskell packages as well
<domenkozar[m]> maintainers/scripts/
rajivr has quit [Quit: Connection closed for inactivity]
<domenkozar[m]> it probably even works already :)
alp has quit [Ping timeout: 260 seconds]
alp has joined #nixos-dev
justanotheruser has joined #nixos-dev
alp has quit [Ping timeout: 272 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
alp has joined #nixos-dev
justanotheruser has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
hl has quit [Ping timeout: 260 seconds]
hl has joined #nixos-dev
hl has quit [Changing host]
hl has joined #nixos-dev
__monty__ has quit [Quit: leaving]
alp has quit [Ping timeout: 272 seconds]
pie_ has quit [Ping timeout: 272 seconds]
pie_ has joined #nixos-dev
m1cr0man has quit [Quit: G'luck]
m1cr0man has joined #nixos-dev
alp has joined #nixos-dev