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
Go there for a screenshot
That's already halfway there.
The complete Ruby code of this example is here. The real thing will be pure C++ without any YaST dependencies.
The Plan
DONE: Clone libyui where libyui (high-level), libyui-qt, libyui-qt-pkg live
DONE: Slash and burn: Get rid of the unneeded parts one by one; libyui-ncurses, libyui-ncurses-pkg, libyui-rest-api, libyui-rest-api-qt, libyui-rest-api-ncurses, libyui-qt-graph.
DONE: Reduce the CMake build environment to what is actually needed.
DONE: One by one move the parts that libyui-qt-pkg needs from the outside to that directory
DONE: Slash and burn some more: Get rid of all the stuff that YQPackageSelector / YQPkg* don't need
DONE: Replace the libyui / YEvent-based event handling with standard Qt event handling so the program reacts properly to "Cancel", "Accept", WM_Close "[x]"
[DONE] Come up with one or more classes to initialize libzypp; basically those Pkg.xy() calls that are now new in the UI examples (in their C++ counterparts, of course)
Come up with one or more classes to handle the "commit" phase where packages are actually installed / updated / deleted
Write the most basic callbacks for the commit phase to show at least some progress
DONE: Add basic session handling for window size and position etc. (QSettings)
PARTLY DONE: Add a read-only mode so the program can be used without root privileges (without committing the package transactions, of course)
Write the remaining ton of callbacks for the commit phase to show progress, errors and questions
Make a more user-friendly UI for the commit phase, not just that single progress bar that we have right now; possibly allowing the user to show more details or just the progress bar
Use a more modern development method for that commit phase based on Qt Designer and .ui files (see QDirStat for examples)
Future Plans (After this Hack Week)
- Also make the main screen prettier, based on Qt Designer and .ui files; add some margins and some eye candy
Out of Scope
Repos management (adding, removing, modifying repos). This will still be left to zypper commands for the time being.
An NCurses version. The NCurses UI has been the bane of YaST development since two and a half decades - since 1999. It was always the limiting factor, it was alwas the reason why we could never use advanced Qt features, it was always the reason why YaST always looked so fugly; so 1980s, so mainframe-like.
NCurses
Those who claim they absolutely need the NCurses UI, and they cannot use a Qt application, are welcome to use the command line: There is always zypper. We will no longer let a 1970s text terminal mode like NCurses be the limiting factor for a good UI.
It was mostly NCurses that kept YaST so ugly that it was finally time to kill it in favor of a web UI like Agama. In this new web UI world, nobody has argued yet that an NCurses UI is an urgent requirement; all of a sudden, everybody can also live just fine with only a browser-based UI.
Development
Repo
https://github.com/shundhammer/yqpkg
Status
See issue #1
Result
Status at the end of the hack week:
- It's a standalone binary.
- It doesn't need any YaST infrastructure, and no YaST libs; just Qt 5 and libzypp.
- It can load the RPM DB (the installed packages).
- It can load the active repos.
Caveat: No repo refresh, no GPG key import - use
zypper reffor that. - You can use all of the usual views:
- Search
- Patterns
- Repos
- Package Classification
- Languages
- Installation Summary
- Patches (hit F2 to get this one)
- You can change the status of packages, patterns etc. as usual
- It uses the dependency resolver as usual including reporting dependency problems
- You can start it as an unprivileged user, then it's in read-only mode: You can look, you can search, you can experiment with "what...if" secenarios, but you cannot apply the changes (the "Accept" button is disabled)
- There is rudimentary instant feedback during the startup phase so it doesn't feel slow
CAVEAT: It does not actually install anything yet. The "commit" phase is not yet implemented.
But even with this limitation, it is already useful: Searching for packages, for provides, for requires, and experimenting with "what..if" scenarios is useful by itself. Once you know a package name, you can use zypper in.
text text
This project is part of:
Hack Week 24
Activity
Comments
-
30 days ago by shundhammer | Reply
Update Tue 2024-11-19 18:00:
Slashing and burning is mostly done; there is now a standalone binary that does not depend on (or link against) any YaST lib anymore. The stripped binary is just 838 k.
It doesn't have any content yet, and it's quite ugly, but it shows the principle.
-
28 days ago by shundhammer | Reply
Update Wed 2024-11-20 20:00:
We have a standalone yqpkg application, and it can show the packages and patterns from the installed system.
We now also have a read-only mode for viewing and checking "what if" scenarios as a non-privileged user. You can see that in the window title, and the "Accept" button is disabled; you can't install / delete anything.
Window size and position are saved, so it looks much better now. It also shows "YQPkg-0.3.0" in the top right corner to tell the difference in a screenshot between "yast2 sw_single" and yqpkg.
-
26 days ago by shundhammer | Reply
Update 2024-11-22 22:00:
It can now load the content of the enabled repos.
-
26 days ago by shundhammer | Reply
Update 2024-11-23 18:30:
Rudimentary progress reporting of the initialization phase with some splash screens while the repos are loaded or the package selector is populated with content.
No repo refresh, no importing of new GPG keys etc.; the repos need to be prepared in advance. A manual
sudo zypper refbefore starting the program is recommended. -
23 days ago by lkocman | Reply
YaST is mentioned as super helpful in most of the reviews done by users user switching specifically from Fedora and Debian. The software installation part is where we differ the most as far as SLES/Leap 16 and typical day-to-day user scenarios go.
This project is all about future-proofing a powerful GUI tool for a software installation, and potentially keeping single-click installation from a browser a thing.
I highly appreciate Stefan's work on this project to ensure we remain user-friendly in key areas, even after the YaST stack reduction. This is happening on SLFO, and therefore Leap 16 https://code.opensuse.org/leap/features/issue/173
Many thanks, Stefan!
-
12 days ago by Pharaoh_Atem | Reply
In case you're not aware, there is a standalone application that uses libyui called dnfdragora that does this too. The only thing missing from dnfdragora is a setting to scan for patterns packages and populate group listings accordingly, which should be possible with a small bit of code to locate all packages labeled as Metapackages and with pattern names and populate them accordingly.
-
7 days ago by shundhammer | Reply
I know that one; it's different. Just do a direct comparison.
And since I wrote libyui, libyui-qt and libyui-qt-pkg, I also know its limitations because of that abstract UI layer that it depends on.
That was the reason why we decided to write that specialized YQPackageSelector widget for YaST back 20+ years ago: So we would finally not be limited by the least common denominator between a late 1960s VT100 text terminal and a modern GUI.
Before YQPackageSelector, there was no end of bitching about the single package selection. With it, that bitching came to an end.
Been there. Done that. Got the T-shirt; actually, a whole stack of them. ;-)
-
Similar Projects
RISC-V emulator in GLSL capable of running Linux by favogt
Description
There are already numerous ways to run Linux and some programs through emulation in a web browser (e.g. x86 and riscv64 on https://bellard.org/jslinux/), but none use WebGL/WebGPU to run the emulation on the GPU.
I already made a PoC of an AArch64 (64-bit Arm) emulator in OpenCL which is unfortunately hindered by a multitude of OpenCL compiler bugs on all platforms (Intel with beignet or the new compute runtime and AMD with Mesa Clover and rusticl). With more widespread and thus less broken GLSL vs. OpenCL and the less complex implementation requirements for RV32 (especially 32bit integers instead of 64bit), that should not be a major problem anymore.
Goals
Write an RISC-V system emulator in GLSL that is capable of booting Linux and run some userspace programs interactively. Ideally it is small enough to work on online test platforms like Shaderoo with a custom texture that contains bootstrap code, kernel and initrd.
Minimum:
riscv32 without FPU (RV32 IMA) and MMU (µClinux), running Linux in M-mode and userspace in U-mode.
Stretch goals:
FPU support, S-Mode support with MMU, SMP. Custom web frontend with more possibilities for I/O (disk image, network?).
Resources
RISC-V ISA Specifications
Shaderoo
OpenGL 4.5 Quick Reference Card
Result as of Hackweek 2024
WebGL turned out to be insufficient, it only supports OpenGL ES 3.0 but imageLoad/imageStore needs ES 3.1. So we switched directions and had to write a native C++ host for the shaders.
As of Hackweek Friday, the kernel attempts to boot and outputs messages, but panics due to missing memory regions.
Since then, some bugs were fixed and enough hardware emulation implemented, so that now Linux boots with framebuffer support and it's possible to log in and run programs!
The repo with a demo video is available at https://github.com/Vogtinator/risky-v
Port some classic game to Linux by MDoucha
Let's pick some old classic game, reverse engineer the data formats and game rules and write an open source engine for it from scratch. Some games from 1990s are simple enough that we could have a playable prototype by the end of the week.
Write which games you'd like to hack on in the comments. Don't forget to check e.g. on Open Source Game Clones, Github and SourceForge whether the game is ported already.
Hack Week 24 - Master of Orion II: Battle at Antares & Chaos Overlords
Work on Master of Orion II continues but we can hack more than one game. Chaos Overlords is a dystopian, lighthearted, cyberpunk turn-based strategy game originally released in 1996 for Windows 95 and Mac OS. The player takes on the role of a Chaos Overlord, attempting to control a city. Gameplay involves hiring mercenary gangs and deploying them on an 8-by-8 grid of city sectors to generate income, occupy sectors and take over the city.
How to ~~install & play~~ observe the decompilation progress:
- Clone the Git repository
- A playable reimplementation does not exist yet, but when it does, it will be linked in the repository mentioned above.
Further work needed:
- Analyze the remaining unknown data structures, most of which are related to the AI.
- Decompile the AI completely. The strong AI is part of the appeal of the game. It cannot be left out.
- Reimplement the game.
Hack Week 20, 21, 22 & 23 - Master of Orion II: Battle at Antares
Master of Orion II is one of the greatest turn-based 4X games of the 1990s. Explore the galaxy, colonize planets, research new technologies, fight space monsters and alien empires and in the end, become the ruler of the galaxy one way or another.
How to install & play:
- Clone the Git repository
- Run
./bootstrap; ./configure; make && make install - Copy all *.LBX files from the original Master of Orion II to the installation data directory (
/usr/local/share/openorion2by default) - Run
openorion2
Further work needed:
- Analyze the rest of the original savegame format and a few remaining data files.
- Implement most of the game. The open source engine currently supports only loading saved games from the original version and viewing the galaxy map, fleet management and list of known planets.
Hack Week 19 - Signus: The Artifact Wars
Signus is a Czech turn-based strategy game similar to Panzer General or Battle Isle series. Originally published in 1998 and open-sourced by the original developers in 2003.
How to install & play:
- Clone the Git repository
- Run
./bootstrap; ./configure; make && make installin bothsignusandsignus-datadirectories. - Run
signus
Further work needed:
- Create openSUSE package
- Implement full support for original game data (the open source version uses slightly different data file contents but original game data can be converted using a script).
New KDE Plasma notification app/applet by apappas
Description
My memory is terrible so I depend a lot on notifications to carry me through the workday. As a plasma user I am ok with the current applet, but I don't love it. It is too small for the centrality it has in my day. Also I dislike how you can not go back to notifications you have dismissed
Goals
Develop a plasma app that * must gather notifications without disrupting the existing notification app * must offer the ablity to refer to dismissed/archived/seen notification up to some defined point in the past * must allow deletion of notifications
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
New migration tool for Leap by lkocman
Update
I will call a meeting with other interested people at 11:00 CET https://meet.opensuse.org/migrationtool
Description
SLES 16 plans to have no yast tool in it. Leap 16 might keep some bits, however, we need a new tool for Leap to SLES migration, as this was previously handled by a yast2-migration-sle
Goals
A tool able to migrate Leap 16 to SLES 16, I would like to cover also other scenarios within openSUSE, as in many cases users would have to edit repository files manually.
- Leap -> Leap n+1 (minor and major version updates)
- Leap -> SLES docs
- Leap -> Tumbleweed
- Leap -> Slowroll
- Leap Micro -> Leap Micro n+1 (minor and major version updates)
- Leap Micro -> MicroOS
Hackweek 24 update
Marcela and I were working on the project from Brno coworking as well as finalizing pieces after the hackweek. We've tested several migration scenarios and it works. But it needs further polishing and testing.
Projected was renamed to opensuse-migration-tool and was submitted to devel project https://build.opensuse.org/requests/1227281
Repository
https://github.com/openSUSE/opensuse-migration-tool
Out of scope is any migration to an immutable system. I know Richard already has some tool for that.
Resources
Tracker for yast stack reduction code-o-o/leap/features#173 YaST stack reduction
Create openSUSE images for Arm/RISC-V boards by avicenzi
Project Description
Create openSUSE images (or test generic EFI images) for Arm and/or RISC-V boards that are not yet supported.
Goal for this Hackweek
Create bootable images of Tumbleweed for SBCs that currently have no images available or are untested.
Consider generic EFI images where possible, as some boards can hold a bootloader.
Document in the openSUSE Wiki how to flash and use the image for a given board.
Boards that I have around and there are no images:
- Rock 3B
- Nano PC T3 Plus
- Lichee RV D1
- StartFive VisionFive (has some image needs testing)
Hack Week 22
Hack Week 21
Resources
Enlightenment in Leap 16 by simotek
Description
Get the Enlightenment stack + X11 building and running on the Leap 16 codebase.
Goals
- Get enlightenment / terminology compiling for Leap 16
- Test that they are running correctly in a Virtual Machine.
Resources
Update Haskell ecosystem in Tumbleweed to GHC-9.10.x by psimons
Description
We are currently at GHC-9.8.x, which a bit old. So I'd like to take a shot at the latest version of the compiler, GHC-9.10.x. This is gonna be interesting because the new version requires major updates to all kinds of libraries and base packages, which typically means patching lots of packages to make them build again.
Goals
Have working builds of GHC-9.10.x and the required Haskell packages in 'devel:languages:haskell` so that we can compile:
git-annexpandocxmonadcabal-install
Resources
- https://build.opensuse.org/project/show/devel:languages:haskell/
- https://github.com/opensuse-haskell/configuration/
- #discuss-haskell
- https://www.twitch.tv/peti343
New openSUSE-welcome by lkocman
Project Description
Let's revisit our existing openSUSE welcome app.
My goal was to show Leap 16 in a new coat. Welcome app adds to the first time use experience. We've recently added donation button to our existing welcome.
Some things that I recently wanted to address were EOL and possibly upgrade notification.
I've already done some experiments with mint welcome app, but not sure if it's better than the existing one.
There is also a PR to rework existing app https://github.com/openSUSE/openSUSE-welcome/pull/36 (this should be considered as an option too)
Goal for this Hackweek
New welcome app, possibly with EOL notification for Leap.
1) Welcome application(s) with (rebrand changes) maintained under github.com/openSUSE
2) Application is submitted to openSUSE:Factory && openSUSE:Leap:16.0
3) Updated needles in openQA (probably post hackweek)
Resources
Reddit discussion about the best welcome app out there.
Github repo for the current welcome app.