Added reGenda

[tenJirka]

reGenda is agenda app for reMarkable tablet

It is written in Python and uses wrapper around SAS. Can connect to caldav server and show events from there. (read only for now). For more info check my repo.

I'm author of the package and I tested it on reMarkable 2 but I hope it should work on reMarkable 1 too.

[Eeems]

I did a quick pass to restructure the package with the following:

• Removed display from depends and instead used the patch_rmfb flag
• Moved all filesystem layout related stuff from configure() to package()
• Removed all the extra mkdir calls as they are not needed when using install
• Simplified the install statements that don't rename the file

[raisjn]

just want to comment and say: cool app!!

[Eeems]

just want to comment and say: cool app!!

Oh yeah, ditto

[tenJirka]

I've added postremove function because a lot of empty directories were left over after uninstall in /opt/usr/lib/reGenda.

[Eeems]

I've added postremove function because a lot of empty directories were left over after uninstall in /opt/usr/lib/reGenda.

This shouldn't be the case unless runtime is creating files? That said, blanked removing the directory could remove user created files, which is not something we want to do. Empty folders being left behind is not as large of a concern.

[tenJirka]

I've added postremove function because a lot of empty directories were left over after uninstall in /opt/usr/lib/reGenda.

This shouldn't be the case unless runtime is creating files? That said, blanked removing the directory could remove user created files, which is not something we want to do. Empty folders being left behind is not as large of a concern.

Some pycache files should be only created files by runtime. I don't know how bad it would be if they they will last.

root@reMarkable:/opt/usr/lib/reGenda# find . -name "*.pyc"
./__pycache__/languages.cpython-311.pyc
./__pycache__/calendar_caldav.cpython-311.pyc
root@reMarkable:/opt/usr/lib/reGenda# ls -lh __pycache__/
-rw-r--r--    1 root     root        3.7K Aug 24 19:18 calendar_caldav.cpython-311.pyc
-rw-r--r--    1 root     root        2.4K Aug 24 19:18 languages.cpython-311.pyc

[Eeems]

I've added postremove function because a lot of empty directories were left over after uninstall in /opt/usr/lib/reGenda.

This shouldn't be the case unless runtime is creating files? That said, blanked removing the directory could remove user created files, which is not something we want to do. Empty folders being left behind is not as large of a concern.

Some pycache files should be only created files by runtime. I don't know how bad it would be if they they will last.

root@reMarkable:/opt/usr/lib/reGenda# find . -name "*.pyc"
./__pycache__/languages.cpython-311.pyc
./__pycache__/calendar_caldav.cpython-311.pyc
root@reMarkable:/opt/usr/lib/reGenda# ls -lh __pycache__/
-rw-r--r--    1 root     root        3.7K Aug 24 19:18 calendar_caldav.cpython-311.pyc
-rw-r--r--    1 root     root        2.4K Aug 24 19:18 languages.cpython-311.pyc

It might be best to target those folders and files explicitly then instead of a blanket delete. Ideally, we could generate them as part of the package process and include them, but we don't really have the build process setup for that yet, as they can only be created on the same architecture.

rm -f /opt/usr/lib/reGenda/**/*.cpython-*.pyc

[Eeems]

I took a look at what entware distributes for their python packages, they just distribute the pyc files instead of the source. So they don't have to do any magic cleanup. We'll have to sort out a way to generate them for python packages in the future. I'm fine with just removing the generated pyc files as part of cleanup for now in this package.

[tenJirka]

*.cpython-*.pyc

I've added postremove function because a lot of empty directories were left over after uninstall in /opt/usr/lib/reGenda.

This shouldn't be the case unless runtime is creating files? That said, blanked removing the directory could remove user created files, which is not something we want to do. Empty folders being left behind is not as large of a concern.

Some pycache files should be only created files by runtime. I don't know how bad it would be if they they will last.

root@reMarkable:/opt/usr/lib/reGenda# find . -name "*.pyc"
./__pycache__/languages.cpython-311.pyc
./__pycache__/calendar_caldav.cpython-311.pyc
root@reMarkable:/opt/usr/lib/reGenda# ls -lh __pycache__/
-rw-r--r--    1 root     root        3.7K Aug 24 19:18 calendar_caldav.cpython-311.pyc
-rw-r--r--    1 root     root        2.4K Aug 24 19:18 languages.cpython-311.pyc

It might be best to target those folders and files explicitly then instead of a blanket delete. Ideally, we could generate them as part of the package process and include them, but we don't really have the build process setup for that yet, as they can only be created on the same architecture.

rm -f /opt/usr/lib/reGenda/**/*.cpython-*.pyc

I was thinking more of find /opt/usr/lib/reGenda/ -name "*.cpython-*.pyc" -exec rm -r {} + because modules in subdirectories can produce pycache as well.

[Eeems]

Okay, I was doing some more digging. I misremembered, pyc is not architecture dependant, that would be pyd files. So we could compile them easily as part of the build process and only include those. This would require some extra work to make sure to update this package when entware pushes a new version of python.

https://docs.python.org/3/library/py_compile.html
https://docs.python.org/3/library/compileall.html#module-compileall
https://docs.python.org/3/tutorial/modules.html#compiled-python-files

[Eeems]

It might be best to target those folders and files explicitly then instead of a blanket delete. Ideally, we could generate them as part of the package process and include them, but we don't really have the build process setup for that yet, as they can only be created on the same architecture.

rm -f /opt/usr/lib/reGenda/**/*.cpython-*.pyc

I was thinking more of find /opt/usr/lib/reGenda/ -name "*.cpython-*.pyc" -exec rm -r {} + because modules in subdirectories can produce pycache as well.

That is functionally the same as my example. ** matches all levels of folders.

[tenJirka]

