Create an Android app for Syncthing as part of the Syncthing Tray project by mkittler

Description

There's already an app but code/features already in Syncthing Tray could be reused to create a nicer app with additional features like managing ignore patterns more easily. The additional UI code for the app could then in turn be re-used by other parts of Syncthing Tray, e.g. to implement further steps in the wizard as requested by some users. This way one "UI wrapper codebase" could serve GNU/Linux, Windows and Android (and in theory MacOS) at the same time which is kind of neat.

Goals

• DONE: Learn more about development for Android and development of UIs with Qt Quick
• DONE: Create an experimental app reusing as much existing Syncthing Tray code as possible
• DONE: Build Syncthing as a library also for Android and use it in the app (already done but needs further testing and integration with the rest of the app configuration)
• DONE: Update the Syncthing Tray website, documentation
• Extend the app so it has at least a start page and an import that can cope with an export of the other app
• Update forum thread
• Upload an experimental build on GitHub
• Extend the Syncthing API to download single files on demand (instead of having to sync the whole directory or use ignore patterns)

Resources

• Android SDK/NDK and emulator
• Qt Quick

---

YQPkg - Bringing the Single Package Selection Back to Life by shundhammer

tl;dr

Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.

See section "Result" at the bottom for the current status after the hack week.

Current Status

See the development status issue at the GitHub repo.

tl;dr: It's usable now with all the key features.

It does real package installation / removal / update with reasonable user feedback.

The Past and the Present

We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.

You can search packages based on name, description, "requires" or "provides" level, and many more things.

The Future

YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.

Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?

For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.

But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.

The Idea

YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.

For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.

For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.

Preparatory Work: Initializing the Package Subsystem

To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?

Yes, it is: That part is already working:

https://github.com/yast/yast-ycp-ui-bindings/pull/71

---

A sane DSL for udev rules by mwilck

Description

The "language" in which udev rules are written as documented in udev(7) is horrible. To name just a few problems:

• The only control statements are LABEL and GOTO.
• Conditionals are the most important part of the language, but it supports only conjunction ("AND"), forcing developers to use GOTO even for simple "OR" relations.
• The AND operation is denoted by a comma (,).
• Conventions for quoting are weird.
• There aren't even basic string handling facilities.
• There is no API for passing flags between different rule sets, just a set of global environment variables.
• Environment variales are written in ENV{FOO} when assigned to, but $env{FOO} or %E{FOO} when dereferenced.

While this is ok-ish for the simple set of tasks the language was originally intended for, it makes larger rule sets with complex logic almost impossible to read and understand. Examples for such complex rule sets are the device-mapper and multipath rules.

While working on the multipath rule sets a few weeks ago, I found myself desparately translating the rules into some pythonesque pseudo-code in order to make sure I fully understand the code flow.

This project wants to explore the possibilities to replace this weird DSL with something saner. The idea is to embed Lua in udev, and rewrite the udev rule sets as Lua modules.

It's meant as a fun project that may have practical merits. I am aware that it's questionable whether the systemd maintainers are going to embrace this. I think it will only have a tiny chance if it really improves readability of rules massively, while impacting neither performance nor code size too badly. I have good hopes in terms of performance as Lua has the reputation to be fast, but code size will of course increase, and so will the list of dependencies of systemd.

Goals

1. Learn how to write Lua, and how to embed it in C code and write C modules for it. I've read the manual, but I can't say that I'm fluent with it yet.
2. Design an API for udev in Lua. Figure out how to expose status like device properties (environment variables), tags, and other variables like ACTION and SUBSYSTEM to Lua code, and tentatively re-write a set of representative rule sets in this new DSL. This may need several attempts until the rules can be written in an intuitive way.
3. Create the basic framework for embedding Lua in udev and providing the environment for the Lua code.
4. Write libraries with helper funtions to be used by the Lua. For example, we'll need code to access sysfs in order to provide ATTRS and similar features of udev. I'm not certain yet but for most of this it will probably make sense to write the code in C and make it callable by Lua, as udev already has powerful mechanisms for accessing sysfs attributes.
5. One problem is that the Lua standard library provides getenv but not setenv. We need to be able to set environment variables in order to work with external programs to replicate the functionality of the PROGRAM and IMPORT{program} directives.
6. Eventually, make the entire feature set of the udev language available.
7. Eventually, rewrite the entire set of upstream rules (to the extent we're aware of) in Lua.
8. While I'd love trash the original language, I guess it needs to continue to exist.

---