Involved Projects and Packages
These are all the comments this user made
Stop your constant personal attacks. Please.
The one who broke stuff is you.
It's not my fault that you don't understand the internals despite multiple hints given to you in the relevant mailinglist threads. Fix it or I will revert.
BTW, just to make it clear to you that you are wrong:
The relevant definition comes from here: which is SL15-SP*4* and propagates into Leap 15.4:
https://build.opensuse.org/projects/SUSE:SLE-15-SP4:Update/prjconf
#request by slemke/dmueller 2023-05-04 for python311 builds Macros: # Macro to build Python Stack Proposal packages %sle15_python_module_pythons() %global pythons python311 # 2023-06-07 meissner # Macro to build Python Stack Proposal packages %sle15allpythons() %global pythons python311 python3 :Macros
No, I am not wrong.
...
Maybe I am wrong.
(...)
Look at the evidence, not of what you think you understood from some ambiguous announcements or outdated mailinglist comments. Furthermore, your own projects have special overrides which are not applicable to the plain repositories.
python-qt5 is unresolvable for 15.4 and 15.5 in KDE:Qt:PyQt. It was the same in KDE:Qt5 until @krop undefined the macros.
Read the comment I linked. You only "activated" the python311 module for a subset of packages but it is not enough for python-qt5. It is unresolvable in the plain repos outside of your private home realm. Fix it or I will remove the macros from the packages in the plain devel repo, because right now it is unusable.
Stop your constant personal attacks. Please.
The one who broke stuff is you.
It's not my fault that you don't understand the internals despite multiple hints given to you in the relevant mailinglist threads. Fix it or I will revert.
BTW, just to make it clear to you that you are wrong:
The relevant definition comes from here: which is SL15-SP*4* and propagates into Leap 15.4:
https://build.opensuse.org/projects/SUSE:SLE-15-SP4:Update/prjconf
#request by slemke/dmueller 2023-05-04 for python311 builds Macros: # Macro to build Python Stack Proposal packages %sle15_python_module_pythons() %global pythons python311 # 2023-06-07 meissner # Macro to build Python Stack Proposal packages %sle15allpythons() %global pythons python311 python3 :Macros
No, I am not wrong.
...
Maybe I am wrong.
(...)
Look at the evidence, not of what you think you understood from some ambiguous announcements or outdated mailinglist comments. Furthermore, your own projects have special overrides which are not applicable to the plain repositories.
python-qt5 is unresolvable for 15.4 and 15.5 in KDE:Qt:PyQt. It was the same in KDE:Qt5 until @krop undefined the macros.
Upstream is already informed: https://github.com/Azure/azure-cli/issues/26375
"BuildRequires: mercurial" looks strange for a project using git(hub)
What use case is there for the single-use "%pythons" macro?
"BuildRequires: python3" (after expanding %pythons) should be "BuildRequires: python3-base".
LICENSE.ASSETS.md likely belongs into the data subpackage.
Still several unused (i.e. MacOS/Windows) icons packaged (already noted in an earlier review). Only PNG and likely SVG should be kept.
You should use the "%python3_compile" macro from the python-rpm-macros package, you invocation leaves the buildroot path in the cache files.
The only practical solution I see here is to link the newer libtorrent-rasterbar from devel:libraries:c_c++ or Factory and have it build for 15.4. But I'm not a project maintainer, so you'll have to ask them. Merely disabling the version check might be very insidious.
Let me restate that:
Please provide a link to the passage in the documentation which gives sufficient information to understand why builds on Riscv require more disk space than any other documentation.
Let me restate that:
Please provide a link to the documentation.
Let me restate that:
Please provide a link to the passage in the documentation which gives sufficient information to understand why builds on Riscv require more disk space than any other documentation.
Which optimizations? Why are these only done on riscv? Is this documented somewhere?
Let me restate that:
Please provide a link to the documentation.
Let me restate that:
Please provide a link to the passage in the documentation which gives sufficient information to understand why builds on Riscv require more disk space than any other documentation.
Which optimizations? Why are these only done on riscv? Is this documented somewhere?
Let me restate that:
Please provide a link to the documentation.
Let me restate that:
Please provide a link to the passage in the documentation which gives sufficient information to understand why builds on Riscv require more disk space than any other documentation.
[ 70s] /home/abuild/rpmbuild/BUILD/blender-3.4.1/intern/locale/boost_locale_wrapper.cpp: In function 'void bl_locale_set(const char*)':
[ 70s] /home/abuild/rpmbuild/BUILD/blender-3.4.1/intern/locale/boost_locale_wrapper.cpp:112:10: error: 'cout' is not a member of 'std'
[ 70s] 112 | std::cout << "bl_locale_set(" << locale << "): " << e.what() << " \n";
As the title says "Test this driver for boot problem" I originally created this kmp because the kernel didn't have a driver and I wanted a driver that was updated for each new kernel for zypper dup. The kernel incorporated rtw88_8723d driver and I deleted the package. Since the 6.1.x kernel https://bugzilla.opensuse.org/show_bug.cgi?id=1206767 has occurred and I recreated the package to facilitate overcoming the bug. If you also have the same wifi hardware as my laptop please join the bug and help. If your system boots correctly with network manager you can definitely supply information that will help solve the problem.
The build error has two reasons. One is that the build guidelines between Leap and Tumbleweed are different. Why this is so, I do not understand. And secondly, the constant changes in the build rules in Tumbleweed. You can hardly keep up with them. And mostly, in my opinion, it's completely unimportant things that suddenly make it impossible to build a package. Apparently it is probably too boring for some.
Now it was build.
I'm afraid janus-gateway sneak in into the Leap while we refactoring the review process, do you want to have janus-gateway in Leap? if not we can remove it from Leap.
Yeah, that needs to be raised to libguile-ssh14, but can't build ATM see https://build.opensuse.org/request/show/1037417
I'm not sure if @lyan is still working on this package, but I suppose he's not. However, @ccrane said he'd be ok with taking care of it. So, Caleb, you can check yourself as the bugowner here: https://build.opensuse.org/package/users/Virtualization/firecracker (and also accept this request, if you're fine with that :-D)
Reported upstream: https://github.com/Azure/azure-cli/issues/23222
Haven't verified yet whether argcomplete 2.0.0 has introduced any incompatible changes.
I believe this has been fixed by deadbeef being re-added to Factory
This comment has been deleted