wile_e8

I don't know how many people take the Tram in the middle of the winter, especially since the ski area hasn't opened the past few years. But it won't be open if you try. Hopefully the promised "quicker trips during busy periods" will materialize.

I know this isn't technically ABQ, but I drive up to Ski Santa Fe multiple times each winter and I'm guessing other people in this community do as well. The new technology mentioned in this article made it interesting to me.

The RFID passes aren't a big deal, but they are kind of nice. They could be finicky when trying to get on the lift when I had them at Red River, no better or worse than having someone manually scan passes. But being able to reload them without visiting the ticket office in the morning was great.

But this is the first time I've heard about the high-speed detachable lifts coming to Santa Fe, and I'm really looking forward to that even though it won't be there until next winter. I've only gotten to try them once, in Winter Park, CO, and spending half as much time sitting on a lift makes the day so much better.

The stadium still needs to get approved by City Council, but this was another step on the way that has been passed.

I don't know if anyone here actually cares enough to go an provide input, but it's nice to be aware that construction here is coming up a few years down the line.

The website for the project also mentions that reconstructing the I-25/Gibson interchange is further down the line. And also, construction on the Montgomery and Comanche interchanges with I-25 should be starting next year.

Are you calling for a ban on human driven cars? They killed more than zero people yesterday! If you aren't, you've accepted a human-driven vehicular homicide rate above zero.

I've always been pretty underwhelmed by In-N-Out, which has been fine the times I've tried it but never seems to live up to the hype. But having more options is nice (or will be, in 2027), although I'll make sure to wait at least a few weeks for the initial hype to die down.

Now, let me know when Culver's will be showing up....

I mean, that sucks, but it's not like things are going to get better once you're outside of the conditions mentioned

That's the plan! But it's still nice to know if these are the find I thought they were even if I don't plan on reselling them any time in the near future.

Kind of mixed on this. I think new EV infrastructure is good, and I think apartment complex (especially need ones) should be providing ways for residents to charge EVs. But requiring every new business to build EV charging in their parking lot seems like expensive overkill.

OK, so I looked though my browser history, and here are some relevant pages I found:

• keepassxc-browser Issue 1267
• keepassxc-browser Issue 1631
• keepassxc-browser Issue 1783
• browserpass-native Issue 93

I don't remember how much I used each one, but eventually I pieced together enough information information to get the Browserpass extension working in the Google Chrome flatpak. But three of those links are KeePassXC, which should be useful for adapting this for your use.

The main file that was having problems was the Browserpass Native Messaging Hosts file in my config directory for the Chrome flatpak, ~/.var/app/com.google.Chrome/config/google-chrome/NativeMessagingHosts/com.github.browserpass.native.json. Originally it was a symlink to a file at /usr/lib/browserpass/hosts/chromium/com.github.browserpass.native.json:

{
    "name": "com.github.browserpass.native",
    "description": "Browserpass native component for the Chromium extension",
    "path": "/usr/bin/browserpass-linux64",
    "type": "stdio",
    "allowed_origins": [
        "chrome-extension://naepdomgkenhinolocfifgehidddafch/"
    ]
}

The call to /usr/bin/browserpass-linux64 did not see to work for me, so I ended up making a copy of the file in the NativeMessagingHosts directory and modified it to point to a script in my home mount:

wile_e8 NativeMessagingHosts $ diff com.github.browserpass.native.json.orig com.github.browserpass.native.json
4c4
<     "path": "/usr/bin/browserpass-linux64",
***
>     "path": "/home/wile_e8/.config/browserpass/browserpass.sh",

I don't remember why I picked to do it inside the ~/.config directory, but it worked so I left it. And here is the script I put at ~/.config/browerpass/browserpass.sh:

#!/bin/sh
cd ~
/usr/bin/flatpak-spawn --host /usr/bin/browserpass-linux64 2>/tmp/error.log

I don't remember how I came up with that script, it must be somewhere in the four links at the top.

Finally, I needed to use Flatseal to allow access to the script. In the Google Chrome settings, under "Filesystem->Other files", I added an entry saying ~/.config/browserpass:ro. Also modified from the default in Flatseal, I have "Filesystem->All user files" enabled, along with "Socket->D-Bus session bus" and "Socket->D-Bus system bus". I don't know how necessary the last three are, but I'm not messing with it now that I have it working.

So, that's what I did to get the Browserpass extension working in the Google Chrome flatpak. You'll have to modify some things to get it working for KeePassXC, or for Firefox. But that general pattern should work.

Keep an eye out, I'll come back to this. It involves posting config file diffs and a script I wrote, it'll be a longer post I don't have the time to write right at this moment.

But yes, the fact that I need to find the time to post all the changes I needed to make to get this to work is part of the problem here.

FWIW I figured out how to get a password manager (Browserpass, not KeePassXC) to communicate with flatpak Chrome if you want some advice on how to get it to work.

But yes, it was way more difficult than it should have been (which is "should work out of the box, just like a regular package"). So if you're just listing some of the shortcomings of flatpak, never mind.