vika_nezrimaya has quit [Ping timeout: 265 seconds]
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-aarch64
lopsided98 has joined #nixos-aarch64
<gchristensen> instead of trying to figure it out, I just deleted some code to make it shorter
<clever> gchristensen: my local hydra is also failing to build...
<clever> ../libhydra/hydra-config.hh:17:24: error: invalid initialization of reference of type 'const Path&' {aka 'const std::__cxx11::basic_string<char>&'} from expression of type 'std::optional<std::__cxx11::basic_string<char> >'
<clever> if (pathExists(hydraConfigFile)) {
<clever> ../libhydra/db.hh:15:60: error: no matching function for call to 'getEnv(const char [10], const char [21])'
<clever> auto s = getEnv("HYDRA_DBI", "dbi:Pg:dbname=hydra;");
<clever> a `git pull` on hydra appears to have fixed it
<clever> your initrd thing is also still building
<gchristensen> making the file a bit smaller seems to have helped
<clever> nas...> Job for hydra-init.service failed because the control process exited with error code.
<clever> Mar 09 22:53:46 nas hydra-init[26515]: schema upgrade failed: main::run_(): DBI Exception: DBD::Pg::db do failed: ERROR: column "jobset_id" contains null values at /nix/store/q8j0zzvx49i55m6afxp589f0byv98am5-hydra-0.1.0.0000000000000000000000000000000000000000/bin/.hydra-init-wrapped line 70
<clever> gchristensen: wasnt that supposed to be fully automatic (with possible extended downtime)?
<gchristensen> yeah as long as you migrate to an interim commit
<clever> i just went to head of master, and it failed
<gchristensen> yah you'll need to pick an interim commit
<clever> which one would be good?
<gchristensen> like c4cc72f94449564b56ad9f71d530ee5917af3a97
<gchristensen> but if you don't have abig db, ust run hydra-migrate
<clever> hydra-migrate: command not found
<gchristensen> tab-complete
<gchristensen> ?
<clever> i did, it wasnt found
<clever> [hydra@nas:~]$ ls /nix/store/q8j0zzvx49i55m6afxp589f0byv98am5-hydra-0.1.0.0000000000000000000000000000000000000000/bin/
<clever> hydra-backfill-ids hydra-create-user hydra-eval-jobs hydra-eval-jobset hydra-evaluator hydra-init hydra-notify hydra-queue-runner hydra-s3-backup-collect-garbage hydra-send-stats hydra-server hydra-update-gc-roots nix-prefetch-bzr nix-prefetch-git nix-prefetch-hg
<gchristensen> backfill
<clever> only those commands exist
<clever> (pass 1/2) (batch #1; 23421 remaining) Builds.jobset_id: affected 10000 rows; max ID: 52 -> 86518
<clever> gchristensen: thats not too bad, should be done soon
<gchristensen> nice
<gchristensen> it took only ~15h on hydra.nixos.org
<clever> i was expecting hydra-init to migrate and backfill automatically
<clever> causing it to just take longer to start
<gchristensen> right
<gchristensen> the migrations are designed in such a way that it won't proceed if you haven't backfilled
<clever> ah
<gchristensen> meaning you aren't stuck for 20 hours migrating if you didn't mean to
<clever> but, since hydra-init failed, the entire UI went down
<clever> and nixops cant deploy, because it cant reach hydra-server
<gchristensen> ow
<clever> so id have to do a manual rollback
<clever> luckily, this was only on my local nas, not the iohk hydra yet
<clever> trial-runs!
<gchristensen> why does nixops talk to hydra?
<clever> fetching pre-built things from hydra
<gchristensen> ah
<clever> my local hydra is configured to pre-build the nixops deployment
<clever> gchristensen: how much do you know about prometheus sample storage? i'm trying to figure out why mine is using 15gig
<gchristensen> do youhave high-cardinality metrics?
<gchristensen> prometheus.nixos.org uses like 150G
<clever> cardinality?
<gchristensen> labels which change a lot
<gchristensen> or worse, a metric with two labels which change a lot
<clever> i dont think so
<clever> just hydra, the normal exporter, and a few custom things that dont use any labels
<gchristensen> hrm
<clever> does prometheus have any internal metrics that can help answer things?
<gchristensen> probably :) but I don't know
<clever> gchristensen: prometheus_tsdb_storage_blocks_bytes is something i added to my graph
<gchristensen> nice
<clever> i think it only increments every time a 2h chunk is copied from the WAL
<clever> so you need to average over a pretty wide window
<gchristensen> hrm... weird :?
<clever> the WAL is a seperate metric
<clever> Mar 09 23:31:00 nas hydra-queue-runner[31475]: possibly transient failure building ‘/nix/store/2vggq7y55l4587nqg590s4mzwj90gws6-bootdir.drv’ on ‘builder@system76.localnet’: unexpected end-of-file
<clever> gchristensen: and now hydra is failing all builds
<gchristensen> heh
<clever> might be ssh related, let me check...
<clever> ehhh, some are passing, weird
<clever> [9084414.842244] starman worker [4180]: segfault at 1054 ip 00007f8c9c8a73b0 sp 00007fff2b819360 error 4 in libnixrust.so[7f8c9c8a5000+1f000]
<clever> gchristensen: and hydra-server managed to segfault in rust!
<gchristensen> :o
<gchristensen> maybe need an updated Nix?
<clever> using nix-2.4pre7250_94c93437
<clever> according to hydra
<gchristensen> okay I'm heading to bed
<clever> nn
<gchristensen> hydra is building an armvl glibc so I feel like I made real progress https://hydra.nixos.org/build/114258274#tabs-buildsteps
<gchristensen> night!
<clever> nice
<clever> gchristensen: oh, and ive also heard recently about arm cores, how you can choose to make an arm cpu, that lacks 32bit EL1, but still has 32bit EL0
<clever> gchristensen: so the kernel must be 64bit, but the userland can be 32 or 64
<clever> and that can be cheaper (in terms of die area) then a cpu that can be 32 or 64 in every level
<samueldr> gchristensen++
<{^_^}> gchristensen's karma got increased to 224
h0m1 has quit [Ping timeout: 256 seconds]
h0m1 has joined #nixos-aarch64
<clever> samueldr: the arm bootstrap tools somehow got a hash validation error??
<samueldr> I don't know about that
<clever> wanted: sha256:0l0544ixi9x2y23c9fmwyvb1y9kd9gb3yamnr73mdf5f49vjvykr
<clever> got: sha256:0pf4p5r28vj62j7bqjc4qhwdriaikf2fc4pflhrjp8cbh3sgk124
<samueldr> maybe you don't have a nixpkgs with the "executable = true" fix
<clever> "executable": "",
<clever> samueldr: that one shouldnt be executable...
<clever> "builder": "builtin:fetchurl",
<samueldr> I really wouldn't know, I don't grok the bootstrap stuff
<clever> [clever@amd-nixos:~/apps/rpi/rpi-open-firmware]$ wget https://hydra.nixos.org/build/112609103/download/1/bootstrap-tools.tar.xz
<clever> [clever@amd-nixos:~/apps/rpi/rpi-open-firmware]$ nix-hash bootstrap-tools.tar.xz --type sha256 --base32 --flat
<clever> 0pf4p5r28vj62j7bqjc4qhwdriaikf2fc4pflhrjp8cbh3sgk124
<clever> samueldr: if i manually download with wget, i get the "got" hash
<clever> samueldr: can you confirm the same thing on your end?
<samueldr> no
<samueldr> I mean, I'm not setup to test and confirm
<clever> just run those 2 commands
<samueldr> or wget?
<samueldr> I thought about confirming the nix-build :)
<samueldr> 0pf4p5r28vj62j7bqjc4qhwdriaikf2fc4pflhrjp8cbh3sgk124
<clever> yep, your getting the same hash as my hydra
<clever> so its not a mitm attack
<clever> which would be unlikely, its https!
<clever> to github!
<clever> for me, its happening on a diff branch
<clever> brb
<clever> back
zarel_ has quit [Ping timeout: 265 seconds]
zarel has joined #nixos-aarch64
orivej has joined #nixos-aarch64
ilios1 has quit [Read error: Connection reset by peer]
ilios1 has joined #nixos-aarch64
<srk> actually both the initrds are weird and contain tons of stuff they shouldn't / can't even list
lovesegfault has quit [Quit: WeeChat 2.7.1]
zupo has joined #nixos-aarch64
zupo has quit [Read error: Connection reset by peer]
zupo_ has joined #nixos-aarch64
lovesegfault has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-aarch64
lovesegfault has quit [Quit: WeeChat 2.7.1]
lovesegfault has joined #nixos-aarch64
lovesegfault has quit [Client Quit]
lovesegfault has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
njd has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
bdju has joined #nixos-aarch64
rsa has joined #nixos-aarch64
<gchristensen> thefloweringash: tiny problem with the `xz` thing :)
<gchristensen> [root@nixos:~]# ls -la /nix/store/xxaszh5pxaay47ipnv52l3k0mdjn3f9y-sudo-1.8.31/libexec/sudo/sudoers.so
<gchristensen> -r--r--r-- 1 nobody nogroup 401368 Jan 1 1970 /nix/store/xxaszh5pxaay47ipnv52l3k0mdjn3f9y-sudo-1.8.31/libexec/sudo/sudoers.so
<gchristensen> [root@nixos:~]# sudo reboot
<gchristensen> sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"
<gchristensen> sudo: /nix/store/xxaszh5pxaay47ipnv52l3k0mdjn3f9y-sudo-1.8.31/libexec/sudo/sudoers.so must be owned by uid 0
<thefloweringash> yikes. is that in the vm or the host?
<gchristensen> the host
<thefloweringash> gosh, how did I not notice this.
<gchristensen> well like I said, it is a tiny problem so far
<{^_^}> grahamc/packet-nix-builder#3 (by thefloweringash, 22 seconds ago, open): tar-store: fix uid and gid
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
orivej has joined #nixos-aarch64
<samueldr> Danct12[m]: I'm curious about your color fixes on redmi 4X, mainly if my approach with kernel patches is probably right or wrong
<samueldr> basically the same patch, two different kernel vintages
<samueldr> what I do is add BGRA to the driver, and make it the default
orivej has quit [Ping timeout: 255 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
<Danct12[m]> i think the patch is good, doesn't seem to affect the colors on hybris
<samueldr> AFAICT I'm only adding a missing mode (and setting it as the default one)
<Danct12[m]> and yes, the color depth was mentioned in the commit https://gitlab.com/postmarketOS/pmaports/-/commit/52f04befaf855388b5f746c7f1c6793fe4afd8a3
<samueldr> ah, so it's the same patch I see :)
<Danct12[m]> well, afaict it's the first device ever on pmos to have this patch
<samueldr> I haven't verified those assertions yet
<samueldr> I think what's happening is that the framebuffer logo doesn't show up as wrong RGB/BGR since G is in the middle
<samueldr> and that wayland handles that format just fine
<samueldr> but I've been so far removed from postmarketOS since I added asus-z00t that I can't say for sure if that's right
<samueldr> it would be weird that the same kernel (asus-z00t)
<samueldr> wouldn't have the same issue on postmarketOS
<Danct12[m]> fbsplash seems to handle that just fine too
<samueldr> it could be
<samueldr> I was relying on ply-image (originally from plymouth, though forked by chromeos) for splashes
<Danct12[m]> alright, so im building nixos for santoni
<Danct12[m]> here's a problem when i build it:
<Danct12[m]> error: The option `mobile.system.system' is used but not defined.
<samueldr> you'll need `mobile.system.type = "android";` to be set for the device
<samueldr> "used but not defined" means that something relies on the value of the configuration, but nothing set its value (and it has no default value)
<samueldr> uh
* samueldr is wrong
<samueldr> I should have read
<Danct12[m]> mobile.system.type it is set in default.nix, so that's not a issue
<samueldr> mobile.system.system <- is it possible you doubled `system` somewhere, e.g. mobile.system = { system = "..."; };
<samueldr> do you have that as a branch I can look at?
<Danct12[m]> pushing it
<samueldr> ah, I think I see, `modules/hardware-qualcomm.nix`
<samueldr> I figure you set soc = "qualcomm-msm8940"; but it's not in that list
<samueldr> or, I'm guessing at this point :)
<Danct12[m]> nah, you're wrong, i had that set before that error appears
<samueldr> halfway there
<Danct12[m]> non-supported soc would have a different error
<samueldr> the first part makes the sdm660 option, in that example, the second part configures `system.system` and some quirks when that option is enabled
<Danct12[m]> oh right, that's the reason
<Danct12[m]> quirks.qualcomm.msm-fb-handle.enable is imo msm-fb-refresher?
<samueldr> right
<samueldr> that commit was from before I dropped fb-handle
<samueldr> fb-handle didn't work right with LVGL
<samueldr> (speaking of, it would be much better if I simply added that into LVGL for early boot stuff)
<Danct12[m]> question, how can i set a kernel config?
<Danct12[m]> is there anything like kconfig edit like in pmbootstrap?
<samueldr> sadly not yet, you should be able to drop into a nix-shell to make menuconfig, and configure stuff just right, but I don't have docs for that yet because I haven't figured it out myself yet
<samueldr> last time I tried it assumed I wanted an x86_64 kernel
<samueldr> what I've been doing is extract the config from a boot.img's kernel, starting from there enable the options I know are needed, build and hopefully boot all the way
<Danct12[m]> any list of what to enable and what not to enable?
<samueldr> I'll be extremelt annoying: not yet :(
<Danct12[m]> nvm, there isn't any docs yet
<samueldr> extremely annoying*
<samueldr> yeah
<samueldr> though I have an android device I'm keeping untouched to write docs about every little details
<samueldr> last time I added an android kernel config I used `vimdiff` with a kernel from around the same era
<samueldr> and one that has the same base kernel version
<Danct12[m]> that would be nice to see some docs, which would then help more people to get involved in the project
<samueldr> it should show some things like FRAMEBUFFER FB, USERNS and such as enabled
<samueldr> you're definitely right, it's on the roadmap
<Danct12[m]> real linux for phones are kinda underrated, until the pinephone and librem era
<Danct12[m]> and even then not everyone can afford one of these devices :P
<samueldr> I made sure to port to a variety of android devices for that one simple goal: use a device you already own
<insep[m]> fun fact: msm-fb-refresher is not only for msm devices :)
<samueldr> fun!
<samueldr> what did you end up needing it with?
<samueldr> mtk?
<Danct12[m]> first time having a nixos chroot setup just for mobile-nixos development.. everything is kinda new and weird lol
<Danct12[m]> really not used to the new development environment
<samueldr> in theory a chroot shouldn't be needed, only having nix installed, though that does mean the system has /nix and nix installed on it
<samueldr> and if you use a chroot (or a VM) you could also use another distro with nix, but eh, NixOS is quite good :)
<Danct12[m]> oh so basically you can still have arch, and /nix in the root directory..
<samueldr> nix can be used on other distros (and on macOS) without being a nuisance to other package managers
<insep[m]> <samueldr "what did you end up needing it w"> spreadtrum
<samueldr> (on macOS you will have some issues with building linux things)
<insep[m]> but it works on mtk too
<Danct12[m]> oh right, development on a mac kinda sucks.. i guess
<Danct12[m]> mainly because most of the stuffs are meant to be used with glibc and musl i guess
<samueldr> it should be doable as long as you have a nix builder, since nix does not require to build on the platform you evaluate on
<samueldr> as long as you have a linux nix builder*
<samueldr> and that linux nix builder could be a VM
<samueldr> your files, and development would happen on the mac side of things, but end up being built on that other machine
<Danct12[m]> hmm, so that's like distcc, kinda cool
<Danct12[m]> and the isolated environment is much more easier to uninstall when you don't need it.. or just want to restart the environm
<samueldr> well, there's no "environment" :)
<Danct12[m]> `No space left on device`
<Danct12[m]> s*it
<samueldr> because of how nix evaluates, any change ends up changing the hash of that derivation, and all derivations depending on it, meaning that in practice you don't get "bad cache"
<Danct12[m]> 37G 35G 0 100% /
<samueldr> yeah, that will happen :)
<samueldr> each successful builds are kept
<Danct12[m]> is there anyway to change this folder in anyway?
<samueldr> the /nix folder?
<Danct12[m]> yeah
<Danct12[m]> i think it's torturing the rootfs part
<samueldr> since you're not botting from it or relying on it to boot, it could be a mount or bind mount without issues
<samueldr> not sure if anything would break with a symlink though
<Danct12[m]> mhmm
<samueldr> (some software is sneaky and use readlink hapazardly)
<samueldr> the "dumb" way to change nix to just use another folder will not work as expected, as /nix is part of the inputs, so the resulting hashes end up changing
<samueldr> there is another way which I'm looking up, trying to buy time by writing sentences in IRC doesn't help :)
<Danct12[m]> ah, nix-collect-garbage
<samueldr> --store local?root=some/path can be used with nix-build, it will completely ignore the /nix root, but will use user namespaces and act as if some/path/nix was /nix
<LinuxHackerman> or --store /some/path for short ;)
<samueldr> I assumed that was changing the store path in the "dumb" way previously mentioned
claudiii has joined #nixos-aarch64
<LinuxHackerman> samueldr: nope, that only works via NIX_STORE_DIR iirc
<samueldr> LinuxHackerman: good to know, I tried to find actual docs about it (thus my question in #nixos-dev)
<Danct12[m]> anyway to change the build directory somehow?
<Danct12[m]> everything currently spats out in /run/user/1000 which then would go out of space and stops compiling
<LinuxHackerman> TMPDIR
<LinuxHackerman> of the nix-daemon, if one is running
h0m1 has quit [Quit: WeeChat 2.7.1]
h0m1 has joined #nixos-aarch64
<Danct12[m]> ok_hand
lovesegfault has quit [Quit: WeeChat 2.7.1]
cidkid has joined #nixos-aarch64
<gchristensen> thefloweringash: I'm thinking this machine should run 4 builders, and have the host run a nix-daemon, using remote building to the 4 VMs on the host
zupo has joined #nixos-aarch64
<misuzu> gchristensen: a lot of jobs seem to fail due to oom, maybe there is some issue with kernel? i'd check output of free -h on those VMs just to make sure
<gchristensen> total used free shared buff/cache available
<gchristensen> Mem: 31Gi 163Mi 30Gi 8.0Mi 406Mi 30Gi
<samueldr> misuzu: some builds could be failing due to 32bitness and inability for *one* process to allocate enough ram?
<misuzu> samueldr: yeah, that too
<samueldr> I think LPAE has been enabled though for the kernel/system
<LinuxHackerman> ^ this is definitely the case for firefox
<LinuxHackerman> that doesn't increase the address space available to a single process
<gchristensen> the VM also doesn't start if I give it too much RAM
<misuzu> i tried running cross-compiled armv7 image with ARM_LPAE enabled under qemu and it didn't see more than 3G of ram for some reason
<samueldr> hm, the one time I tried it worked
<samueldr> at least, for `free`
<gchristensen> I see other serious problems too
<gchristensen> lots of coredumpctl errors about too few arguments to the kernel
<srk> boot.extraModprobeConfig = "options zfs zfs_arc_max=${toString (2 * 1024 * 1024 * 1024)}";
<srk> this helped with one of the build machines with zfs eating too much rum
<gchristensen> hmm I only use zfs on the host
<srk> ah, nvm
<gchristensen> and ZFS isn't going to over-use RAM when I can only give the VM up to 32G
<samueldr> ✅ stage-1 GUI on pinephone
<gchristensen> wooo!
<samueldr> ❌ stage-2 example system on pinephone
<samueldr> hmm, display-manager failed to start
* samueldr checks
<samueldr> oh, that's my testing system with hwcomposer... that sure can't boot
<samueldr> (I was re-using an old system image)
lovesegfault has joined #nixos-aarch64
<samueldr> ✅ stage-2 from the same system.img I'm using on android and depthcharge one pinephone
<samueldr> (which I should probably rebuild)
<srk> ✓
cidkid has quit [Ping timeout: 256 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<Irenes[m]> wooo! super cool
<Irenes[m]> I kind of thought it might be a lucky first try like that, I'm excited to see it really was
<samueldr> well, it wasn't as much a lucky try that I had the dont-be-evil devkit to work with initially
<Irenes[m]> oh, that makes sense
<samueldr> still, most things just dropped in place with that devkit, one could have approximated the boot things using another u-boot-using device
<Irenes[m]> sure
<samueldr> in fact that's what I did before working on the devkit, I had an A64-LTS that I used to get the mobile nixos boot chain setup
<samueldr> and just now, late last week I re-worked the u-boot things for the pinebook pro
<samueldr> which actually helped in getting this going since that refreshed the work-in-progress branch :)
<Irenes[m]> neat. makes sense.
<samueldr> not "useful" yet, but that's mainly post-boot things to work on, same with all devices
<samueldr> though it does match the chrometab in usefulness since it has wifi (and maybe bluetooth) working
<srk> cool!
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Ox4A6F> samueldr: ++
<Ox4A6F> I'm hoping, that my PinePhone shipment arrives. Unfortunately I'm located in Germany.
<samueldr> I think you needed to be informed of something, or getting in touch or gotten in touch about that
* samueldr checks
<samueldr> gotten in touch with
<andi-> That looks amazing :)
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andi-> samueldr: how awful is the browser experience?
<samueldr> right now, very, but it's likely due to the fact that it it runs from the SD card
zupo has joined #nixos-aarch64
<andi-> the whole touch input stack works on firefox? My touch experience wasn't great so far on our FF builds
<samueldr> it uh, always worked, but you need an environment variable to make use of the good one
<andi-> Yeah, I remember that... Even then chromium felt kinda better in that regard :/
<andi-> e.g. multi-touch on websites
<samueldr> I haven't actually compared the experience (on an x86_64 laptop) between firefox and chrome for touch
<samueldr> but with MOZ_USE_XINPUT2 it's passable
<andi-> Yeah my go to test was always google maps
<andi-> and trying to rotate the map
<samueldr> andi-: rotating in satellite view I presume?
<andi-> Yeah
<andi-> maybe even tilting the view (that wasn't a thing back when I last tried)
<samueldr> that's currently horrible due to xorg using the framebuffer backend :)
<samueldr> oof, no, not good, firefox doesn't transmit the events
<samueldr> it zooms/unzooms the page as if ctrl+wheeling
<samueldr> though I'm on 70
<samueldr> (that image dates from a few months back)
orivej has joined #nixos-aarch64
<FireFly> ooh :o exciting pic of the pinephone
<samueldr> I'll be cleaning up the PR and sending it later tonight
claudiii has quit [Quit: Connection closed for inactivity]
lovesegfault has quit [Quit: WeeChat 2.7.1]
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64