https://lists.sr.ht/~trs-80/public-inbox
sr.ht has been a very welcome breath of fresh air, and I am happy to be part of it.
Some times you can find me in #emacs on libera.chat.
From TRS-80 to ~sircmpwn/sr.ht-discuss
Jakob Neufeld <jakobneufeld@tutanota.com> writes: > Tutanota Stuff like this is why I stopped using Tutanota as well. Their non-standard way of doing things precludes the use of many power user email tools. That plus the fact that I realized, for private chatting, I would be better off using (self hosted) XMPP + OMEMO. In my case anyway, the vast majority of my email just does not contain anything really confidential. Mostly email from businesses I have relationships with (your package shipped, etc.) and mailing list correspondence which is public anyway. YMMV of course, but perhaps think hard about risk
From TRS-80 to ~mil/sxmo-user
After my last email, and further diagnostics in IRC, I think I am hitting this bug: https://gitlab.com/kop316/vvmd/-/issues/12 I sat down this evening to compile curl with the patch, which is the workaround mentioned in this post: https://gitlab.com/kop316/vvmd/-/issues/12#note_1059769797 But then I realized all the commands would be different on SXMO, being PostmarketOS (Alpine) based. I am a Debian guy, and quite out of my depth here, so any help would be
From TRS-80 to ~mil/sxmo-user
In IRC, wart_ had the idea to try and check DNS in the mobile network, so I did: pine64-pinephone:~$ ping -I wwan0 vvm.mstore.msg.t-mobile.com PING vvm.mstore.msg.t-mobile.com (2607:fb90:c13e:fff3::2): 56 data bytes 64 bytes from 2607:fb90:c13e:fff3::2: seq=0 ttl=55 time=773.702 ms 64 bytes from 2607:fb90:c13e:fff3::2: seq=2 ttl=55 time=476.503 ms 64 bytes from 2607:fb90:c13e:fff3::2: seq=3 ttl=55 time=222.383 ms 64 bytes from 2607:fb90:c13e:fff3::2: seq=6 ttl=55 time=175.082 ms 64 bytes from 2607:fb90:c13e:fff3::2: seq=7 ttl=55 time=204.936 ms 64 bytes from 2607:fb90:c13e:fff3::2: seq=8 ttl=55 time=356.556 ms ^C --- vvm.mstore.msg.t-mobile.com ping statistics --- 10 packets transmitted, 6 packets received, 40% packet loss
From TRS-80 to ~mil/sxmo-user
"Hartman, Peter" <phartman@luc.edu> writes: > Ok, I think you probably do need mmsd working, or probably the dns part > of that, but I guess we'll see. Yes, I remember reading about the DNS part and trying to get that to work as well, but not sure I was doing it correctly. > The log would be vvms log --- set SXMO_VVMD_ARGS to -d and then > monitor ~/.local/state/*/vvmd*.log or whatever. (Or just launch vvmd > -d) I apologize, but I am a Debian guy, and so I got used to SystemD commands for starting and stopping services. The following is still
From TRS-80 to ~mil/sxmo-user
It appears we got off list somehow. For the benefit of posterity, I've replied to the last on-list message, but below I quote the message I received off-list: "Hartman, Peter" <phartman@luc.edu> writes: > On Fri, Nov 11, 2022 at 08:00:15AM -0500, TRS-80 wrote: >>"Hartman, Peter" <phartman@luc.edu> writes: >> >>> Our code (sxmo_vvms.sh) just converts it into an sms with an audio file >>> attached to it, so once you have the vvm config file setup it should all >>> work. >> >>Where would those be located, and/or how to listen to them? Some menu >>option? I don't see anything.
From TRS-80 to ~mil/sxmo-user
"Hartman, Peter" <phartman@luc.edu> writes: > Should just install vvmd (its an alpine package), then there's a vvmd > config menu which is close to mmsd config menu. > > More details: > https://gitlab.com/kop316/vvmd > > Config file is ~/.vvm/modemmanager/vvm, which is what our menu edits for > you. Thanks for the fast reply. It looks like I have vvmd running already, actually. I tried to install
From TRS-80 to ~mil/sxmo-user
What do I need to do to get voicemail working? Install vvm? I read all the docs, poked around, but sadly I still could not figure it out. I see some menu entries in SXMO about voicemail, is this something that should 'just work'? If so, I may have buggered it up somehow. Cheers, TRS-80
From TRS-80 to ~mil/sxmo-user
TRS-80 <lists.trs-80@isnotmyreal.name> writes: > "Stacy Harper" <contact@stacyharper.net> writes: > >> I think you just dont have the driver patch he used for this. > > I think you are right. > >> Megi's tree is megi's tree :) He doesnt speak about the mainlined >> tree nor the tree used in your distro package. An update for interested parties. I cam across this in PINE64's October monthly update[0] (bottom of
From TRS-80 to ~sircmpwn/sr.ht-discuss
On 2022-01-12 13:23, Evan Boehs wrote: >> Is it just me who'd find a button leading back to the project from >> the associated sources, mailing lists, and tickets desirable? > I think we all would. The problem is that it is not a 1:1 > relationship between git repositories/lists/todo, it's actually > Many:Many. Repositories, for instance, can belong to many > projects. Projects can have many repositories. From the repository, > would there be a link back to every project that includes it? Thanks a lot for this explanation. In my naivete, I had assumed this to be a simple matter of adding a link, and then of course wondering what was taking so long (as I seem to recall this being discussed at
From TRS-80 to ~sircmpwn/sr.ht-discuss
On 2020-12-08 19:44, Nolan Prescott wrote: > TRS-80 writes: >> I am pretty sure this is because there is no provision to insert the >> id when constructing the link in the render_link[1] and/or maybe the >> render_plain_link[2] function(s). > > The issue is in how the id attribute was added to the sanitizer > whitelist. I've submitted a patch here: > > https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/15867 I can confirm this is now working! I pushed a small change in order to regenerate the HTML to test. Results (working in-page links generated by org-md-export-to-markdown function) can now be seen at: