<{^_^}>
#122561 (by davidtwco, 6 days ago, open): cargo-bisect-rustc: init at 0.6.0
<supersandro2000>
*at the patch in the PR
maljub01 has quit [Ping timeout: 268 seconds]
maljub01 has joined #nixos-dev
philipp has quit [Ping timeout: 265 seconds]
philipp has joined #nixos-dev
orivej has joined #nixos-dev
<ryantm>
Has anyone tried making a Matrix/Element.io "space" for NixOS? I just tried making one and it seems to work, but I don't want to make another one public if someone already did.
<MichaelRaskin>
So is your approach better because no special mono?
<yorick>
well, it's not a supported configuration
<yorick>
but it does decrease the closure size if something else happens to use mono 6
<MichaelRaskin>
Ah hm, it's unfree anyway
<yorick>
yeah, arch has it in the AUR
<MichaelRaskin>
Well, that does remove the question of «is it too big _and_ too niche for Hydra»
<yorick>
it builds fast, being a binary package
<MichaelRaskin>
And it will not got to the cache, which is a plus given the context
<yorick>
it's just a bit tricky because you need a fhsuserenv and/or a wrapper or it will error in weird ways
<MichaelRaskin>
Hmm, why wrapper is not enough, BTW?
<yorick>
MichaelRaskin: it loads some .so with a signature check on it
<MichaelRaskin>
But you set LD_LIBRARY_PATH already?
<yorick>
yeah, I think you can use nixpkgs mono + LD_LIBRARY_PATH wrapper (my solution) or picoscope's mono (needs buildFHSuserenv) + LD_LIBRARY_PATH wrapper (their solution)
<yorick>
maybe you don't need the wrapper if you're already doing fhsuserenv
<yorick>
I don't really see the downsides to merging as-is and then fixing the mono with the picoscope v7 release
<supersandro2000>
you are grabbing 15 debs from a server. This is not really the nixpkgs way.
<MichaelRaskin>
Oh, Nixpkgs has a way? That's new. And unfortunate
<yorick>
mainly because it doesn't implement support for the hardware I don't have
<yorick>
supersandro2000: where else would you put this package, NUR?
kini has quit [Remote host closed the connection]
<MichaelRaskin>
If it is a deb per model, and it is promised that the approach is uniform, I prefer grabbing all of them
<MichaelRaskin>
I do like the wrapping approach better with yorick's expression, though
<yorick>
grabbing them all might be bad for closure size, might be useful to have a supportedModels argument
<supersandro2000>
MichaelRaskin: thats not new. We are building from source and using already packaged libraries where ever possible
<MichaelRaskin>
That's true…
kini has joined #nixos-dev
<yorick>
if there were a source I'd build from it
<supersandro2000>
yorick: yeah, NUR would be a good fit for the current state
<MichaelRaskin>
supersandro2000: first is true but irrelevant
<MichaelRaskin>
second is kind of complicated if upstream does weird things
<MichaelRaskin>
Actually, first is also not really true, but that's another story
<MichaelRaskin>
If it was wrap-with-mono6 and pick-supported-models from the full list I guess I would just merge it.
<yorick>
fine, you've convinced me
<yorick>
I'll fix it
<MichaelRaskin>
I am definitely not merging an expression that is not even PR-ed yet (even though I like it modulo model list)
<supersandro2000>
also updating that looks not straightforward
<MichaelRaskin>
Doesn't matter for the current PR
<MichaelRaskin>
It brings most of the stuff with it anyway
<MichaelRaskin>
So it should not break quickly, and when the next version comes, let those who have read PicoScope docs figure out what's going on
<yorick>
yeah, best way to get the versions is inspecting the deb
<yorick>
(or just scraping the http directory listing)
<supersandro2000>
it does matter for the PR. Introducing a new package which is already hard to manage from the beginning with no hope of getting better is not ideal and if there is a better way we should explore it.
<yorick>
but it seems that people care enough to do so
<yorick>
which is great, because it saves me time
<MichaelRaskin>
It cannot even break on Hydra because it is unfrtee
<MichaelRaskin>
People who have never touched PicoScope HW will not do a good job updating that anyway
<yorick>
supersandro2000: excellent
<yorick>
I'll at least move to a sources.json file
orivej has joined #nixos-dev
<yorick>
hm, gtk-sharp-2_0.override { mono = mono6; } broke a while ago
<yorick>
why don't I use mono5?
ghuntley has joined #nixos-dev
<dotlambda>
For #123496, I'm trying to figure out why gst-plugins-bad depends on ffmpeg_3. But `nix why-depends -f . gst_all_1.gst-plugins-bad ffmpeg_3` yields no result. Does someone have an idea?
<domenkozar[m]>
what's the best guide that we have on cross compilation with nix?
<domenkozar[m]>
seems like the wiki is pretty good
<qyliss>
I was about to say the wiki
<qyliss>
hopefully all somebody needs to know is "use pkgsCross.<platform>"
mjlbach has quit [Ping timeout: 245 seconds]
bitonic has quit [Ping timeout: 245 seconds]
Dandellion has quit [Ping timeout: 276 seconds]
LinuxHackerman has quit [Ping timeout: 245 seconds]
ma27[m] has quit [Ping timeout: 245 seconds]
thefloweringash has quit [Ping timeout: 276 seconds]
veleiro has quit [Ping timeout: 245 seconds]
siraben has quit [Ping timeout: 245 seconds]
Dandellion has joined #nixos-dev
thefloweringash has joined #nixos-dev
mdlayher has quit [Ping timeout: 245 seconds]
angerman has quit [Ping timeout: 260 seconds]
Guest76370 has quit [Read error: Connection reset by peer]
Guest76370 has joined #nixos-dev
emilazy has quit [Ping timeout: 245 seconds]
betawaffle has quit [Ping timeout: 260 seconds]
ma27[m] has joined #nixos-dev
siraben has joined #nixos-dev
veleiro has joined #nixos-dev
mjlbach has joined #nixos-dev
bitonic has joined #nixos-dev
LinuxHackerman has joined #nixos-dev
mdlayher has joined #nixos-dev
emilazy has joined #nixos-dev
Guest76370 has quit [Ping timeout: 276 seconds]
betawaffle has joined #nixos-dev
<domenkozar[m]>
heh fails on perl
<domenkozar[m]>
that's as per my expectations :D
Guest76370 has joined #nixos-dev
angerman has joined #nixos-dev
<qyliss>
domenkozar[m]: what arch to/from?
betawaffle has quit [Max SendQ exceeded]
<qyliss>
(assuming Linux is both host and build?)
<domenkozar[m]>
from: 64bit linux to: pkgsCross.aarch64-multiplatform.git
<qyliss>
from x86_64?
<domenkozar[m]>
yeah
<qyliss>
surprised that's failing tbh
betawaffle has joined #nixos-dev
<qyliss>
I'd expect that to be a pretty well tested path
<domenkozar[m]>
me too :/
<qyliss>
(and I cross-compiled perl to NetBSD this morning with only NetBSD-specific changes, so would have expected Linux to work fine)
<domenkozar[m]>
it's not perl itself, but one of the core libs
<qyliss>
do you want to fix it? I've been looking for a distraction so would be happy to take a look if not.
<qyliss>
(and already have a bunch of perl context loaded in my brain from fixing it for NetBSD earlier)
<domenkozar[m]>
it would be great if you can take a look, I wanted to get a feeling how far I get building the basic tools
<qyliss>
I'd expect perl to usually work
<domenkozar[m]>
(never used Nix for cross-compiling)
<qyliss>
hopefully you've just caught it at a bad time
<thibm>
domenkozar[m]: I just successfully built pkgsCross.aarch64-multiplatform.perl
<domenkozar[m]>
then I was just unlucky on master
cptchaos83 has quit [Remote host closed the connection]
htr has quit [Quit: working hard]
<thibm>
But git does not cross compile. I was on 4e82cf91
<domenkozar[m]>
ah yeah, it's not perl itself but a perl lib.
<thibm>
ok
cptchaos83 has joined #nixos-dev
<sterni>
domenkozar[m]: you could always try gitMinimal maybe it doesn't have that particular dependency
htr has joined #nixos-dev
NULLx760 has joined #nixos-dev
<qyliss>
ah yeah builder for '/nix/store/9sp1mnaxgk76ij1z556cq237lq1wacxa-perl5.32.1-Module-Build-aarch64-unknown-linux-gnu-0.4231.drv' failed with exit code 2
supersandro2000 has quit [Killed (verne.freenode.net (Nickname regained by services))]
supersandro2000 has joined #nixos-dev
pingiun has quit [Quit: Bye!]
ris has quit [Remote host closed the connection]
<sterni>
since the stagin(-next) merge action got stuck on merge conflicts since yesterday we should probably merge staging-next into staging manually as well?
pingiun has joined #nixos-dev
dongcarl7 has joined #nixos-dev
<qyliss>
sterni: sounds right
fzakaria_ has joined #nixos-dev
ekleog_ has joined #nixos-dev
ris has joined #nixos-dev
NULLx76 has quit [Quit: Ping timeout (120 seconds)]
dongcarl has quit [Quit: Ping timeout (120 seconds)]
ekleog has quit [Remote host closed the connection]
fzakaria has quit [Quit: No Ping reply in 180 seconds.]
dongcarl7 is now known as dongcarl
NULLx760 is now known as NULLx76
<sterni>
seems like we'll have to live with no automation until the end of this staging-next cycle
<qyliss>
sterni: won't it start working again once the conflicts are fixed?
<sterni>
jon did a manual merge yesterday and there are still conflicts
bennofs__ has quit [Read error: Connection reset by peer]
bennofs_ has joined #nixos-dev
cole-h has joined #nixos-dev
<Ericson2314>
thefloweringash: so to be clear, you said the sanitizers ought to work but didn't?
<thefloweringash>
They should work right? They build ok on x86_64-darwin, but seem to fail in cross due to "compiler-rt-11.1.0.src/lib/fuzzer/FuzzerDefs.h:14:10: fatal error: 'cassert' file not found"
<thefloweringash>
fail in x86_64-darwin -> aarch64-darwin, that is
<thefloweringash>
IIUC the two builds are quite different in the branch. x86_64-darwin is building compiler-rt with a full clang/llvm 7 toolchain, but x86_64-darwin -> aarch64-darwin is building compiler-rt with nearly bare clang and libSystem.
<Ericson2314>
thefloweringash: ah it wants c++
<Ericson2314>
thefloweringash: So maybe I should put on the cc-wrapper whether C++ is supported
<Ericson2314>
or hmm well I suppose this is STL not the language itself
<sterni>
may be due to case insensitive file system?
<andi->
We had similar issues with buildRustPackage a while ago. Building the vendor bundle on aarch64 would always be different from x86_64. Sometimes including a dot folder.. sometimes not...
<andi->
Also ends up weird if the output of the vendor command depends on the arch but you only ever plug one into the derivation. Building something with a different set of dependencies than those that it should receive.. joy..
<sterni>
that's what you get for using fixed output drvs for such stuff I guess :p
<andi->
Yeah, using them like that is an ugly hack.
<gchristensen>
can you identify any major problems this might introduce for stable users?
<ma27[m]>
gchristensen: https://wiki.qemu.org/ChangeLog/5.2#Incompatible_changes mostly. I mean, after reading through it, it seems OK to me. OTOH given its length I'm not 100% confident anymore that it's the right choice and thus I'd like to get a second opinion first :)
<gchristensen>
only BC breaknig change is something is deprecated, but not removed
<ma27[m]>
omg, I misinterpreted this as big block and was confused because it doesn't seem really breaking to me!
<ma27[m]>
and that's why I wasn't confident enough to decide this on my own because I thought I was misunderstanding something!
<ma27[m]>
ok then it should be good to go!
rajivr has quit [Quit: Connection closed for inactivity]
<ScottHDev>
You might ask why I create a custom python env for building, and this is because the test scripts run some python scripts directly with python command which doesn't seem to use PYTHONPATH
<Mic92>
jonringer: supersandro2000 should we give stephank eventually the commit bit?
<Mic92>
I saw a lot of PRs from him lately
<jonringer>
I mean he has done 100+ fixes recently
<jonringer>
but I think once someone reviews other PRs and gives guidance that you would expect from someone with a commit bit, I'm apprehensive about handing it out
<gchristensen>
how is stephank's reviews?
<gchristensen>
+1
<sterni>
what about vm-test-run-boot-bios-usb which has been failing for trunk-combined:tested btw?
<ScottHDev>
Oh, nevermind, I'm supid, I just had to propagate PYTHONPATH threw subprocess.Popen
<jonringer>
I think he wants to see nixpkgs succeeds, and he getting a lot of brownie points with me. Especially since darwin is severely lacking contributions recently. But I think those two tings are separate
<jonringer>
Mic92: for the qemu PR, I'm good with it :)
<jonringer>
I was actually running a nixpkgs-review on it as you merged it
<Mic92>
I guess I have a lower bar for the commit bit if it covers areas that are less well covered.
<Synthetica>
Could someone look at #121887 ? Been open for a while now, mostly looking for someone to double-check the update script.
<MichaelRaskin>
I think that if a person is working on a less-covered area and plans to continue concentrating there, it _is_ a good idea to give commit access with slightly lower expectations
<jonringer>
I mean, if he sticks around and continues to help with darwin, and able to test other PRs. I think that's a definite possibility
<MichaelRaskin>
Maybe even openly telling the person.
<MichaelRaskin>
There are areas where we have problems aligning expectations of too many people doing something, and there are areas where this problem is not acute because there are no those too many people
<MichaelRaskin>
Moving forward in the first area surely needs more experience just to have an idea of the range of opinions…
<jonringer>
I mean, I'm fine with specialization.
<MichaelRaskin>
I'm kind of even in favour on it! It makes it easier to understand who is the best person to ping
<rmcgibbo[m]>
Is stephank on IRC? Someone could ask what his interests/plans are.
<gchristensen>
they're stephank in #nix-darwin
<samueldr>
specialization is dangerous
<samueldr>
suddenly you're "that guy"
<samueldr>
who's pinged for "that thing"
<gchristensen>
whew
<samueldr>
:)
<samueldr>
what I mean to say is: specialization is desired... but maybe the person should know they're being type cast into being that guy for that thing :)
pbb has quit [Ping timeout: 260 seconds]
<MichaelRaskin>
samueldr: and given advice how not to end up pinged for some other thing they just merged once?
<MichaelRaskin>
(three rewrites ago)
<samueldr>
speaking from experience?
<samueldr>
(I wouldn't know what advice to give for that!)
<MichaelRaskin>
Technically speaking I never got around tp remove myself from maintainers of some Gnome stuff…
<lukegb>
samueldr: aren't you the arm guy
<MichaelRaskin>
(but sometimes, although rarely, pinged for niche stuff I only merged a couple of times)
<samueldr>
👀
mikroskeem has joined #nixos-dev
<gchristensen>
lukegb: it is important to learn from our mistakes