Package etesync (and its dependencies)

I have installed and tested etesync on my openwrt router. I want to share the packages for etesync and its dependencies that are not in the official feed. But I am new in contributing. Do you have mentors or so? Right now I have the following questions:

  1. How should I publish the packages: All of them as one pull request or separately?
  2. The of suggest to install it via virtualenv. But I made packages for the (missing) dependencies, too. Would it be advisable to use a virtualenv instead?
  3. Is there a how to make a package uci compatible?
    Could anybody look over my changes and give me feedback?

Posting your changes to Github on a topic branch (something not called master) is a good way to collaborate and get some input before a formal PR.

Thank you for your answer, I made the following topic branches:

The latter one is for moving the luci on nginx related files from the nginx and the uwsgi-cgi package to the luci-nginx and luci-ssl-nginx package. I would make this change only if @Ansuel approves it since it is his project.

This is a first proposal and there are some points still missing:

  1. Install etesync to another folder (instead of /etesync-server). What would be the canonical place?

  2. Maybe add uci support and a luci app for etesync, mainly for configuring the server name; there is already a admin interface build in for user management.

  3. Create a self-signed certificate and enable ssl in the etesync server section of the nginx configuration.

  4. I am not sure how to interact with the nginx configuration. Do you have any suggestions? Would it help to make it available via uci? Or would that be a bad idea or difficult?

  5. Etesync starts a uwsgi instance; how can I restart it after an update of uwsgi? Would that be a good idea at all?

  6. Autostart etesync by: uwsgi --ini /etc/uwsgi/sites/etesync.ini

  7. Define appropriate conffiles to control files on update and remove.

I appreciate other suggestions for improvement, too.

Think that talk on a pr is better

I put a lot of changes into one commit, would it be better to split it up? If so, how fine, every dependent package one commit? I would do that in another branch of peter-stadler/packages.

@Ansuel: Do you think, I should make a PR already? I would at least complete points 3 (ssl certificate) and 6 (autostart), and do some work on point 7 (conf files) before.

@jeff: I think I am in the wrong subforum, I intended to post this topic to Community Builds, Projects & Packages. Should I post it there, too?

At least at this point, the questions seem to be ones that "developers" can answer. At least as I understand it, the "Community Builds..." section is for content that end-users can download and install (without building it themselves) and for support of such content.

I understand, thank you :slight_smile:

Do a draft pull request this way we can see changes more easily
(If it's not a problem)

1 Like

I, personally, would include [RFC] in the title to minimize the wrath of the core development team.

So, I will do a PR tomorrow after working out and testing the points 3, 6 and maybe 7.

Thank you both very much.

1 Like

I made the PRs hoping they can be understood:


Do you have some suggestions for me?

My personal suggestion would be push changes gradually
For example changes to uwsgi to support modules
Changes to nginx

This way you can focus on smaller part. And thing can be tested easily.

1 Like

For now, I made the following draft PRs:


The changes for moving the luci on nginx files from the packages to the luci repository are missing here.

I updated the PR for collecting the luci on nginx files into the luci repository:

This would make the corresponding parts in the packages repository obsolete.

you should tag jow for luci changes just to make sure that package follow openwrt guidelines

I adopted the PRs for nginx (as well as ariang) and the modular uwsgi to follow the recent changes. Furthermore, I did split up the django2 PR into single packages:sqlparse, django-cors-headers and drf-nested-routers. These PRs are quite ready imho and I removed the draft status.
I will make another PR for the django-etesync-journal as it is missing for now. Then I will change the PR for the etesync-server, too. And I am not sure wether we should integrate the luci mods into the uwsgi and nginx Makefiles or if we could collect them; in the second case I would update the luci PR.

We need to hear the devs opinion... As i already said... hen i first tried to push luci on nginx they told me that a different package can't modify files of others... For this specific reason i had to create 2 subpackage for nginx and uwsgi... Anyway i will update nginx to mainline version so i think we can merge your changes before my commit. What do you think? Also can you put the pr in a list so i ca check them quickly?

I see, maybe it is different when we use the subfolders (/etc/nginx/conf.d and /etc/uwsgi/vassals) since the purpose of these folders is for other packages to install their files there.

If the conf.d folder can be enabled, the nginx PR could be merged anytime.

I did link all the current PRs in my last post, the first six would be ready:

  1. nginx
  2. ariang
  3. uwsgi
  4. sqlparse
  5. django-cors-headers
  6. drf-nested-routers
  7. django-etesync-journal (prePR)
  8. etesync-server needs some work (I would wait until the other are merged)
  9. luci needs some work if the extraction from uwsgi and nginx is desired.

I am not sure if it is that, what you meant with putting the PR in a list. Else, what did you mean/how can I do that?

Just this... a list to track the pending PR

Think the priority here is nginx and uwsgi....

About files yes... as they are just configuration files i think it should be allowed to add files related to other package...