lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-aarch64
blackriversoftwa has quit [Excess Flood]
blackriversoftwa has joined #nixos-aarch64
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-aarch64
lovesegfault has quit [Ping timeout: 265 seconds]
lovesegfault has joined #nixos-aarch64
lovesegfault has quit [Quit: WeeChat 2.7.1]
<flokli> blackriversoftwa: currently building your PR once again
lovesegfault has joined #nixos-aarch64
<blackriversoftwa> flokli: is it taking a long time?
<blackriversoftwa> I have a warm cache for it but it didn't seem like that big to build
<flokli> I built it
<blackriversoftwa> flokli: any remaining outstanding issues? It does still leak build-platform things into the runtime closure but all the issues I encountered on a Pi before are cleared up now
<blackriversoftwa> except the part where the closure is >1GB
<flokli> should coreutils really just point to coreutils' bin/ directory?
ryantrinkle has joined #nixos-aarch64
<flokli> otherwise, the paths all seem to exist
<blackriversoftwa> flokli yes
<blackriversoftwa> that was what I had to fix with this last push
<flokli> where does it get used?
<blackriversoftwa> in the PATH for the channel fetcher scripts in corepkgs
<flokli> right
<flokli> cool
<blackriversoftwa> it's expected to point at the /bin directory because it just gets added to PATH without any preamble
<blackriversoftwa> I tried it the other way and it complained that it couldn't find `mkdir`
<flokli> merged :-)
<blackriversoftwa> Yay
<blackriversoftwa> flokli: thanks
lovesegfault has quit [Ping timeout: 268 seconds]
<blackriversoftwa> flokli: I'm starting to get an idea of why we get that huge gcc output in the closure.
<blackriversoftwa> ```
<blackriversoftwa> ```
<blackriversoftwa> libgcc_s.so.1 => /nix/store/jxv3p9zmr8v8z6nh8lpyjf6c8gpr1r1z-armv7l-unknown-linux-gnueabihf-stage-final-gcc-debug-9.2.0/armv7l-unknown-linux-gnueabihf/lib/libgcc_s.so.1 (0x76717000)
<blackriversoftwa> libstdc++.so.6 => /nix/store/jxv3p9zmr8v8z6nh8lpyjf6c8gpr1r1z-armv7l-unknown-linux-gnueabihf-stage-final-gcc-debug-9.2.0/armv7l-unknown-linux-gnueabihf/lib/libstdc++.so.6 (0x767b3000)
<blackriversoftwa> $ ldd /nix/store/k1hr62wvnjgys7rf20xprd0p471zn1cb-nix-2.3.3-armv7l-unknown-linux-gnueabihf/bin/nix| grep gcc-debug
<blackriversoftwa> So it depends on libstdc++ and libgcc_s.so.1 from the gcc derivation
<blackriversoftwa> and gcc gets built without stripping for cross-compilation: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/gcc/9/default.nix#L22-L24
h0m1 has quit [Ping timeout: 272 seconds]
h0m1 has joined #nixos-aarch64
<clever> blackriversoftwa: libstdc++.so.6 and libgcc_s.so.1 should be in gcc.lib, not gcc.out
<blackriversoftwa> clever: right but the rpath is getting set to gcc.out
<blackriversoftwa> that's why I'm confused
<blackriversoftwa> flokli: this is probably why all the build system deps come in
<blackriversoftwa> clever: If I figure out how to fix this then another big issue with cross-compiled Nix for small systems goes down
<clever> blackriversoftwa: does the file exist in .out or .lib?
<blackriversoftwa> clever: that path is .out
<blackriversoftwa> it also exists in .lib
<blackriversoftwa> so both
<blackriversoftwa> (This is a x-compiled build)
<clever> somehow delete it from .out and maybe things will correct themselves?
<blackriversoftwa> Doubtful because the only paths in rpath are to glibc and to gcc.out
<blackriversoftwa> so if I could delete it from out it just wouldn't find it
<clever> those paths are picked by patchelf --shrink-rpath and cc-wrapper.sh
<blackriversoftwa> oh right
<clever> and if the only libstdc++.so.6 is in .lib, it may correct itself
<blackriversoftwa> hrm
<blackriversoftwa> how would I go about deleting that
<blackriversoftwa> since .out is basically just a synthesis of the other outputs?
<clever> an override against the cross gcc i think
<clever> not sure where
<clever> .out is just a normal output
<blackriversoftwa> I know the attribute path for it
<clever> a split output drv must put files in $out, $lib, $dev for example
<clever> and it can put whatever it wants in each one
<blackriversoftwa> clever: ah ok
<blackriversoftwa> and it's just the `buildPackages.gcc-unwrapped` attribute
<blackriversoftwa> not sure how I'd go about messing with that in an overlay
<clever> yeah, not sure either
<blackriversoftwa> `pkgsCross.armv7l-hf-multiplatform.buildPackages.gcc-unwrapped`
<clever> sometimes, its simpler to just edit nixpkgs directly
<blackriversoftwa> Well I just got done doing that to make current stable nix not import the wrong bash
<blackriversoftwa> when cross-compiled
<blackriversoftwa> so no reason I can't do it again :P
lovesegfault has joined #nixos-aarch64
<blackriversoftwa> clever: aha I might know why?
<blackriversoftwa> I think there is some logic to auto-split /lib directories out, but since this is a cross-compiler the libraries get put under /nix/store/<gcc>/<system>/lib
<blackriversoftwa> so build system libraries get dumped to .lib but not x-compiled libraries, I think?
<blackriversoftwa> clever: yeah the `.lib` output just has x86 libraries
<clever> blackriversoftwa: i think you need 2 outputs then, for x86 and arm libraries
<clever> so it doesnt depend on the x86 libs at arm runtime
<blackriversoftwa> clever: yeah but then do you need to explicitly tell everything downstream about the new output so it goes in the rpath?
<blackriversoftwa> maybe
<blackriversoftwa> it is very late here so I'll look at it tomorrow
orivej has joined #nixos-aarch64
andi- has quit [Ping timeout: 272 seconds]
craige has quit [Ping timeout: 252 seconds]
lovesegfault has quit [Ping timeout: 256 seconds]
lovesegfault has joined #nixos-aarch64
andi- has joined #nixos-aarch64
craige has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
tilpner has joined #nixos-aarch64
lovesegfault has quit [Ping timeout: 256 seconds]
tilpner_ has quit [Ping timeout: 256 seconds]
lovesegfault has joined #nixos-aarch64
lovesegfault has quit [Ping timeout: 240 seconds]
lovesegfault has joined #nixos-aarch64
lovesegfault has quit [Quit: WeeChat 2.7.1]
zupo has joined #nixos-aarch64
lovesegfault has joined #nixos-aarch64
lovesegfault has quit [Quit: WeeChat 2.7.1]
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
vcunat has joined #nixos-aarch64
vcunat has quit [Client Quit]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zarel_ has quit [Ping timeout: 240 seconds]
zarel has joined #nixos-aarch64
<blackriversoftwa> clever: there does seem to be some automagical handling of multiple outputs: https://nixos.org/nixpkgs/manual/#sec-multiple-outputs-
<blackriversoftwa> doesn't mean I can't make another output for cross-compiled libraries for the compiler
chiefgoat_ has quit [Quit: ZNC 1.7.5 - https://znc.in]
chiefgoat has joined #nixos-aarch64
<blackriversoftwa> clever, flokli : I made an issue about gcc putting target system libraries in its `$out`: https://github.com/NixOS/nixpkgs/issues/81716
<{^_^}> #81716 (by eamsden, 1 minute ago, open): gcc: Place target system libraries in a separate output
<blackriversoftwa> flokli: I'm fairly convinced that the reason there are still build-system paths in the output closure for `nix` is because they are runtime dependencies of `gcc`, so fixing this might finally clean all of those up
cidkid has joined #nixos-aarch64
<cidkid> I see the boot selection screen has finally been merged
<cidkid> will attempt to boot on the 5T, but not much more work will be done for 5T for awhile
<cidkid> as mainline is booting and my main focus is helping the dude developing it
<cidkid> we only get simple graphics using simplefb
<cidkid> for now
cidkid has quit [Remote host closed the connection]
jackdk has quit [Read error: Connection reset by peer]
jackdk has joined #nixos-aarch64
TheNumb has quit [Read error: Connection reset by peer]
TheNumb has joined #nixos-aarch64
dongcarl has quit [Read error: Connection reset by peer]
TheNumb has quit [Ping timeout: 256 seconds]
TheNumb has joined #nixos-aarch64
rajivr___ has quit [Ping timeout: 240 seconds]
NekomimiScience has quit [Ping timeout: 252 seconds]
NekomimiScience has joined #nixos-aarch64
rajivr___ has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 258 seconds]
zupo has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
ilios has quit [Ping timeout: 258 seconds]
chiefgoat has quit [Quit: ZNC 1.7.5 - https://znc.in]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ryantrinkle has quit [Ping timeout: 268 seconds]
chiefgoat has joined #nixos-aarch64
<andi-> Has anyone here seen https://www.kickstarter.com/projects/volla/volla-phone-designed-with-simplicity-and-security-in-mind ? I think we had the previously (failed?) campaign here
<samueldr> I think I did
<samueldr> IIRC, mediatek, so not a good outlook about open source software
<samueldr> and wasn't it from a brand of german (landline) phones that is "not good", or something like that?
<samueldr> >> “Made in Germany” from our experienced hardware partner Gigaset, the Volla Phone is durable enough to be your device for years.
<samueldr> I don't remember what was said about gigaset though, andi-
<andi-> oh yeah I remember me rumbling against made in germany..
<samueldr> but yeah, mediatek, not a good outlook for other OSes
<samueldr> it's totally a "land grab" early in the "let's put lipstick on an android and call it privacy"
<samueldr> at least, that's what it looks like
<samueldr> same as /e/, though /e/ has the distinction of re-purposing existing hardware
<samueldr> which is a net positive
ryantrinkle has joined #nixos-aarch64
<andi-> Yeah, I read an article ( https://tuxphones.com/made-in-germany-linux-ready-volla-phone-kickstarter/ ) that sounded very positive about the mainline kernel.. I only believe it once I see it.
<samueldr> >> If we reach a funding target of more than 490k Euro, we can offer Nemo Mobile as an alternative operating system for subsequent installation
<samueldr> I wonder if nemo was involved
<andi-> 490k€.. good luck
<samueldr> I see nothing about mainline though
<samueldr> only that the pinephone and librem 5 are mainlined
<samueldr> >> and if it'll ever arrive to the point of running a stable, fully featured "mainline" Linux kernel
<samueldr> and that sentence full of doubt
<andi-> Yeah
<andi-> ALso being able to make a phone in <7m sounds like they are just using some ready made device with a slightly changed user space.
<samueldr> I don't doubt that they'll release the sources, even though mediatek is reportedly against it, others do release the sources
<samueldr> oh, it *is* that, that's for sure
<samueldr> I'm sure you could figure it out through ODMs
<samueldr> maybe on taobao or alibaba you can find the same exact phone shell
<samueldr> but slightly unlikely
<samueldr> what might be more likely, is on source release, find who the ODM is and then find matching devices
<samueldr> I forgot again the name of the ODM that makes some xiaomi devices
<samueldr> http://www.longcheer.com/ (as said in that previous discussion about the volla)
<samueldr> oh, and volla sounds awfully close to jolla to me
<andi-> Yeah, purposely I would say
<samueldr> so it's likely a common ODM
<andi-> everything else wouldn't explain the price point and the delivery dates
<samueldr> it might if it's not a real kickstarter product, but ad-kickstarter
<samueldr> step 1: prepare an AOSP-based OS
<samueldr> step 2: find an ODM
<samueldr> step 3: advertise on kickstarter
<andi-> also likely
lovesegfault has joined #nixos-aarch64
<gchristensen> lol.
<samueldr> anyone can send me an iphone 7?
<gchristensen> I have an iphone 6...
<samueldr> it's kind of a big ad for corellium, but it looks like an actual thing
<samueldr> I figure it's like all the other things: can't reboot without being near a computer
<gchristensen> yeah
<flokli> andi-: samueldr: forget about mainline kernel. I saw a similar promise with the gemini pda "once hitting xxk, you'll be able to install Debian on it as well"
<samueldr> flokli: the thought never crossed my mind
<flokli> Turns out, still uses the android kernel, and there's some libhybris stuff
<flokli> they rolled their own distro on top of that
<samueldr> yep
<flokli> or at least some packages
<flokli> they're buggy and not pleasant at all
<samueldr> when even google is not arsed to pick up behind the vendor (chromeos team) I figure the vendor is hopeless
<flokli> Not to talk about the amount of hacks required to get the sp-flash-tool to flash that mediatek device
<flokli> mediatek is very "eeeh, don't touch, it might be contagious"
<flokli> at the end, I gave it away to adisbladis :-)
<samueldr> ah, I thought he got one for himself, not that it was hazardous waste from someone else ;)
<adisbladis> Hazardous waste indeed
<adisbladis> I spent way to much time on that thing already :P
<blackriversoftwa> flokli: I think I figured out why there is still cross-contamination, and it is a more general issue with x-compiling gcc. In fact there's already an open PR to fix it: https://github.com/NixOS/nixpkgs/pull/58606
<{^_^}> #58606 (by illegalprime, 48 weeks ago, open): [WIP] gcc: put target-specific libs in lib output
<adisbladis> flokli: Actually for the purpose of mobile-nixos I'm pretty grateful it relies on hybris
<adisbladis> I managed to test a bunch of stuff using their android containers with nix-built hybris
zupo has joined #nixos-aarch64
lovesegfault has quit [Quit: WeeChat 2.7.1]
<flokli> blackriversoftwa: yeah, I saw the highlight. Just didn't get into reading through aaaall of this PR
<blackriversoftwa> flokli: I tried patching it as matthewbauer suggested and merging in master
<blackriversoftwa> it doesn't build
<blackriversoftwa> the actual code changes are minimal
<blackriversoftwa> and the principal seems correct
lovesegfault has joined #nixos-aarch64
lovesegfault has quit [Client Quit]
<flokli> I currently can't sink too much time into it, sorry :-/
<flokli> it might get better in 2 weeks
<blackriversoftwa> flokli: no it's no problem: but do you think I should ask to take over? the original PR hasn't been updated since april last year
<blackriversoftwa> in terms of being pushed to
<flokli> if you want to work on it, sure.
<flokli> Just push a new PR, link it to the old one, and ask s.o. to close the original one
<blackriversoftwa> OK
<flokli> I hijacked PRs that were far less stale than this one ;-)
<blackriversoftwa> flokli: OK I am still new to the nixpkgs community so I am trying to be polite. But I'll probably swipe this one
<flokli> if sb decides to keep pursuing the original authors intent, I assume they'll have zero problems with so else finishing it up
<blackriversoftwa> Do you have time to push for it to be merged if I do?
<flokli> I usually keep the original Author as author in the git commit, and add myself as Co-Authored-By
<blackriversoftwa> flokli: hrm that isn't something I've had to do before: how to?
<flokli> and ask the original author for some feedback, if possible
<flokli> I mean, you can also just do that for the final merge-able thing
<flokli> and just keep stacking more commits below the existing ones
<flokli> and then do the authorship thing in the final squash
<blackriversoftwa> ok thanks
lovesegfault has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lovesegfault has quit [Quit: WeeChat 2.7.1]
cidkid has joined #nixos-aarch64
<cidkid> samueldr: did you see what I wrote this morning?
<samueldr> yes, and more power for mainline work
<samueldr> that's good
<cidkid> No USB comms yet
<cidkid> Sometime soon I think
<cidkid> Then freedreno will be used for gfx accel
<cidkid> I will attempt to boot the Gen selection gui on downstream then stop
<cidkid> As I won't work on anything until mainline has USB comms
<cidkid> Soon tho work will continue
<cidkid> Also I won't have to Port any libhybris things from sailfish which makes me happy
lovesegfault has joined #nixos-aarch64
ilios has joined #nixos-aarch64
zupo has joined #nixos-aarch64
{`-`} has joined #nixos-aarch64
orivej has joined #nixos-aarch64
cidkid has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
lirzhv has left #nixos-aarch64 [#nixos-aarch64]
orivej has quit [Ping timeout: 258 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chiefgoat has quit [Quit: ZNC 1.7.5 - https://znc.in]
lovesegfault has quit [Quit: WeeChat 2.7.1]
chiefgoat has joined #nixos-aarch64
fooker has quit [Ping timeout: 272 seconds]
fooker has joined #nixos-aarch64
Ashy has left #nixos-aarch64 ["WeeChat 1.9.1"]