It might be best to target those folders and files explicitly then instead of a blanket delete. Ideally, we could generate them as part of the package process and include them, but we don't really have the build process setup for that yet, as they can only be created on the same architecture.

rm -f /opt/usr/lib/reGenda/**/*.cpython-*.pyc

I was thinking more of find /opt/usr/lib/reGenda/ -name "*.cpython-*.pyc" -exec rm -r {} + because modules in subdirectories can produce pycache as well.

That is functionally the same as my example. ** matches all levels of folders.

My bad, didn't know that.

[Eeems]

No worries

[tenJirka]

Okay, I was doing some more digging. I misremembered, pyc is not architecture dependant, that would be pyd files. So we could compile them easily as part of the build process and only include those. This would require some extra work to make sure to update this package when entware pushes a new version of python.

https://docs.python.org/3/library/py_compile.html https://docs.python.org/3/library/compileall.html#module-compileall https://docs.python.org/3/tutorial/modules.html#compiled-python-files

I guess the decision is up to you because the entware connection is probably nothing that can be done from package recipe.
I can inplement pycache building if you want, but just right clean up looks good enought for me.

[Eeems]

Okay, I was doing some more digging. I misremembered, pyc is not architecture dependant, that would be pyd files. So we could compile them easily as part of the build process and only include those. This would require some extra work to make sure to update this package when entware pushes a new version of python.
https://docs.python.org/3/library/py_compile.html https://docs.python.org/3/library/compileall.html#module-compileall https://docs.python.org/3/tutorial/modules.html#compiled-python-files

I guess the decision is up to you because the entware connection is probably nothing that can be done from package recipe. I can inplement pycache building if you want, but just right clean up looks good enought for me.

The decision here is actually up to you. I'm fine with merging either at the moment. Do you feel like just getting this done and merged, or trying something slightly new?

Yes, pushing a new version of the package when entware pushes the next major version of python will be something we have to do manually. To some extent, it might still be required if you don't go with the pyc route as well. Up to you.

Longer term I'd like to get a solution for native compilation in toltec of stuff that can't be cross compiled, that way you could make use of pyinstaller or nuitka to make your application truly standalone.

[tenJirka]

Okay, I was doing some more digging. I misremembered, pyc is not architecture dependant, that would be pyd files. So we could compile them easily as part of the build process and only include those. This would require some extra work to make sure to update this package when entware pushes a new version of python.
https://docs.python.org/3/library/py_compile.html https://docs.python.org/3/library/compileall.html#module-compileall https://docs.python.org/3/tutorial/modules.html#compiled-python-files

I guess the decision is up to you because the entware connection is probably nothing that can be done from package recipe. I can inplement pycache building if you want, but just right clean up looks good enought for me.

The decision here is actually up to you. I'm fine with merging either at the moment. Do you feel like just getting this done and merged, or trying something slightly new?

Yes, pushing a new version of the package when entware pushes the next major version of python will be something we have to do manually. To some extent, it might still be required if you don't go with the pyc route as well. Up to you.

Longer term I'd like to get a solution for native compilation in toltec of stuff that can't be cross compiled, that way you could make use of pyinstaller or nuitka to make your application truly standalone.

I will stick with none pyc compilation and right clean up, because I know it will work.

For longer term if this way of installation will be unwanted I will update it. Right now I'm not sure about pyinstaller because caldav is dependent on lxml which have to be compiled and I don't know how to setup cross compilation for python module right now.
Lxml actually can't be installed via pip on reMarkble as well because of lack of build dependencies and compilation fail.

[Eeems]

I will stick with none pyc compilation and right clean up, because I know it will work.

For longer term if this way of installation will be unwanted I will update it. Right now I'm not sure about pyinstaller because caldav is dependent on lxml which have to be compiled and I don't know how to setup cross compilation for python module right now. Lxml actually can't be installed via pip on reMarkble as well because of lack of build dependencies and compilation fail.

pyinstaller and nuitka can't do cross compilation, and the solution I'm thinking of to support them would be to have an arm version of the toolchain images that can be used instead for compilation, so you'd be able to install lxml as a build dependency and then pyinstall/nuitka would be able to compile the executable using them. It'll be a while before that is implemented. Which reminds me, I need to open an issue to track this idea.

Lxml is the bane of my existence.

[Eeems]

I've cancelled the build for a bit, we have to wait for testing to finish updating with the latest change going in, otherwise this build will be building the linux kernel. This is due to how we detect what packages need to be built, we compare against what is in testing, and any that don't exist, or have a different version number will be built. Since the testing build with the new package is still in progress and hasn't been deployed, it thinks that this PR has also modified the linux kernel package.

https://github.com/toltec-dev/toltec/actions/runs/5968320607

[tenJirka]

I've cancelled the build for a bit, we have to wait for testing to finish updating with the latest change going in, otherwise this build will be building the linux kernel. This is due to how we detect what packages need to be built, we compare against what is in testing, and any that don't exist, or have a different version number will be built. Since the testing build with the new package is still in progress and hasn't been deployed, it thinks that this PR has also modified the linux kernel package.

https://github.com/toltec-dev/toltec/actions/runs/5968320607

Okay totally fine, I was i bit worried if reGenda can't be build or something.
This is actually my first Pull requests so I'm curiously watching how it's going. I'm new to all of this.

[tenJirka]

I would also like to ask. I'm right that I will have to open new Pull requests when i would like to update this package?

[Eeems]

I would also like to ask. I'm right that I will have to open new Pull requests when i would like to update this package?

Correct.

We may also update it independent of you with pull requests in the future as well. Usually this would be to make it consistent with changes to our packaging standards, force a rebuild when a dependency change in entware requires it, or to fix a bug before it gets fixed in your upstream source.

[Eeems]

Tested and it works fine on my reMarkable 1.