Closed colemickens closed 3 years ago
Thanks a lot, I really appreciate that!
I'm just going to ignore those tests they always work locally and never work in CI, no idea why. That particular test failed when it tried to detect terminal size. Should I make another release?
Have you used rumatui I'm curious if the markdown formatting works on other hardware/architecture?
I've got a new failure, but this could be a nixpkgs thing if you don't have any Cargo.lock diff pending?
> nix-build -A rumatui
these derivations will be built:
/nix/store/v2h8j2sl28d6cr5ch85s8p139rs0f4ff-rumatui-0.1.17.drv
building '/nix/store/v2h8j2sl28d6cr5ch85s8p139rs0f4ff-rumatui-0.1.17.drv'...
unpacking sources
unpacking source archive /nix/store/j4qsgqfrwk54rcz08mc96vaca9sz1j7k-source
source root is source
unpacking source archive /nix/store/ckgjbyrklpfhhnssl22layw012sww2wd-rumatui-0.1.17-vendor.tar.gz
patching sources
Validating consistency between /build/source/Cargo.lock and /build/rumatui-0.1.17-vendor.tar.gz/Cargo.lock
configuring
building
++ env CC_x86_64-unknown-linux-gnu=/nix/store/x45gpnpvbq0l3b933k187qh53y1fg7ll-gcc-wrapper-9.3.0/bin/cc CXX_x86_64-unknown-linux-gnu=/nix/store/x45gpnpvbq0l3b933k187qh53y1fg7ll-gcc-wrapper-9.3.0/bin/c++ CC_x86_64-unknown-linux-gnu=/nix/store/x45gpnpvbq0l3b933k187qh53y1fg7ll-gcc-wrapper-9.3.0/bin/cc CXX_x86_64-unknown-linux-gnu=/nix/store/x45gpnpvbq0l3b933k187qh53y1fg7ll-gcc-wrapper-9.3.0/bin/c++ cargo build --release --target x86_64-unknown-linux-gnu --frozen
error: the lock file /build/source/Cargo.lock needs to be updated but --frozen was passed to prevent this
If you want to try to generate the lock file without accessing the network, use the --offline flag.
builder for '/nix/store/v2h8j2sl28d6cr5ch85s8p139rs0f4ff-rumatui-0.1.17.drv' failed with exit code 101
error: build of '/nix/store/v2h8j2sl28d6cr5ch85s8p139rs0f4ff-rumatui-0.1.17.drv' failed
I can test rumatui on rpi4 whenever I get it building, I will let you know!
Let's try this, I rev'ed a git dep and un-gitingored the Cargo.lock file although strangely enough, it has been collecting commits this whole time.
So, it runs under aarch64, but I can't login anywhere....
Did you get any error or did it just hang with the loading bar going?
Oh, a bit of random feedback since I'm here, I also just ssh'd bcak into the raspberry pi, randomly checked htop
, and somehow rumatui was using two cores at 99% CPU.
That's odd, on a successful or failed login I never go above 10% and then it bounces around under 1%. Although the percentages would be relative to power so my comparison would be kinda meaningless, right?
I've added logging so hopefully we can get to the bottom of this. If you are willing to try this out again what's the easiest way for you to get it on the rpi, should I do another release?
The login fails on my desktop, I'll probably just test on there. I can build any commit easily, just let me know what commit you want me to try for debugging the login issue.
This commit c6bcca5cea7dac51712b6b82e84c6bc0ec501da0
or the logging
branch (same thing) has logging to ~/.rumatui/logs.json
by running with cargo run -- -v/--verbose
or rumatui -v
.
Are you passing a homeserver as an argument or are you just using the main Matrix server.
I'm not passing a homeserver. I tried colemickens
and @colemickens:matrix.org
as login names if I recall correctly.
How am I supposed to change fields? I have to click with the mouse. Also, once I get an error, it's just stuck and it also pegs my CPU at 100% on x86-64... and there's no logs. I built that commit and passed -v
. But maybe that's because I can't figure out how to quit rumatui...?
I tried colemickens and @colemickens:matrix.org as login names if I recall correctly.
You only need the local part of the user name so colemickens
should be enough.
Up and down arrows moves selected text boxes for login and registration, you can get to registration using the left arrow.
ESC exits.
This time it showed some moving ellipsis and acted like it was logging in, but ended with "Error" "An error occurred." "expected value at line 1 column 1".
I hit esc and backed all the way out and did get a log:
{"timestamp":"Jul 08 00:32:02.379","level":"INFO","span":{"device_id":"None","initial_device_display_name":"Some(\"rumatui command line client (LINUX)\")","name":"login","self":"Client { homeserver: http://matrix.org/ }","user":"\"colemickens\""},"target":"matrix_sdk::client","fields":{"message":"Logging in to http://matrix.org/ as \"colemickens\""}}
{"timestamp":"Jul 08 00:33:48.126","level":"WARN","target":"rumatui::widgets::app","fields":{"message":"an error occurred Unknown(\"expected value at line 1 column 1\")"}}
Ok I think I actually know what this error is about, if you delete the .rumatui/colemickens/
folder then try logging in again it should work. I need a way to "version" the JSON files that act as a DB.
Thanks for sticking with it I appreciate the reports and help!
Heh, so I did that:
> rm -rf ~/.rumatui
> $(nix-build ~/code/nixpkgs/pulls/rumatui -A rumatui)/bin/rumatui -v
Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }
Okay, mkdir -p ~/.rumatui
helped. But this time when I logged in:
An error occurred with a response from the server.
The user name or password entered did not match any know user.
Make sure you are logging in on the correct server (rumatui defaults to 'http://matrix.org').
I'm pasting from my pw manager so I'm fairly confident that it's correct.
And same thing. I can't "ESC" (it does nothing) and my CPU is spiking again on one core from rumatui.
I can't "ESC" (it does nothing)
Ah ok sorry it took me so long to get this one of the threads is panicking and a channel is shutting down or the other way around. My guess would be that it then loops trying to send or receive from that channel?
I pushed to the logging
branch adding more logging calls in spots that may catch it. More importantly the logger now works constantly not just when it is dropped.
commit e481b1019d093716bb5aaa12a9b87ba91c69b88b
rumatui defaults to 'http://matrix.org'
@DevinR528 That's a typo, right? :O (the http
instead of https
)
No I was using http://matrix.org
in the app, trying https://...
works also but I seem to remember at one time it did not work for me I'm assuming I should change it to https
?
IMO, yes definitely. Nothing should default to http these days.
:| It absolutely should be https. I wish I would've reviewed this before trying to login so many times. In fact, I'm surprised Matrix even allows it.
From chatting in a Matrix rooms, it sounds like pointing at http://...
will just make the client start discovery there. The discovery endpoints advertise https://...
urls for the client to use for login. So there's no concern here after all.
While that makes it much less likely that your ISP now has your messages in their logs, it's still something to be fixed as discovery using plain HTTP means that a MITM could make you authenticate over plain HTTP as well.
Besides fully agreeing with you @jplatte, it also appears clients dont't necessarily always to use the discovery endpoint, for example, if the HS server is specified directly (which appears might be what's happening based on a quick peek at the code).
Well sorry about all that. Logging with default https
is 4c408570338d54e9652dfb0017f29c386b13823c
, which is also master now.
I'm going to close this unless there was any progress?
Hi. I'm packaging this for Nix/NixOS users but am hitting a problem during the test phase: