Multiple people have pinged me regarding lineageos.disavowed.jp having issues.
lineageos.disavowed.jp was deprecated several months ago in favor of lineageos.rezrov.net and the SSL certificate for the old domain finally expired.
I’ve therefore removed the HTTPS redirect to lineageos.rezrov.net with a simple HTTP redirect (because, natch, there won’t be a valid SSL cert for the redirect anymore).
Again: lineageos.disavowed.jp is dead. Use lineageos.rezrov.net.
Thank you.
Octoprint is neat. However, the USB/webcamera support is a bit obtuse — especially when you throw haproxy into the mix.
The Octoprint documentation recommends using mjpg-streamer as a standalone daemon to convert a v4l video stream into a HTTP stream … and use haproxy to selectively redirect traffic to that stream when an arbitrary value prepends the HTTP URI.
There are a few issues:
Wanting this to work, I looked around for a simpler scheme. I came across Igor Maculan’s “Simple Python Motion Jpeg” daemon (https://gist.github.com/n3wtron/4624820), which looked promising.
I spent a few hours this morning porting it to python 3.x, fixing a few bugs, and adding command-line tunables. It works, and it works well. It is available on GitHub at https://github.com/christopherkobayashi/octoprint-stuff/blob/main/webcam.py
Below is a working haproxy.cfg that handles SSL:
global
maxconn 20000
log 127.0.0.1 local0
user haproxy
chroot /usr/share/haproxy
pidfile /run/haproxy.pid
daemon
defaults
timeout connect 5s
timeout client 1m
timeout server 1m
frontend public_ssl
bind :::443 v4v6 ssl crt /etc/letsencrypt/live/both.pem
use_backend webcam if { path_beg /webcam/ }
default_backend octoprint
backend octoprint
mode http
http-request replace-uri '^([^\ :]*)\ /(.*)' '\1 /\2'
option forwardfor
server octoprint1 127.0.0.1:5000
backend webcam
mode http
http-request replace-uri '^([^\ :]*)\/webcam/(.*)$' '\1/\2'
server webcam 127.0.0.1:8080The Octoprint web camera URL should be “https://${SERVER_NAME}/webcam/${SOMETHING}.mjpg”. ${SOMETHING}.mjpg can be anything, actually … webcam.py will respond to any request with a MJPEG stream.
I hope this saves time for others banging their heads against Octoprint’s … interesting camera support scheme.
While cleaning up my work room a few months ago, I found an old Asus Zenfone 2 tucked away in a desk drawer.
The Zenfone 2 is a neat idea executed poorly. It’s dual-SIM (which is why I bought it — it was my China phone, with a China Mobile and a Hong Kong SIM), solidly constructed, with a really good screen. However, one of the SIM slots is 2G-only, it’s using an Intel Atom (x86) processor, and the battery is infamous for randomly dying.
I hooked it up to a USB charger, figuring I’d give the battery a good solid regenerating charge to see if it was worth keeping, and promptly forgot about it. I discovered it again a few days ago (still charging) and tried it out.
Much to my surprise, it booted.
It was supported by LineageOS 14.1. I did a quick build, flashed it onto the device … and it still worked. I’ve added it to the weekly build rooster.
Stock TWRP 3.3.1 (as sourced from twrp.me) works fine. The MM bootloader is probably required; I’ve put a copy of the upgrader in the z00a directory.
Magisk will not work. There’s something odd going on with the bootloader’s kernel image integrity check — after Magisk injects itself into the image, the bootloader will refuse to load it, choosing instead to enter recovery. The fix there is to use LineageOS’ addonsu package. The binary on the official LineageOS site will not work, as one of the ABIs apparently changed in the past few years. I’m now generating the addonsu (and addonsu-remove) package along with the regular build for each platform.
On a different note: I’ve moved the repository from lineageos.disavowed.jp to lineageos.rezrov.net. These builds are apparently a bit popular; I’m seeing people grab these from all over the place (referred from YouTube tutorials, Russian and Japanese forums, in addition to the usual XDA traffic). That makes me happy, but …
… unfortunately, only six people have donated to the webhosting fund. I’ve had to bring the repository in-house to cut costs. I’m really disappointed in the gimme-gimme-gimme mindset displayed by the vast majority of LineageOS users.
I’ll keep the builds available as long as I can, but do not be surprised if the site is one day replaced with a static “so long and thanks for all the fish” page to keep my ISP from throttling my bandwidth. At that point I’ll post my build script and redirect software-lineageos@disavowed.jp to /dev/null.
Anyway … enjoy the Z00A builds.
I’ve been repairing old 68030- and 68040-class Macintoshes for the past few years. It’s a fun hobby, and allows me to reconnect to an Apple era that was long-gone by the time I joined Apple.
At this point, we have a SE/30, a Classic II, a IIsi, an LC III, a Centris 650, a Quadra 700, and a Quadra 950. All are networked, either through Asanté PhoneNet-to-Ethernet bridges or direct Ethernet.
For the last quarter-century, Netatalk has been the go-to solution for file/printer sharing between UNIX and AppleTalk. Version 2.2.6 was the last release that supported classic DDP AppleTalk (as opposed to AppleTalk-over-TCP/IP, aka “DSI”). Unfortunately, the codebase rotted a bit and needed cleanup to run on current Linux and NetBSD releases.
Now that I’m retired, I have time to work on fun projects like this. I’ve spent the past few months refactoring the 2.2.6 codebase; it’s now at the point where I consider it good enough for public consumption.
I’m calling it “netatalk-classic”. It works out-of-the-box with NetBSD, and seemed okay on Linux once they fixed the Huawei commit that broke AppleTalk (as discussed at https://www.downtowndougbrown.com/2020/08/hacking-up-a-fix-for-the-broken-appletalk-kernel-module-in-linux-5-1-and-newer/ — full disclosure, I’m the guy that tried and failed to get the maintainer to fix the broken code that he himself had approved, so I’m a bit bitter).
Release tarball is at https://github.com/christopherkobayashi/netatalk-classic/archive/20200921.tar.gz and the GitHub source is at https://github.com/christopherkobayashi/netatalk-classic
Share and enjoy. Please drop me a line if you find this useful or need functionality that was removed.
The LineageOS team is shutting down builds for 15.1.
Ari Opari has asked for Sony Xperia Tablet Z LTE (pollux) builds. They’ve been added to the rooster and are at https://lineageos.disavowed.jp/pollux
At the request of Sachin Saini, I’ve added the Huawei Honor 5X (kiwi) to the weekly 15.1 build rooster. Share and enjoy.
It looks like the LineageOS team got around to fixing what they’d broken in the hammerhead 15.1 tree. Builds have commenced.
Kudos to Uwe for giving me a heads-up — much appreciated.
It looks like a commit last week to the 15.1 branch broke builds for hammerhead:
ERROR: /mnt/second/android/lineage15/packages/apps/LineageParts/src/org/lineageos/lineageparts/livedisplay/LiveDisplaySettings.java:401.60: config_enableLiveDisplay cannot be resolved or is not a field
I’m seeing discussion about this on other devices (https://www.reddit.com/r/LineageOS/comments/feuc3e/build_for_mako_fails, for example) that indicates that this isn’t isolated to hammerhead. It seems that devices that don’t have active maintainers weren’t updated to handle a feature change.
15.1 on hammerhead builds are going to fail until this is fixed.
The OpenSSH team has a habit of turning off ciphers/features every few releases. The rationale behind this decision is open to debate (this breaks compatibility with Cisco switches, for example), but so far they are only disabling by default rather than removing.
So long as it’s just disabled, it’s easy enough to re-enable. Here’s what to tweak when trying to connect a MacSSH client to a OpenSSH server:
Ciphers +aes256-cbc MACs +hmac-md5 KexAlgorithms +diffie-hellman-group1-sha1
ssh-keygen -f ${PUBLIC_KEY_FILE} -i >> ~/.ssh/authorized_keys
That should do it. At some point I may hack a more current version of lsh into MacSSH to add new ciphers into the suite, but this works for now.
So yes, the weekly LineageOS builds have been a bit sporadic lately.
Both deb and flo 14 builds started claiming that the jack server had disappeared. I temporarily removed them, which made other builds complete, but the build times would range wildly between one hour to six-plus hours per.
I’ve tweaked the build infrastructure (yet again!) to spread out the load a bit. Builds are now going to happen a few batches per day, Monday through Wednesday. I’ll keep an eye on things and see how it goes.
If you use my LineageOS builds, please consider donating.
