<gchristensen>
I'm having trouble with persistent deadlocks in ofborg tooling. anyone here have experience debugging these sorts of problems, and able to help me understand what is happening? I'm out of my league here :$
yegortimoshenko has quit [Remote host closed the connection]
yegortimoshenko has joined #nixos-dev
yegortimoshenko has quit [Remote host closed the connection]
yegortimoshenko has joined #nixos-dev
pie_ has joined #nixos-dev
pie__ has quit [Ping timeout: 268 seconds]
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
mbrgm has quit [Ping timeout: 240 seconds]
mbrgm has joined #nixos-dev
el_putin has quit [Read error: Connection reset by peer]
la_putin has joined #nixos-dev
yegortimoshenko has quit [Remote host closed the connection]
yegortimoshenko has joined #nixos-dev
<catern>
deadlocks in Nix code or in Rust?
<catern>
(I assume the latter) the best way to avoid deadlocks is to avoid sharing data between threads. rather than share a datastructure, have a dedicated thread which maintains the datastructure and which receives requests from other threads
ma27 has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
<ekleog>
hmm, I wondered, is there a reason why there is no way to get the full closure of a derivation in pure nix (ie. except exportReferencesGraph + perl pathsFromClosure + import-from-derivation)?
ckauhaus has joined #nixos-dev
JosW has joined #nixos-dev
FRidh has quit [Quit: Konversation terminated!]
ma27 has joined #nixos-dev
yegortimoshenko has quit [Ping timeout: 255 seconds]
yegortimoshenko has joined #nixos-dev
yegortimoshenko has quit [Remote host closed the connection]
FRidh has quit [Remote host closed the connection]
<gchristensen>
catern: I don't share any datastructures
orivej has quit [Ping timeout: 264 seconds]
<copumpkin>
globin , niksnut (or anyone else): regarding https://github.com/NixOS/nixpkgs/commit/3430b0e859ef75a2c3caa23c4c337e16f5094c0f#commitcomment-27127876, what's good practice here? I can split the aws-sdk-cpp backport into one commit and layer the new nixUnstable bump on top of it but then it's not atomic (meaning there's a broken state in between), or I can roll the two commits into one which makes it atomic but loses
<copumpkin>
ownership/succinctness. Otherwise I might be able to bump nixUnstable first (ISTR seeing some #ifdefs around the aws-sdk-cpp's changed interface but I don't recall) and then cherry-pick aws-sdk-cpp on top of it
* copumpkin
tries the unbumped aws-sdk-cpp against a new nixUnstable
<globin>
clever: if they are pushed at the same time it does not make much difference as the channel bump will always include both
<copumpkin>
yeah, just wondering if we cared about broken intermediate states for the purposes of git bisect or similar
<copumpkin>
anyway, the nix bump first seems to work
<copumpkin>
so I'll just do them in that order and then we're good regardless
<niksnut>
copumpkin: imho aws-sdk-cpp should *not* be backported because it's an incompatible change
<copumpkin>
oh :(
<niksnut>
it could be added as a separate version
<copumpkin>
sure, I can do that in a bit (I'd just bring back the old version, give the new one a new name, and then refer to the new one from nixUnstable)
<copumpkin>
niksnut: do you have guidelines for when builtins appear at the top level vs. just in the builtins attrset?
<Sonarpulse>
orivej: we need pkg-config wrapper I think?
<Sonarpulse>
wanna colab on that?
<Sonarpulse>
(i think i might have said so on this channel before but I forget :))
<Sonarpulse>
niksnut: do you have any interest in having `nix-build --arg foo.bar ...` (or its 1.12 equivalent) work?
<Sonarpulse>
(the missing feature there being an attr path, not single attr, as the first argument to --arg)
<Sonarpulse>
Dezgeg: what do you think about the withTLS one?
<Sonarpulse>
platform attr, that is
<Sonarpulse>
its just a hack for glibc right now
<Sonarpulse>
but I can imagine other things being made to use it --- I think it could be a "real" defaulted platform parameter rather than a glibc hack
<Sonarpulse>
basically, it would be great to pair with someone who actually knows about the platforms we're cross compiling for :) to triage what should be moved to the package and what should be kept
<Dezgeg>
hard to say if and what that's useful for
<Dezgeg>
I don't think anything besides arm/aarch64 has worked for a long, long time which makes it quite hard to say if it's needed
<Dezgeg>
maybe one could check what e.g. buildroot does with the tls flag to glibc
ma27 has quit [Ping timeout: 252 seconds]
<Sonarpulse>
Dezgeg: oh does built root try to encapsulate options for multiple packages?
<Dezgeg>
they don't seem to pass --with-tls to glibc at all, so presumably it's not very important to specify that flag
<Sonarpulse>
hmm ok
<Sonarpulse>
Dezgeg: link, out of curiosity?
<Dezgeg>
glibc changelog for 2011-09-11 states * configure.in: Remove --with-tls option.
<Sonarpulse>
Dezgeg: ah with withTLS gone we at least eval!
<Sonarpulse>
without using the example
taktoa has quit [Read error: Connection reset by peer]
<niksnut>
Sonarpulse: yeah, I think that would be very useful
MichaelRaskin has joined #nixos-dev
<copumpkin>
there's a patch for mono to make it work on a mac in master that I'd like to backport to 17.09. The patch also patches mono 5.4, which isn't in 17.09, so it isn't a clean patch unless I also backport 5.4. Is there any policy against backporting 5.4 to 17.09 as well? I wouldn't change the default top-level `mono =` obviously
<copumpkin>
(I also wouldn't object to getting 5.4 in 17.09 for its own sake, TBC)
<Sonarpulse>
niksnut: glad to hear it!
<Sonarpulse>
Dezgeg: https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/sparc/sparc64/elf/configure.in;h=b56b275a16687b0701bcf9acee946d51ed1c07cd;hp=4f759783580f3fca82309ef9b4eff926429122d2;hb=83cd14204559abbb52635006832eaf4d2f42514a;hpb=633f745dcad9c7324f56f8ef85ee9b460b1006e7 it might still be a thing
<Sonarpulse>
but lets try without
<Sonarpulse>
Dezgeg: next up is --with{,out}-fp
<Sonarpulse>
that is used in buildroot
<Sonarpulse>
can we cleanly derive from the abi of the config? (e.g. after or with lib/systems/parse.nix)
JosW has quit [Quit: Konversation terminated!]
ma27 has joined #nixos-dev
orivej_ has joined #nixos-dev
orivej__ has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
orivej_ has quit [Ping timeout: 240 seconds]
orivej__ has quit [Ping timeout: 240 seconds]
<copumpkin>
anyone else ever felt the urge for an "invert" parameter in fetchpatch?
<gchristensen>
dan, dan stop
<copumpkin>
:(
<gchristensen>
:)
<copumpkin>
hear me out though. Being able to apply patches is nice, which lets you add stuff to upstream projects
<copumpkin>
but what if an upstream project has some misfeature that breaks you in its commit history?
<MichaelRaskin>
Just find a patch-inverter-as-a-service and fetch through it
<copumpkin>
I want to revert just one patch
<copumpkin>
so I fetchpatch that commit, then invert = true
<copumpkin>
and bam we're golden
<copumpkin>
do such things exist?
<copumpkin>
it seems fairly easy to do within fetchpatch
<copumpkin>
maybe not if patchutils doesn't have a util for that
<copumpkin>
I assumed it would
<gchristensen>
it feels like a really narrow utility
<gchristensen>
but I see what you're saying
<copumpkin>
I can also just write a function to do it in nixpkgs, separate from fetchpatch
<copumpkin>
take a patch, flip it, return a patch
<copumpkin>
assuming the logic exists somewhere, since I won't write it myself
<clever>
Profpatsch: using either `docker run ... bash` or `docker exec .. bash i can get a shell, either in a fresh container, or within an existing container, then poke around
<clever>
Profpatsch: and also just iterating and adding ls commands to the startup script
<clever>
i believe it was exec, that could inject a second process&tty into an already existing container, along-side whatever the start script started
<Profpatsch>
clever: Ah, right, I don’t do bash in my containers.
<Profpatsch>
e.g. the postgres image I generate is even more minimal than the official stuff based on alpine.
<Profpatsch>
So I’ll have to play a bit.
<clever>
Profpatsch: i also temporarily add bash and coreutils in for debug
<Profpatsch>
Maybe refactor the bash code.
<clever>
the bash is more to just get an interactive shell so i can figure out whats happening
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-dev
ma27 has quit [Ping timeout: 240 seconds]
ckauhaus has quit [Quit: Leaving.]
<dtz>
Sonarpulse: risc and wasm?! Are you actually using nixpkgs for those yet, or just ensuring we support them in triples?
<Sonarpulse>
dtz: just the latter, for now
lopsided98 has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 256 seconds]
lopsided98 has joined #nixos-dev
Nadrieril has quit [Remote host closed the connection]