pijuice support on fedora

[komacke]

With the imminent release of fedora 37 that has official RPi 4 support, it would be great to have pijuice app support.

Is anyone working on this? Could you share your work or would you like to collaborate?

I got pijuice_cli.py and pijuice_gui.py to run. They seemed to come up on the non-default bus of 3 rather than 1. When I ran Raspberry OS on this device pijuice worked out of the box. I'm trying to figure out if the debian package has some discovery mechanism or if somehow the OS (fedora) enumerates the bus differently.

Fedora seems to want only root to access /dev/ic2-*. Investigating the best way to have the app work without root privileges. Currently I have to run cli and gui as root.

I haven't worked on icon-tray apps before. Not sure if the app will work on gnome 43 without modifications after the root business is sorted out.

So far I have only found these package dependencies and I've only had to change the default bus:

• python3-i2c-tools
• python3-tkinter
• python3-urwid

[komacke]

I've finally gotten around to playing with this. I've upgraded to Fedora 39 Beta. Fedora uses linux device tree rather than firmware device tree like Raspberry OS. although Fedora can be switched to firmware device tree.

I'm not able to get linux device tree working with pijuice satisfactorily. It would require additional scripts and I can't figure out a way to cleanly had a reset RTC throwing the system for a loop when it resets the system time to 2000. So the implementation will require firmware DT.

For those interested, kernel-core-6.5.6 has a bug that does not place the kernel DT folder in /boot. It took me a while to realize in fact my Pi was running in firmware DT mode. There's a way to force Fedora to use firmware DT which is what I recommend going forward.

The next issue is that the python scripts use /tmp for pid and lock files. Since /tmp is ephemeral and gets cleaned up occasionally, we need to move this into /run or /var/run.

[komacke]

Another bonus appears to be that gnome 45 allows task bar icons in the upper right. pijuice_tray.py came up with the icon and the menu items. The menu items function.

I'm having a little trouble with the tray being run as pijuice. The 36x11-pijuice_xhost configuration doesn't seem to allow pijuice user to create the tray icon.

I guess after figuring out this pijuice user issue, the next step is to create an rpm.

[komacke]

It looks like the 36x11-pijuice-xhost needs to be in /etc/X11/xinit/xinitrc.d. Also once I got the sticky bit set on the right executables everything seems to run correctly.

In discussion with the maintainer to see what makes sense to pull into the main branch. In the meantime I've forked and working on an rpm here: https://github.com/komacke/PiJuice/tree/working

[komacke]

I've got a first pass working. The fork can be found here: https://github.com/komacke/PiJuice/tree/working

It creates base and gui rpms similar to the debian packages. cd into the fedora base folder. run the prep script and then the build with rpmbuild -bb pijuice-base.spec and again for the gui. dnf install can be used on the resulting rpm files. reboot.

If you aren't set up for rpm building you'll need to install rpmdevtools and rpmlint and then run rpmdev-setuptree to create the folder structure that rpmbuild is looking for.

I'm in discussion with the maintainer to see if some of the changes can be brought into the main pijuice branch.

[komacke]

You can install this from Fedora copr: https://copr.fedorainfracloud.org/coprs/komacke/pijuice-hat/

Follow the instructions to enable the repo and then: sudo dnf install pijuice-base pijuice-gui

[komacke]

A nice feature added that has always bugged me. Hopefully we'll get the changes pulled into the next release.

The kernel always loads the hwclock into the system clock when the module loads. If the power was lost (and no battery) then the system clock gets set back to 2000. This causes journal corruption issues for systemd and who knows what else. Since pijuice_sys.py is responsible for getting the module loaded and also it can read the clock with direct i2c reads, then we can detect if the clock is set to 2000 and instead write the system clock into the hw clock.

The system clock probably isn't right at this moment (unless NTP has sync'd, which it probably hasn't). However systemd with timesyncd or with chrony uses a file timestamp that is written to frequently so the time at least will be the last time it was running (much, much closer to current time than 2000). Also, systemd is much more forgiving about clocks that jump forward (NTP syncs and fixes the time) than clocks that jump back to the year 2000.