July 2024 - openSUSE Packaging - openSUSE Mailing Lists

Questions about Intel Packages
by compellingbytes＠protonmail.com 03 Aug '24

03 Aug '24

Hi, I'm working on a youtube video about which Intel packages to install on Ubuntu, Debian, and potentially openSUSE to be able to use an Intel Arc/Xe Core APU for compute functions. I had some questions about the structure and choices of these packages, since I noticed some differences between how things are done for Debian/Ubuntu, and other things. If this isn't the best place to ask these questions, please direct me to the right mailing list or forum. First Question: On Ubuntu, Libmfx-gen1.2 is the only package needed for oneVPL-intel-gpu, while on openSUSE Tumbleweed, you need libmfx-gen and libmfx-gen_2 for seemingly the same functionality? Libmfx-gen is 6.6KiB while libmfx-gen1_2 is 8.4MiB, could someone explain why there's a size discrepancy, and what the function of the two packages are? Second Question: I noticed that libvp2 is being built based on oneVPL 2.10.1-2.2, while 2.10.1 was released in December 2023. 2.10.1 was released in December 2023, and that's the only 2.10.1 I see available on github. Are versions like 2.10.1-2.2 created by the openSUSE maintainers with adjustments for openSUSE or... where do they come from? Sub question The latest version is 2.11.0, and I'm wondering if there's an issue as far as it not being the version available for openSUSE Tumbleweed users? Are the intel packages not a priority, especially since there's uncertainty about Intel's gpu future? 3rd question I've tried running the OpenVINO implementation of Stable Diffusion WebUI, and all of the packages needed seem to be available on the openSUSE repo, but script doesn't complete. Would you know if this is because there are at least some packages that are behind the latest of what Intel has made available version wise, or is it an issue with the parameters being passed during compilation by the openSUSE maintainers. I'd really appreciate it if I could get some answers so that I can report a straight story to my audience because I'd really like for Tumbleweed (at least) to be a platform (I'm a Tumbleweed user) that people could utilize Intel Arc/Xe cores on for compute/productivity/AI tasks, instead of having to dual boot into Ubuntu. I hope it doesn't seem that I'm just trying to stick my nose into your business for my own gain; I'd genuinely like to help more people be able to use openSUSE (Tumbleweed) for as many things as possible. Thanks!

4 5

Project for Garage (S3-compatible storage)
by Johannes Kastl 01 Aug '24

01 Aug '24

Hi all, I found Garage recently and tried to package it. Looks good, needs some finetuning and testing. https://git.deuxfleurs.fr/Deuxfleurs/garage/ "S3-compatible object store for small self-hosted geo-distributed deployments" Garage is a S3-compatible storage like MinIO. What would be a good devel project for it? There is no server:storage or similar. Kind Regards Johannes

6 15

How can some packages stay undetected in openQA ?
by Sai Karthik Karra 19 Jul '24

19 Jul '24

Yesterday, I installed nyxt browser & found that it's not launching due to a missing dependency. Installed it manually & it launched. Also, i have proposed a patch https://build.opensuse.org/request/show/1188167 which will catch any runtime errors in the packaging stage. I have encountered a similar issue with neovim too recently. I am curious about why this is not detected in openQA process?

3 2

What to do, when a package exists, but is not pushed to Factory?
by Adam Mizerski 17 Jul '24

17 Jul '24

I recently tried to get munin into usable shape. Now the problem is, that it requires 'perl(CGI::Fast)', which is provided by this package https://build.opensuse.org/package/show/devel:languages:perl/perl-CGI-Fast , which already in the correct devel project, but not pushed to Factory. What should I do? Ask nicely the maintainer (if yes, then who? there are lots of them listed)? Make a submit request by myself?

2 1

RFC: deprecate and drop %suse_update_desktop_file
by Stanislav Brabec 17 Jul '24

17 Jul '24

In 2003, the upstream desktop files translation had a bad quality, as well as desktop tree menu. To prevent ugly and half translated desktop menu, SuSE Linux (actually Novell Linux Desktop 9) introduced the %suse_update_desktop_file macro. It was even mandatory many years ago, and even now it is still recommended in the documentation.[1] This macro does: - Provides SUSE specific desktop translations that don't sync with the upstream. - Provides SUSE specific modification of desktop Categories that don't sync with the upstream. - Provides SUSE specific modifications of Name, GenericName or Comment that don't sync with the upstream. Nowadays, upstream translations got another 20 years of development. Also Desktop Categories specification[2] was updated, and the upstream specification now covers all aspects of former X-SuSE -* Categories extensions. Additionally, the whole concept of %suse_update_desktop_file completely contradicts our policy "Upstream first"[3]. Keeping things as they are, even introduces regressions of the menu and its translation, as nobody updates these texts that diverged from the upstream 20 years ago. That is why I think that %suse_update_desktop_file is now completely obsolete, and it just adds a huge amount of the downstream translation work. We should either upstream it or drop it. If it still brings improvement to the upstream desktop file, it should be sent to the upstream. If it provides a regression, it should be dropped. If it adds obsolete X-SuSE-* desktop Categories instead of modern specification compliant ones, it should be dropped. Current status: %suse_update_desktop_files is used in Factory for 1052 desktop files in 859 packages. It means 3156 strings translation and 1052 desktop files that need to be checked. All of them introduce translatability in the Weblate project [4], some of them modify Categories, GenericName, Comment or even Name (i. e. the application has different names in openSUSE and the upstream (for example: "GNU Image Manipulation Program" is "GIMP" in openSUSE Leap). In summary, it generates a huge amount of translators' work. 1,377,072 words to be translated in sum for supported languages! And most of them just duplicate the upstream translation effort. My plan: 1) Modify %suse_update_desktop_file: a) Whenever %suse_update_desktop_file performs a real change, the user will be warned and asked to review it and send it to the upstream. b) Whenever %suse_update_desktop_file adds obsolete Categories, the user should be warned. c) Whenever %suse_update_desktop_file modifies existing upstream data (Name, GenericName, Comment, existing translations), the user should be warned. 2) Indicate packages, where %suse_update_desktop_file is the only way to translate the desktop. It could be valid for some YaST packages and maybe more. Change them to use the standard way to translate packages in the upstream, e. g. translations as part of the code in the Git repository. Or, if the desktop file is introduced in the spec file (e. g. firefox), create a substitute for update-desktop-files. 3) Turn everything above into an error. 4) Remove %suse_update_desktop_file completely. 5) Drop update-desktop-files package[5] and desktop-file-translations in Weblate[4] References: [1] https://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros#%suse_upd… [2] https://specifications.freedesktop.org/menu-spec/latest/apa.html [3] https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#When_to_send_… [4] https://l10n.opensuse.org/projects/desktop-file-translations/ [5] https://build.opensuse.org/package/show/openSUSE:Factory/update-desktop-fil…

