orivej has quit [Ping timeout: 260 seconds]
Sonarpulse has quit [Ping timeout: 240 seconds]
la_putin has quit [Ping timeout: 265 seconds]
la_putin has joined #nixos-dev
mbrgm has quit [Ping timeout: 268 seconds]
mbrgm has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar_ is now known as jtojnar
<la_putin> patchelf can resize executable files right?
<la_putin> like create holes in them but in a way that makes it still able to work
_rvl has quit [Quit: ZNC 1.6.5 - http://znc.in]
<gchristensen> interesting, what is that for?
<la_putin> who
<gchristensen> you, why would you want to make holes?
<la_putin> cus im trying to figure out how to move the address 0x400000 down so if it is occupied already it is free'd but in a way that allows the application itself to still run
<la_putin> at runtime
<la_putin> but i have no idea how i would do so
alunduil_ has joined #nixos-dev
<la_putin> as there is almost nothing about self-relocation on the internet
<gchristensen> I don't know much about this level of how things work, unfortunately, but reading the help page of patchelf it doesn't seem to do that
<la_putin> or at least nothing specifying exactly how to do so with a working example
alunduil has quit [Ping timeout: 276 seconds]
_rvl has joined #nixos-dev
yegortimoshenko has quit [Ping timeout: 255 seconds]
orivej has joined #nixos-dev
yegortimoshenko has joined #nixos-dev
yegortimoshenko has quit [Remote host closed the connection]
yegortimoshenko has joined #nixos-dev
el_putin has joined #nixos-dev
la_putin has quit [Read error: Connection reset by peer]
la_putin has joined #nixos-dev
ma27 has joined #nixos-dev
el_putin has quit [Ping timeout: 276 seconds]
el_putin has joined #nixos-dev
la_putin has quit [Read error: Connection reset by peer]
el_putin has quit [Read error: Connection reset by peer]
ma27 has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 240 seconds]
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
moredread[m] has quit [Ping timeout: 248 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
moredread[m] has joined #nixos-dev
FRidh has quit [Ping timeout: 276 seconds]
FRidh has joined #nixos-dev
simpson has quit [Ping timeout: 246 seconds]
goibhniu has joined #nixos-dev
simpson has joined #nixos-dev
FRidh has quit [Ping timeout: 260 seconds]
FRidh has joined #nixos-dev
vcunat has joined #nixos-dev
vcunat has quit [Client Quit]
la_putin has joined #nixos-dev
orivej has joined #nixos-dev
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
FRidh has quit [Ping timeout: 248 seconds]
FRidh has joined #nixos-dev
kgz has quit [Quit: WeeChat 1.9.1]
ma27 has joined #nixos-dev
kragniz has joined #nixos-dev
kragniz is now known as kgz
tv has quit [Ping timeout: 248 seconds]
tv has joined #nixos-dev
la_putin has quit [Read error: Connection reset by peer]
el_putin has joined #nixos-dev
<jtojnar> could someone please take a look at https://github.com/NixOS/nixpkgs/pull/33900?
<jtojnar> also would it be okay to make the "2.status: work in progress" label stand out more?
<jtojnar> IMHO the important labels should use more vibrant colors (#FF9800 would be nice here)
<jtojnar> and the "8.has" could probably be desaturated a bit
pie__ has quit [Ping timeout: 256 seconds]
<WilliButz> :q
el_putin has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 240 seconds]
jtojnar has quit [Read error: Connection reset by peer]
<copumpkin> anyone on linux want to try this for me?
<copumpkin> nix-build -K --check '<nixpkgs>' -A pythonPackages.netaddr.patches.0
<gchristensen> output path ‘/nix/store/cwq2b915rlsmnvpjx7gmc78g3mz6q8bf-2ab73f10be7069c9412e853d2d0caf29bd624012.patch’ has sha256 hash ‘0s1cdn9v5alpviabhcjmzc0m2pnpq9dh2fnnk2x96dnry1pshg39’ when ‘08rn1s3w9424jhandy4j9sksy852ny00088zh15nirw5ajqg1dn7’ was expected
<copumpkin> okay
<copumpkin> thanks!
<gchristensen> yep!
<copumpkin> I get the same thing
<copumpkin> on Darwin, the hashes match...
<gchristensen> neat ...
<copumpkin> and...
<LnL> hfs normalisation?
<copumpkin> I think the only difference is whitespace
<copumpkin> no idea why
<gchristensen> is it using fetchpatch?
<copumpkin> it's using fetchpatch
<copumpkin> LnL: no file paths involved at all
<copumpkin> it's a file hash, not a directory hash
<LnL> oh right
FRidh has quit [Remote host closed the connection]
<LnL> sounds like a bug then
<LnL> one of the tools used in fetchpatch must be giving slightly different output
<octe> should be able to diff the outputs?
<copumpkin> yeah, I did that and it only seems to differ in whitespace from what I can tell
<LnL> do you have a diff?
<copumpkin> oh actually it isn't just whitespace
<copumpkin> I'm assuming the temporary build directory has the final file
<copumpkin> that might not be true
<Dezgeg> how about a diff -u?
<Dezgeg> I can't read those legacy diffs :)
<copumpkin> yessir!
<LnL> :p
<copumpkin> it's updated on the ticket
<copumpkin> still not sure if the file I found in the -K directory is the final thing
<gchristensen> copumpkin: not to be annoying, but can you make the ``` block a ```diff block?
<copumpkin> BAM
<gchristensen> ah, now I can read it!
<copumpkin> oh so that's incorrect
<copumpkin> judging by the fetchpatch source, we filterdiff directly into $out
<copumpkin> so nothing in the temporary directory will show the final form
<copumpkin> but the filterdiff doesn't add the diff --git back
<niksnut> copumpkin: ok, I've pushed a slightly different fix for the --check issue
<copumpkin> omg I'm your biggest fanboi
<copumpkin> :P
<copumpkin> niksnut: hah, that's a cute fix :) I thought you meant to do so far more broadly
<niksnut> however, I fail to see how --check helps
<copumpkin> ?
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
jtojnar has joined #nixos-dev
<niksnut> the solutions I see are: 1) remove fixed-output derivations entirely; or 2) include the "url" in the output path calculation, and remove mirroring support in fetchurl
<gchristensen> what does #1 practically mean? #2 seems ... :$
<niksnut> it means that the output path of (say) a fetchurl call is computed like any other derivation
<niksnut> so any change to an input attribute would change the output path
<niksnut> they would still be allowed to access the network
<niksnut> and Nix would still check the output hash
<gchristensen> so it'd still pre-declare its hash?
<niksnut> yes
jtojnar_ has joined #nixos-dev
<niksnut> approach 1) implies 2) btw
<niksnut> we can't have a list of mirrors anymore, because adding any mirror would cause a world rebuild
jtojnar has quit [Read error: Connection reset by peer]
jtojnar_ is now known as jtojnar
<gchristensen> right, ouch
<copumpkin> what do you dislike about what I was suggesting with --check?
<copumpkin> it's sort of "out of band", which obviously I'd prefer not to be the case
<niksnut> we'd constantly be fetching thousands of tarballs
<niksnut> and it would be a post check, so you only discover after the fact that you may have been pwned
<copumpkin> well, it would only be as constantly as we'd be doing it if we removed FO altogether, right?
<copumpkin> so it seems like strictly less, if we can come up with a good UX
<gchristensen> I wonder if we can come up with a nicer solution here which includes the provided URL in the FO hash calculation instead
<gchristensen> so in the mirror case the hashed URL would be mirror://gentoo/distfiles/beast-0.7.1-guile-1.8.diff.bz2 that was hashed
<copumpkin> for that to work, URL would need to become some sort of primitive notion
<copumpkin> I think?
<gchristensen> I'm going to go ahead and put on my "I have no idea what I'm doing" hat :$
<copumpkin> so on the specific fetchpatch invocation
<copumpkin> it's weird that I can't reproduce it, even on macOS
<copumpkin> I mean, I can, but I can't by hand
<LnL> niksnut: do you think the behaviour of https://github.com/NixOS/nix/pull/1713 is ok, or should I change it?
<LnL> it works the same as the local store if you have access to a trusted user (include ~/.config/nix/nix.conf)
<copumpkin> our repo hit 700MB :(
<niksnut> eh, how did that happen?
<copumpkin> I dunno, I haven't done an object breakdown recently
<niksnut> LnL: don't know. It seems strange to make a distinction between overriden and non-overriden settings.
<niksnut> it shouldn't matter whether a setting comes from the config file or from the command line
<LnL> settings from the user config are also overrides
<niksnut> copumpkin: that's really bad, last I remember it was something like 200
<copumpkin> niksnut: yeah :)
<copumpkin> I don't think the autogenerated package sets are doing us any favors
<copumpkin> and was part of the reason I was trying to push for more pleasant IFD :P
<niksnut> yeah nixpkgs fundamentally doesn't scale
<LnL> the logic is the same as client -> daemon works IIRC
<copumpkin> I guess builtins.fetchGit gives us a slightly more pleasant answer
<copumpkin> but it's not great
<LnL> that's what I based it on
<Dezgeg> I guess we need to really write our own fetchpatch cleaner
<niksnut> or not use fetchpatch...
<niksnut> it has the same problem as fetchgit
<niksnut> namely you can't expect the output not to change
<copumpkin> why?
<niksnut> unless you define a canonical representation for patches
<copumpkin> the fundamental patch content shouldn't change on a git repo
<Dezgeg> an upgraded git could result in a different dif
<Dezgeg> diff
<niksnut> yeah
<niksnut> e.g. just the order of files in a patch
<copumpkin> but then our repo just gets even more junked up with patches that have nothing to do with us
<niksnut> how many lines of context
<copumpkin> and that people forget there, and are forever preserved in our history, and pollute our nixpkgs diffs, etc.
<LnL> isn't that exaclty what fetchpatch is for?
<LnL> thought it did something like that to make the diff stable
<Dezgeg> it attempts, yes
<copumpkin> LnL: in theory, but I guess it's a bit of a hack
<copumpkin> so we weren't able to upgrade that package due to it
<gchristensen> :$
<contrapumpkin> anyway, I guess the answer is to write a custom tool whose job is to standardize patches
<contrapumpkin> then patchutils can be unfrozen and we move on
<copumpkin> I still don't actually get what changed
<copumpkin> it seems like the hash is healthy in master again
<copumpkin> maybe Sonarpulse's change fixed it by accident?
<niksnut> copumpkin: after git gc --aggressive, .git is 247 MiB
<niksnut> still pretty bad
<copumpkin> urgh, yeah
<niksnut> the tree minus .git is 122
<copumpkin> a long time ago I ran some analysis over it and found that some of our other branches were carrying a decent amount of baggage
<copumpkin> but there was also a period, I think, where someone was committing binaries to the repo
<copumpkin> and I think those are in mainline history so we're stuck with them forever
<LnL> binaries? aaah
<copumpkin> that was my ancient thread on it
Sonarpulse has joined #nixos-dev
<niksnut> this is bad news for using builtins.fetchGit to get nixpkgs
<copumpkin> I'm a huge fan of https://rtyley.github.io/bfg-repo-cleaner/ + coordinated agreements that hashes will change :P
<copumpkin> preserve most history, get rid of stupid large objects, get rid of stupid binaries, etc.
<copumpkin> of course, hash changes, so coordination is needed :)
ckauhaus has joined #nixos-dev
<gchristensen> we could go back to SVN which handles this better ;)
<gchristensen> hmm Amazon has an internal build tool "similar to Nix"
<niksnut> yes, it's called Brazil
<gchristensen> neat
<niksnut> but that's all I know about it
<copumpkin> anyone have any idea why fetchpatch started working again after Sonarpulse's change to it?
<Sonarpulse> copumpkin: wow, I accidentally *un*broke something? :D
<copumpkin> oh it wasn't you
<copumpkin> sorry to get your hopes up :)
<copumpkin> I have no idea how it works
<Sonarpulse> copumpkin: I did change, though
<copumpkin> anyway, I'm going to push a fix to the hash in 17.09
<copumpkin> I know you did
<Sonarpulse> oh well :)
<copumpkin> I assumed that was why the hash got fixed
<copumpkin> now I'm just baffled
<copumpkin> see my latest comments on
<Sonarpulse> gchristensen: interesting tweak, but annoying to think they could get decent cabal/cargo integration first
<gchristensen> Sonarpulse: :)
FRidh has quit [Remote host closed the connection]
<Sonarpulse> copumpkin: weird
<copumpkin> oh never mind
<copumpkin> just needed backporting
<Mic92> I would not be surprised if not Nix, but a nix-like tool will win the popularity race.
<Sonarpulse> Mic92: not the most surprising, but we should be shamed
<Sonarpulse> with our huge head start
<Mic92> Well bigger companies, would just prefer amazons's implementation, because amazon is amazon.
goibhniu has quit [Ping timeout: 240 seconds]
<Sonarpulse> bgamari: btw https://nixos.org/nixos/nix-pills/index.html is the closest we have to the "maintainer" docs we have these days
<bgamari> mm
<bgamari> I saw that
jtojnar has quit [Quit: jtojnar]
<bgamari> they definitely helped
<bgamari> it's a shame they stopped when they did though
ckauhaus has quit [Remote host closed the connection]
<Sonarpulse> bgamari: well it was moved to nixos.org so it can be continued!
<gchristensen> anyone know of a way to check a git repo in to a git repo without it turning in to a submodule? :)
<srhb> I think the only alternative is subtrees.
<srhb> Short of actually duplicating files and history, of course.
<gchristensen> hrm, maybe I'll just rename `.git` to `git` prior to committing it, so git doesn't catch on to what I'm doing
<Sonarpulse> gchristensen: commit .git?!
<gchristensen> I'm trying to write an automatic test for ofborg which involves merging a branch in to another branch and running tests against it
<Sonarpulse> gchristensen: oh so this would be the dummy branches for the tests?
<gchristensen> right
<samueldr> tar (not compressed) the artifacts used for tests?
<gchristensen> that is another option, for sure
<Sonarpulse> I would make 3 dirs of "original, branch a, branch b"
<Sonarpulse> and make the git repo on the fly
<gchristensen> now that seems smart
ckauhaus has joined #nixos-dev
<Sonarpulse> perhaps my favorite programming mantra is "don't commit auto-generated stuff" / "VCS is not a cache"
<copumpkin> +1 on that :)
<copumpkin> niksnut: do you have any hypotheses on that build user leak in #1804? I'm happy to experiment with stuff, but don
<copumpkin> 't really understand the concurrency machinery in build.cc well enough to feel like I can do it without advice
ckauhaus has quit [Ping timeout: 268 seconds]
ckauhaus has joined #nixos-dev
<Sonarpulse> peti: I updated my PR to include 8.4.1
<Sonarpulse> oh but eval problems
<shlevy> thanks :(
<shlevy> niksnut: can you *please* ping me when you revert my work?
<gchristensen> ouch, shlevy
<Sonarpulse> it also broke eval
<gchristensen> double ouch
<Sonarpulse> (a better url)
<niksnut> alright, I'll revert
<copumpkin> the easy win in that space IMO
<copumpkin> is to stick it in a separate file
<copumpkin> when it was 4 lines, it was fine in all-packages
<copumpkin> I also dislike the fallback to fetchGit, FWIW
<copumpkin> but the private support seems simple enough
FRidh2 has joined #nixos-dev
<LnL> I kind of agree with the fetchgit fallback, I’ve seen a lot of people confused about that
<copumpkin> when I originally proposed a fetchSubmodules for fetchFromGitHub, I was thinking of a recursive github tarball fetcher that would barf on other submodule sources
<Sonarpulse> all this sounds good, lets just try to use PRs :) at the very least, get that ofborg check!
<Sonarpulse> copumpkin: I was just thinking of that now +1
orivej has quit [Ping timeout: 260 seconds]
jtojnar has joined #nixos-dev
<Sonarpulse> niksnut: 6060a6dd220bc62dcf48eece8e8f201b93cfeb52 can i nominate orivej to join me as *-wrapper codeowner?
<niksnut> Sonarpulse: go ahead
<Sonarpulse> niksnut: thank you
jtojnar has quit [Ping timeout: 240 seconds]
ckauhaus has quit [Remote host closed the connection]
goibhniu has joined #nixos-dev
ma27 has quit [Ping timeout: 276 seconds]
pie__ has joined #nixos-dev
jtojnar has joined #nixos-dev
orivej has joined #nixos-dev
goibhniu has quit [Ping timeout: 248 seconds]
michaelpj_ has joined #nixos-dev
<catern> woah woah woah what is this issue that requires one of "1) remove fixed-output derivations entirely; or 2) include the "url" in the output path calculation, and remove mirroring support in fetchurl"
<catern> I like fixed-output derivations as they are and was planning on major new features for them :(
MichaelRaskin has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
nixer has joined #nixos-dev
<copumpkin> it's a long story, I'll probably write up a github issue eventually about it
<catern> is there any github issue or email or anything about it? I don't see anything in the backlog
<catern> I have a different way to implement fixed-output derivations that could allow them to work even through whatever issue is happening
<copumpkin> not yet
<copumpkin> curious what your different way to implement them is though
<copumpkin> I'll try to write something up this weekend
<catern> Essentially it's just handling fixout derivations immediately at the user level, in the user's environment, outside the sandbox, instead of inside the nix-daemon with a sandbox. that can be done several ways, I think I've settled on having a proxy for the nix-daemon which intercepts requests to build fixed-output derivations and directly builds them and calls addToStore
<catern> and I'm implementing that now (implementing the nix-daemon protocol in Python...)
<gchristensen> that is very cool, catern
<copumpkin> catern: what's the goal of doing it that way?
<gchristensen> it _sounds_ like it'd allow for fetchgitPrivate but not scary
nixer has quit [Quit: Page closed]
<copumpkin> something about multi-user nix on darwin completely screws up my download progress reporting
<copumpkin> anyone else seen that?
<catern> gchristensen: right
<LnL> copumpkin: howso?
<copumpkin> it just gets completely mangled, presumably because it's trying to use terminal control characters to hop around and update things in place
<catern> copumpkin: fetchGitPrivate is one benefit, also my concrete benefit is that it would allow using user-specific proxies (like I have at my work)
<copumpkin> ah okay
<catern> copumpkin: could it be https://github.com/NixOS/nix/issues/1691 ?
<copumpkin> aha, you're right
<copumpkin> that's it
<copumpkin> niksnut ikwildrpepper : I think something on hydra might be b0rked, see https://hydra.nixos.org/jobset/nix/master#
<catern> I might fix that build output mangling thing soon as a side-effect of my investigations into nix-daemon stuff, so don't feel obliged to debug it
<copumpkin> oh, never mind, it's just a broken test I think
<LnL> weird, I've only seen that in a hydra log
zarel has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
FRidh2 has quit [Quit: Konversation terminated!]
jtojnar has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 260 seconds]
jtojnar_ is now known as jtojnar
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 276 seconds]
jtojnar_ is now known as jtojnar
zarel has quit [Quit: Leaving]
ckauhaus has joined #nixos-dev
gchristensen is now known as the
la_putin has joined #nixos-dev
ckauhaus has quit []
the is now known as gchristensen
michaelpj_ has quit [Ping timeout: 240 seconds]
Sonarpulse has quit [Ping timeout: 256 seconds]
michaelpj_ has joined #nixos-dev
<LnL> does import <nix/config.nix> work in hydra?
<LnL> do we?
michaelpj_ has quit [Ping timeout: 240 seconds]
<clever> LnL: i think it does
<clever> LnL: i'm using it on some hydra supported projects
<LnL> hmm no, what I was thinking of doing is probably a bad idea
<gchristensen> how're you doing, clever?
<clever> gchristensen: good, currently in lisbon, heading home on monday
<gchristensen> ahh is that why you've not been on much?
<clever> yeah
<clever> company wide meetup
<gchristensen> cool :) how is lisbon?
<clever> much warmer then NB canada
<gchristensen> :D
<clever> 14-15c on the average day, in the middle of winter
<gchristensen> a man can dream...
<clever> back home, the snow in the driveway was past my knees
<clever> here, the grass is still green
<clever> gchristensen: does this look like winter? https://imgur.com/a/xcLO5
<gchristensen> O.O