WIP: Package the touch keyboard onboard and polybar (for i3)

Created by: ollieparanoid

The fonts are partially missing, unfortunately, so just copying the setup does not work.

I guess the missing font is font awesome 5? The version 4 is already packaged in Alpine, so we could package v5 as well.

Should this go into postmarketOS or directly into Alpine Linux?

Since this would work on plain Alpine as well, I think it would be good practice to upstream it (it can be that they are not interested at all in the packages however, so asking first in #alpine-devel seems like a good idea). For that to work out, you would need to add yourself as maintainer to the new packages.

With that being said, it will probably take quite some time until your packages would get accepted in upstream, so if we add them to postmarketOS first and to upstream them afterwards, then we can use them faster.

I have added myself as contributor, should I also add myself as maintainer, if yes, what would be expected of me?

From Alpine's wiki:

The maintainer is responsible for the the package and is expected to:

fix bugs in package

keep it updated. This includes follow upstream announcement list, RSS feed etc and provide updates to Alpine Linux in timely fashion.

For postmarketOS we don't require people to add themselves as maintainer at this point (though some have done it, which is really nice!). While this lowers the barrier to contribute new packages, this has the obvious downside that people contribute packages once and then there's a good chance that they won't see updates any time soon. So I would prefer if we had more maintainers, and when the project becomes closer to being a daily driver we will need maintainers for all packages. What I'm saying is, it would be very nice if you add yourself as maintainer and actually follow the upstream releases of your package's sources and create a PR which updates the package as soon as there is a new version. And if you can't do that for whichever reason, then don't add yourself as maintainer (or make a PR in the future when you can't maintain them anymore).

onboard uses the error() method of glibc. From the manual I understood that the way it is used (errnum=0), this would only add the program name as prefix and then just print the rest similar to printf. Therefore, I have replaced them with fprintf to stderr which is not equivalent but at least shows the messages. Is there a better fix?

Sounds good to me! Depending on how much work you want to put into this, you could ask upstream to not use error() at all in an issue (so the program becomes POSIX compatible), or create a PR that fixes this by yourself.

onboard does not require py3-dbus, but without py3-dbus, some functionality is missing like showing the keyboard instead of starting a second instance when running onboard again. As I think this is quite difficult to discover, I have just added py3-dbus as a dependency.

That's reasonable.

py3-dbus shares some files with py-dbus, that's why Arch Linux has a third package with the common files (see PKGBUILD). How is such a situation handled in Alpine Linux?

So in Arch there is one package build recipe, that builds the python2 and python3 version, and the common files. I'm looking at pytest as an example for a package that is present in both the py2 and py3 versions in Alpine. And it turns out, they use one package build recipe for both as well. My conclusion is, that the proper way to package py3-dbus would be extending the py-dbus package, and then you could share the common files in a subpackage just like it is done in Arch. I think Alpine developers will appreciate the deduplication, and this would be a good change to upstream to Alpine (it also means that you wouldn't need to add yourself as maintainer there, since the package already exists).

Side note: please remove the || return 1 statements from the APKBUILD (even when doing the change upstream) because this is legacy.

Some dependencies of polybar are actually optional (only required for certain modules) but the build system just added them as dependencies. As mentioned in the discussion in the AUR, if the packages are not present during the build, they also cannot be enabled later, that's why I have added them as build dependencies. Should they be added as regular dependencies in the APKBUILD?

This sounds like the dependencies have been added automatically with abuild's dependency tracing feature. You can disable it by adding !tracedeps to the options, and only specifying the required dependencies as depends. Then the user can install the additional packages if they like.

polybar has two git submodules, therefore a regular git archive does not work. I am now just using git directly. There are several alternatives though. Alpine Linux has an example how to create an archive manually (but I assume this does only work for packages built in their systems). One could also just download the archives of the submodules manually. Any opinions?

We had a similar situation when packaging nheko and the best solution was to ask upstream if they could include the submodule checkouts in the release tarball.

Alpine's git checkout is meant for downloading the source once, and then mirroring it on an Alpine server, where it can then be used as regular source URL. So it does not really work without the Alpine server that stores the source (and we don't use that for postmarketOS packages).

I hope everything is answered, thanks for making this great PR!

PS: When everything is packaged, we could (in a new PR) extend the postmarketos-ui-i3wm package with a configuration that directly uses this cool stuff!

By * postmarketOS Bot on 2018-03-18T09:03:43

Thank you @ollieparanoid for your answers. I will try to get as much of this as possible into Alpine Linux. There won't be release archives for polybar unfortunately anytime soon, unfortunately (see jaagr/polybar#1120). Todo list for me and progress tracker:

Properly package py-distutils-extra with Python 3 support - see alpinelinux/aports#3956
Properly package py-dbus with Python 3 support - see https://github.com/alpinelinux/aports/pull/4846
See if upstream onboard would be interested in fixing musl libc compatibility (the project does not seem to be that active though). - TODO
See if Alpine Linux is interested in onboard, try to use archives for submodules - TODO
See if Alpine Linux is interested in polybar - TODO
Try packaging font awesome 5 or siji, which is the other font used in the example configuration - TODO

I think rofi would nicely complement this setup so I will try to package that, too. Rofi might allow to have a generic application launcher that should be usable with touch input (though probably not ideal, I need to test that).

I suggest to leave this PR open to track the progress, I will update this from time to time to reflect what is still missing in Alpine Linux.

By Michael Hamann on 2018-07-24T20:09:48

Created by: ollieparanoid

Awesome work, it really shows how much effort you put into this

On a side note, Alpine prefers squashed commits in their PRs.

By * postmarketOS Bot on 2018-04-08T12:17:35

marked as a Work In Progress

By Martijn Braam on 2018-06-30T13:13:13

Unfortunately, this merge request was not imported correctly from GitHub:

source branch does not exist. Please restore it or use a different source branch

@michitux or anyone else: if you have updated the code for another review, please open up a new merge request. Sorry for the trouble.

By Oliver Smith on 2018-07-09T19:43:29

closed

By Oliver Smith on 2018-07-09T19:43:30

WIP: Package the touch keyboard onboard and polybar (for i3)

Closed by Administrator 6 years ago (Jul 9, 2018 7:43pm UTC) 6 years ago

Activity

WIP: Package the touch keyboard onboard and polybar (for i3)

Merge request reports

Closed by Administrator 6 years ago (Jul 9, 2018 7:43pm UTC) 6 years ago

Activity