Description

There are already k9s and kustomize packages that exist for openSUSE today. These could be used as the source for these binaries in our rancher projects. By using them we would benefit from CVE fixes included in our distribution of the packages not in cluded upstream. However they are not providing arm package builds which are required.

Goals

  • [ ] Update the kustomize package in OBS to use the newest version and send change request

Resources

  • k9s: https://build.opensuse.org/package/show/openSUSE:Factory/k9s
  • kustomize: https://build.opensuse.org/package/show/openSUSE:Factory/kustomize
  • Learning Docs: https://confluence.suse.com/display/packaging/Training%2C+Talks+and+Videos

Looking for hackers with the skills:

obs

This project is part of:

Hack Week 24

Activity

  • 2 months ago: dpock started this project.
  • 2 months ago: hennevogel added keyword "obs" to this project.
  • 3 months ago: hennevogel liked this project.
  • 3 months ago: dpock originated this project.

  • Comments

    • dpock
      2 months ago by dpock | Reply

      The first thing I've learned about OBS revolves around the way packages are maintained and delivered. And unfortunately, that lesson largely causes the rest of the "exciting" parts of this hack week project to fizzle away.

      I assumed that because I couldn't do: zypper in k9s On the BCI images that this would work for all architectures after adding the right repo. This may still be partially possible, however the architecture for packages may cause the source to vary.

      For instance the k9s package for ARM on factor can be found here: https://build.opensuse.org/package/show/openSUSE:Factory:ARM/k9s

    • dpock
      2 months ago by dpock | Reply

      In my testing to learn OBS, I enabled my project to have ARM published on 15.6 and 15.7. Then enabled the repo to build for those and it gave me the desired results: https://build.opensuse.org/package/show/home:dpock:branches:devel:kubic/k9s

      However, even this isn't strictly necessary as I once suspected. Since ARM builds/packages exist in a dedicated repo. So for the intent of my downstream project, we just add both repos into the image. The ARM ones will be used on arm and ignored on non-arm.

      • donna1205
        7 days ago by donna1205 | Reply

        That's a great discovery! It sounds like you've successfully streamlined your Worldle process for handling ARM builds with OBS

    • dpock
      2 months ago by dpock | Reply

      Ultimately it seems like the k9s package -which was the biggest concern- is ready to use. No notes needed to shift over to use that in our image. However, kustomize binary is very old so needs to be updated.

    • dpock
      2 months ago by dpock | Reply

      I've created an initial PR to switch k9s to this source for shell: https://github.com/rancher/shell/pull/294

    • dpock
      about 2 months ago by dpock | Reply

      I must admit - this project is a bit of a bust at this point.

      In hindsight, it was created with a clear assumption that "SLES is missing these packages due to missing repo sources". From my previous comments it should be fairly clear that this assumption was incorrect. There are multiple community-maintained packages that can be sourced for the development package, which in turn can feed into the repo which could be used in SLES (and there by BCI images).

      That said, the difficulties I found accessing these binaries via BCL images are more reflective of openSUSE/SLES packaging practices. To solve for that may still be possible, however it's not going to be a technical focused solution as I assumed I could attempt here.

    Similar Projects

    Automation of ABI compatibility checks by ateixeira

    Description

    ABI compatibility checks could be further automated by using the OBS API to download built RPMs and using existing tools to analyze ABI compatibility between the libraries contained in those packages. This project aims to explore these possibilities and figure out a way to make ABI checks as painless and fast as possible for package maintainers.

    Resources

    https://github.com/openSUSE/abi-compliance-checker

    https://github.com/lvc/abi-compliance-checker

    https://sourceware.org/libabigail/


    obs-service-vendor_node_modules by cdimonaco

    Description

    When building a javascript package for obs, one option is to use https://github.com/openSUSE/obs-service-node_modules as source service to get the project npm dependencies available for package bulding.

    obs-service-vendornodemodules aims to be a source service that vendors npm dependencies, installing them with npm install (optionally only production ones) and then creating a tar package of the installed dependencies.

    The tar will be used as source in the package building definitions.

    Goals

    • Create an obs service package that vendors the npm dependencies as tar archive.
    • Maybe add some macros to unpack the vendor package in the specfiles

    Resources


    Bootstrap openSUSE on LoongArch by glaubitz

    Description

    LoongArch is a new architecture from China which has its roots in the MIPS architecture. It has been created by Loongson and is already supported by Debian Ports, Gentoo and Loongnix.

    Upstream support for LoongArch is already quite complete which includes LLVM, Rust, Golang, GRUB, QEMU, LibreOffice and many more. In Debian Ports, where the port is called "loong64", more than 95% of the whole Debian archive have been successfully built for LoongArch.

    QEMU support is rather complete and stable such that packages can be built in emulated environments. Hardware can also be requested by Loongson on request for free. Access to real hardware is also provided through the GCC Compile Farm.

    Goals

    The initial goal should be to add LoongArch to OBS and build a minimal set of packages.

    Resources

    Results

    Acknowledgements

    • Thanks to Adrian Schröter and Rüdiger Oertl for the help with setting up the FTP space and OBS project
    • Thanks to Dirk Müller for the input on how to get started with a new port
    • Thanks to Richard Biener for quickly accepting my submit requests to add loongarch64 support to the toolchain


    Git CI to automate the creation of product definition by gyribeiro

    Description

    Automate the creation of product definition

    Goals

    Create a Git CI that will:

    • automatically be triggered once a change (commit) in package list is done.
    • run tool responsible to update product definition based on the changes in package list
    • test the updated product definition in OBS
    • submit a pull request updating the product definition in the repository

    NOTE: this Git CI may also be triggered manually

    Resources

    • https://docs.gitlab.com/ee/ci/
    • https://openbuildservice.org/2021/05/31/scm-integration/
    • https://github.com/openSUSE/openSUSE-release-tools


    Learn obs/ibs sync tool by xlai

    Description

    Once images/repo are built from IBS/OBS, there is a tool to sync the image from IBS/OBS to openqa asset directory and trigger openqa jobs accordingly.

    Goals

    Check how the tool is implemented, and be capable to add/modify our needed images/repo in future by ourselves.

    Resources

    • https://github.com/os-autoinst/openqa-trigger-from-obs
    • https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin/-/tree/master?ref_type=heads