I want to create a more modern mail storage format, which leverages git and tagging instead of folders to manage my mail.
This is inspired by having used notmuch and mbsync for a long time, liking the good aspects of this setup but getting frustrated with the problems. Mainly the issue of storing mail on multiple computers with eventual consistency (for example being able to read mail on my laptop when travelling but my desktop computer when at home).
No Hackers yet
Looking for hackers with the skills:
This project is part of:
Hack Week 17
Activity
Comments
Be the first to comment!
Similar Projects
Agama installer on-line demo by lslezak
Description
The Agama installer provides a quite complex user interface. We have some screenshots on the web page but as it is basically a web application it would be nice to have some on-line demo where users could click and check it live.
The problem is that the Agama server directly accesses the hardware (storage probing) and loads installation repositories. We cannot easily mock this in the on-line demo so the easiest way is to have just a read-only demo. You could explore the configuration options but you could not change anything, all changes would be ignored.
The read-only demo would be a bit limited but I still think it would be useful for potential users get the feeling of the new Agama installer and get familiar with it before using in a real installation.
As a proof of concept I already created this on-line demo.
The implementation basically builds Agama in two modes - recording mode where it saves all REST API responses and replay mode where it for the REST API requests returns the previously recorded responses. Recording in the browser is inconvenient and error prone, there should be some scripting instead (see below).
Goals
- Create an Agama on-line demo which can be easily tested by users
- The Agama installer is still in alpha phase and in active development, the online demo needs to be easily rebuilt with the latest Agama version
- Ideally there should be some automation so the demo page is rebuilt automatically without any developer interactions (once a day or week?)
TODO
- Use OpenAPI to get all Agama REST API endpoints, write a script which queries all the endpoints automatically and saves the collected data to a file (see this related PR).
- Write a script for starting an Agama VM (use libvirt/qemu?), the script should ensure we always use the same virtual HW so if we need to dump the latest REST API state we get the same (or very similar data). This should ensure the demo page does not change much regarding the storage proposal etc...
- Fix changing the product, currently it gets stuck after clicking the "Select" button.
- Move the mocking data (the recorded REST API responses) outside the Agama sources, it's too big and will be probably often updated. To avoid messing the history keep it in a separate GitHub repository
- Allow changing the UI language
- Display some note (watermark) in the page so it is clear it is a read-only demo (probably with some version or build date to know how old it is)
- Automation for building new demo page from the latest sources. There should be some check which ensures the recorded data still matches the OpenAPI specification.
Changing the UI language
This will be quite tricky because selecting the proper translation file is done on the server side. We would probably need to completely re-implement the logic in the browser side and adapt the server for that.
Also some REST API responses contain translated texts (storage proposal, pattern names in software). We would need to query the respective endpoints in all supported languages and return the correct response in runtime according to the currently selected language.
Resources
- Agama sources
- Experimental proof of concept demo
- The respective source code change
Better diff'ing experience by MSirringhaus
Description
For diff-ing directories, I usually like to use meld, but it struggles a lot with large trees. Experiment with writing a TUI meld-clone for diffing directories and files
Goals
Get first prototype going of a TUI that can show
- diffs of text-files
- diffs of directories.
Stretch goals
- Themes
- Filters (no whitespace, etc.)
- Live config changes (Show/hide line numbers, etc.)
SMB3 Server written entirely in Rust by dmulder
Description
Given the number of bugs frequently discovered in the Samba code caused by memory issues, it makes sense to re-write the smbd service purely in Rust code. Meanwhile, it would be wise to abandon backwards compatibility here with insecure protocol versions, and simply implement the SMB3 spec.
Goals
Get a simple server up and running and get it merged into upstream Samba (which now has Rust build support).
Resources
Hacking on sched_ext by flonnegren
Description
Sched_ext upstream has some interesting issues open for grabs:
Goals
Send patches to sched_ext upstream
Also set up perfetto to trace some of the example schedulers.
Resources
https://github.com/sched-ext/scx
Kanidm: A safe and modern IDM system by firstyear
Kanidm is an IDM system written in Rust for modern systems authentication. The github repo has a detailed "getting started" on the readme.
In addition Kanidm has spawn a number of adjacent projects in the Rust ecosystem such as LDAP, Kerberos, Webauthn, and cryptography libraries.
In this hack week, we'll be working on Quokca, a certificate authority that supports PKCS11/TPM storage of keys, issuance of PIV certificates, and ACME without the feature gatekeeping implemented by other CA's like smallstep.
For anyone who wants to participate in Kanidm, we have documentation and developer guides which can help.
I'm happy to help and share more, so please get in touch!
Try to render Agama in a TUI browser by ancorgs
Description
Agama is a new Linux installer that will be very likely used for SLES 16. It offers a modern and convenient web interface that can be executed both locally and remotely.
But of course some users will miss the old TUI (ncurses) interface of the YaST installer.
So I want to experiment whether would it be possible to render a simplified version of the web interface for TUI browsers. That's only doable and maintainable if we keep the current technology stack we use for rendering the full-blown page, simply replacing complicated UI elements with others that are easy to render. That means the browser would need to support Javascript.
Chawan seems to be almost there regarding support for Javascript, XHR and related technologies. But according to this conversation, the next missing piece would be to support recursive import of module script tags.
Unfortunately, Chawan is written in Nim and I'm pretty sure a week is not enough time for me to learn Nim, implement the feature at Chawan and then fix whatever is the next obstacle on the Agama side.
But if someone could take care of the Nim part, I would do the same with the Agama one. So this is basically a call for help to get this project even started.
Agama Expert Partitioner by joseivanlopez
Description
Agama is a new Linux installer that will be very likely used for SLES 16.
It offers an UI for configuring the target system (language, patterns, network, etc). One of the more complex sections is the storage configuration, which is going to be revamped. This project consists on exploring the possibility of having something similar to the YaST Expert Partitioner for Agama.
Goals
- Explore different approaches for the storage UI in Agama.
Agama installer on-line demo by lslezak
Description
The Agama installer provides a quite complex user interface. We have some screenshots on the web page but as it is basically a web application it would be nice to have some on-line demo where users could click and check it live.
The problem is that the Agama server directly accesses the hardware (storage probing) and loads installation repositories. We cannot easily mock this in the on-line demo so the easiest way is to have just a read-only demo. You could explore the configuration options but you could not change anything, all changes would be ignored.
The read-only demo would be a bit limited but I still think it would be useful for potential users get the feeling of the new Agama installer and get familiar with it before using in a real installation.
As a proof of concept I already created this on-line demo.
The implementation basically builds Agama in two modes - recording mode where it saves all REST API responses and replay mode where it for the REST API requests returns the previously recorded responses. Recording in the browser is inconvenient and error prone, there should be some scripting instead (see below).
Goals
- Create an Agama on-line demo which can be easily tested by users
- The Agama installer is still in alpha phase and in active development, the online demo needs to be easily rebuilt with the latest Agama version
- Ideally there should be some automation so the demo page is rebuilt automatically without any developer interactions (once a day or week?)
TODO
- Use OpenAPI to get all Agama REST API endpoints, write a script which queries all the endpoints automatically and saves the collected data to a file (see this related PR).
- Write a script for starting an Agama VM (use libvirt/qemu?), the script should ensure we always use the same virtual HW so if we need to dump the latest REST API state we get the same (or very similar data). This should ensure the demo page does not change much regarding the storage proposal etc...
- Fix changing the product, currently it gets stuck after clicking the "Select" button.
- Move the mocking data (the recorded REST API responses) outside the Agama sources, it's too big and will be probably often updated. To avoid messing the history keep it in a separate GitHub repository
- Allow changing the UI language
- Display some note (watermark) in the page so it is clear it is a read-only demo (probably with some version or build date to know how old it is)
- Automation for building new demo page from the latest sources. There should be some check which ensures the recorded data still matches the OpenAPI specification.
Changing the UI language
This will be quite tricky because selecting the proper translation file is done on the server side. We would probably need to completely re-implement the logic in the browser side and adapt the server for that.
Also some REST API responses contain translated texts (storage proposal, pattern names in software). We would need to query the respective endpoints in all supported languages and return the correct response in runtime according to the currently selected language.
Resources
- Agama sources
- Experimental proof of concept demo
- The respective source code change
Design the new UI for storage configuration at Agama by ancorgs
Description
We are in the process of re-designing the web user interface to configure storage at Agama. We expected to have a clear idea of what we wanted before starting Hack Week. But the idea is still not that clear. So I will use use my Hack Week time to try several prototypes since I really want this to be done.
Goals
Have a prototype using Patternfly components and addressing all the use-cases we want to cover. Easy for the easy cases. Capable for the complex ones.
Editor mode at Agama web interface by ancorgs
Description
Agama is a new Linux installer that will be very likely used for SLES 16.
It takes a configuration (in JSON format) as input. And offers several interfaces to build that configuration in an easy and interactive way.
I was considering the possibility to add to the web interface a "text editor" mode similar to the XML editor available at virt-manager. That could be used to see how the changes in the UI translate into changes on the configuration.
Goals
- Refresh my knowledge about UI development for Agama, since there was a major overhaul recently (adopting TanStack Query) and I need to learn the new way to do things.
- Please hackers who always want to know how things work internally. :-)
Explore the integration between OBS and GitHub by pdostal
Project Description
The goals:
1) When GitHub pull request is created or modified the OBS project will be forked and the build results reported back to GitHub. 2) When new version of the GitHub project will be published the OBS will redownload the source and rebuild the project.
Goal for this Hackweek
Do as much as possible, blog about it and maybe use it another existing project.
Resources
- The Blog post
- Issue: poo#123858 - build.opensuse.org: /usr/lib/obs/service//go_modules.service No such file or directory
Port git-fixup to POSIX shell script and submit to git/git by mcepl
Description
https://github.com/keis/git-fixup is an exceedingly useful program, which I use daily, and I would love to every git user could bask in its awesomeness. Alas, it is a bash script, so it is not appropriate for the inclusion in git proper.
Goals
Port the script to plain POSIX shell and submit for consideration to git@vger.kernel.org
Resources