<Shados>
samueldr: Shouldn't be 2 weeks unless it was previously unlocked on another account/sim, fwir. Should only be... I think either 48 or 72 hours, I forget.
<samueldr>
Shados: information is out of date pretty much everywhere
<samueldr>
it's now 360 hours
<samueldr>
new xiaomi account, new device
<Shados>
"now"... I did this a few months ago
<samueldr>
I did this 15 days ago
<Shados>
they change their policies pretty quickly eh
<samueldr>
yeah
<samueldr>
it's a real bother
<aanderse>
samueldr: were you the person working on nix on phone?
<samueldr>
yeah
<aanderse>
mmm
<samueldr>
and fun thing, apparently if you try to cheat it, they add more time
<samueldr>
(there were methods to cheat it that they fixed recently)
<samueldr>
I hope that if/when they remove devices from the unlock service servers, that they release a tool to do it offline, otherwise it's going to be bad at one point in the future :/
<samueldr>
(let's face it, if/when it happens, they won't have anything to lose so they won't do it, most likely)
<samueldr>
btw, don't all go buying that phone, there's no way to know if there's a show stopper yet!
Synthetica has quit [Quit: Connection closed for inactivity]
clever has joined #nixos-chat
iqubic has joined #nixos-chat
drakonis has quit [Quit: WeeChat 2.4]
gchristensen has quit [Quit: Connection closed for inactivity]
Myhlamaeus has joined #nixos-chat
iqubic has quit [Ping timeout: 248 seconds]
Myhlamaeus has quit [Ping timeout: 248 seconds]
endformationage has quit [Quit: WeeChat 2.4]
noonien has quit [Read error: Connection reset by peer]
kalbasit has quit [Ping timeout: 276 seconds]
<joepie91[m]>
samueldr: tbh, Xiaomi's approach sounds quite reasonable to me
<joepie91[m]>
I much prefer it over just preventing any kind of reflashing full stop :)
<joepie91[m]>
this sounds like they made a genuine effort to not break it for legitimate users
sdier has quit [Ping timeout: 276 seconds]
pasukon has quit [Ping timeout: 252 seconds]
tazjin has quit [Ping timeout: 252 seconds]
pasukon has joined #nixos-chat
sdier has joined #nixos-chat
tazjin has joined #nixos-chat
kalbasit has joined #nixos-chat
noonien has joined #nixos-chat
{^_^} is now known as Guest7513
nix-build has joined #nixos-chat
Guest7513 has quit [Ping timeout: 252 seconds]
nand0p has quit [Ping timeout: 252 seconds]
noonien has quit [Ping timeout: 250 seconds]
noonien has joined #nixos-chat
sdier has quit [Ping timeout: 252 seconds]
sdier has joined #nixos-chat
cbarrett has quit [Ping timeout: 250 seconds]
nand0p has joined #nixos-chat
nix-build has quit [Ping timeout: 252 seconds]
cbarrett has joined #nixos-chat
nh2 has quit [Ping timeout: 250 seconds]
pie_ has quit [Ping timeout: 252 seconds]
nh2 has joined #nixos-chat
<flokli>
samueldr: my phone came pre-unlocked from where I bought it (some importing company, IIRC based in spain)
<flokli>
first thing I did was flash my own rom to it :-D
<flokli>
xiaomi mi note 3
pie_ has joined #nixos-chat
<pie_>
clever, grahamc any ideas for throwing together an exercise list (/ things i know how to do checklist) for some sort of semi-ad-hoc nix mastery progression? maybe mostly to just highlight areas someone might have forgotten to work on
<pie_>
ah grahams not here right now
tilpner has quit [Quit: WeeChat 2.4]
tilpner has joined #nixos-chat
<pie_>
mostly unrelated, anyone know a good crash course on systemd services? or just any suggestions on how to deploy an executable to a server?
__monty__ has joined #nixos-chat
<averell>
maybe we should mine for common problems from #nixos
<pie_>
averell, ive thought of that before but i dont have any good ideas on how to do it
<pie_>
time to throw some NLP at the channel but im not set up for that
<ivan>
grep nixpkgs for systemd.services
<pie_>
ivan, i figured i could look at examples but that would be clueless copy pasting
<ivan>
well I mean you could read the systemd docs, the nixpkgs systemd stuff maps to that
<__monty__>
Weechat needs an external script to autoconnect?
<averell>
no, /server add ... -autoconnect
<averell>
i think even reconnect with exponential backoff is default
<__monty__>
Was thinking autojoin.
<averell>
maybe, at least i have that installed. IMO it's easiest to put a znc in the middle to handle that.
<__monty__>
Disagree. Having a client autojoin *is* simpler than setting up an always running bnc.
<__monty__>
Doesn't matter though. Just surprised because weechat usually does things irssi doesn't. It's the other way round here.
<averell>
if you only use one machine maybe
<gchristensen>
heh this doesn't do that at all!
<__monty__>
I already run an always on server. Still nice to have the freedom to just reboot that whenever.
<gchristensen>
the important thing is that when you join and leave channels, and connect / disconnect to servers, it automatically updates and saves the configuration
<__monty__>
Ah, that makes more sense.
<gchristensen>
I do run weechat from an always on server, and use ssh & screen to connect
<gchristensen>
I never "Got" znc.
<averell>
and apparently it does by setting irc.server.%s.autojoin properties. so phew, irssi loses again :)
<averell>
well you couldn't use a graphical client then for example
<gchristensen>
sure
<averell>
or you have to visibly quit for client config tinkering
<gchristensen>
aye, if that is important to you, I understand
<averell>
but yeah, it's probably not all that necessary in that case
<averell>
but really, screen? is that like a nostalgia thing? :)
<gchristensen>
but I haven't even updated the list of channels to join since 2009
<averell>
haha, wow
<gchristensen>
not sure why I'd switch from screen tbh
<__monty__>
Irssi loses how?
<averell>
cooler prompts? i dunno, i guess it works.
<averell>
well it's not the other way round that irssi does something weechat doesn't :)
<averell>
(that setting is built in)
<__monty__>
gchristensen: I think a good application of a bnc might be if you irc from a phone?
<gchristensen>
yeah
<averell>
weechat has a relay built in for that, even including unread from the client etc
<gchristensen>
only an ANdroid client atm though
<joepie91[m]>
frankly I've found IRC-via-Matrix to be a far more pleasant experience than any ZNC-based setup
<joepie91[m]>
even despite the IRC bridge lag
<joepie91[m]>
deals much better with intermittent connectivity, and doesn't require me to mentally parse two different formats (normal messages from users, and backdated ZNC messages)
<etu>
gchristensen: Mine autoconnects and autojoins by default
<etu>
with intcremental backoff
<joepie91[m]>
also, Riot Android is far better than any IRC client I've used for Android :/
<etu>
Weechat Android is quite nice
<etu>
But that's not an IRC client
<etu>
it's a relay client
<__monty__>
Is there a quassel mobile client?
<averell>
is it better than glowing bear? that's what i use, but it's kinda old-fashioned
<gchristensen>
etu: I think the name of the script misconstrues what it does
<aanderse>
infinisil recently convinced me to try znc
<aanderse>
so far i'm happy with it
<gchristensen>
etu: because when I was looking for something that does what this script does, you said you were also interested
<etu>
aanderse: I never understood why I want a bouncer, I kinda use weechat as a bouncer but with a ncurses ui as well
<joepie91[m]>
averell: not sure if I've tried that, but from a look at screenshots: most likely, yes
<etu>
gchristensen: Ah, the syncing of which channels you're in?
<gchristensen>
etu: so I encourage you to read the 95 lines of code :P
<joepie91[m]>
averell: (or was that a question for etu ?)
<etu>
joepie91[m]: I haven't tried glowingbear except in a browser at some point
<averell>
both is good, i might try matrix-mode :) i like having multiple channels visible at the same time, is that possible with these slack-like UIs?
<aanderse>
etu: yeah, it was the first one on a list to try... and then i never continued as it seemed to work
<joepie91[m]>
etu: you probably meant to highlight averell ? :P
<etu>
averell: But differences I can think of straight up front is that weechat android is less "modern" like it doesn't show inline images etc
<etu>
joepie91[m]: you're right
<etu>
joepie91[m]: Many threads atm :D
<joepie91[m]>
hehe
<etu>
aanderse: Yeah, that kinda happens. You settle on things, if it's aint broke etc :)
<gchristensen>
I *do* like to see when companies paste my articles in to their slack
<aanderse>
mhm
<aanderse>
etu: i can't recall if you mentioned at some point in the past... is your gitea instance running on postgresql?
<etu>
aanderse: It does yes
<aanderse>
ohh....
<aanderse>
:)
<etu>
aanderse: But it's on 18.09, haven't migrated yet. I should move it to my newer 19.03 VPS on another hosting provider
<etu>
So it's a bit old :)
<aanderse>
oh right, yeah you said that too
<aanderse>
hmm
<aanderse>
ok
<etu>
Any week now so I can stop paying double the cost :p
<aanderse>
ha
<aanderse>
hoping for someone with existing pgsql install will get a chance to test the changes in that gitea pr i pinged you on
<aanderse>
:smile:
<etu>
That will be hard on my current one since yeah, old :p
<aanderse>
mhm
<etu>
I should migrate the data to my newer one and test your PR there before I actually make the switch :)
<aanderse>
my gitea changes in that PR require pgsql changes which are in master
<etu>
The newer one also has a tmpfs / setup :D
<etu>
ohh
<etu>
That new
<aanderse>
yessir
<etu>
I could probably run that vps on unstable
<etu>
The new one
<aanderse>
hmm... no one has kicked us out of #nixos-chat for being off topic of off topic yet
<etu>
hah
<etu>
aanderse: Yeah, I've seen the PR but haven't had the time to try it out yet
<aanderse>
toying with my emotions T_T
<aanderse>
etu: yeah, no worries, still in draft mode :)
<etu>
It was quite a bunch of changes
<etu>
Not bad ones!
<etu>
But still a bunch
<aanderse>
yeah. read the changes commit by commit. and i was really torn on whether to break into multiple prs or not
<aanderse>
put it as one, but made mention if anyone wants i'll split
<etu>
It's reasonable as one PR since all the commits does related things but for different areas
<samueldr>
(regarding bootloader unlocks) I don't think the xiaomi approach is right, and fine. It is understandable because of the situation they were put in by their supply chain... but make the parallel to a laptop. Waiting 2 weeks before being able to remove windows from it is crazy
<pie_>
gchristensen, i guess i dont see why nix-env couldnt have some sort of activation script thing. if it can put stuff in .nix-profile/bin for me (well ok thats probably just a matter of symlinking .nix-profile to a new profile generation i think?) why couldnt i get it to do other stuff too
<pie_>
unless you didnt mean that youre against it and its just not implemented
<gchristensen>
it doesn't *put* anything in .nix-profile/bin, it makes a new one
<gchristensen>
the fundamental difference is constructing something from scratch (as if it had always been) vs. mutating your system to become something new
<gchristensen>
always push as much as possible to be correct and complete by how they are built, and remove as much as possible from a mutation step
<pie_>
sure
<pie_>
but some things cant be done in some ways
<pie_>
gchristensen, i guess for that example i just meant its doing something outside the store
<pie_>
but thats not much of an argument for putting arbitrary mutative functionality in it
pie_ has quit [Ping timeout: 252 seconds]
<gchristensen>
Nix is a tool for construction, whatever else needs to be done can be built as tools on top
<Taneb>
Speaking of things built on top of Nix...
<Taneb>
I'd like there to be a way for Hydra to have a way to include details from tests that can't happen in a Nix build, due to, eg., having to communicate with other machines in such a way that makes using VMs or similar infeasible
<gchristensen>
oh?
<Taneb>
We do tests as part of a RunCommand plugin invocation that needs to reboot an FPGA host, and currently we just post the results to Slack
* gchristensen
is very paying attention
<Taneb>
It'd be nice if in the RunCommand we could go back and mark the build in at least the Hydra interface as a failure
<Taneb>
But this is, for fairly solid technological reasons, not an option
<gchristensen>
can you write up, a bit more formally, what needs to happen?
<Taneb>
I can give it a go, but it might be Monday if at all
<Taneb>
(about to go home from work and I've got weekend plans)
<gchristensen>
ah
<gchristensen>
ok, informally
<gchristensen>
how do you know the test failed? what runs the thing which failed?
<Taneb>
So, Hydra has a "RunCommand" plugin which lets you run some script on the completion of a job.
<gchristensen>
yep
<Taneb>
We're using that to run some tests which cannot be part of a nix-build, and currently sending the results of the test to a Slack channel
<gchristensen>
ooh
<Taneb>
I'd like for the results of this test to be marked in Hydra somehow, but this would require Hydra to store information about build results in some database outside the Nix store
<gchristensen>
you could make the sandbox mode relaxed, and then disable sandboxing for the FPGA tests -- and run the FPGA tests inside a nix build
<Taneb>
Hmm, that is true.
<Taneb>
We're already disabling sandbox for some builds
<gchristensen>
how do you talk to the fpga?
<Taneb>
ssh to a machine connected to the FPGA, program via PCIe, reboot the FPGA host, run tests also via PCIe
<gchristensen>
does that machine run nix?
<Taneb>
Yes
<gchristensen>
cool, is the pcie device like /dev/mycoolfpga?
<Taneb>
I'm not sure, I've not been involved in that side of things as much as I'd like
<gchristensen>
ok
<Taneb>
Let's say it is, for now
<gchristensen>
if so, it is possible to also specify additional impure paths
<gchristensen>
for example, Nix already does this for /dev/kvm
<Taneb>
Remember that as part of the tests the machine with the FPGA needs to be rebooted
<gchristensen>
right
<gchristensen>
oh the whole machine
<Taneb>
Yeah
<gchristensen>
ah. that is more challenging :P
<Taneb>
There's still things to think about here, thank you very much :)
<Taneb>
I'm going to sign off for now, though
<gchristensen>
glad to help! also, I'd be interested in knowing more
<gchristensen>
(in private if need-be)
drakonis has joined #nixos-chat
Myhlamaeus has joined #nixos-chat
drakonis1 has quit [Ping timeout: 246 seconds]
drakonis_ has joined #nixos-chat
drakonis1 has joined #nixos-chat
drakonis has quit [Ping timeout: 248 seconds]
drakonis_ has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-chat
drakonis1 has quit [Read error: Connection reset by peer]
drakonis has quit [Ping timeout: 259 seconds]
MichaelRaskin has joined #nixos-chat
waleee has quit [Quit: WeeChat 2.4]
<samueldr>
heh, just realised that #aarch64-laptops has an over-representation of nixos lurkers :)
<gchristensen>
oops forgot to add that to my join list
<ar>
heh
<ar>
i'd love an aarch64 laptop in the formfactor (incl. keyboard/trackpoint and battery capacity - 96Wh) of a thinkpad X260/X270
<samueldr>
#aarch64-laptops is about those qualcomm-based WoA laptops mainly
<samueldr>
though, shared on #nixos-aarch64, but since the topic here is relevant
<samueldr>
>> The RYF has a “secondary processor” exclusion that can be granted on a case by case basis. We will leverage this exclusion to load and train the DDR PHY on the i.MX 8. We will use a secondary processor to keep binary blobs out of u-boot and the kernel.
<samueldr>
>> This implementation keeps the A53 core “clean” of binary firmware blobs and the M4 is the “secondary processor” that handles the blobs.
<samueldr>
"our main CPU cannot touch the icky blob, so it's Free" — apparently purism :(
<gchristensen>
sheesh
<samueldr>
maybe I am misreading it
<samueldr>
but I think I am not
<samueldr>
and, there is an implementation detail I am not sure of
<samueldr>
is the M4 cpu accessible afterwards for the end-user?
<samueldr>
if it is not, it's basically a CPU that's acting like an hidden rootkit, that has access to all the hardware, that has been co-opted for loading a blob out of sight
hedning_ has quit [Quit: hedning_]
<MichaelRaskin>
Well, it depends on what access it actually has.
<samueldr>
>> The M4 has access to all of the peripherals attached to the i.MX 8 so our initial proof of concept reads the DDR PHY firmware from the MMC card and then the M4 takes over to load it into the DDR PHY. Then U-Boot runs the training algorithm and initializes the DDR.
<samueldr>
so it reads "same as the main CPU"
<samueldr>
which makes sense since "the i.MX 8 has some A53 cores and an M4 core all on the same silicon"
<samueldr>
and if the M4 core is out of reach for end-users, it's even a double-whammy considering it could be used for low power operations, AFAIUI something like that is possible on beagle boards
<MichaelRaskin>
Ouch
<samueldr>
all conjecture based on the few information points in the post; in many ways I hope I'm wrong
<gchristensen>
perl[1487]: segfault at 7fffff7feff8 ip 00007ffff7d9f352 sp 00007fffff7feff0 error 6 in libperl.so[7ffff7cf1000+15c000] <- neat.
<MichaelRaskin>
Should have used bash!
<gchristensen>
+1
<gchristensen>
I suspect my home server is dying too (when it rains it pours)
<MichaelRaskin>
Ouch
<MichaelRaskin>
Also known as «the entire general area has received HDDs from a single production run»?
<averell>
it's probably just scared it'll be beered next
<gchristensen>
I think more likely memory problems, I'm sending it memtest86 and we'll find out
<gchristensen>
my other (hosted) server's entire mainboard whet kaput: it stopped booting and its BMC stopped replying about 3 days after the first signs of failure
jtojnar has joined #nixos-chat
ma27 has quit [Quit: WeeChat 2.4]
<adisbladis>
samueldr: That's the FSF approach to firmware overall.. I think it's ridiculous.
<samueldr>
I'm glad I'm not alone
<samueldr>
invisible closed firmware is worse than observable, maybe tinkerable-with, firmware
<samueldr>
it should be roped off with a "look at these shameful bits, please help and fix this" instead of the "what firmware?" approach :/
<adisbladis>
Taneb: Hmmm.. I know some other people using Hydra for testing FPGAs. I wonder how they do it.
<adisbladis>
A userspace loadable firmware can be reverse-engineered and overriden, bundled ones not so much...
<samueldr>
an implement with two or more prongs used for lifting food to the mouth or holding it when cutting.
<qyliss>
This got me thinking about how nice it is that nixpkgs’ model lends itself so well to having your own tree and just taking the bits you need from other people working on it
<qyliss>
Which I do a lot
<samueldr>
nixpkgs composes neatly
<adisbladis>
samueldr: Oh I know this one! That's a hand with chopsticks attached!
<samueldr>
it wasn't a riddle, I was answering the confused^W^W drewdevault :)
<adisbladis>
I know :)
<gchristensen>
huh, tmpfiles.d is pretty annoying for deleting temporary files
<gchristensen>
quite slow and blocks
<qyliss>
Flakes will be subject to an RFC before it makes it into a nix release, right?
<qyliss>
Cool thanks. Was just reading about it and wanted to make sure I knew when the right time to state my opinions was.
<gchristensen>
qyliss: any time :)
<qyliss>
What’s the proper venue for that sort of thing?
<gchristensen>
it depends on what it is I suppose
<gchristensen>
NixOS/nix is a good bet
qyliss^work has quit [Ping timeout: 252 seconds]
ma27 has joined #nixos-chat
qyliss has quit [Ping timeout: 258 seconds]
qyliss has joined #nixos-chat
qyliss^work has joined #nixos-chat
jtojnar has quit [Ping timeout: 268 seconds]
pie_ has joined #nixos-chat
<gchristensen>
I think that segfault I was seeing is a bug in git and/or perl
drakonis has quit [Ping timeout: 248 seconds]
__monty__ has quit [Quit: leaving]
<andi->
samueldr: yeah, the FSF definition of a free system is nice and all but exactly those workarounds make the entire thing less attractive. On the one hand it is great if the firmware is really immutable and you do not have to worry about that while tinkering but also what you said.. Maybe in a year we find a serious bug in it. Maybe we have an open-ish alternative, …