Acou_Bass has quit [Ping timeout: 260 seconds]
Acou_Bass has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 258 seconds]
orivej_ has quit [Ping timeout: 240 seconds]
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
Acou_Bass has quit [Quit: ZNC 1.7.5 - https://znc.in]
Acou_Bass has joined #nixos-aarch64
<matthewbauer> On my raspberry pi😁
<matthewbauer> $ uptime
<matthewbauer> 22:24:01 up 18402 days 3:23, 1 user, load average: 0.00, 0.00, 0.00
<gchristensen> :o :D
<samueldr> bad clock?
<matthewbauer> The rpi doesn't have a hardware clock
<samueldr> yeah
<matthewbauer> So at boot time the time starts at Dec 31 18:00:00
<samueldr> I would have assumed "uptime" was from a kind of monotonic clock
<matthewbauer> i wonder if there's a way to fix it
<matthewbauer> the clock is set eventually by systemd-timecsync, just not immediately
<samueldr> I guess you'd need the clock to be set *before* the kernel boots, do you really want to push that into the bootloader?
<samueldr> you'd need an external source, so networking in the bootloader only to fix that :/
<matthewbauer> i think if it happens in /init it would be soon enough: https://www.raspberrypi.org/forums/viewtopic.php?t=200385#p1615915
<matthewbauer> maybe https://github.com/NixOS/nixpkgs/pull/74842 would fix it
<{^_^}> #74842 (by ElvishJerricco, 24 weeks ago, open): [WIP]: initialRamdisk: Use systemd for initrd's /init
<elvishjerricco> matthewbauer: I have absolutely no idea if that PR would work on aarch64 :P
<samueldr> eh, aarch64's not much different in the end once the system is up
<samueldr> getting to the kernel is different, but kernel onward it's pretty similar
<hexa-> missing rtc can be a messy business
<gchristensen> going down ...
<hexa-> race condition when bootstraping ntp/dnssec
<hexa-> unbound + chrony/timesyncd on an rpi
<gchristensen> uh oh
<gchristensen> oh, phew.
<gchristensen> uh oh
evils has quit [Quit: Lost terminal]
<gchristensen> wtf
<gchristensen> anyone 'round?
<samueldr> what did you do?
<samueldr> :)
<gchristensen> `curl https://netboot.gsc.io/nix-community-aarch64/netboot.ipxe` does this work for you?
<samueldr> got an ipxe script yeah
<gchristensen> hm
<gchristensen> Could not boot image: HTTP 5xx Server Error (http://ipxe.org/1d0c6598)
<samueldr> okay, from the source it really looks like a 5xx error
<samueldr> do you see something in your logs?
<samueldr> like, from packet?
<samueldr> do note that I'm ipv4 only
<samueldr> if relevant
<gchristensen> nothing, heh
<gchristensen> hm
<gchristensen> I think it was a firmware thing
<samueldr> ugh, firmware
<gchristensen> since it just booted okay
<gchristensen> [grahamc@aarch64:~]$ uname -a
<gchristensen> Linux aarch64.nixos.community 5.4.41 #1-NixOS SMP Thu May 14 05:58:30 UTC 2020 aarch64 GNU/Linux
<gchristensen> [grahamc@aarch64:~]$ nixos-version
<gchristensen> 20.03post-git (Markhor)
<gchristensen> upgraded!
<gchristensen> way past my bed time :)
<gchristensen> thanks for the check, samueldr
<samueldr> 'night!
thequux[m] has quit [Ping timeout: 260 seconds]
thequux[m] has joined #nixos-aarch64
evils has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
<dan_b`> 23:12 < samueldr> though I have some hopes that it's as dumb as stripping │
<dan_b`> 23:12 < samueldr> and use symbols in the current executable rather than │dlopening │
<dan_b`> once upon a time that was supported
<dan_b`> according to dlopen(3) manual page "If filename is NULL, then the returned handle is for the main program.
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
zupo has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
<dan_b`> well, I built *something* that's fully cross-compiled
<dan_b`> unfortunately it doesn't have networking and doesn't have /dev/ptmx (which adb needs, apparently)
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has quit [Ping timeout: 258 seconds]
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
<dan_b`> oh, maybe it does have networking and I need to be running a dhcp server on my rndis
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 252 seconds]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #nixos-aarch64
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 260 seconds]
dongcarl has quit [Quit: Ping timeout (120 seconds)]
dongcarl has joined #nixos-aarch64
alp has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alj[m] has joined #nixos-aarch64
<alj[m]> Hello! I'm having a peculiar problem with my armv7l box. Apparently my garbace collector is cleaning up the toolchain needed for running `nixos-rebuild` which leads to me having to rebuild gcc, perl, python and the like for the second time in 2 days. On my other (x86 64) NixOS system the garbage collector does NOT shred half the system. Can anyone help me figure out whats going on or at least give me a good workaround?
<alj[m]> For now I'm disabling GC but thats not really a future-proof solution.
<clever> alj[m]: if you know the path to that gcc, you can just run `nix-store -r /nix/store/gcc --add-root ./result --indirect`
<clever> alj[m]: it will then behave as-if you had just ran nix-build on the expr, and keep it until result is deleted
<clever> nix kind of expects things like gcc to come from a binary cache, and things get costly when it doesnt
<alj[m]> and the ./result is gonna be the root keeping it alive? and i need to keep that file somewhere save?
<alj[m]> clever: and is knowing the .drv enough?
alp has quit [Ping timeout: 260 seconds]
alp has joined #nixos-aarch64
<clever> alj[m]: you can run nix-store -r on the drv as well
<clever> alj[m]: that will build it, then symlink the result of the build
<alj[m]> thanks
<clever> and result itself cant be moved once made, or nix will think it was just deleted
<alj[m]> gotcha
<alj[m]> can i just vent for a second and say that this is an utterly stupid problem? damn.
<clever> nix expects to be able to just download it from a cache, i tend to configure my hydra to pre-build things for me
<clever> hydra also roots the build-time closure, instead of the runtime closure, so it cant gc a gcc
<alj[m]> can you guide me to set up an arm hydra sometime soon-ish?
<xdej> alj[m]: do you share a tarball of your armv7l files ?
<xdej> I would like to start on armv7l but croc-copilation failed.
<xdej> croc-copilation=cross-compilation
<clever> alj[m]: youll want to start with something like this, it can run on any arch, so if you have an x86 server handy, slap it there
<alj[m]> xdej: You mean if i share my binaries, so you can skip the long build process? If you tell me how i can share them I will set that up as soon as i find time
<alj[m]> clever: will take a look at that thanks so much mate
<simpson> xdej: Once you're set up, you should be able to reproduce a build environment just by running Nix. It is unfortunate that we don't have a binary cache for everything.
<alj[m]> f***, another day lost to rebuild the same damn binaries...
<simpson> alj[m]: FWIW this is part of why I don't have automatic GC enabled on one of my build machines. It is less hassle to run GC manually once a quarter than to have automatic GC interrupt work.
<alj[m]> simpson: what do you mean "once you're set up" ?
<simpson> Like, with Nix. Or maybe there's more context.
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-aarch64
<alj[m]> well if i understood correctly, the issue hes describing (or alluding to) is that he cant get cross building to work and therefore want to otherwise jumpstart his armv7l installation by using my binaries instead of having to wait 3 days or longer on the poor little processor to do all the work.
<simpson> Yes. Nix's security model means that, while there's no practical obstacles to doing this P2P, at scale we'd want the builders to be trusted. (Reminder that "to trust" means "to be vulnerable to")
zupo has joined #nixos-aarch64
<alj[m]> fair
<alj[m]> i wouldnt necessarily trust a random person from IRC with my binaries
orivej_ has quit [Ping timeout: 260 seconds]
<xdej> simpson: "to trust" means "to be vulnerable to": I certainly understand that. All I can say is that Raito_Bezarius recommended #nixos-aarch64, so I am looking for (1) tarballs of people here (2) Raito_Bezarius to tell me if he trusts you.
<xdej> alj[m]: "having to wait 3 days or longer on the poor little processor to do all the work." : wait I learn something here. Can you tell me where I can find that ?
<Raito_Bezarius> I trust typed lambda calculus
<xdej> I do not mind waiting 3 days or longer.
<Raito_Bezarius> I guess alj[m] is doing compilation on the system
<Raito_Bezarius> That requires that you already have Nix at least on one of these machines
<alj[m]> Oh yes I am. I can tell you how i got a basic system going
<xdej> Raito_Bezarius: read things here from one hour ago.
<alj[m]> it was a struggle, but hopefully you have a board thats a little nicer to you
<alj[m]> xdej: my first step was to download the sd-nixos installer image mentioned on the "NixOS on ARM" page in the wiki
<alj[m]> with a bit of luck and reading you might get your system off the ground and have it build all you need, granted it will probably take a long long time
<xdej> alj[m]: the part about armv7l of https://nixos.wiki/wiki/NixOS_on_ARM ?
<alj[m]> yes. https://nixos.wiki/wiki/NixOS_on_ARM#Getting_the_installer here you can find links to installer images
<xdej> Thanks.
<alj[m]> no problem, i hope you find a good installer without bugs
<alj[m]> i had the problem that i downloaded my installer ages ago and it was on version 19.03 which meant a big rebuild when i switched to version 20
<alj[m]> just read carefully
ninjin has quit [Remote host closed the connection]
ninjin has joined #nixos-aarch64
vika_nezrimaya has joined #nixos-aarch64
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
<gchristensen> btw adisbladis, cole-h, LnL, and zimbatm can all push the "deploy" button for the community builder
<cole-h> o/
<gchristensen> oh and samueldr of coures!
<simpson> Is there a central page for what the community builder builds? Like, which arches, which packages?
<simpson> Even better, is there a ,hint?
<gchristensen> none of that
<gchristensen> see the link in the readme: github.com/nix-community/aarch64-build-box
<gchristensen> er
<gchristensen> in the /topic
<simpson> Oh, nice. Walked right past it.
<gchristensen> I would like to improve the trust model and only allow users to nix-copy-closure a `.drv` (don't need to be a trusted user) and `nix-build`
<LnL> I'm pretty sure you don't need trust for that
<LnL> since drvs are fixed output
<gchristensen> exactly
<gchristensen> instead right now where everyone is trusted
<LnL> could even restrict access so it's build only
<LnL> command="nix-daemon --stdio" <key> + nix-build --store ssh-ng://builder
<gchristensen> heck yes!
dongcarl has quit [Quit: Ping timeout (120 seconds)]
dongcarl has joined #nixos-aarch64
telent has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
telent has quit [Ping timeout: 256 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<hexa-> samueldr: updated my rpi4 to 5.6.10 and guess what, wlan seems stable
<hexa-> so the driver is just shit way back in 4.19
<ashkitten> gchristensen: still, i wouldn't call it trusted if it's possible for people to execute arbitrary code (sandboxed or not)
<ashkitten> oh, you mean trusted by nix?
<gchristensen> yeah, it just takes it from "you can literally upload compromised builds without even thinking" to "you'd need to use a kernel vuln"
<ashkitten> oh right
alp has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
<samueldr> does those restriction mean the inputs are loaded from the user's system?
<samueldr> (those theorical restrictions)
<gchristensen> only content addressable things could be sent (drv files, fixed-output derivations, local sources referred to by path syntax)
<samueldr> because the only reason I ssh into the server is because my upload speed is so bad it'd be faster to build on an underpowered aarch64 device than wait for the upload
<samueldr> I want nothing to be sent :)
<samueldr> all fetched
<samueldr> well, only .drv I guess
<gchristensen> you'd want to pass
<gchristensen> nix-copy-closure --to --gzip --use-substitutes samueldr@aarch64.nixos.community ./my.drv
<samueldr> I'll have to try and remember
alp has joined #nixos-aarch64
dongcarl has quit [Quit: Ping timeout (120 seconds)]
dongcarl has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
<alj[m]> bro, if only i had known about packet.com and grahamcs nix-builder repo (specifically this PR: https://github.com/grahamc/packet-nix-builder/pull/2 )
<{^_^}> grahamc/packet-nix-builder#2 (by thefloweringash, 15 weeks ago, open): armv7l-linux build vm for aarch64-linux machines
<gchristensen> interesting, I'm surprised that PR isn't merged, sinceit is already actually integrated in to the repo
<alj[m]> the prices are amazing, 50 cents per hour on the c1 arm machine? thats nice for starting an arm system
<gchristensen> super nice
<alj[m]> and i just looked up this "spot market" thing you mentioned in the Readme. I can get time on the machine for even cheaper?! thats omega-nice
<alj[m]> (also its kinda hilarious that I have to auth to get the current spot market prices, like wtf :D )
<gchristensen> hehe
<gchristensen> one sec alj[m]
<alj[m]> you are a genius
<gchristensen> :)
<alj[m]> c1.large.arm is hecking cheap with spot market o_o
<gchristensen> a lot of cores, too
<gchristensen> not grea cores, but it makes up for slowness in quantity
<alj[m]> why did nobody tell me this before i built all of this on my stupid little board ? xD
<gchristensen> hehehe
<alj[m]> I'll remember this exists if I ever build a big arm thing again
<alj[m]> also with this existing i wonder why we're not having at least a limited binary cache for arm
<alj[m]> is it not about the building but about the disk space/resources to serve the cache?
<samueldr> alj[m]: for aarch64, we have a good coverage
<samueldr> for arm (32 bit) there are issues, mainly, that the firepower to build doesn't exist
<alj[m]> well apparently we can build on packet machines for relatively cheap
<alj[m]> *could
<samueldr> not armv7l :)
<samueldr> the available machines can't execute in 32 bit mode
<samueldr> and there is no usable "personality" on the kernel like there is for i686/x86_64
<samueldr> so builds forced in 32 bit mode on that kind of hardware get ambient impurities of the aarch64ness of the CPU
<alj[m]> then am i reading the pull request above wrong? doesnt it enable you to "emulate" armv7l on the aarch64 machines?
<samueldr> and they sometimes break in "fun" ways
<samueldr> it's on a kind of machine that is not available
<samueldr> we have one (1) of them
<alj[m]> so you're saying its kinda possible, but not stable
<samueldr> that machine can execute in 32 bit mode
<samueldr> so the qemu VM actually runs in 32 bit mode entirely
<samueldr> if there was a large(r) pool of that machine type it would be possible
<alj[m]> to get this straight. I can't use the packet.com c1.large.arm, which provides bare-metal aarch64, in armv7l mode to build packages for my armv7l machine because of stability issues?
<alj[m]> *using grahamc's cool iPXE setup
<gchristensen> if I remember correctly, c1.large.arm, an aarch64 machine, does not have CPU support fro armv7 instructions
<samueldr> I'm not sure which one the c1 is, but IIRC the 32 bit VM simply won't work when the CPU doesn't support 32 bit mode
<alj[m]> > if I remember correctly, c1.large.arm, an aarch64 machine, does not have CPU support fro armv7 instructions
<alj[m]> there we go. gotcha.
<{^_^}> error: syntax error, unexpected ',', expecting THEN, at (string):310:24
<alj[m]> back to building on my board like a pleb i guess
<gchristensen> c2.large.arm does have CPU support for armv7 instructions
<alj[m]> aha! perfect. a little more expensive, but still great
<samueldr> if you have an aarch64 sbc, using the same kind of qemu VM can be done
<samueldr> most sbcs will support 32 bit
<samueldr> (and newer aarch64 sbcs are likely to be faster than 32 bit sbcs)
<gchristensen> and have enough ram to chew gum and walk at the same time
<alj[m]> i can't really switch out my chips... it was an oversight when buying and i would've loved to get aarch64, but I'm here now
orivej has quit [Ping timeout: 246 seconds]
<alj[m]> so again, what I'm getting from this is: Its possible to build armv7l stuff on those buildfarm servers.
<samueldr> as long as the server supports 32 bit execution, yes
orivej has joined #nixos-aarch64
<alj[m]> sick.
<samueldr> (sometimes it's hard to actually *know* if it is)
<alj[m]> I'll keep that in mind. Currently I don't plan to actually use this. At the moment (after the build toolchain is done compiling and such) I'm actually okay for the time being. no plans to build lots of armv7l packages. But if i ever decide to do something big this is good to keep in mind tho
dongcarl has quit [Quit: Ping timeout (120 seconds)]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej_ has joined #nixos-aarch64
dongcarl has joined #nixos-aarch64
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<dan_b`> what's the wifi device called in linux on a qualcomm chipset?
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<samueldr> it's varied
<samueldr> I really don't know yet how to know *for sure*
<samueldr> but check on a running system if you have cnss-daemon running
<samueldr> if so you have something I have planned to figure out later on, started and I need to work on something else first before
<dan_b`> 80 ? S 0:00 [wcnss_smd_trans]
<dan_b`> bash-4.4# ps awwx|grep cnss
<dan_b`> 1661 pts/0 S+ 0:00 grep cnss
<dan_b`> 360 ? S 0:00 [irq/518-wcnss]
<dan_b`> guess that's "no"
<dan_b`> unless you mean a running android system
<samueldr> running _android_ system :)
<samueldr> though seeing wcnss here is a clue I think
<dan_b`> really need to root my new android phone before I get so much stuff installed on it that it becomes painful
<samueldr> dan_b`: ^ pretty sure you have wcnss since you have kernel process (I think?) named wcnss
<samueldr> I *think* it's likely it should be set at the SoC level, but until I get proper proof I'll have it enabled at the device level
<samueldr> you'll need to figure out a source for the files
<samueldr> The Muppets could help
<dan_b`> thanks
<dan_b`> bash-4.4# echo 1 > /dev/wcnss_wlan
<dan_b`> seems to have hung my adb session
<samueldr> yeah
<samueldr> it'll hang for like a minute
<samueldr> if it can't find the firmware files
<samueldr> you're 99% likely to be missing the firmware files :)
<dan_b`> ah yes, that would explain it :-)
<dan_b`> *probably* I should first find out why I can't read from /dev/random and then i could at least ssh in over the usb cable
<samueldr> wow, nice, that would be the second wcnss device available, thus confirming whether I built wrong abstractions and assumptions
<samueldr> just saying, though not useful here, the progression for qualcomm wifi is wcnss, something I forgot the name, then qcacld with cnss-daemon
<dan_b`> my impression so far is that potter is addison with usb micro instead of usbc
<samueldr> I *think* the thing I forgot the name is simply "cnss" at the kernel level, but with cnss-daemon also
<dan_b`> and some different hs for sensors
<samueldr> it's likely to be the same "vintage" of SoCs, but different variants yeah
<samueldr> often times things released with a SoC of the same age has a bunch of similarities
<samueldr> (and same manufacturer)
orivej has quit [Quit: No Ping reply in 180 seconds.]
<alj[m]> xdej: Hey did you make some progress? :)
orivej has joined #nixos-aarch64
<dan_b`> weston: failed to get username: Success
<dan_b`> [nixos@nixos:~]$ sudo weston-launch -t 1 -u 1000
<dan_b`> unix, I <3 your error messages
<alj[m]> well aint that a funky message
<samueldr> dan_b`: just saying, if you get wcnss working, you still have to deal with random issue :)
<samueldr> I wonder if it's poor entropy, and blocking, and if rngd could help
<dan_b`> random issue may be random, too :-/ I just restarted the sshd service and now it works (over usb, still)
<dan_b`> [01:26:29.669] fatal: drm backend should be run using weston-launch binary, or your system should provide the logind D-Bus API.
<dan_b`> I used to understand how linux worked, some day I will have to accpet that D-Bus is not just a fad
<dan_b`> but for now I am going to do some exercise and maybe come back to this later
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
<samueldr> :)
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<thefloweringash> On the topic of the armv7 builder, what’s the current expected state? Hydra seems to be failing all the builds with “Unsupported system type”
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andi-> I think someone (gchristensen?) fires up an instance and hydra tries to build the latest job on that.
<gchristensen> it runs periodically
<gchristensen> 2020-04-25 it built 15,000 pkgs
<gchristensen> ah, oops
<gchristensen> I had to disable it, it was pushing us over the limit too much
<thefloweringash> ah, ok
<gchristensen> maybe could build that VM and download after startup
<thefloweringash> do we know what the limit is?
orivej_ has joined #nixos-aarch64
<gchristensen> I really don't know / understand the problem
<thefloweringash> I think there was some accidental retention in the tarball, which could be trimmed. it might not be enough though
<gchristensen> it has to do with, an incomplete write or something, I really don't know
orivej has quit [Ping timeout: 246 seconds]
<samueldr> is it the initrd thing?
<thefloweringash> it's just the mysterious: image gets big -> error unpacking initrd ?
<gchristensen> yeah samueldr
<samueldr> I can reproducibly do something similar to that with a too-big initrd
<samueldr> (in qemu, x86_64)
<samueldr> so yeah, that sounds like the spoon is too big
<samueldr> I'm curious as to what defines the limits for initrd
<thefloweringash> would you consider deploying from a nix cache instead of a large image?
<thefloweringash> something in stage-1 that does a `nix copy` of the main system configuration before switching to it
<thefloweringash> would mean no size limits, and possibly faster iteration times for the main builders
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
ssk has joined #nixos-aarch64
<ssk> does anyone have any ideas on how I might be able to solve: https://github.com/NixOS/nixpkgs/issues/88449 ? All I'd like to do is cross compile numpy from x86 to armv7 :)
<{^_^}> #88449 (by satshabad-cr, 3 hours ago, open): Can't build numpy cross package for armv7 due to failure compiling gfortran needed in lapack and blas dependencies
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
orivej has quit [Quit: No Ping reply in 180 seconds.]
cole-h has joined #nixos-aarch64
orivej has joined #nixos-aarch64
ssk has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #nixos-aarch64