Involved Projects and Packages
These are all the comments this user made
Any reason this has been open for 1 month without any feedback?
Could you please update the _service file ? - disabled should now be manual - Change revision to 2.7.2 - Run osc service mr should then update the tarball while keeping the same naming scheme as before so some of your .spec file changes shouldn't be needed anymore
Thanks! Made the change but it still appears as unresolvable, if I trigger a rebuild nothing seems to happen, perhaps I need to bump the Release or should I just wait?
@M0ses, @adrianSuSE, @dirkmueller, @lrupp, @mstrigl: review reminder
The build is failing, though... Or am I missing anything?
Build is failing because of GCC requirements with the newer passt version: it uses C23 syntax, which requires GCC15. I have tested a patch on SLES15 SP7:
diff --git a/passt.spec b/passt.spec
index ... .. ...
--- a/passt.spec
+++ b/passt.spec
@@ -80,7 +80,13 @@ URL: https://passt.top/
Source: %{name}-%{version}.tar.zst
BuildRequires: zstd
-BuildRequires: gcc, make
+BuildRequires: make
+%if 0%{?suse_version} == 1500
+BuildRequires: gcc15
+%else
+BuildRequires: gcc
+%endif
@@ -128,6 +134,10 @@ Requires: container-selinux
%prep
%autosetup
%build
+%if 0%{?suse_version} == 1500
+export CC=gcc-15
+export CXX=g++-15
+%endif
%set_build_flags
Alright then, tell me which commit code that should be merged. Also, create some pull request at https://codeberg.org/jimed-rand/waydroid-opensuse-sources for backup purpose.
@pluskalm @dirkmueller @simotek Hi, did this get overlooked? I’m no sommelier but I don’t think this SR needs to ferment before it’s good to merge 😉
But please do let me know if there are any objections or blockers to this change.
@dimstar_suse Mind taking a quick look at this? Just adds a runtime QML dependency without which monero-gui prints a cryptic error to stderr and refuses to start.
I don’t use this software much but feel free to add me as maintainer as well 🙂
btw, we cannot create symlinks for the 2MB OVMF because it will break users' VMs after they update.
So, dropping the files breaks the machines because they can no longer find the UEFI firmware, and symlinks break it because they are incompatible.
No. Existing users can continue to use their 2M OVMF without it being removed, while 4M OVMF will receive updates. For new users, only the creation of 4M OVMF instances will be permitted.
could you please try to stage it together with https://build.opensuse.org/requests/1315967?
Am I supposed to approve my own request?
Since nobody seems to care that this package no longer builds, despite a trivial fix being available for months, should I file a delete request instead?
OK, this makes sense, but let's redirect this request through a git PR, https://github.com/libyui/libyui
I created a pull request by: eosc rdiff devel:libraries:libyui libyui home:alarrosa:branches:devel:libraries:libyui >/data/work/tmp/libyui_sle16.diff git/libyui/package> patch -p0 -i /data/work/tmp/libyui_sle16.diff
https://github.com/libyui/libyui/pull/119
Background: I also need a change in this area (libyui-qt-graph.spec). Hope this is fine. I would still submit a build service SR first for discussion for my problem, as it's similar as this one build service related.
in case someone is interested or could give it a quick review, my SR:
https://build.opensuse.org/requests/1284225
Thanks!
Seems to be fixed with latest update , thanks.
Another problem is that the wine-32bit-win-debuginfo-10.8-2.1.i586.rpm package is not available as ::import::i586::wine-32bit-win-debuginfo-10.8-2.1.x86_64.rpm, which prevents debugging symbols for Windows DLLs from being available on x86_64 systems.
At https://build.opensuse.org/projects/home:rhabacker:branches:Emulators/prjconf I fixed that by adding
ExportFilter: ^wine-.-debug..i586.rpm$ . x86_64
to the project config
i added it to baselibs.conf, so:
wine-32bit-win-debuginfo
is there now I think.
Hi Dmitriy, When you look at it, could you please also switch to use PCRE2 instead PCRE?
Dear Ana, as far as I see pcre isn't required directly any more and pcre2-devel-10.44-1.3 is pulled as a secondary build requirement.
Hi Dmitriy, When you look at it, could you please also switch to use PCRE2 instead PCRE?
Dear Ana, as far as I see pcre isn't required directly any more and pcre2-devel-10.44-1.3 is pulled as a secondary build requirement.
This comment has been deleted