Project Description

The folks at Asahi linux have been working on porting linux on the Apple Silicon. In a recent blog post they announced they will be joining forces with Fedora on releasing a Fedora Asahi Remix. I would be happy to see this level of collaboration between Asahi and openSUSE community, too.

Goal for this Hackweek

Ideally, create an openSUSE spin that would benefit from the great work of the Asahi linux folks. A minimum requirement for success - is reaching out to them, and talk about the partnership opportunity.

Resources

I need help from the openSUSE board. Looks like Neal, wearing his Fedora, was already in contact with them. add-emoji

A few openSUSE hackers might be interested in experimenting with the stuff available in Asahi Linux repos.

Note: I doubt that I would be able to deliver anything useful for this project, but would be happy to take the challenge if anyone finds any use for me.

Looking for hackers with the skills:

applesilicon asahilinux opensusespin opensuse apple

This project is part of:

Hack Week 23

Activity

  • about 1 year ago: binary_sequence liked this project.
  • about 1 year ago: ggardet_arm liked this project.
  • about 1 year ago: itorres liked this project.
  • about 1 year ago: mbrugger liked this project.
  • about 1 year ago: dgedon liked this project.
  • about 1 year ago: bfilho liked this project.
  • about 1 year ago: eminguez liked this project.
  • over 1 year ago: Pharaoh_Atem liked this project.
  • over 1 year ago: livdywan liked this project.
  • over 1 year ago: livdywan started this project.
  • over 1 year ago: vgrinco added keyword "opensuse" to this project.
  • over 1 year ago: vgrinco added keyword "apple" to this project.
  • over 1 year ago: vgrinco added keyword "applesilicon" to this project.
  • over 1 year ago: vgrinco added keyword "asahilinux" to this project.
  • over 1 year ago: vgrinco added keyword "opensusespin" to this project.
  • over 1 year ago: vgrinco originated this project.

  • Comments

    • vgrinco
      over 1 year ago by vgrinco | Reply

      @Pharaoh_Atem hoping to get a reaction on this one add-emoji

    • livdywan
      over 1 year ago by livdywan | Reply

      Very cool project. I'm an early tester of Fedora Remix. No idea what's required to enable openSUSE, though.

    • Pharaoh_Atem
      over 1 year ago by Pharaoh_Atem | Reply

      This would certainly be cool to do. add-emoji

    • mbrugger
      about 1 year ago by mbrugger | Reply

      I suppose the first thing would be to understand the installer script to see where we could plug-in our openSUSE bits

    • mgrossu
      about 1 year ago by mgrossu | Reply

      I found a port of openSUSE on GitHub: https://github.com/ivabus/asahi-opensuse/

    Similar Projects

    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


    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.


    Digital art wallpapers for openSUSE Leap and Tumbleweed by lkocman

    Description

    We've enrolled set of new wallpapers to both Leap 16 and Tumbleweed as part of https://news.opensuse.org/2024/10/26/leap-tw-get-makeovers/

    We've previewed digital art wallpapers which were not part of the initial drop. I'd like to spend time on hackweek to finialize my current Taipei (mountains) and Mauritius digital art wallpapers.

    Goals

    Finalize existing two digital art wallpapers for Leap and Tumbleweed https://github.com/openSUSE/branding/issues/155 Make them available as part of leap16 dir in https://github.com/openSUSE/wallpapers and update (This makes is available to Tumbleweed users as well). Update https://build.opensuse.org/package/show/X11:common:Factory/wallpapers-openSUSE-extra && Leap:16.0 && Factory.

    Resources

    https://github.com/openSUSE/branding/issues/155 The mauritius draft can be found in https://github.com/lkocman/geo-wallpapers


    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