<qyliss>
have only tested static builds so far fwiw
<Ericson2314>
qyliss: you mean that one works now?
<qyliss>
works for the example in the PR body
<Ericson2314>
cool!
<qyliss>
all that gcc stuff I was talking about before doesn't seem to be needed any more, so I must have made it necessary with another change that was also unnecessary or something
<qyliss>
gosh I wish I'd started with NetBSD -- FreeBSD was a million times harder than this
<qyliss>
(so I gave up on it)
<Ericson2314>
:) glad it's working!
<qyliss>
I guess with netbsd we had a good head start by having the package set all there, just a bit broken
<Ericson2314>
so I did end up merging master into staging
<Ericson2314>
I wonder if we should get those two commits, base off master and re-merge into staging
<Ericson2314>
so I can rebase mine off that without rebuilding the world :)
<qyliss>
not sure i follow
<qyliss>
but I have stayed up all night doing this so maybe that's to be expected
<Ericson2314>
haha well if you wanna call it I've approved the second one
<qyliss>
I'll wait for OfBorg then go to bed
<Ericson2314>
I can merge it too if you want
<Ericson2314>
timezone works out well for me
<qyliss>
yeah sure
<qyliss>
next things on my to-do list for this will be making sure non-static cross works, and testing NetBSD programs other than column
<Ericson2314>
sounds good
<qyliss>
I was still watching so just went ahead and merged it myself
<elvishjerricco>
So I'm getting back into my systemd based initrd for nixos. There's a lot of stuff in like postDeviceCommands and whatnot. I think I can implement backwards compatibility with these by using a neat new-ish systemd feature. `/etc/systemd/system/service.d/` can contain drop-ins that will be applied to all service units; should work for stuff like device.d and mount.d. So I could make a service that runs all the
<elvishjerricco>
postDeviceCommands, and then add `Before=post-device.service` to `device.d/nixos.conf` and `After=post-device.service` to `mount.d/nixos.conf`, and then do the same sort of thing for all the other *Commands.
<elvishjerricco>
Problem is that it places barriers in the boot process that might unnecessarily hinder parallelism and therefore boot times a bit. And it'd prevent e.g. device units that depend on mount units, like if your luks keyfile is on a file system that needs to be mounted.
<elvishjerricco>
So I'm not sure if I should do that or if I should just not implement those commands and leave removing them entirely as WIP.
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #nixos-dev
<elvishjerricco>
also, I'm very close to having a nixpkgs branch with the initial work for this initrd. Just need to add a bunch of boiler-plate-ish lines about the compressor since I'm not using makeInitrd. It's missing a lot of the functionality initrd currently has, but it's got mounts, rudimentary luks, and some nifty options for easily adding units to initrd.
Irenes has quit [Ping timeout: 260 seconds]
<symphorien[m]>
sterni you know how the ocaml infra works, right? do you know if bytecode linking works? I have had strange problems when linking bytecode with zarith
Irenes has joined #nixos-dev
<sterni>
symphorien[m]: I'm not sure never explicitly used that, I'd think it *should* work unless it depends on something other than OCAMLPATH
<sterni>
the ocaml infra is pretty simple overall since it doesn't do to crazy stuff internally
<sterni>
I can look at the error but not sure if I'll figure it out, I mostly only package OCaml stuff don't use it too much from a dev perspective or deployment really
<symphorien[m]>
well I have a problem where it cannot find -lzarith, so it's a question of "finding the right path" which is typically a nix induced problem
<symphorien[m]>
but first I need to reproduce on open source code :/
<sterni>
okay maybe there is another env var we need to set
<sterni>
is the target stuff in OCAMLPATH?
<symphorien[m]>
hum I can't reproduce on hello world...
orivej has joined #nixos-dev
<sterni>
do package renames (with backwards compatible alias) get a changelog entry?
<spacekookie>
Regarding the rfc meeting later, who's gonna lead the meeting? There's no issue for meeting notes from the 1.4
<sphalerite>
spacekookie: oh no, I forgot to copy the notes into an issue :( sorry
<sphalerite>
kloenk will be leading it
<spacekookie>
Okay
<spacekookie>
I can relax a bit then x)
<kloenk>
Well, I can't xP
<sterni>
we can't compile glibc with clang, can we?
<lukegb>
hmm, I thought they made clang glibc-compatible a while back
<lukegb>
ah right, maybe only GRTE
<lukegb>
(Google uses glibc and some other things and bundles them into the Google Run Time Environment, for which there's a corresponding upstream glibc branch; GRTE is clang-compilable)
<sterni>
hm well making pkgsClang pkgsMusl but with llvm could also work for now
<sterni>
but clang glibc would be very cool to have as well
<lukegb>
yeah, grte's glibc's configure has a "with-clang" flag, that does... something
<qyliss>
could we just set stdenv = gccStdenv in glibc, like we would for other packages that required a specific compiler?
<lukegb>
that might make sense; I get the impression glibc in general isn't intended for compilation with anything other than gcc
<lukegb>
(like the Linux kernel used to be in days gone by...)
abathur has joined #nixos-dev
<sterni>
checking if x86_64-unknown-linux-gnu-clang is sufficient to build libc... no
<sterni>
lol
<sterni>
can you build gcc with clang doe
<sterni>
well that doesn't really matter
<sterni>
since pkgsClang only works by taking the cross stdenv code path currently
<symphorien[m]>
<sterni "can you build gcc with clang doe"> I suppose bsd people do that
<sterni>
Ericson2314: llvmPackages_7.libunwind works as of #119479, but unfortunately it doesn't build yet when useLLVM2 = true; because the patches to make it libc++ free don't apply
<siraben>
How do I open a Nix repl for an older version of Nix?
<siraben>
Of nixpkgs*
<lukegb>
Usually I just do "nix repl ." in a checkout
<gchristensen>
niksnut: re https://github.com/NixOS/hydra/pull/911 maybe it'd be better to have a single jsonb column called meta so we can store more meta fields later as needed
<{^_^}>
hydra#911 (by grahamc, 2 days ago, open): meta.outputsToInstall: store and propogate
cole-h has joined #nixos-dev
<niksnut>
gchristensen: I'm concerned about how much data this will add to the DB
<gchristensen>
yeah, understandable
<niksnut>
but yeah if we had unlimited space then we should just store all of meta
<gchristensen>
oh, I don't mean all the meta
<niksnut>
I did :-)
<gchristensen>
specifically chosen columns
<niksnut>
right, it could be configurable
Irenes has joined #nixos-dev
supersandro2000 has joined #nixos-dev
mkaito has joined #nixos-dev
mkaito has joined #nixos-dev
bgamari has quit [Ping timeout: 260 seconds]
mkaito has quit [Quit: WeeChat 3.1]
bgamari has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
tomberek has quit [Quit: Connection closed]
zhaofeng1 has quit [Ping timeout: 258 seconds]
justan0theruser has quit [Quit: WeeChat 2.9]
zhaofeng1 has joined #nixos-dev
justanotheruser has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
justanotheruser has joined #nixos-dev
maxine has quit [Quit: Goodbye]
endocrimes has quit [Quit: running from the computers]
maxine has joined #nixos-dev
endocrimes has joined #nixos-dev
rj has joined #nixos-dev
rj has quit [Ping timeout: 240 seconds]
rj has joined #nixos-dev
jefferai__ has joined #nixos-dev
jefferai__ is now known as jefferai
<jefferai>
I'd love to update the protobuf package, but I am blindingly new to nix package development and a bit lost. I can easily update the version in the 3.15.nix file but not sure where that sha256 sum is coming from, it's not from the source tarball. I tried building locally with the instructions from the wiki but it really wants a default.nix file which doesn't exist in that dir.
<gchristensen>
,tofu jefferai
<{^_^}>
jefferai: To get a sha256 hash of a new source, you can use the Trust On First Use model: use probably-wrong hash (for example: 0000000000000000000000000000000000000000000000000000), then replace it with the correct hash Nix expected. The library functions lib.fakeSha256, lib.fakeSha512, lib.fakeHash are available for this.
<jefferai>
Got it -- that all makes sense. How do I build it though, do get that sha256 out? I've tried various combinations of the nix-build $NIXPKGS -A protobuf command but it keeps wanting a default.nix in that directory.
<jefferai>
Example output from that:
<jefferai>
error: getting status of '/home/jeff/src/nixpkgs/pkgs/development/libraries/protobuf/default.nix': No such file or directory
<lukegb>
You probably want to do nix-build /home/jeff/src/nixpkgs -A protobuf3_15
<jefferai>
yes!
ghuntley has quit [Quit: Connection closed for inactivity]
<jefferai>
So interestingly(?) it built 3.15.8, but it didn't actually complain about an invalid sha256, even though I didn't change it from the value it had for 3.15.5
<jefferai>
Ah. I'm on master branch which I guess corresponds to unstable repo but needs to get synced from staging?
<infinisil>
jefferai: But yeah, if you don't change the hash, Nix just assumes that the source didn't change, since the hash that was requested is already present with specific contents
<jefferai>
regardless, I need 3.15.8 :)
<jefferai>
Ah, ok
<jefferai>
I'll set it to something different hen
<infinisil>
So to actually force a hash recalculation you need to change it to an invalid hash first, like the all-0 one
<lukegb>
infinisil: didn't you propose changing that
<jefferai>
So when does the staging branch get merged into unstable?
<lukegb>
staging gets merged into staging-next, and then from there into master (to avoid rebuilding-the-world too often)
tomberek has joined #nixos-dev
<lukegb>
master becomes unstable once it's been validated through hydra
<jefferai>
ah
<jefferai>
so if I send a PR I should PR against the staging branch
<jefferai>
And by "if" I mean "shortly" :-)
<lukegb>
well, only if it would cause a "large" number of rebuilds
<lukegb>
which, for protobuf, is the case :)
<lukegb>
(although I forget what the $BIG_NUMBER guidance is)
orivej has quit [Ping timeout: 240 seconds]
justanotheruser has quit [Ping timeout: 258 seconds]
<jefferai>
Once I have a package built, while I wait for it to go through PR and then eventually into unstable, what's the best way to install locally? I thought maybe I could add the local repo as a channel but if that's possible I haven't gotten the syntax right
<lukegb>
It depends: do you only need it for packages outside of nixpkgs?
<lukegb>
or are you trying to replace the version used by other things *in* nixpkgs
<{^_^}>
jefferai's karma got increased to 2, it's a crit!
<jefferai>
Crit!
<jefferai>
BTW, I can try running those other commands in the template. The previous update didn't, so I figured not specifically necessary...?
rj has joined #nixos-dev
justanotheruser has joined #nixos-dev
<jefferai>
@lukegb given I just need it locally, is there an easy way?
<sterni>
Ericson2314: the GNU binutils derivation doesn't seem to emit an as with a correct targetPrefix
<Ericson2314>
sterni: that's very odd
<sterni>
i. e. pkgsCross.gnu64.buildPackages.binutils-unwrapped and pkgsCross.musl64.buildPackages.binutils-unwrapped only have bin/as and not bin/${targetPrefix}as
<sterni>
which is a bit of a problem because then the binutils wrapper just ignores as
<Ericson2314>
is it because the host and target are too similar?
<sterni>
I think so at least for the build system
<sterni>
I made a stupid fix for it where I had a lib.optionalString (stdenv.hostPlatfrom != stdenv.targetPlatform) " … " which symlinked as to ${targetPrefix}as in postInstall
<sterni>
so I figure binutils has its own ideas about whether it wants cross or not
<sterni>
I guess the next thing to try is to see if you can force it to use a certain target prefix
<sterni>
Ericson2314: oh yeah in that case --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu are passed lol
<lukegb>
jefferai: yeah, you can just import that nixpkgs
<jefferai>
As a channel you mean?
<jefferai>
I assume if so, not the repo directly
<lukegb>
I mean, literally just `import /path/to/nixpkgs {}`
rj has joined #nixos-dev
<sterni>
Ericson2314: what do you think about adding a special case to binutils wrapper to catch that if stdenv.hostPlatform.config == stdenv.targetPlatform.config
<sterni>
hm it's kinda ugly actually :/
jonringer has quit [Remote host closed the connection]
<Ericson2314>
sterni: sorry i walked away right after
<Ericson2314>
sterni: i think there is a way to force the previx
<Ericson2314>
*prefix
teto has joined #nixos-dev
<sterni>
kk, I'll try around tomorrow
<sterni>
I scrolled through the configure script earlier but gave up :p
rj has quit [Ping timeout: 240 seconds]
rj has joined #nixos-dev
<abathur>
nix#4690 (3 word diff!) could use a look from someone with a handle on sudo security policy. It basically rewrites a few uses of `sudo HOME=ROOT_HOME command` -> `sudo env HOME=ROOT_HOME command` in the installer to support `doas` as a sudo replacement. I'm wondering if `env` is more likely to be blocked than changing HOME already would be?