uncomfy - opensuse

I am running for board membership

2026-02-19T09:51:18+00:00

Hi there. I am actually running for openSUSE's board membership.

And the reality is... I don't know what it's like to run or lead a community. 😅

So why?§</a > </h1>
The community is growing. With multiple derivatives, I think it's time that we need to find new stewards of the community. I am not really sure where to start on this as, honestly, my only pressing concern is that who are going to replace the oldies1</a>?
Jokes aside, the openSUSE community is growing but as a community grows, there is also another pressing problem if the current structure of governance can keep up.
Am I capable to be a board member? What even is a board member?§</a > </h1>
The short answer is I don't know. The other short answer is no.
I am not really sure if I can commit to it either. What I do know is my passion for the community.
A board member in openSUSE is to lead the overall project in different areas and that includes moderating conflicts, revising rules, and promoting inclusivity.
It may also include initiatives like new projects or conferences and partnerships.
With that said, I don't think there really is much to say to change a board member's role in the community.
Regarding the proposed changes on Governance§</a > </h1>
This thread -> https://lists.opensuse.org/archives/list/project@lists.opensuse.org/thread/YKI5QVMT66WMZLOPTCQOEQZPTEWPDIBV/</a> contains the proposed governance structure for the openSUSE community. It's a lot so you have to read it again and again. Took me days to get to it but I have an idea of what was being proposed.
The proposal is intended to add new committees instead of having just the board members pivoting the project. If I can understand correctly, this is meant to invite more contributors and allow to diversify the functions and goals of the project as well as ensuring that the community is involved. By adding new committees, new independent bodies and members will take initiative on how to steer the project in specific areas. Here is a copy of the proposed committees and their roles:

Introducing a Technical Steering Committee to provide technical direction and arbitration when consensus fails</li>
Introducing a Community & Marketing Committee focused on community growth, communication spaces, and outreach</li> </ul> </blockquote>
After I read until the end, there really is nothing much that has changed but just an additional specificity that the project needs so new contributors are not burdened by confusion. Autonomy is preserved and at least the community now has a clearer way to contribute back without the need to understand the full history of the project.
Overall opinion about the new governance §</a > </h1>
Like Bernhard said, it is well formulated.

Although, our views might be different so well formulated might be a different part of the proposal or the overall proposal itself. </blockquote>
Because in my opinion, the new governance structure allows that the power to steer the project is for the community, by the community, to the world.
Closing thoughts and concerns§</a > </h1>
My only concern now is I have no history of being involved in discussions, especially as a newcomer and from Asia and no experience in being a steward of a community. But that's something I'll know once I am elected.
Answering the bonus question §</a > </h1>
I'll be honest, the dates are overlapping with my family's celebration plan for my sister's medschool graduation so there is a chance that I am not able to attend oSC2026. Maybe I can attend the openSUSE.Asia Summit which was proposed to be hosted in Indonesia, a neighbour country. I am excited to attend. Hopefully, I'll get employed by then and save enough to get there (currently unemployed as of writing 🥀🥀🥀🥀🥀)

Old people 50+yrs oldies. Although, there really is a bit of truth to it that I think we might need to have younger members... ↩</a> </li> </ol> </section>

Let's revisit packaging with SCMSync workflow

2025-07-20T00:00:00+00:00

So here I am doing another attempt at updating a package in openSUSE. This package is biome</a>. As of writing, it's way behind 1 minor version, and still at version 2.0.5.
Preparing to fork and clone §</a > </h1>
The first thing I did was login to https://src.opensuse.org</a> with my openSUSE account.


Once logged in, I headed to https://src.opensuse.org/javascript/biome</a>.

I clicked the fork button on the upper-right and cloned the repository to inside a local directory, in this case, mine is located at ~/development/git-obs/</code> since this kind of workflow does not really require a "root" OBS directory e.g. ~/development/obs</code> where it contains directories to projects such as my home project home:uncomfyhalomacro</code> that contains packages or subprojects.


