worldofpeace changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 20.09 Nightingale ✨ | | | 20.09 RMs: worldofpeace, jonringer |
orivej has quit [Ping timeout: 276 seconds]
justanotheruser has quit [Ping timeout: 265 seconds]
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nixos-dev
<clever> [1/167/268 built, 291 copied (1186.0 MiB), 20.9 MiB DL] building glibc-2.27-armv6l-unknown-linux-gnueabihf on ssh://builder@
<clever> i think i crossed it?
<clever> [1/170/268 built, 297 copied (1301.8 MiB), 20.9 MiB DL] building armv6l-unknown-linux-gnueabihf-stage-final-gcc-debug-7.4.0 on ssh://builder@
<clever> or not, lol
<clever> configure: error: C compiler cannot create executables
<clever> builder for '/nix/store/n03cjh2n0q9msj94zsnfn0lskhr3w32d-audit-2.8.4-armv6l-unknown-linux-gnueabihf.drv' failed with exit code 1; last 10 log lines:
<samueldr> hm... just in case you see weird breakage with kernel 4.4 and 4.9 soon,
<samueldr> though I don't think we should be worried about breakage at build time
<clever> armv6l-unknown-linux-gnueabihf-ld: cannot find -lgcc_s
<clever> ok, i sorta see the problem
<clever> attempt to open /nix/store/qxsbn4d4l32p1v620hx89vgl87i4j8ls-armv6l-unknown-linux-gnueabihf-stage-final-gcc-debug-7.4.0/lib/gcc/armv6l-unknown-linux-gnueabihf/7.4.0/../../../../armv6l-unknown-linux-gnueabihf/lib/ failed
<clever> it was looking in $out/$targetConfig/lib
<clever> but i moved it to $lib/$targetConfig/lib
<clever> and for $lib, it doesnt include the $targetConfig prefix, it just checks raw $lib/lib
<clever> how does this search path get configured...
BaughnLogBot has quit [Ping timeout: 258 seconds]
jonringer has quit [Remote host closed the connection]
BaughnLogBot has joined #nixos-dev
Emantor has quit [Quit: ZNC -]
Emantor has joined #nixos-dev
jonringer has joined #nixos-dev
supersandro2000 has quit [Quit: The Lounge -]
supersandro2000 has joined #nixos-dev
das_j has quit [Quit: Bridge terminating on SIGTERM]
ajs124 has quit [Quit: Bridge terminating on SIGTERM]
Scriptkiddi has quit [Quit: Bridge terminating on SIGTERM]
das_j has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
ajs124 has joined #nixos-dev
<hexa-> hm, so can I just start a staging next merge request?
<hexa-> like … merge staging into staging-next and open the staging next -> master pull request
<infinisil> hexa-: This happens automatically afaik
mkaito has quit [Quit: WeeChat 3.0]
<hexa-> infinisil: prettya sure staging -> staging-next happens manually
<hexa-> what happens automatically is master -> staging-next -> staging
<infinisil> Ah I see
<hexa-> here goes nothing
tgamblin-llnl has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has joined #nixos-dev
tgamblin-llnl has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
jonringer has quit [Remote host closed the connection]
evanjs- has joined #nixos-dev
evanjs has quit [Ping timeout: 276 seconds]
tgamblin-llnl has quit [Ping timeout: 276 seconds]
BaughnLogBot has quit [Ping timeout: 264 seconds]
BaughnLogBot has joined #nixos-dev
tgamblin-llnl has joined #nixos-dev
tgamblin-llnl is now known as toddgamblin
toddgamblin is now known as tgamblin_
jonringer has joined #nixos-dev
disasm has joined #nixos-dev
cole-h has quit [Ping timeout: 240 seconds]
AlwaysLivid has quit [Remote host closed the connection]
<eyJhb> DockerTools WIP PR here - would love some comments
<{^_^}> #112105 (by eyJhb, 33 seconds ago, open): WIP: build-support.dockerTools: fix `buildTools` not inheriting configs from `fromImage`
rajivr has joined #nixos-dev
jonringer has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-dev
tgamblin_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 276 seconds]
cptchaos83 has joined #nixos-dev
rnhmjoj_ has joined #nixos-dev
<rnhmjoj_> what do you think of removing old modules from boot.initrd.availableKernelModules?
<rnhmjoj_> should we just in and leave them here forever or make an attempt at removing them?
<rnhmjoj_> *just give in
fuzzypixelz has joined #nixos-dev
<fuzzypixelz> hello, I'm trying to backport tailscale updates, what should I do with ?
<fuzzypixelz> do I leave it out?
<rnhmjoj_> fuzzypixelz: does it make any noticeable difference to tailscale? given it was broken since 2016 and nobody notices, probably not
<Mic92> Already blocked him personally
<gchristensen> new account from late last year, forked a bunch of repos without adding any activity, a handful of issues in nixpkgs ... worth watching
<siraben> I've seen that account and they seem to have access to volth's commits?
<gchristensen> oh?
<siraben> oh they removed the link, weird. let me dig up my emails
<rnhmjoj_> i thought they *were* in fact volth
<siraben> it's probably volth or someone pretending to be volth
<siraben> Given the nature of the treewide commit, I only know of volth who can do that.
<siraben> and they are hiding commits and marking them as off-topic, strange isn't it?
<siraben> s/commits/comments
<siraben> "Forked repos are accessible using parent's user name, so @volth's work could be accessed this way"
<rnhmjoj_> it's probably a habit of them, even before the disappearance of volth's account, whole conversation were being deleted leaving the impression that one talking to himself
<gchristensen> where are they doing that, siraben?
<gchristensen> yes, volth did like to delete their own comments
<siraben> gchristensen: doing the deletion of their own comments? well in they definitely posted a link to their patch (to which I was replying) but it has now been deleted
<gchristensen> ah gotcha
<siraben> I have the email notification
<gchristensen> andi probably has it archived as well
<gchristensen> okay, well, volth or not -- worth keeping an eye on the user for bad behavior
<siraben> andi?
* andi-
<siraben> ah
<gchristensen> thanks for that siraben
<siraben> np
<siraben> I guess all the more reason to quote-reply.
<andi-> Reminds me to finish my WIP code for providing a GH event search
__monty__ has joined #nixos-dev
<stigo> hey. can someone have a look at #110654 would be great to get an updated perl into staging soon :-)
<{^_^}> (by stigtsp, 1 week ago, open): perl532: 5.32.0 -> 5.32.1, perl-cross: 4c55233 -> 1.3.5
<infinisil> andi-: Oh yeah I thought about creating something like that too
<infinisil> I'd just extract all PR events into a text file, then grepping and co. are very easy
<infinisil> "just"
<andi-> lol
<andi-> Have you any idea about the data volu,?
<andi-> *Do
<andi-> s/volu,/volume/
<gchristensen> andi-: would you like to try again?
<infinisil> I think that's not a problem. But the API might not make it super easy to extract everything
<andi-> there have been a few people working on this already
<andi-> and as far as I can tell I think GH never deletes the events from their database...
<andi-> they just don't share it with us
<siraben> Good thing our stale bot only adds a tag instead of locking;
<siraben> Yeah GH doesn't actually delete a lot of things. I know of people who recovered their accidentally deleted gists, for instance.
<adisbladis> Is there any good reason we don't allow the Nix install script to run as root? This is annoying me so often.
<gchristensen> if you're using the daemon, it would be fine
<gchristensen> if you're single-user'ing it, well, you probably shouldn't be using root so much you want a package manager just for root
<adisbladis> I am
<adisbladis> I think maybe the right call is to make that bit interactive too?
<adisbladis> And give users the opportunity to bail out, but not do so automatically
<adisbladis> With a good informative message of course
<gchristensen> yeah maybe so
<gchristensen> I think nix-as-root assumes you have the daemon (but skips talking to it)
<gchristensen> oh, yeah
<gchristensen> if you runnix-build as root, it uses nixbld* users and whatnot
<adisbladis> I think for multi user it never makes sense to bail out actually
<gchristensen> so nix as root *requires* multiuser
<andi-> I wish we would default to multi-user more oftan
* andi- typing is bad today, I should have breakfast...
<gchristensen> +100 andi-
<adisbladis> gchristensen: I thought that was controlled by build-users-group ?
<gchristensen> yes, but it is required
<adisbladis> Hm, TIL
fuzzypixelz has left #nixos-dev [#nixos-dev]
cole-h has joined #nixos-dev
toddgamblin has joined #nixos-dev
<V> hm so while recovering from a toasted laptop yesterday, I ended up having to write an extractor for my initrd so I could patch the stage 1 init
<V> AFAICT we have an impurity there in that initrds include hardlink counts from the host
<V> I might be wrong here, but that seems like an oversight
<V> I don't think the nlink part of the CPIO is actually used by the kernel
<V> (this needs further investigation, as I didn't spend a ton of time looking into it b/c trying to do anything from a recovery USB is a huge PITA, but I was having difficulty getting my extractor/repacking scripts to generate fully reproducible archives, and repacking was using code very similar to the generator in nixpkgs)
cole-h has quit [Ping timeout: 256 seconds]
<symphorien[m]> what does this mean ?
evanjs- is now known as evanjs
toddgamblin has quit [Ping timeout: 276 seconds]
<gchristensen> iirc the definitions merge
<andi-> V: so that would be a reproducible build issue and not an impurity in terms of missing some dependencies?
<V> andi-: it's an impurity in the nix build env
<V> hardlink count of stuff in the nix store shouldn't be exposed IMO
<gchristensen> why would a cpio's hardlink count be impure? wouldn't it be based on what is in the cpio?
<V> but it didn't appear to be
<gchristensen> do you use an optimised store?
<V> Yep
<V> I think that's the issue here
<gchristensen> when you rebuilt it, did you have an optimised store?
<V> I unpacked the archive (using cpio(1), so I wondered if it just generated symlinks when extracting hard links, initially, but that didn't appear to be the case), changed a file, and repacked it. this was using the files I took out of my existing initrd, except I was running in the recovery image this time
<V> so no files would have a hardlink count, as they were all distinct
<V> in order to test this, I would probably try building derivations with duplicate files, building an initrd from that, optimising the store, building another initrd, and seeing if the two change
<V> probably easier to just test by running cpio in a derivation tbh
rajivr has quit [Quit: Connection closed for inactivity]
rnhmjoj_ has quit [Ping timeout: 272 seconds]
clever has joined #nixos-dev
stigo has quit [Remote host closed the connection]
jonringer has joined #nixos-dev
stigo has joined #nixos-dev
jonringer has quit [Ping timeout: 240 seconds]
<eyJhb> If a project was renamed, then how should one go about that?
<eyJhb> `transmissionrpc` -> `transmission-rpc` ?
<lassulus> add an alias with deprecation warning?
<eyJhb> This package is used in two places in nixpkgs, so maybe renome them to use the new version + deprecated warning to rename it, as not to create alias clutter?
<samueldr> aliases will be for external users
<samueldr> external users include misc. projects using Nixpkgs, and NixOS users within systemPackages
<samueldr> (even though here it looks like a lib which shouldn't really be in systemPackages)
<samueldr> there is no alias clutter... there is only missing aliases
<samueldr> (I include in aliases: explaining removal with a throw, and similar things)
<eyJhb> So... You are all in for a alias samueldr ?
__monty__ has quit [Quit: leaving]
<samueldr> I don't see no reasons not to add an alias entry* when an attribute name changes
<samueldr> (here, alias entry, again may refer to a throw in aliases.nix)
<eyJhb> But would you then pend the other for removal?
<samueldr> I don't understand the question
<eyJhb> What I would do in this case, based on this is 1. `transmissionrpc` would be renamed to `transmission-rpc`, folders, files, packages, etc. 2. Create an alias for `transmissionrpc` which points to `transmission-rpc`, and then throw a message saying something like "package renamed, please use..." 3. Remove the alias after some time?
justanotheruser has joined #nixos-dev
<samueldr> no throws with aliases.nix if it's renamed
<samueldr> (I think)
<samueldr> there's a gap in policies regarding aliases though
<samueldr> we add the date it was aliased at though
srk has quit [Ping timeout: 268 seconds]
jonringer has joined #nixos-dev
srk has joined #nixos-dev
jonringer has quit [Remote host closed the connection]
<eyJhb> Eh... Is nixpkgs being screwy for anyone else?
<eyJhb> eyjhb@eos /tmp [1]> nix-shell -I nixpkgs= -p poetry2nix
<eyJhb> error: cannot coerce a set to a string, at /nix/store/q9zq73jnpgsqhwcr723q1mxfvwnjvvsx-master.tar.gz/pkgs/build-support/trivial-builders.nix:7:7
<eyJhb> Oh, might be the name
cole-h has joined #nixos-dev
<eyJhb> ehm samueldr , I forgot to add, this is a python module
<samueldr> ¯\_(ツ)_/¯
<eyJhb> Do we have any aliases here?
<samueldr> see previous response :)
<eyJhb> But would I then just add.. What to aliases.nix? This is the part that confuses me when we talk about `pythonPackages.tran...`
<eyJhb> Eh, I can see we just alias in python-packages.nix and leave a date
<eyJhb> Seems like my preferred method atm. for fixing stuff fast, ie. a wrong version, is to make a PR for it, and then pull in that PR to patch my nixpkgs.
<{^_^}> #112237 (by eyJhb, 2 minutes ago, open): transmission-rpc: 0.11 -> 3.2.2
<clever> --inhibit-cache Do not use /nix/store/bykwcin1idaz4cc15vm7bjkszv4rf004-glibc-2.27-armv6l-unknown-linux-gnueabihf/etc/
<clever> due to --help, i must ship an extra ~200mb of binaries, lol
<clever> on the itself
<samueldr> eyJhb: there's a few other aliases in python-packages, so... I still don't know, but you're not the first one to put one in
<eyJhb> Nope, so I hope it is OK
<eyJhb> Also, I think very few uses transmissionrpc