<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
<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
<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)
<danderson>
I could use some wisdom on https://github.com/NixOS/nixpkgs/pull/104484 . 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).
<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>
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.
<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 http://status.nixos.org:9200? I'd like to fix that so we have details in grafana again.
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
<{^_^}>
#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>
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\
<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