<samueldr>
with Mobile NixOS, depending on the device, you start going way off the regular use case
<genevino>
not sure if that's "neat" or something. it's a love/hate relationship.
<samueldr>
I figure that if the android-based device *actually* goes in suspend mode it's going to have a way longer standby time, but no comms (so no notifications)
<genevino>
i run it on my everyday workstation and love to use it, but then again, sometimes i wish for being able to just fucking edit that file and call it a day, and not having to run nixos-rebuild switch each time or home-manager or something.
<samueldr>
when the pinephone's crust firmware is handled, it should handle suspend at a really low power use (but still no comms AFAIK)
<energizer>
i guess the downside with nixos vs android is that nixos has no application sandboxing by default
<samueldr>
whew, completely different use cases, but yes I see what you mean
<genevino>
i don't care about mobile devices. i have an iphone and an android telephone and hate both.
<energizer>
so anything bad i download from limewire will pwn the rest of my device
<samueldr>
hah :) I don't like the choices, so I'm making my own bad option now
<genevino>
i mean my workstation has 2 4k 32" screens, why would i want to use these tiny screen things that run out of battery twice a day with my kind of use
<genevino>
and quite frankly yeah i'm just considering to buy the 3rd one
<genevino>
viva la resolution!
<samueldr>
well, one reason to work on an alternative *open ended* solution for mobile is to be able to try different things, and mainly, manage it through the same mechanisms you (I) manage other devices
<genevino>
i fail to feel a strong connection to that kind of device. a real computer with a real keyboard is where it's at for me.
<energizer>
maybe it's the software that makes the connection, not the keyboard
<energizer>
i wont know until i have a nixos mobile
<samueldr>
energizer: do understand that I'm actually making no mobile software :) just like NixOS itself makes no DE-specific development work
<samueldr>
so hopefully whatever options there exists with non-Android linux out there are good
<cole-h>
bqv / colemickens: Do you guys get infinite recursion when using `nix-shell` or `nix-build`? I do, but the problem goes away with `-I nixpkgs-overlays=/var/empty`...
<bqv>
What is your nixpkgs-overlays normally?
<cole-h>
Oh, it may have to do with the fact my overlays is in overlays/default.nix (which nix-* uses, IIRC, but not nix(1))
<cole-h>
(I think nix-* implicitly imports ~/.config/nixpkgs/overlays or something)
<cole-h>
Yep, that was it.
<bqv>
Heh.
<cole-h>
Or rather, moving overlays/default.nix to test/default.nix didn't exhibit the same problem :P
<bqv>
I was mostly just interested if nixpkgs-overlays might end up being recursive
<cole-h>
nixpkgs-overlays was unset, FWIW
<bqv>
Ah
<bqv>
Well fuck, idk then :D
<cole-h>
But implicitly takes stuff from ~/.config/nixpkgs/overlays{/default.nix,.nix}
<bqv>
Yeah
<bqv>
I have an empty nixpkgs, mostly
<cole-h>
That's where I hold my config :P
<bqv>
"forOneSystem" heh
<cole-h>
:P
<cole-h>
Because if I had aarch64 in the "allSystems" list, I would be unable to build because cntr doesn't support aarch, apparently
<cole-h>
lol
<cole-h>
bqv++ Thanks again for all the help. Especially the `specialArgs` + `modules` magic (to be able to pass it to nixus, etc.)
<{^_^}>
bqv's karma got increased to 25
<bqv>
Np!
<cole-h>
Next task is to make passrs a flake :P
<bqv>
I'm still tied to bitwarden, or I'd be interested
<cole-h>
Heh, no worries. It's more of a personal project, though c*lemickens showed interest in the past.
<cole-h>
Still gotta read through pass's source and see what kind of ssytem quirks it deals with... 👀
<bqv>
Hmm, I'm curious how to get git-crypt to unencrypt modified files
<bqv>
It seems harder than it should be
<bqv>
*unmodified
<bqv>
Ah well, seems you can't keep them in-place
<cole-h>
How do you mean?
<cole-h>
"unencrypt unmodified files"
<cole-h>
bqv: Is it possible to have `{ asdf ? true, fds ? false }:` in a flake.nix for the defaultPackage?
<bqv>
Don't think so
<cole-h>
F
<bqv>
Its expected to be a derivation, not a function
<cole-h>
Yeah, figured :(
<bqv>
Also, I meant unencrypt some previously encrypted files
<bqv>
I'm decrypting stuff :p
<cole-h>
`git crypt unlock`?
<bqv>
Nah, I mean in git's context
<cole-h>
(Though I am sympathetic -- I had an issue with git-crypt last night because uninstalling git-crypt is super hard and I was testing something)
<cole-h>
At one point, I had to un-private my (encrypted) secrets repo on github so I could clone it and copy over the secrets (after decrypting them) :P
<bqv>
Heh
<cole-h>
Since I had symlinked my secrets -- which included ssh+gpg config
<bqv>
Yeah, I just moved a load of files out of legacy/ in my repo cause I can't seem to decrypt them for git, in place
<bqv>
Heh, flake no longer depends on legacy/ at all!
<cole-h>
bqv: (back to my earlier question) Wait, I could just have `asdf = { asdf ? true, fds ? false }: buildPackage { ... }` and then `defaultPackage = ... import self.asdf {}` maybe?
<bqv>
Yeah, sure
<cole-h>
Gonna try that. Sounds like a neat hack.
<bqv>
Heh
<bqv>
(the import is superfluousb
<colemickens>
So, I finally swapped the RAM out, going through zfs scrub errors and the top of the sorted list (of corrupt files) is: /nix/store/099ld7j971q0ij5ccv7kvin3lsxxzinw-nixos-system-slynux-20.09.20200827.33b4f64/init
<cole-h>
bqv: orly? just need to do `self.asdf {}`?
<bqv>
Ye
<cole-h>
bqv++ Sik
<{^_^}>
bqv's karma got increased to 26
<cole-h>
bqv: Now to see if `--arg doCheck true` does anything with this...
<bqv>
Lol
<cole-h>
Doesn't :(
<cole-h>
While that was a cool idea, time to just have a `test` attr and `overrideAttrs` the defaultPackage x)
<bqv>
My simple hack for that kind of thing is to have a tree in pkgs for that feature. E.g. pkgs.broken.haskellPackages.git, or pkgs.insecuressl.epsxe
<cole-h>
Appears I can't overrideAttrs naersk's buildPackage?
<cole-h>
bqv: OK, so back to my earlier idea :P
<cole-h>
bqv: Is there a way to default to the current system like `defaultPackage` does?
<cole-h>
(e.g. `nix build .#test` vs `nix build .#test.x86_64-linux`)
<bqv>
Heh, nope
<cole-h>
ffffffff
<bqv>
Thats a hardcoded shortcut
<bqv>
But it'll apply to packages
<bqv>
And legacypackages
<bqv>
So you could use those
<bqv>
e.g. .#test == packages.${system}.test
<bqv>
And .#test == legacyPackages.${system}.test
<bqv>
In that order :p
<bqv>
cole-h: ´
<cole-h>
assuming `packages` is also `forAllSystems ...`
<bqv>
Yeah
<cole-h>
bqv++ Cheers, that works!
<{^_^}>
bqv's karma got increased to 27
<bqv>
\o/
<bqv>
cole-h: fwiw that applies to "apps" too, e.g. `nix run`
<cole-h>
bqv: ...... Man, the `nix shell`/`nix develop` split is wreaking havoc on my brain
<bqv>
lol
<cole-h>
bqv: I just spent so long trying to get `nix shell` to activate the devShell attr
<samueldr>
:/ I had hopes for an obscure search, but looks like it didn't help
<samueldr>
good UI/UX though
<samueldr>
the github built-in search is not good for results that repeat themselves from being in multiple repos
<ar>
z/24
<samueldr>
ar: irssi's leaking out again
<ar>
samueldr: weechat, but yes
<samueldr>
heh
<ar>
i switched to weechat over three years ago. i should use alt+g more
<ashkitten>
good, github's search shits itself on special characters
<ashkitten>
etu++
<{^_^}>
etu's karma got increased to 26
<cole-h>
I'm so confused
<cole-h>
Flakes-based passrs builds fine when in debug mode, but libgit2-sys fails when in release mode
<cole-h>
Adding pkg-config fixed it though...
<cole-h>
bqv: Is there any way for a flake to get the current commit hash for itself? self.rev doesn't work.
<pie_>
etu: holy **** if that actually works
<pie_>
ive been wondering for months why teamviewer isnt working and i jsut realized it looks like you might have to enable a service
<pie_>
is it possible to temporarily enable a service without a system rebuild or do i need so start figuring out how to run this crap in a container? :P
<V>
systemctl start foo.service
* pie_
hopes it works with xvfb
<pie_>
guess i gotta dig some module guts again and get it to spit me out a service file
<pie_>
i always forget how to do that
* pie_
checks the service description
<pie_>
why they need a service to run the client is beyond me -_-
<pie_>
or maybe it is unrelated. who knows.
<cole-h>
bqv: Found it -- self.shortRev. Kinda wish it worked in a dirty tree, though (e.g. `self.shortRev` would be `<rev>-dirty`, instead of just "`<rev>` or attribute doesn't exist")
<pie_>
unless i run it in --pure the client outright fails to start properly and just "hangs" somewhere
<pie_>
samueldr: you dont want to make reporting bugs too easy ;)
<samueldr>
last time I reported a bug (on the bugzilla) I was basically told "oh, that, no one uses that"
<samueldr>
so now you have to basically wrangle a list of possible suspects, and annoy them directly
<samueldr>
because it wouldn't make sense to have some sense of centralized triaging
<etu>
>1000 emails a day :|
<pie_>
i should check out git-bug >.>
<samueldr>
and annoyingly I have strong suspicions the patch (commit) identified somehow only breaks my specific device, which also has issues specific to it
<pie_>
samueldr: we'll build our own kernel with blackjack and a proper workflows
<samueldr>
it seems that no one actually tested it once they contributed it to mainline
<samueldr>
which is maddening
<samueldr>
since its introduction it had *obvious* glaring problems according to a bisect expedition I was on
<pie_>
mainline needs a datacenter full of random devices which get tested automatically and you cant merge unless it works
<pie_>
samueldr: do you remember who i was talking to the other day about wine? I cant find it in my log
<Church->
Second one in a row that's died on me the exact same way.
<samueldr>
died how?
<Church->
samueldr: Storage/Storage controller
<Church->
Suddenly everything on disk drops away. I/O errors everywhere
<Church->
Reboot and I can't mount.
<Church->
So guess I'll get myself and apu2 setup... I know disasm uses that and it works.
<MichaelRaskin>
I have a quite old BRIX, where I need to re-seat the SATA cable from time to time to get the thing booting…
<samueldr>
flipping heck is the e-mail workflow built on so many fiddly and crumbly assumptions that never hold true
<samueldr>
right, gmail's SMTP server must have only one answer for any auth failure, rather than say "you didn't even try to auth you dum dum"
<samueldr>
now to get flamed at because I sent the e-mail with one too many byte somewhere or didn't do something arcane
<samueldr>
(I was sure I somehow had an issue with the app password, or some kind of 2-factor auth issue... while it was claws that by default doesn't auth with the same credentials as it does with IMAP)
<sphalerite>
Church-: we have a couple APUs in production at work, and they've been rock solid
<Church->
sphalerite: They support gigabit?
<sphalerite>
Church-: of course!
<sphalerite>
we use them as routers, specifically
<sphalerite>
one as the main router for one of our offices, more (with LTE modems) as remote management fallbacks in case the internet goes poof in the other offices, and another with an LTE modem as a router for off-site events