3 3

Using golang buildinfo when building in OBS?
by Johannes Kastl 12 Jul '24

12 Jul '24

Hi all, I found regclient today and packaged it: > https://github.com/regclient/regclient > https://build.opensuse.org/package/show/home:ojkastl_buildservice:Branch_Vi… Unfortunately, the version output is broken, as the package uses the go debug.buildinfo internally: > https://github.com/regclient/regclient/blob/410091ab2d89e76ffa039f36e569547… $ regctl version VCSTag: 0.6.1 VCSRef: unknown VCSCommit: unknown VCSState: unknown VCSDate: unknown Platform: linux/amd64 GoVer: go1.22.5 GoCompiler: gc $ No matter what I do, I cannot get it to properly show the version. I changed the _service file to include the .git directory (in both obs_scm and the buildtime tar repackaging) and made sure git-core was installed. But it errors out with the generic "error obtaining VCS status: exit status 128" error that means that something went wrong with git. My guess is that git cannot reach the remote, due to being offline in OBS. Removing the remote before building (git remote remove origin) does not solve this issue. So, besides patching the file to have the actual desired information init, is there a way to get "go build" to spit out a binary containing the debuginfo? I tried various combinations of options and ldflags for the go build command, but to no avail. Any ideas, anyone? Kind Regards, Johannes

2 3

watchdog
by Jonas Kvinge 12 Jul '24

12 Jul '24

Hi, I don't think the maintainer for watchdog is active anymore, can someone respond to these? https://build.opensuse.org/request/show/1178939 https://build.opensuse.org/request/show/1179894 Jonas

2 1