<samueldr>
I don't remember what I did when playing with the qualcomm download mode, but looks like my oneplus oneplus3 does weird stuff during boot :)
<samueldr>
looks like I'll have to fully recover it to stock
<samueldr>
for anyone scared about mobile nixos bricking their device: this is 99.999% sure not related to mobile nixos... I was exploring the limits of the device last time I was doing something with it
<samueldr>
hmmm... I wonder if it could be related to my attempt at "relocking" the device from the download mode
<samueldr>
though it did not work, it surely could have messed up something else
<clever>
test/t/test_perldoc.py .F. [ 55%]
<clever>
samueldr: even with a doCheck = false overlay, it still runs the tests, weird
<clever>
ok, weird, its part of pulseaudio's deps, wut
<clever>
aha
<clever>
qemu depends on pulse
<clever>
and i think i see the overlay problem now
<patagonicus>
Hmm. Has anyone had luck getting haskell to work on armv7l? ghc seems to be marked as not supporting it, which is a bit of a bummer since I'd like to install git-annex.
<thefloweringash>
shouldn't be impossible, but 8.10.1 is newer than the current binary version in nixpkgs (8.6.5)
alp has joined #nixos-aarch64
<patagonicus>
Ah, cool. Guess I'll play around with that a bit, but I'll probably work on other things first. git-annex isn't a hard dependency for what I want to do, would just be nice. I can just run it off of an x86 machine and mount the stuff from the arm machines via NFS/SSHFS/NBD/whatever.
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-aarch64
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
tilpner has quit [Quit: tilpner]
tilpner has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
disasm has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
NickHu has left #nixos-aarch64 ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
<colemickens>
/boot is not mounted, I probably did something bad
<samueldr>
I hope this is not a password
<colemickens>
nah, something buggy in the latest Element client causes the cursor to get duplicated in place and dupes text wildly
<samueldr>
sounds likely on pi4 if you don't have a FAT32 partition
<samueldr>
yep, the text is duplicated as many times as there are chars, every time with one fewer char on the end, it looks like
<colemickens>
this is weird though, this pi has been in steady state for months
<samueldr>
maybe it failed to mount the /boot partition? look at logs?
<colemickens>
and I haven't changed how my mounts are configured, and my zfs partitions are clearly mounted
<colemickens>
I guess so! yeah...
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
<colemickens>
it looks like at one point /boot was unmounted, then the bootloader got installed, then mounting got blocked because /boot was non-empty.
<colemickens>
If I had pushed a generation without /boot mounted even once, and didn't take steps to recover, this would've happened. (And I think might've iirc)
orivej has quit [Ping timeout: 240 seconds]
<samueldr>
what weird me out is why the boot didn't get failed by systemd if a mount failed
<colemickens>
It wasn't failed, and something else is still wrong.
<colemickens>
I rebooted and /boot is unmoutned again.
<colemickens>
My zfs mounts are still here, so this file (with /boot declared) is still active in this generation. :?
<samueldr>
I have had *one* boot on the pi4 with similar unmounted /boot and no fail from systemd
<samueldr>
well, I think, I don't remember having looked into it
<colemickens>
Active: inactive (dead)
<samueldr>
and couldn't reproduce at the time so I chalked it up to me not having looked at things properly
<colemickens>
to be fair, for *some* reason I have `nofail` configured for `/boot` (which honestly, an old generation is better than a failed boot for this device)
<samueldr>
hmmm... it shouldn't be nofail
<colemickens>
I am a bit confused simply from a linux perspective what's going on
<samueldr>
this is because with the default setup it's not important, we don't manipulate /boot
<samueldr>
well, let me rephrase it right: we don't manipulate the fat32 partition specific to the raspberry pi
<samueldr>
I hate lists in configurations in NixOS
<samueldr>
there is no clean way to remove stuff from them :(
<colemickens>
I dropped a bunch of stuff from this config, I wonder if it caused /boot to stop auto-mounting since it had 'noauto' on?
<colemickens>
I'm rebuilding now without `noauto` to see if it helps
<colemickens>
dropping noauto seemed to do it. /boot is as I expected on reboot.
<colemickens>
Hmph.
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
quinn has joined #nixos-aarch64
<samueldr>
and nofail?
<samueldr>
I really think it should go :/
<colemickens>
I kept nofail, but only because I don't want my Pi to ever be in a situation where Ih ave to go plug in hdmi etc
<samueldr>
hm
<samueldr>
understandable
<colemickens>
a big flashing banner "hey your /boot is unmounted" when I login would be cool, but so would lots of things, heh
<colemickens>
I have thought a "nixos.warnIfBootUnmountedOnActivate" or something would be neat. Haven't really thought it through though.
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has quit [Remote host closed the connection]
<clever>
when booting legacy with ext4, you also dont need a dedicated /boot/
alp has joined #nixos-aarch64
<colemickens>
legacy, vs u-boot/efi?
<samueldr>
clever: please expand
<clever>
samueldr: if your legacy booting with mbr (or gpt+bios boot), and ext4 for /, then your /boot can just be a normal dir on the rootfs
<samueldr>
on a raspberry pi? :)
<samueldr>
or even pretty much all ARM SBCs? :)
<clever>
on x86
<clever>
for an arm, you could maybe configure u-boot to look at the /boot folder of an ext4 rootfs, and then /firmware doesnt need to be mounted or updated
<samueldr>
I don't follow why you said that then :)
<clever>
half forgot that this is an arm channel
alp has quit [Ping timeout: 272 seconds]
jumper149 has joined #nixos-aarch64
Thra11 has quit [Quit: WeeChat 2.8]
<samueldr>
neat, prototypical form of volume keys + power input for the boot menu is done
<clever>
nice!
<clever>
are the keys acting as a keyboard out of the box?
<samueldr>
useful for those devices where the touchscreen doesn't work (yet?) or that early
<samueldr>
yep
<samueldr>
and directly map to the right KEY_ events
<clever>
i tend to just ignore the license for most things
<clever>
if i change it, i post changes to my fork on github
<clever>
and then either i pr it back, or i forget about it
<samueldr>
oh boy
<samueldr>
without the proper license it may not be legal
<clever>
the changes are public, do with it as you will
<samueldr>
even if the source is available and on github
<clever>
which licenses would get upset over my actions?
<samueldr>
when there is none
<clever>
ah
<samueldr>
it's all rights reserved to the author
<samueldr>
so you're doing copyright infringement
<clever>
if its on github, and the fork button works, then id blame them for not disabling that
<samueldr>
(or any non open source "license", which ends up being about equivalent to all rights reserved to the author)
orivej has joined #nixos-aarch64
<samueldr>
I don't think a project can disable the fork button
<clever>
ive only seen it disabled on private repos within an org
<samueldr>
yeah
<clever>
there used to be bugs involving that too
<samueldr>
and that still doesn't invalidate their fully ownership and copyright over the code
<clever>
if you forked a private repo, to another org, and then lost access to the original, the fork still worked
<clever>
and due to how all forks share the object store in github, you could pull a commit from the fork, if you knew the sha1
<clever>
i tend to just keep the history and original authorship info intact, so you can proove who made what
<clever>
and its obvious i'm not claiming to have written those parts
<samueldr>
even adding on top of existing copyrighted work is (AFAIUI) a no-no :(
<clever>
most projects i deal with are at least open-source based
<samueldr>
copyrighted and where you haven't been given rights*
<samueldr>
yeah
<samueldr>
most likely you won't be in trouble, but it's something to be aware of
mvnetbiz_8 has quit [Quit: Bye!]
<clever>
the bit of a weird part, is that the rpi uefi guys, refuse to even look at GPL'd code
<clever>
because its not compatible with the uefi license, and they dont want that even in their head
<samueldr>
so yeah, the CLA included the following:
<samueldr>
>> **Copyright License.** You hereby grant, and agree to grant, to LVGL a non-exclusive, perpetual, irrevocable, worldwide, fully-paid, royalty-free, transferable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute your Contributions and such derivative works, with the right to sublicense the foregoing rights through multiple tiers of sublicensees.
<samueldr>
which, withoug being a lawyer, sure sounds like "we own your code now, we can re-license as we please"
<clever>
yeah
<samueldr>
clever: that's a perfectly valid approach
<samueldr>
that way, though not easy to prove, he at least knows his contribution is not "tainted" (interpretations vary) by the GPL
mvnetbiz_8 has joined #nixos-aarch64
<samueldr>
so huh, I guess I don't have an issue with their project anymore... other than they changed the API way too much so I'll stick with the fork for the time being :)
<clever>
the only project i can think of where the license was maybe questionable, was realvnc...