worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ | | | 20.09 RMs: worldofpeace, jonringer |
__monty__ has quit [Quit: leaving]
supersandro2000 has quit [Disconnected by services]
teto has quit [Ping timeout: 264 seconds]
supersandro2000 has joined #nixos-dev
<supersandro2000> Can we disable the pytorch tests by default? they take forever to build.
<samueldr> I don't think so because the default is what runs in hydra
<supersandro2000> I could do an overlay but then I always need to compile it
rajivr has joined #nixos-dev
orivej has quit [Ping timeout: 272 seconds]
kalbasit has joined #nixos-dev
<abathur> curious if anyone has thoughts/experience on ~organizing people interested in a certain language packaging ecosystem? (I guess mostly toward the ends of keeping everyone in the loop while patterns and practices are shaking out?)
<supersandro2000> try to contact the others and maybe organize a little meet if there is something to talk about
maljub01 has quit [Ping timeout: 258 seconds]
maljub01 has joined #nixos-dev
fuzzypixelz has joined #nixos-dev
justan0theruser has quit [Ping timeout: 264 seconds]
<{^_^}> firing: RootPartitionLowInodes:
Jackneilll has quit [Ping timeout: 246 seconds]
Jackneilll has joined #nixos-dev
<pie_> puck: Ericson2314: this might or might not be interesting git uses a custom Makefile and a configure scripts for the build. The build system does not seem to have native support for the compilation database generation. We will use bear and intercept-build to generate one.
<pie_> Bear and intercept-build from scan-build, are two tools from László Nagy, that collects the compile options by intercepting calls to the compiler during the build. To have a complete compilation database a full build is required.
<Ericson2314> pie_: ah i think i remember meson can generate those tooo
<pie_> also something called ldlogger but im not sure what that does. basically, if interesting, probably see rest of page
<pie_> also mildly intriguing thought: running statistics on compilation databases generated for a whole machine or whatever. dunno if that would be interesting
<pie_> im going to sleep now though
mkaito has quit [Quit: WeeChat 3.0]
<supersandro2000> an alternative to
<{^_^}> rfcs#84 (by Infinisil, 1 week ago, open): [RFC 0084] Input-aware fetchers
<supersandro2000> could we just a github action which fetches the URL and compares the hash to the on in the PR? If it does not match it just fails.
<cole-h> That's then limited to GitHub PRs, no?
<samueldr> won't help the poor soul trying to do something who accidentally left the wrong (right) sha256sum
<samueldr> and that's further tie-in to a proprietary system
<supersandro2000> cole-h: it would solve my my need for inputs aware fetchers
<supersandro2000> or we just make a by default off dev options which does it
<supersandro2000> samueldr: we can also write it in plain shell and just execute it there
<supersandro2000> or lets say we had a tool that would work like nix-update but verify the hash
<supersandro2000> if we didn't have normal and sri hashes we could just replace the hashes with 0s and run nix update
<cole-h> recent Nix versions treat an empty hash as the all-0 / all-A hash
<abathur> nice
<supersandro2000> What if we ever get a hash of all 0 or A?
<supersandro2000> do we need to request a repackage upstream?
<samueldr> the same as what do you do for any other arbitrary hash collision with any hash as I understand it
<abathur> hehe
<abathur> maybe worth an assertion
<abathur> oh nice
<cole-h> I mean
<abathur> 3 cheers for regular channel advancements; resholve's already in unstable and I wasn't even expecting it yet
<cole-h> If you ever get an all-0 hash when updating a package, congrats, you don't have to change it to the new hash.
<cole-h> :P
<cole-h> As unlikely as an all-0 hash is, I'm sure it's even less likely you get an all-0 hash on two unrelated blobs.
<cole-h> (Don't quote me on that, I'm obviously not well-versed in hashing / crypto / what have you)
<abathur> well
<supersandro2000> abathur: next time just write me earlier 😜
<abathur> <3 supersandro2000
<{^_^}> supersandro2000's karma got increased to 21
<supersandro2000> hehe
<supersandro2000> now lets start using it
<supersandro2000> abathur: can you do a blocking event queue manager with that opens an interactive command?
<abathur> ha, I was about to mention that I'd already un-drafted #107182
<{^_^}> (by abathur, 2 weeks ago, open): bashup-events: init at it's-complicated
<abathur> uhrm, I understand all of these words separately but I'm not 100% sure what they mean in this arrangement
<abathur> example maybe?
<supersandro2000> I want to queue nixpkgs-review shells and want them to be automatically executed but in an interactive shell where I can inspect the reports and post them by hand
<supersandro2000> imagine something like task-spooler but with an bash -i
<abathur> hmm
<abathur> would you distinguish that from, say, for pr in {id,id,id}; do nixpkgs-review pr $id; done?
<abathur> are you wanting them to run parallel but block for inspection?
<abathur> er, $pr
<supersandro2000> I don't want to run them in parallel
<supersandro2000> something like nixpkgs-review pr 1 2 3..n but I want to instead n while it is running
<supersandro2000> not sure how to do that
<supersandro2000> I could append it to a file and read from the beginning of it
<abathur> maybe I can work around the other way; the main things I get out of are: 1) it adds a legible abstraction for declaring a hook/event interface that lets one or more developers build modular code (so, for example, it's easy for a shell module/library to publish before-command/after-command events for consumers to hook onto without clobbering each other
<abathur> and 2) it can do some fun currying stuff, (register a one-time event specifying some of the function's eventual call arguments at registration time and the rest at emit time)
<abathur> so in some sense it's just sugar, but in another sense it does make it easy to have a queue (though I think maybe you want bashup-events32 if you care about order?)
<fuzzypixelz> what are some tasks that an unitiated person like me can start off with? do you have anything in mind that could potentially invlove lots of work, but isn't very invloved as I'm not familiar with the ins and outs of nixos yet
<abathur> so you could do like `event once "gotta run 'em all" nixpkgs-review pr 1` and then `event once "gotta run 'em all" nixpkgs-review pr 2` and then `event emit "gotta run 'em all" and it should go run them all in sequence
<cole-h> fuzzypixelz: How most people start out is reviewing PRs (e.g. if they build, if they function properly, etc), updating a package you're interested in, or creating a new package for something you're interested in'
<cole-h> e.g. my first ever Nixpkgs PR was, a version bump.
<{^_^}> #79682 (by cole-h, 47 weeks ago, merged): fish-foreign-env: git-20170324 -> git-20200209
<abathur> should have like eh, a documentation slot machine; pull the lever, get a doc section, rate how decipherable it is
<abathur> that feeds a triage list of least-decipherable documentation sections :)
<fuzzypixelz> I've been browsing the PRs for a while and they call look very intimidating haha
<abathur> it takes a bit to find your sea-legs
sorki has joined #nixos-dev
srk has quit [Ping timeout: 240 seconds]
sorki is now known as srk
<fuzzypixelz> what is your usual workflow like?
<fuzzypixelz> how do you test prs for example?
<samueldr> 1. look at the PR changes through github... see if it's something I can't handle
<samueldr> 2. then scrutinize the changes, however, for glaring obvious issues
<samueldr> 3. test the changes, hopefully the contributor left instructions to test changes
<samueldr> when testing, you should also run the affected programs, ideally, and not only compile them
<samueldr> but for changes affecting loads of packages, it can be hard
<fuzzypixelz> samueldr: I mean, how do you actually test the changes? do you just build it on your own machine? do you pull the changes into a local repo?
<samueldr> 4. scrutinize changes again
<samueldr> yeah, checkout the PR locally, nix-build what it affects
<samueldr> I'm leaving "checkout the PR locally" quite vague, multiple approaches exist
<fuzzypixelz> samueldr: for example?
<samueldr> there's some github helper commands, I think hub is one of them
<samueldr> you could also fetch the pr head from github using uh... convoluted commands available in github's help pages :)
<samueldr> you might also want to apply the PR as a patch by curl-ing it and then git applying it (but that's not really a good way)
<samueldr> there's nixpkgs-review that does many things
<samueldr> I'm sure there's about as many strategies to review as there are reviewers, which is both good (no monoculture!) and not ideal (blind spots?)
<worldofpeace> hub cherry-pick $patch-url | hub am -3 | hub pr checkout #134
<{^_^}> github/hub#134 (by ndbroadbent, 8 years ago, closed): Added simple bash tab completion for hub commands
<{^_^}> (by MarcWeber, 8 years ago, closed): adding pygame.patch
<worldofpeace> or the new gh command which is really intuitive
fuzzypixelz has quit [Ping timeout: 246 seconds]
<samueldr> I CTRL+L, copy, `curl -L [CTRL+V].patch | git apply` (or am)
<samueldr> (or use my pr checkout script if I intend to dig deeply, which really is unneeded)
<qyliss> I just git fetch nixpkgs pull/XXXXX/head && git checkout FETCH_HEAD
<samueldr> yeah, those convoluted instructions :)
<samueldr> they don't stick in my mind
<siraben> using magit + forge really makes it easy in Emacs :)
Mic92 has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-dev
<{^_^}> firing: RootPartitionLowInodes:
kalbasit has quit [Ping timeout: 240 seconds]
sreybastien has quit [Ping timeout: 246 seconds]
<supersandro2000> if you are using refined github or gh you can easily checkout PRs
<supersandro2000> I would take a look at PRs which init new packages because this are the places where most of the mistakes are made in my opinion
cole-h has quit [Ping timeout: 260 seconds]
teto has joined #nixos-dev
sreybastien has joined #nixos-dev
rnhmjoj has quit [Changing host]
rnhmjoj has joined #nixos-dev
rnhmjoj has quit [Changing host]
rnhmjoj has joined #nixos-dev
<siraben> supersandro2000: what sort of script are you running to generate your reviews? looks like nix-hammering + nix-review
<supersandro2000> plus some ripgrep, pup and hydra-check
<supersandro2000> going to publish it soon ™️
<siraben> nice
yuuki_ has joined #nixos-dev
<rnhmjoj> i have a problem running a set of NixOS tests: if i do `nix build -f. nixosTests.installer` i get an OOM, even with `--max-jobs 1`
<rnhmjoj> presumably nix is evaluating all tests at once, is there a way to make it somewhat strict or use less memory?
<rnhmjoj> i hacked something together to run one at a time using nix eval and xargs but it's not very nice
<lassulus> nix-build nixos/tests/installer.nix -A simple ?
<supersandro2000> Can someone confirm or deny this?
<rnhmjoj> lassulus: without specifying manually each test name?
<rnhmjoj> this is what i'm currently doing: `nix eval --impure --expr 'with (import ./. {}); lib.concatMapStringsSep "\n" (x: "nixosTests.installer.${x}") (builtins.attrNames nixosTests.installer)' --raw | xargs -I name -n1 nix build -f. name -o result-name`
<lassulus> hmm, yeah I would have done something similiar, sadly I don't know any way to limit the evaluator :/
<rnhmjoj> guess i'll have to buy more ram, thanks anyway
orivej has joined #nixos-dev
<supersandro2000> how much do you have?
<lukegb> rnhmjoj: just a `nix-build nixos/tests/installer.nix` should work too iirc
<lukegb> if you want all the tests
<siraben> how do i run nixpkgs tests?
<lukegb> which ones
__monty__ has joined #nixos-dev
justanotheruser has joined #nixos-dev
<{^_^}> firing: RootPartitionLowInodes:
<rnhmjoj> supersandro2000: only 8GB on my desktop. i have a broken ram slot :(
<rnhmjoj> i have a homeserver to do the heavy lifting, but remote builds can't handle evaluation
<supersandro2000> eval shouldn't take more than 4
<rnhmjoj> uhm, i assumed it was being killed by the OOM killer but it's actually segfaulting
<rnhmjoj> strange: nix[31375]: segfault at 7fb4e8844000 ip 00007fb52a913d40 sp 00007fb4e3702110 error 4 in[7fb52a90c000+1b000]
<rnhmjoj> lukegb: nix-build nixos/tests/installer.nix crashes similarly
<lukegb> yeah, the nix gc is, err, sometimes invoked at Bad Times
<rnhmjoj> it crashes at around 1.2GB, so it can't be an oom
<supersandro2000> Anyone has any idea how to make cargoHash python version aware?
<supersandro2000> I get a different one for every python version using maturin...
<supersandro2000> I mean I could use a different one per version but this is ugly...
<siraben> How often does staging-next get merged into master?
__monty__ has quit [Quit: leaving]
<Mic92> spacekookie: (since you are not in #nixos) don't forget the RFC steering committee meeting today
lukegb has quit [Quit: ~~lukegb out~~]
lukegb has joined #nixos-dev
lukegb is now known as lukegb_
lukegb_ is now known as lukegb
<spacekookie> Mic92: oh interesting, I thought it was gonna be next week
<Mic92> we already skipped a meeting over christmas
<spacekookie> The on the 31st?
<Mic92> Yes
fuzzypixelz has joined #nixos-dev
justanotheruser has quit [Ping timeout: 260 seconds]
<gchristensen> thanks andi- -- I'm going the scenic route on fixing that, about done
<andi-> gchristensen: was it a nice route? :)
justanotheruser has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
<supersandro2000> siraben: once in a while when some things pilled up
<Mic92> niksnut: coming?
<gchristensen> andi-: created a role in vault, a iam policy to write state to an s3 bucket, a script to fetch environment variables ...
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has quit [Changing host]
fuzzypixelz has quit [Ping timeout: 256 seconds]
<{^_^}> firing: RootPartitionLowInodes:
fuzzypixelz has joined #nixos-dev
Cale has joined #nixos-dev
justanotheruser has quit [Ping timeout: 264 seconds]
fuzzypixelz has quit [Ping timeout: 264 seconds]
teto has quit [Quit: WeeChat 3.0]
<pingiun> is eelco dolstra not in this channel?
<pingiun> or just not currently?
<tilpner> pingiun: The name's ${"niks" + "nut"}
<pingiun> ah thanks
sorki has joined #nixos-dev
srk has quit [Ping timeout: 240 seconds]
sorki is now known as srk
sreybastien has quit [Ping timeout: 240 seconds]
<supersandro2000> When do I use autoreconfHook?
<qyliss> supersandro2000: when you need to (re)generate a configure script
<symphorien[m]> when you patch
<supersandro2000> I am trying to apply a patch and it prompted me for aclocal and autom4te
<qyliss> usually when you're building from git, or applying a patch that modifies a file that is involved in generating configure, like
<qyliss> supersandro2000: does the patch modify,, or similar?
<supersandro2000> I patched a m4 file
<supersandro2000> nah
<qyliss> right, yes, then autoreconfHook is appropriate here
<qyliss> because the m4 files are used to generate configure
<supersandro2000> great thanks
fuzzypixelz has joined #nixos-dev
<supersandro2000> error: possibly undefined macro: AC_MSG_RESULT
<supersandro2000> -_-
<qyliss> that means you're missing another nativeBuildInput
<qyliss> I don't remember which one
<qyliss> pkg-config maybe?
<qyliss> it's usually pkg-config with the missing macros that are named like they should be part of autoconf
<supersandro2000> I have pkg-config in nativeBuildInputs
<qyliss> hmmm
<qyliss> autoconf-archive?
<supersandro2000> seems to do something now
<supersandro2000> qyliss++
<{^_^}> qyliss's karma got increased to 108, it's a crit!
<supersandro2000> autoconf is weird...
<siraben> has anyone run some sort of analysis on Nixpkgs to see what packages are likely to be in nativeBuildInputs or buildInputs?
<siraben> I was thinking about doing a PR like the cmake one but more general
<supersandro2000> yes
<supersandro2000> I am not 100% confident if they are all correct
<supersandro2000> if not please let me know
<symphorien[m]> siraben if you are to spend some time on this, you'd better set `strictDeps` to true
kalbasit has joined #nixos-dev
<siraben> oh great, this is for nativeBuildInputs I'm presuming
<siraben> symphorien: where do I set that?
<supersandro2000> siraben: yes
<siraben> in the expression or in my nix.conf
<supersandro2000> in the package expression IIRC
<symphorien[m]> it will automatically fail the build when nativeBuildInputs vs buildINputs is incorrect
<symphorien[m]> yes as argument to mkDerivation
<siraben> But some programs might indeed need gcc at runtime
<jtojnar> supersandro2000: I would expect fontconfig, icu and krb5 in buildInputs
<jtojnar> and bzip2 probably too (more likely you will want to link against it than use it to extract an archive)
<siraben> Ah I see, setting strictDeps = true prevents cmake from being used at build time if it's in buildInputs
<siraben> symphorien: but should `strictDeps = true` be kept?
<qyliss> in general it's a good thing, but it can cause problems if used indiscriminately:
<{^_^}> #56943 (by emmanuelrosa, 1 year ago, open): setup hook of gobject-introspection in nativeBuildInputs does not run with strictDeps
<symphorien[m]> yes ! it helps inadvertently regressing cross
<symphorien[m]> also it's the default for python and maybe rust and go, iirc
<qyliss> all of those
<siraben> I see
<siraben> Do we have cross comp checked in hydra?
<qyliss> no
<siraben> I'd also imagine it's a N*M type of problem where you have N platforms and M packages
<siraben> oh man if there was an easy way to automate this
<siraben> the issue is with packages that break their inputs into separate lines
<qyliss> I think we don't need to test _every_ cross combination, as long as we're testing one of them so the cross-compliation infra is actually tested at all
<siraben> or let-bind their inputs
<siraben> qyliss: right.
<qyliss> I broke cross last week because I was just working through fixing Hydra failures, and didn't think to test cross because there was no automated test for it.
<siraben> I hate having to recompile a cross GCC each time, anyone have a cachix with a cross GCC?
<siraben> tangential but emulators feature of cross is undocumented #106375
<{^_^}> (by siraben, 4 weeks ago, open): Add documentation for emulators feature in cross infra
<siraben> when I have more time I plan to do some substantial rewrites to cross docs matthewbauer has some good content:
AlwaysLivid has joined #nixos-dev
costrouc has quit [Quit: costrouc]
AlwaysLivid has quit [Remote host closed the connection]
rajivr has quit [Quit: Connection closed for inactivity]
cole-h has joined #nixos-dev
<{^_^}> firing: RootPartitionLowInodes:
<lukegb> gchristensen: hmm, would you mind if I added Prometheus metrics to your github exporter for, I guess, this query: so we can define an alert for if the staging merge stops working
<lukegb> mostly to spam this IRC channel rather than bugging anyone in particular
<gchristensen> sure
fuzzypixelz has left #nixos-dev [#nixos-dev]
sreybastien has joined #nixos-dev
teto has joined #nixos-dev
asbachb has joined #nixos-dev
<asbachb> supersandro2000: Are you here?
justanotheruser has joined #nixos-dev
<rnhmjoj> do you have more suggestions for things to test for PR #107382?
<{^_^}> (by rnhmjoj, 2 weeks ago, open): nixos/{networkd,dhcpcd}: remove udev-settle hack
sreybastien has quit [Ping timeout: 246 seconds]
kalbasit has quit [Ping timeout: 240 seconds]
<ryantm> samueldr: Could you elaborate on ? Maybe an example would help.
<samueldr> sorry, I don't really have anything on-hand
<samueldr> I don't know either your level of comfort with web development
<samueldr> but, you know how, let's say, bootstrap tells you to use specific elements with specific class names to use some of their "components" or "layouts"?
<ryantm> My web development comfort is pretty high.
<samueldr> if you were doing that, without providing a way to replace the template, it'd make things harder to work on when implementing without bootstrap
<samueldr> hm
<samueldr> (sorry if that sounded a bit patronizing then)
<asbachb> Can I limit a package for linux 64/i86 only?
<samueldr> asbachb: with meta.platforms
<ryantm> Currently I only have 3 elements I'm styling: nav for the sidebar, section for the main text, and #search-results for the search results.
<ryantm> Probably need to add styling for all the Markdown elements though.
<samueldr> ryantm: I guess that since your comfort with web dev is pretty high there's not much fear from me
<asbachb> samueldr: Got it. Thanks.
<ryantm> samueldr: I guess I need to make a version that doesn't output a complete HTML page, so it can be better embedded.
<samueldr> let's see how your mmdoc thing evolves then :) haven't looked deeply into it, but on the surface it sounds great
<samueldr> yeah, as long as you keep provisions around for extensibility, things should be just right
<samueldr> which, AFAICT currently it's about right
<ryantm> I'm glad you like the general idea. I could probably use some help with the styling at some point and I know you've done a lot of great work on My experience with CSS is not as good as the HTML/Javascript side of things.
<samueldr> would be glad to help as much as I can
<ryantm> samueldr: Thanks! Let me look into man pages, and polish it a bit more then I'll ping you
<samueldr> sure :)
asbachb has quit [Remote host closed the connection]
yuuki_ has quit [Ping timeout: 265 seconds]
yuuki_ has joined #nixos-dev
yuuki_ has quit [Ping timeout: 240 seconds]
<{^_^}> firing: RootPartitionLowInodes:
<samueldr> I'm having some trouble figuring out why `disabledModules` seems to fail to disable a module
yuuki_ has joined #nixos-dev
yuuki_ has quit [Ping timeout: 264 seconds]
<samueldr> now I'm confused about `config.assertions` not triggering
<samueldr> oh right, forgot that it's only on `toplevel` use
<samueldr> ah, disabledModules is relative to <nixpkgs/nixos/modules>, not to <nixpkgs> (or equivalent without NIX_PATH)
<samueldr> samueldr++ for missing the obvious
<{^_^}> samueldr's karma got decreased to 301
<hexa-> I have a rust package that during startup tries to find, but doesn't look int the right path:
<cole-h> samueldr++
<{^_^}> samueldr's karma got increased to 302
<cole-h> hexa-: Probably have to patchelf --set-rpath
<hexa-> :<
<hexa-> I feared as much
<cole-h> Or wrap with LD_LIBRARY_PATH
<cole-h> Both are kinda ugly
<hexa-> ok, patchelf it is then
<ekleog> hexa-: you can also try autoPatchelfHook, maybe it'll solve the issue for you
<hexa-> ekleog: thx, checking
<hexa-> it found like 6 deps, not all :)
<ekleog> sad :'(
<samueldr> if the thing is doing dlopen, I don't know that patchelf would find it
<hexa-> just libvulkan missing now!
<hexa-> its doing openat, read, fstat
<hexa-> and in case it doesn't find it, just a bunch of openats
<samueldr> could be the syscalls dlopen does
<samueldr> hm
<ekleog> oh right there's dlopen, I was about to say that autoPatchelfHook should be able to find all the things if it didn't have bugs, but I had completely forgotten about that ./