Updating the sources§</a > </h1> I deleted the sources first with the following commands: cd biome # heading into the git repository git rm *.tar* # deleting the sources</code></pre> FYI, I accidentally ran osc rm *.tar*</code> at first because I was still stuck with the mindset using the old workflow. The latest version as of writing is now at 2.1.2 or specifically, at the git tag @biomejs/biome@2.1.2</code>. Seems they use a different naming scheme for tagging versions but it's still 2.1.2. No worries because the Source0</code> points to the archive of the same naming scheme. Then I ran the following command. osc service -vvv mr</code></pre> As you can see from the image above, biome has a lot of crate dependencies. This command produced two new tarballs, biome-2.1.2.tar.gz</code> and a refreshed vendor.tar.zst</code>. Updating the changes file§</a > </h1> I ran the following command to update the biome.changes</code> file. osc vc</code></pre> However, this makes this a manual process because there is no perfect way to get all changelogs. Hence, I have to clone the upstream biome repository on GitHub. Then ran the following commands to get each commit summary between 2.0.5 and 2.1.2. git log @biomejs/biome@2.0.5..@biomejs/biome@2.1.2 --oneline | cut -d' ' -f2- | wl-copy</code></pre> Commiting and pushing the changes§</a > </h1> Then I committed those changes after adding the updated files and removing the old sources. I ran git push</code>. Remember that this operation should have Git LFS enabled. Setting the meta project and meta package§</a > </h1> At this point, if I was sure that this will build correctly, I can just open a PR to https://src.opensuse.org/javascript/biome</a>. However, just for showing how I set a meta project and a meta package, I ran the following commands. osc meta prj -e home:uncomfyhalomacro:biomejs</code></pre> The XML file configuration for this meta project is this. <project name="home:uncomfyhalomacro:biomejs"> <title></title>  <description></description>   <person role="maintainer" userid="uncomfyhalomacro" /> <person role="bugowner" userid="uncomfyhalomacro" />  <publish> <disable /> </publish> <build> <enable /> </build> <debuginfo> <enable /> </debuginfo> <repository name="openSUSE_Factory"> <path project="openSUSE:Factory" repository="snapshot" /> <arch>x86_64</arch> <arch>i586</arch> </repository> </project></code></pre> Take note that I did not set scmsync option for this because I don't need to or I have not learned to set a git project as a meta project's scmsync option yet. For package setup, I pointed it to the new meta project and then added a suffix /biome</code> to create a package biome. osc meta pkg -e home:uncomfyhalomacro:biomejs/biome</code></pre> Sadly, I am not too fluent with how the XML configuration works. So I just passed this one instead <package name="biome"> <title></title>  <description></description>  <scmsync>https://src.opensuse.org/uncomfyhalomacro/biome#main</scmsync>    </package></code></pre> Notice the scmsync option. I pointed it to my fork and with the branch "main". Fortunately, the meta project has the correct config for setting which images to use for the build workers. For clarity, the full link to the build after setting the meta project and meta package is https://build.opensuse.org/package/show/home:uncomfyhalomacro:biomejs/biome</a>. You may not be able to access this in the future because I probably deleted the meta project. I waited for the builds to succeed. One of the builds succeeded after a while. Making a PR§</a > </h1> Lastly, I created a PR from my fork to the javascript project The autogits-devel bot will stage my changes (with the autogits_obs_staging_bot) and creates a new meta project for testing my PR. It basically just did what I did in the last steps where I created a meta project and meta package and check if the builds succeed. Once the builds succeed, my changes are then merged. The merge message should look similar to the one I had for rusty_v8 (see image below). Conclusion§</a > </h1> At this point, I am not familiar how those changes are pushed into Factory</del>. I believe there will be an automation as well for pushing devel packages from devel projects to Factory. I also believe that the https://opensuse.github.io/scm-staging/user_guide.html</a> is deprecated or inaccurate because of this experience. In conclusion, I guess this is how far I can understand how the SCMSync workflow works. If you have any questions, just email me</a> or message me in openSUSE Discord</a>. Updated Last Step–SR a devel project to Factory§</a > </h1> Avindra, one of the packagers, messaged me on Discord and that there is a part I missed. To submit a devel project to Factory, one can just do the same thing as mentioned in https://en.opensuse.org/openSUSE:OBS_to_Git#How_to_submit_from_devel_project_to_Factory?</a>. Hence, for biome, it would be just osc sr devel:languages:javascript/biome openSUSE:Factory</code></pre> But when I did this, the rev is suspicious and also there was no changelog. I aborted because I then discovered that the meta package is still building for RISCv64. It's still building after I slept for 8 hours... 🤣 Thus, I SR-ed for rusty_v8. I will SR for deno too after a few days to let the snapshot have rusty_v8. 🙂
Packaging with Roast and Roast SCM 2025-06-01T00:00:00+00:00 Hello! In the iteration of all the changes for roast</a>, we have finally released a new major version, 7.x series. Although, I really don't care much about the strictness of version numbers, this release brings a new addition, a feature flag called obs</code>. This is OpenBuildService</a> specific, and it allows it to become an alternative to obs-service-set_version</code> + obs-service-obs_scm</code>, hence, a combination of both services. roast itself is using this to package itself to b-o-o</a> using the following _service</code> file configuration. <services> <service name="roast_scm" mode="manual"> <param name="url">https://codeberg.org/Rusty-Geckos/roast</param> <param name="revision">v7.1.1</param> <param name="versionrewriteregex">v(.*)</param> <param name="versionrewritepattern">${1}</param> <param name="changesgenerate">true</param> <param name="changesauthor">Soc Virnyl Estela</param> <param name="changesemail">uncomfyhalomacro@opensuse.org</param> </service> <service name="cargo_vendor" mode="manual"> <param name="src">roast*.tar.zst</param> <param name="update">true</param> </service> </services></code></pre> which can be seen here</a>. In the future, I will release a small video tutorial on how to use roast_scm</code> for b-o-o</a>. Because the crate is written in Rust, I intentionally made it part of obs-service-cargo</a> because of this PR</a> which is now merged. With this, sources can now be fetched from git sources and vendored in just one XML file, like for obs-service-cargo</code> itself: <services> <service name="cargo_vendor" mode="manual"> <param name="src">https://github.com/openSUSE-Rust/obs-service-cargo</param> <param name="update">true</param> <param name="versionrewriteregex">^v?(.*)</param> <param name="versionrewritepattern">${1}</param> <param name="changesgenerate">true</param> <param name="revision">master</param> <param name="changesauthor">Soc Virnyl Estela</param> <param name="changesemail">uncomfyhalomacro@opensuse.org</param> </service> </services></code></pre> which can also be seen here</a>. Since I am one of the active Rust packagers in openSUSE, I plan to just switch and use this new feature for vendoring auto-magically. Well, that's just it for this short update. Why I stopped maintaining Julia in openSUSE 2025-05-15T00:00:00+00:00 So recently, I noticed that I have a lot of emails about some build problems in openSUSE, specifically, the Julia</a> package. I attempted to package this software for openSUSE in hopes that I can help out bring the programming language to the Linux distribution. However, it was kind of hairy, not to mention, a lot of workarounds... like a lot — imagine you have to patch and create a lot of patches for the patches to patch the patches. So I have ignored it for a very long while, thinking that I can do it in the future. But as of writing? I gave up. It's a tiresome software to package, and it is incompatible most of the time with OpenBuildService's policies. But if you still want to use Julia in openSUSE, you can always use the juliaup</a> package. It is a version multiplexer for Julia similar to rustup</a>. Just run the following command on your terminal if you are using openSUSE. sudo zypper install juliaup</code></pre> Nothing much I can say further as this is just a small update. Bye! Exploring Efficient Ways To Package Rust Software in openSUSE 2024-08-22T00:00:00+00:00 Update I am moving over some logic as another package called roast</a>. This is to prepare this vendoring alternative called obs-service-cargo-vendor-home-registry</a>. The project is still worked on during my free time. </blockquote> I have re-investigated possible solutions for confusing packaging in Rust. Currently, we are using cargo vendor</code> to vendor package dependencies. This comes at a cost. Back and forth copying of .cargo/config.toml</code> for possible projects that use monorepo configurations i.e. workspace and real monorepos. Examples of these are: zellij, wezterm and python-tokenizers</li> </ul> </li> We always want to ensure Cargo.lock</code> and I doubt the solution will not avoid this since lockfiles are always essential when building software with Rust.</li> Existing .cargo/config.toml</code> from projects will be overridden with our generated .cargo/config.toml</code>.</li> </ul> The first solution I thought of is a global .cargo/config.toml</code> for projects. This has been done with python-tokenizers in openSUSE because it is possible to use --manifest-path</code> to specify a manifest Cargo.toml</code> file in the specfile for cargo invocations. Seeing this, I realised, why not just use the $CARGO_HOME</code> since we are pointing at a global cache anyway? This blog is about tracking my future project https://github.com/uncomfyhalomacro/obs-service-cargo-vendor-home-registry</a> of which I plan to integrate into https://github.com/Firstyear/obs-service-cargo</a> as an alternative vendor generating utility for Open Build Service or OBS. Storage size eaten by CARGO_HOME</code> vs cargo vendor</code> comparison§</a > </h1> NOTE cargo fetch</code>, cargo vendor</code>, cargo build</code>, and cargo generate-lockfile</code> all update the CARGO_HOME</code> or what we call the cargo home registry or just cargo home. We use cargo fetch</code> here because it's designed to update the registry cache instead of other commands. WARNING Behaviours between cargo fetch</code> and cargo generate-lockfile</code> cargo fetch</code> updates the registry to latest version of crates and also regenerates Cargo.lock</code> to reflect the versions unless --locked</code> flag is passed where it tries to respect the versions of the crates from the existing Cargo.lock</code> despite this contradicting description in the manpage that If a Cargo.lock file is available, this command will ensure that all of the git dependencies and/or registry dependencies are downloaded and locally available. Subsequent Cargo commands will be able to run offline after a cargo fetch unless the lock file changes. However, cargo generate-lockfile</code> updates the registry + updates the Cargo.lock</code> which in my opinion is just a duplication of the other cargo sub-command cargo update</code>. Why? Both do the same behaviour. Even the part where you pass --locked</code> will give you the same error "error: the lock file /run/host/tmp/jay-1.4.0/Cargo.lock needs to be updated but --locked". </blockquote> Here are the zstd compressed tarballs for the following after running the cargo commands wezterm cargo-vendor</code>: 1.1GB</li> cargo-fetch</code>: 1.3GB</li> </ul> jay cargo-vendor</code>: 24MB</li> cargo-fetch</code>: 76MB</li> </ul> zellij cargo-vendor</code>: 66MB</li> cargo-fetch</code>: 133MB</li> </ul> Why does it seem like cargo-fetch</code> duplicates the contents in the tarball? Because it really does. The registry contains the following directory structure . └── registry ├── cache │ └── index.crates.io-6f17d22bba15001f ├── index │ └── index.crates.io-6f17d22bba15001f └── src └── index.crates.io-6f17d22bba15001f 8 directories, 0 files </code></pre> One can remove the .cargo/registry/src</code> directory as that contains the extracted crates and then create a tar.zst</code> file using the following commands # Assuming $CARGO_HOME is set to $PWD/.cargo pushd .cargo rm -rfv registry/src popd tar --zstd -cvf vendor.tar.zst .cargo/</code></pre>How to get cache from $CARGO_HOME</code>§</a > </h1> Any of these commands will generate the cargo home registry cache build</li> generate-lockfile</li> vendor</li> fetch</li> update</li> </ul> Some commands are duplication of the other commands i.e. update and generate-lockfile. It's just that the former prefetches the latest crate versions while the latter doesn't.</del> To update the registry cache, one must either go with cargo fetch</code> or even cargo vendor</code> to avoid building or updating (unless update is set). All commands try to regenerate the Cargo.lock</code> with the latest compatible MSRV. If --locked</code> is passed, it will try to attempt to respect the versions in the Cargo.lock</code>. However, if the version of a dependency in Cargo.lock</code> got yanked and there is a newer version, then an operation with --locked</code> will fail. Also, passing --locked</code> to cargo-update</code> is ambiguous as it will always almost fail since it tries to update the Cargo.lock</code>. Why not go with cargo vendor --sync</code>§</a > </h3> Reason? Uncertainty of how that command respect Cargo.lock</code> for each crate. I would rather have do cargo fetch --locked --manifest-path=path/to/Cargo.toml</code></pre> for each manifest found since one can flexibly turn --locked</code> on and off. Building now with $CARGO_HOME</code>§</a > </h1> It's always has been possible to use $CARGO_HOME</code>, specifically, $CARGO_HOME/registry</code>. There was an attempt in this repository, https://github.com/openSUSE-Rust/obs-service-cargo-vendor-home-registry</a>. Now, that project has been merged into https://github.com/openSUSE-Rust/obs-service-cargo</a>. You can see this working in https://build.opensuse.org/package/show/editors/kak-lsp</a>. But we lied a bit here. We will explain that in the later sections. Path dependencies in Cargo.toml</code> needs to be revisited§</a > </h2> Membered crates (in workspace configurations) and local crates (both are local and in path actually) should also be taken consideration when vendoring dependencies. For example, https://build.opensuse.org/package/show/science:machinelearning/python-tokenizers</a> have two different dependencies that are actually related to each other. The solution to this is to eagerly check their manifest and lockfiles. Hence, either with multiple vendor tarballs or a vendored $CARGO_HOME</code>. Lockfiles are always inconsistent§</a > </h2> See https://github.com/rust-lang/cargo/issues/7169</a>. This is a glaring issue and not just for cargo install</code> but almost all cargo commands such as cargo fetch</code>. That's why in openSUSE, we try to include the lockfile as much as possible even if passing --locked</code>. I think I would agree to this comment https://github.com/rust-lang/cargo/issues/7169#issuecomment-539226733</a>. Observation cargo fetch --locked</code> does not work because it tries to keep the registry cache updated</li> cargo vendor --locked</code> works because I don't know why???</li> </ul> Now is the use of --sync</code> idea thrown out the window? For crates that don't ship with a lockfile, we will run eithercargo generate-lockfile</code> or cargo update</code>, former is more semantically correct to do as opposed to cargo update</code>. But update</code> makes sense the most because we are going to add update options on the new project anyway. cargo-fetch</code> vs cargo-update</code>§</a > </h2> Two days ago as of writing, I filed a bug report regarding inconsistencies between cargo-fetch</code> and cargo-vendor</code>. Link to bug report https://github.com/rust-lang/cargo/issues/14795</a>. The inconsistency specifically is the way the two handle dependencies differently especially when it comes to cargo-fetch</code>'s --target</code> flag. I had high hopes that by default1</a>, it gets all target architectures. But I was met with failed builds on not so commonly used</del> architectures whereas vendored dependencies from cargo-vendor</code> compiles. They fail because they cannot find their dependencies fetched from cargo-fetch</code>. I will just have to wait for a feedback regarding how cargo-fetch</code> behaves as compared to cargo-vendor</code>. I believe though that both should be at least similar in almost all aspects. This is still not a loss yet for me since most of the software I used in openSUSE are used by people who either use x86_64 and aarch64. I don't believe that the other architectures are used commonly so I have removed support. ↩</a> </li> </ol> </section> Packaging Crystal Software for openSUSE 2023-07-31T00:00:00+00:00 Prerequisites§</a > </h2> You will need the following: osc</code> and obs-service-download_files</code></li> your editor of choice e.g. emacs, helix</li> tar</code></li> familiarity of how to use https://build.opensuse.org/</a>. See https://en.opensuse.org/Portal:Packaging</a> for guides. Fedora has one too, see https://docs.fedoraproject.org/en-US/packaging-guidelines</a>.</li> crystal</code></li> </ul> Check with zypper if osc</code> is installed. Tip: Use the cnf</code> command to check which package osc</code> comes from. cnf osc</code></pre></blockquote> Recipe§</a > </h2> The following subtopics explain how to package crystal software step-by-step. Adjust accordingly based on your setup. Create a new package§</a > </h3> You can do it at https://build.opensuse.org/</a> but if you prefer the commandline, you can do for example osc mkpac blahaj cd blahaj</code></pre> In this tutorial, we will try to package BLAHAJ</a> using the shards</a> project and dependency manager for Crystal</a> and tar</code>. Package without a dependency§</a > </h2> Write the specfile§</a > </h3> Using your preferred editor, create a file named blahaj.spec</code>. The following prelude should be enough for the specfile: Name: blahaj Version: 2.1.0 License: BSD-2-Clause Summary: Gay sharks at your local terminal Url: https://github.com/GeopJr/BLAHAJ Source0: https://github.com/GeopJr/BLAHAJ/archive/refs/tags/v2.1.0.tar.gz#/%{name}-%{version}.tar.gz Source1: vendor.tar.zst BuildRequires: crystal BuildRequires: shards BuildRequires: make</code></pre> How do I have shards</code> and crystal</code>? </blockquote> You can branch packages from my home project at Open Build Service - https://build.opensuse.org/project/show/home:uncomfyhalomacro</a>. Or even just add an repository image of that project. I have shards</code> and crystal</code> there. The latter can also be found at https://build.opensuse.org/package/show/devel:languages:crystal/crystal</a> if you want that too. For the sake of simplicity, we will assume that we are going to use crystal</code>, shards</code>, and make</code> at your home project in Open Build Service. Add the following sections: description, prep, build, install, files and changelog section. Name: blahaj Version: 2.1.0 Release: 0 License: BSD-2-Clause Summary: Colorize your terminal with gay sharks Url: https://github.com/GeopJr/BLAHAJ Source0: https://github.com/GeopJr/BLAHAJ/archive/refs/tags/v2.1.0.tar.gz#/%{name}-%{version}.tar.gz BuildRequires: crystal BuildRequires: shards BuildRequires: make %description Apart from a cute cuddly shark plushie from IKEA, BLÅHAJ is a lolcat-like CLI tool that colorizes your input, shows flags and prints colorful sharks! It has a wide variety of flags/colors to choose from and many options from flag size to whether to colorize by line, word or character. %prep %build %install %files %changelog</code></pre> At the root of your project package e.g. home:yourusername/blahaj</code>, run osc service localrun download_files</code>. You will get a file called blahaj-2.1.0.tar.gz</code>. Extracting the file gets us the directory BLAHAJ-2.1.0/</code>. This means that in our %prep</code> section, we need to add %setup -qa1 -n BLAHAJ-%{version}</code>. This is to redirect the rpm macros that building should be at RPM_BUILDDIR/BLAHAJ-2.1.0/</code> since by default, it is RPM_BUILDDIR/nameofpackage-version/</code> based on the Name:</code> and Version:</code> RPM specfile prelude. Building and Installing the package§</a > </h3> The following sections should be easy here since make</code> as build dependency has convenient macros such as %make_build</code> and %make_install</code>. Name: blahaj Version: 2.1.0 Release: 0 Summary: Colorize your terminal with gay sharks License: BSD-2-Clause Url: https://github.com/GeopJr/BLAHAJ Source0: https://github.com/GeopJr/BLAHAJ/archive/refs/tags/v2.1.0.tar.gz#/%{name}-%{version}.tar.gz BuildRequires: crystal BuildRequires: shards BuildRequires: make %description Apart from a cute cuddly shark plushie from IKEA, BLÅHAJ is a lolcat-like CLI tool that colorizes your input, shows flags and prints colorful sharks! It has a wide variety of flags/colors to choose from and many options from flag size to whether to colorize by line, word or character. %prep %setup -q -n BLAHAJ-%{version} %build %make_build %install %make_install %files %{_bindir}/blahaj %doc README.md CODE_OF_CONDUCT.md %license LICENSE %changelog</code></pre> As for %files</code>, you can just do a "best guess" or "best observation" approach. Here, we based it from the Makefile</code> and for documentation and license, those are self-explanatory. Changelog can be left as is since we are not Fedora 😘. We use blahaj.changes</code> for that generated with osc vc</code>. It creates a temporary file you can edit from like below ------------------------------------------------------------------- Mon Jul 31 12:34:07 UTC 2023 - Your Name <youremail@example.com> - Initial spec for blahaj 2.1.0 </code></pre>Add the files§</a > </h3> Add the files by running the command osc add blahaj.spec blahaj-2.1.0.tar.gz blahaj.changes</code></pre> And then push it to your home project at Open Build Service with osc ci</code>, which allows you to check the diff and see what was changed based from the blahaj.changes</code> file. Check if it builds correctly§</a > </h3> Now check your new blahaj package at your home project. If it fails, investigate what went wrong! Check mine at https://build.opensuse.org/package/show/home:uncomfyhalomacro/blahaj</a>. NOTE: It seems at the time of writing, I missed some dependencies or optional dependencies for crystal! Anyway, I am confident it will build this correctly after that's fixed. </blockquote> Package With dependencies§</a > </h2> This is where tar</code> and shards</code> comes in. An example of this is shards</code> itself. See https://build.opensuse.org/package/show/home:uncomfyhalomacro/shards</a>. What I did here is at the root of the project e.g. home:yourname/shards, I extracted the shards source tarball, tar xvf shards-0.17.3.tar.gz</code>. Changed directory to the extracted directory, shards-0.17.3/</code> and then ran shards check</code> and shards install</code>. You will get a new directory called lib/</code>. This is where you vendor your dependencies like how Rust and Go do. To vendor it, it's simple. Just run tar --zstd -cvf vendor.tar.zst lib/</code></pre> Copy vendor.tar.zst</code> to the root of the project package folder. Add it to one of the sources of your project and adjust your %setup</code> with flags -qa1</code> which a1</code> means extract Source1: vendor.tar.zst</code> to the root of RPM_BUILDDIR/shards-0.17.3</code> including the root folder of the archive lib/</code>. This will create a new directory called lib/</code>, and contains other crystal packages that are dependencies of that project. Then I just used crystal</code> to build shards</code> as seen from the build section and do a manual install with install</code> command at the install section. Other possibilities§</a > </h2> You can also remove make</code> or shards</code> as well if you prefer just using crystal</code> on the build section.

uncomfy - opensuse

I am running for board membership

Let's revisit packaging with SCMSync workflow

Packaging with Roast and Roast SCM

Why I stopped maintaining Julia in openSUSE

Exploring Efficient Ways To Package Rust Software in openSUSE

How to get cache from $CARGO_HOME</code>§</a > </h1> Any of these commands will generate the cargo home registry cache</p> build</li> generate-lockfile</li> vendor</li> fetch</li>

Packaging Crystal Software for openSUSE