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

• NanoPC T4

Hack Week 21

• NanoPi M4B
• Radxa Zero

Resources

• https://en.opensuse.org/Portal:Arm
• https://en.opensuse.org/Portal:RISC-V

---

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-annex
• pandoc
• xmonad
• cabal-install

Resources

• https://build.opensuse.org/project/show/devel:languages:haskell/
• https://github.com/opensuse-haskell/configuration/
• #discuss-haskell
• https://www.twitch.tv/peti343

---

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

---

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

---

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.

---

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.

---