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@192.168.2.32
<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@192.168.2.32
<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:
<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/libgcc_s.so 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]
<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>
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)
<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>
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.