My username I used there is the same as the one I used here. “joe-albanese”
I’m not an IRC user yet, but I just installed ii the other day with the intent of joining this one and Void’s IRC. I’ll see if I can get that going this evening
1 Like
I’ve been wondering lately if the usage of the openSUSE OBS might streamline the support for other deb/rpm/pkg-based distros… or other architectures perhaps? (non-arm64 fpga-layouts/CMs wink wink) It’d still be a bit of a long shot from truly universal packages but i believe if anything it’d provide an easily searchable resource 
Of course, i do have to disclose i’m a opensuse fan, so i am not exactly impartial, but i cant quite think of another resource that is both as featured and with no upstreams… Idea patches welcome?
A similar idea would be to package it for the nixpkgs repo, as nix can be installed as a package manager and used from most distros. It’s not very hard to go from .deb to nix package in most cases. I may look at this in the future once I get started on making NixOS work with my Pocket Reform. Others have already contributed a lot of effort here, so it may not be much work. We’ll see!
There is also the option of flatpak, perhaps a custom MNT-controlled repo rather than Flathub. (Flathub doesn’t really make sense for hardware-specific utils like this.) Almost all distros can use flatpaks. I’m not sure about the impact of sandboxing though.
Either of these would be a way to bring the tools to many distros without needing to worry about explicit support for niche distros.
Sure! If either @svp or @mountain set something up and you say that reform-tools could change this or that to make your life easier, please tell me and we can talk about adding these things to reform-tools.
With reform-tools release 1.66, the ./debian directory is now gone from it. New features do no longer have to merged into a branch that is not main (because there they would get picked up by the reform-debian-packages gitlab pipeline) but instead, new features can be pushed directly to main as with any other upstream project. Once a new release comes around, CHANGELOG.md gets updated and tagged. So development of reform-tools should now be much closer to how it would be for any normal project. The Debian integration is gone now.
4 Likes
@josch what license is reform-tools distributed under? I can’t seem to find any license info in the repo
Thank you, that is a very good point! The license information was recorded in debian/copyright but that obviously got deleted when I removed the debian directory from reform-tools. You can find the current version of debian/copyright here for an up-to-date overview:
https://sources.debian.org/src/reform-tools/latest/debian/copyright/
But of course the reform-tools project itself also needs to contain this information independent from the Debian packaging. Thus I now added it in this commit:
Thank you!
1 Like
I just made a PR to try and get this into the offical Void repos!
Since I made that dracut fix and you added the license back in, would you feel comfortable making a new release tag so that I can just tag my void package 1.69?
Nice! Do you have a link?
I’m about to make a new release. Do you want to help testing it? If you have some time, please consider applying this patch to the git HEAD: Debian Pastezone I’d appreciate any feedback.
Also, maybe reform-emmc-bootstrap is broken: Migration from i.MX8MPlus to A311D - #38 by G3M
1 Like
This is just reform tools. I have to finish making PRs for the kernel and qcacld2. I’m trying to set up a build machine with distcc so I can compile the kernel faster.
I’m also building the lpc driver as a separate DKMS package because it was more convenient with Void’s build system.
1 Like
Are you cross-compiling? That might give you acceptable build times for the kernel on a beefy x86 box.
Did you see my post about reform-tools 1.69? Request for help: reform-tools 1.69 release
Do you want to test these as well before I add the git tag?
Yeah I gave up on distcc and am just cross compiling on my x86 workstation.
I did not see your post about testing the new release but I will try it this evening and report any new issues.
Thanks a ton!
I’m having some issues with SDDM, but I’m like 80% sure it has nothing to do with the config file
help2man is unhappy with reform-compstat outputting --help to stderr instead of stdout
help2man is also unhappy with reform-mcu-tool but I haven’t looked into why yet
I plan on doing more testing tomorrow, but I don’t see any real issues with using the packages 
edit: looking closer it looks like it should be looking at the stderr out so I’m not sure why my packages isn’t building correctly 
reform-tools installs /usr/lib/sddm/sddm.conf.d/10-wayland.conf – maybe that contains bad content for void linux?
The Makefile runs help2man with --no-discard-stderr but if that’s a problem for other distros we can also dump --help output to stdout instead.
ha I figured it out. Help2man was giving me an error message that was saying something about stderr, but what was actually happening was I didn’t have python installed in my build container 
Easy fix
I figured out SDDM too. I was missing the kwin package. Question: where does the SDDM theme come from in Debian?
The sddm package Recommends: sddm-theme-debian-breeze | sddm-theme. The former is a real package and the default provider of the sddm theme in Debian. The latter is a virtual package provided by sddm-theme-breeze, sddm-theme-debian-breeze, sddm-theme-debian-elarun, sddm-theme-debian-maui, sddm-theme-elarun, sddm-theme-maldives, sddm-theme-maui and sddm-theme-maya.
2 Likes