[opensuse-factory] need rebuilds for Leap:15.1:PowerPC at least for yast unresolvables
Hello Michal, Since 20181119, there are more than 500 unresolvables in Leap:15.1:PowerPC (1) osc jobhist (2) show that at least yast2 packages need rebuilds I thought there was automatic rebuild of unresolvable in OBS, is it disabled for this project ? (1) https://build.opensuse.org/project/show/openSUSE:Leap:15.1:PowerPC (2) === nothing provides libyui.so.8()(64bit) needed by yast2-ycp-ui-bindings, nothing provides libzypp.so.1702()(64bit) needed by yast2-pkg-bindings, nothing provides libzypp.so.1702(ZYPP_plain)(64bit) needed by yast2-pkg-bindings === $for xx in libyui libzypp yast2-pkg-bindings; do osc jobhist -l2 openSUSE:Leap:15.1:PowerPC/$xx ports ppc64le; done time package reason code build time worker 2018-07-18 19:39:14 libyui new build succeeded 2m 32s obs-power8-05:33 2018-11-12 12:26:02 libyui source change succeeded 2m 48s obs-power8-03:7 time package reason code build time worker 2018-11-02 09:39:06 libzypp source change succeeded 18m 56s obs-power8-03:13 2018-11-21 11:47:40 libzypp source change succeeded 24m 45s obs-power8-05:3 time package reason code build time worker 2018-08-07 08:54:59 yast2-pkg-bindings source change succeeded 5m 47s obs-power8-05:14 2018-11-07 09:43:01 yast2-pkg-bindings source change succeeded 4m 46s obs-power8-07:20 === -- Michel Normand -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi! On 11/29/18 10:21 AM, Normand wrote:
Since 20181119, there are more than 500 unresolvables in Leap:15.1:PowerPC (1) osc jobhist (2) show that at least yast2 packages need rebuilds
I'm maintaining multiple unofficial ports in Debian, among these is also Debian for 32-bit PowerPC. I would be interested in co-maintaining SUSE for 32-bit PowerPC as well. One of the things that I wanted to change is to enable Rust for PowerPC as of recently we got it working in Debian again after helping upstream finding and fixing some issues in LLVM and Rust itself. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29/11/2018 12:16, John Paul Adrian Glaubitz wrote:
Hi!
On 11/29/18 10:21 AM, Normand wrote:
Since 20181119, there are more than 500 unresolvables in Leap:15.1:PowerPC (1) osc jobhist (2) show that at least yast2 packages need rebuilds
I'm maintaining multiple unofficial ports in Debian, among these is also Debian for 32-bit PowerPC. I would be interested in co-maintaining SUSE for 32-bit PowerPC as well.
One of the things that I wanted to change is to enable Rust for PowerPC as of recently we got it working in Debian again after helping upstream finding and fixing some issues in LLVM and Rust itself.
Adrian
Hello John Paul, If you want to help on Rust for PowerPC, then better to address that to the devel:languages:rust (1) that is related development project. I changed Subject title as your discussion is not about specific thread I am addressing before (about generic build problem in Leap:15.1:PowerPC project that is anyway ppc64le only. openSUSE Tumbleweed do not support anymore ppc 32-bit since a while. we still have ppc64 (BE) 64-bits and ppc64le 64-bits (2) (1) https://build.opensuse.org/project/show/devel:languages:rust (2) https://build.opensuse.org/project/show/openSUSE:Factory:PowerPC -- Michel Normand -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi! On 11/29/18 1:46 PM, Normand wrote:
If you want to help on Rust for PowerPC, then better to address that to the devel:languages:rust (1) that is related development project.
Yeah, sure, I know it's done to be in the devel project for Rust :).
I changed Subject title as your discussion is not about specific thread I am addressing before (about generic build problem in Leap:15.1:PowerPC project that is anyway ppc64le only.
My plan is to eventually set up my own OBS instance for building ppc64, ppc64 and ppc in the future. But I'm not there yet, so I'm maintaining those architectures in Debian Ports.
openSUSE Tumbleweed do not support anymore ppc 32-bit since a while. we still have ppc64 (BE) 64-bits and ppc64le 64-bits (2)
Well, Factory is building packages for ppc, ppc64 and ppc64le so it's not so relevant at the moment that there are no Tumbleweed releases for 32-bit PowerPC:
https://build.opensuse.org/project/show/openSUSE:Factory:PowerPC
It's similar for Debian where 32-bit PowerPC was dropped from the release architectures but I made sure it was moved to Debian Ports as there are still people using Debian on their PPC Macs and similar hardware. FWIW, Rust does work reasonably well on ppc, ppcspe and sparc64 and very well on ppc64. We fixed a lot of Rust issues in Debian to get to that state. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Nov 29 2018, John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
Well, Factory is building packages for ppc, ppc64 and ppc64le so it's not so relevant at the moment that there are no Tumbleweed releases for 32-bit PowerPC:
https://build.opensuse.org/project/show/openSUSE:Factory:PowerPC
If you want to work on ppc for Factory, the biggest obstacle right now is mariadb. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/29/18 2:15 PM, Andreas Schwab wrote:
On Nov 29 2018, John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
Well, Factory is building packages for ppc, ppc64 and ppc64le so it's not so relevant at the moment that there are no Tumbleweed releases for 32-bit PowerPC:
https://build.opensuse.org/project/show/openSUSE:Factory:PowerPC
If you want to work on ppc for Factory, the biggest obstacle right now is mariadb.
Ah, I already guessed that. I saw the build was missing which makes quite a number of reverse dependencies unresolvable. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Andreas! On 11/29/18 2:16 PM, John Paul Adrian Glaubitz wrote:
If you want to work on ppc for Factory, the biggest obstacle right now is mariadb.
Ah, I already guessed that. I saw the build was missing which makes quite a number of reverse dependencies unresolvable.
Ok, this is the same issue as on Debian [1, 2]: ../include/my_atomic.h:121:2: error: #error atomic ops for this platform are not implemented #error atomic ops for this platform are not implemented ^~~~~ I will have a look. I wonder why they're not the atomic stuff from C++11. Adrian
[1] https://build.opensuse.org/package/live_build_log/openSUSE:Factory:PowerPC/m... [2] https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3&arch=powerpc&ver=10.3.0-0%2Bexp2&stamp=1536336776&raw=0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/29/18 7:38 PM, John Paul Adrian Glaubitz wrote:
On 11/29/18 2:16 PM, John Paul Adrian Glaubitz wrote:
If you want to work on ppc for Factory, the biggest obstacle right now is mariadb.
Ah, I already guessed that. I saw the build was missing which makes quite a number of reverse dependencies unresolvable.
Ok, this is the same issue as on Debian [1, 2]:
../include/my_atomic.h:121:2: error: #error atomic ops for this platform are not implemented #error atomic ops for this platform are not implemented ^~~~~
I will have a look. I wonder why they're not the atomic stuff from C++11.
Oh, they actually do that! Their test is just flawed in cmake: CHECK_CXX_SOURCE_COMPILES(" int main() { long long int var= 1; long long int *ptr= &var; return (int)__atomic_load_n(ptr, __ATOMIC_SEQ_CST); }" HAVE_GCC_C11_ATOMICS) On ppc64, this works: glaubitz@redpanda:~/mariadb$ g++ cpp11test.cpp -o cpp11test glaubitz@redpanda:~/mariadb$ ./cpp11test On powerpc, we need -latomic: root@kapitsa:~# g++ cpp11test.cpp -o cpp11test -Wl,--as-needed /usr/bin/ld: /tmp/ccyivhlO.o: in function `main': cpp11test.cpp:(.text+0x48): undefined reference to `__atomic_load_8' collect2: error: ld returned 1 exit status root@kapitsa:~# root@kapitsa:~# g++ cpp11test.cpp -o cpp11test -latomic root@kapitsa:~# Now, I don't know from the top of my head how to fix the cmake file. Any suggestions? Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 29 Nov 2018, 19:50:40 +0100, John Paul Adrian Glaubitz wrote:
On 11/29/18 7:38 PM, John Paul Adrian Glaubitz wrote:
On 11/29/18 2:16 PM, John Paul Adrian Glaubitz wrote:
If you want to work on ppc for Factory, the biggest obstacle right now is mariadb.
Ah, I already guessed that. I saw the build was missing which makes quite a number of reverse dependencies unresolvable.
Ok, this is the same issue as on Debian [1, 2]:
../include/my_atomic.h:121:2: error: #error atomic ops for this platform are not implemented #error atomic ops for this platform are not implemented ^~~~~
I will have a look. I wonder why they're not the atomic stuff from C++11.
Oh, they actually do that! Their test is just flawed in cmake:
CHECK_CXX_SOURCE_COMPILES(" int main() { long long int var= 1; long long int *ptr= &var; return (int)__atomic_load_n(ptr, __ATOMIC_SEQ_CST); }" HAVE_GCC_C11_ATOMICS)
On ppc64, this works:
glaubitz@redpanda:~/mariadb$ g++ cpp11test.cpp -o cpp11test glaubitz@redpanda:~/mariadb$ ./cpp11test
On powerpc, we need -latomic:
root@kapitsa:~# g++ cpp11test.cpp -o cpp11test -Wl,--as-needed /usr/bin/ld: /tmp/ccyivhlO.o: in function `main': cpp11test.cpp:(.text+0x48): undefined reference to `__atomic_load_8' collect2: error: ld returned 1 exit status root@kapitsa:~#
root@kapitsa:~# g++ cpp11test.cpp -o cpp11test -latomic root@kapitsa:~#
Now, I don't know from the top of my head how to fix the cmake file.
Any suggestions?
Does CHECK_CXX_SOURCE_COMPILES use anything like LDFLAGS which could be predefined in a host specific way?
Adrian
Cheers. l8er manfred
On Donnerstag, 29. November 2018 19:56:27 CET Manfred Hollstein wrote:
On Thu, 29 Nov 2018, 19:50:40 +0100, John Paul Adrian Glaubitz wrote:
Now, I don't know from the top of my head how to fix the cmake file.
Any suggestions?
Does CHECK_CXX_SOURCE_COMPILES use anything like LDFLAGS which could be predefined in a host specific way?
https://cmake.org/cmake/help/latest/module/CheckCXXSourceCompiles.html CMAKE_REQUIRED_LIBRARIES A ;-list of libraries to add to the link command. These can be the name of system libraries or they can be Imported Targets (see try_compile() for further details). Kind regards, Stefan-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/29/18 7:50 PM, John Paul Adrian Glaubitz wrote:
Now, I don't know from the top of my head how to fix the cmake file.
Found something from Debian [1]: # Check whether atomic operations require -latomic or not # See https://github.com/facebook/hhvm/issues/5217 INCLUDE(CheckCXXSourceCompiles) set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS}) set(CMAKE_REQUIRED_FLAGS "-std=c++1y") CHECK_CXX_SOURCE_COMPILES(" #include <atomic> int main() { struct Test { int val; }; std::atomic<Test> s; s.is_lock_free(); } " NOT_REQUIRE_ATOMIC_LINKER_FLAG) if(NOT "${NOT_REQUIRE_ATOMIC_LINKER_FLAG}") message(STATUS "-latomic is required to link hhvm") target_link_libraries(hhvm atomic) endif() set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS}) Adrian
[1] https://sources.debian.org/src/hhvm/3.24.7+dfsg-2/hphp/hhvm/CMakeLists.txt/?... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Andreas! On 11/29/18 2:15 PM, Andreas Schwab wrote:
If you want to work on ppc for Factory, the biggest obstacle right now is mariadb.
The attached proof-of-concept patch fixes mariadb for me on Debian unstable on powerpc. I was not able to make it build on openSUSE yet. The underlying issue is that gcc doesn't link against libatomic automatically but I think you already knew about this since you're on the corresponding gcc bug report [1]. Adrian
Hi! On 11/30/18 1:08 PM, John Paul Adrian Glaubitz wrote:
The attached proof-of-concept patch fixes mariadb for me on Debian unstable on powerpc. I was not able to make it build on openSUSE yet.
An improved patch which works against MariaDB 10.3 but not 10.2.x which requires more work as 10.2 doesn't fully use C++11 atomics yet. Adrian
Hello! On 11/30/18 2:29 PM, John Paul Adrian Glaubitz wrote:
On 11/30/18 1:08 PM, John Paul Adrian Glaubitz wrote:
The attached proof-of-concept patch fixes mariadb for me on Debian unstable on powerpc. I was not able to make it build on openSUSE yet.
An improved patch which works against MariaDB 10.3 but not 10.2.x which requires more work as 10.2 doesn't fully use C++11 atomics yet.
I have a patch now which fixes the build on ppc but the testsuite failes two tests [1]. Patch attached but also available in my home project. Test failure looks a bit suspicious: [ 2951s] --- /home/abuild/rpmbuild/BUILD/mariadb-10.2.19/mysql-test/suite/encryption/r/innodb-bad-key-change2.result 2018-11-12 16:32:39.000000000 +0000 [ 2951s] +++ /home/abuild/rpmbuild/BUILD/mariadb-10.2.19/mysql-test/suite/encryption/r/innodb-bad-key-change2.reject 2018-11-30 19:47:44.670000000 +0000 [ 2951s] @@ -10,7 +10,7 @@ [ 2951s] ERROR HY000: Got error 192 'Table encrypted but decryption failed. This could be because correct encryption management plugin is not loaded, used encryption key is not available or encryption method does not match.' from InnoDB [ 2951s] SHOW WARNINGS; [ 2951s] Level Code Message [ 2951s] -Warning 192 Table test/t1 in tablespace is encrypted but encryption service or used key_id is not available. Can't continue reading table. [ 2951s] +Warning 192 Table ??? in tablespace is encrypted but encryption service or used key_id is not available. Can't continue reading table. [ 2951s] Warning 192 Table t1 in file ./test/t1.ibd is encrypted but encryption service or used key_id is not available. Can't continue reading table. [ 2951s] Error 1296 Got error 192 'Table encrypted but decryption failed. This could be because correct encryption management plugin is not loaded, used encryption key is not available or encryption method does not match.' from InnoDB [ 2951s] ALTER TABLE t1 ENGINE=InnoDB; [ 2951s] @@ -38,7 +38,7 @@ [ 2951s] UNLOCK TABLES; [ 2951s] ALTER TABLE t1 DISCARD TABLESPACE; [ 2951s] Warnings: [ 2951s] -Warning 192 Table test/t1 in tablespace is encrypted but encryption service or used key_id is not available. Can't continue reading table. [ 2951s] +Warning 192 Table N?? in tablespace is encrypted but encryption service or used key_id is not available. Can't continue reading table. [ 2951s] Warning 1812 Tablespace is missing for table 'test/t1' [ 2951s] restore: t1 .ibd and .cfg files [ 2951s] ALTER TABLE t1 IMPORT TABLESPACE; [ 2951s] [ 2951s] mysqltest: Result length mismatch [ 2951s] [ 2951s] - saving '/home/abuild/rpmbuild/BUILD/mariadb-10.2.19/build/mysql-test/var/8/log/encryption.innodb-bad-key-change2-innodb/' to '/home/abuild/rpmbuild/BUILD/mariadb-10.2.19/build/mysql-test/var/log/encryption.innodb-bad-key-change2-innodb/' [ 2951s] ***Warnings generated in error logs during shutdown after running tests: encryption.innodb-bad-key-change2 [ 2951s] Adrian
[1] https://build.opensuse.org/project/show/home:glaubitz:branches:server:databa...
Hi! On 11/30/18 9:50 PM, John Paul Adrian Glaubitz wrote:
I have a patch now which fixes the build on ppc but the testsuite failes two tests [1]. Patch attached but also available in my home project.
Ok, package is fixed for ppc and submitted now:
Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2018-11-29 14:00, John Paul Adrian Glaubitz wrote:
On 11/29/18 1:46 PM, Normand wrote:
If you want to help on Rust for PowerPC, then better to address that to the devel:languages:rust (1) that is related development project.
Yeah, sure, I know it's done to be in the devel project for Rust :).
I changed Subject title as your discussion is not about specific thread I am addressing before (about generic build problem in Leap:15.1:PowerPC project that is anyway ppc64le only.
My plan is to eventually set up my own OBS instance for building ppc64, ppc64 and ppc in the future. But I'm not there yet, so I'm maintaining those architectures in Debian Ports.
openSUSE Tumbleweed do not support anymore ppc 32-bit since a while. we still have ppc64 (BE) 64-bits and ppc64le 64-bits (2)
Well, Factory is building packages for ppc, ppc64 and ppc64le so it's not so relevant at the moment that there are no Tumbleweed releases for 32-bit PowerPC:
Isn't the ppc target more or less just an ILP32 variant of a ppc64 anyway, similar to what x32 is to x86_64? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Nov 29 2018, Jan Engelhardt <jengelh@inai.de> wrote:
Isn't the ppc target more or less just an ILP32 variant of a ppc64 anyway, similar to what x32 is to x86_64?
Not quite. The ppc target uses only the 32-bit subset of the powerpc ISA. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/29/18 3:22 PM, Jan Engelhardt wrote:
Well, Factory is building packages for ppc, ppc64 and ppc64le so it's not so relevant at the moment that there are no Tumbleweed releases for 32-bit PowerPC:
Isn't the ppc target more or less just an ILP32 variant of a ppc64 anyway, similar to what x32 is to x86_64?
It's a different instruction set. x32 is basically x86_64 with 32-bit pointers with the full x86_64 instruction set available. 32-bit PowerPC is the PowerPC 74xx series (based on the POWER3 ISA IIRC) while 64-bit PowerPC is the 970 series (based on the POWER4 ISA). For 32-bit SPARC, people usually use SPARCv9 (the first 64-bit UltraSPARC) with 32-bit pointers. So it's very much comparable with x32 and x86_64. One of the main reasons for using it over SPARCv8 here that SPARCv9 introduces a couple of atomics instructions which were not present on earlier ISA versions. Regular 32-bit x86, on the other hand, has fewer registers and instructions than x86_64, so the jump from 32 to 64 bits is huge. It's smaller for PowerPC and the smallest for 32-bit SPARC and x32. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2018-11-29 15:36, John Paul Adrian Glaubitz wrote:
On 11/29/18 3:22 PM, Jan Engelhardt wrote:
Well, Factory is building packages for ppc, ppc64 and ppc64le so it's not so relevant at the moment that there are no Tumbleweed releases for 32-bit PowerPC:
Isn't the ppc target more or less just an ILP32 variant of a ppc64 anyway, similar to what x32 is to x86_64?
It's a different instruction set. x32 is basically x86_64 with 32-bit pointers with the full x86_64 instruction set available. 32-bit PowerPC is the PowerPC 74xx series (based on the POWER3 ISA IIRC) while 64-bit PowerPC is the 970 series (based on the POWER4 ISA).
For 32-bit SPARC, people usually use SPARCv9 (the first 64-bit UltraSPARC) with 32-bit pointers. So it's very much comparable with x32 and x86_64.
That last part has always been a bit strange, because sparc64-linux-gcc -m32 does not actually make use of the basic 64-bit instructions like ldx/stx, noticable for example when playing with uint64_t-based time. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Normand schrieb:
Since 20181119, there are more than 500 unresolvables in Leap:15.1:PowerPC (1) osc jobhist (2) show that at least yast2 packages need rebuilds
I thought there was automatic rebuild of unresolvable in OBS, is it disabled for this project ?
The project is set to rebuild="local"¹. So rebuilds are only triggered on source changes or manually. There's also a script that can be used in rebuild=local mode to trigger rebuilds of unresolvables². It's not enabled for 15.1 PPC as it is only halfway safe with rebuild=local which it doesn't actually check for. Nevertheless rebuild=local is not a clean way to build the distro. So unless you are very short on build power or have other constraints that outweigh the disadvantages of rebuild=local I would recommend to use at least rebuild=direct. [1] https://build.opensuse.org/project/meta/openSUSE:Leap:15.1:PowerPC [2] https://github.com/openSUSE/openSUSE-release-tools/blob/master/rebuildpacs.p... Volunteers to rewrite that script in a less hackish way welcome :-) -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/12/2018 09:45, Ludwig Nussel wrote:
Normand schrieb:
Since 20181119, there are more than 500 unresolvables in Leap:15.1:PowerPC (1) osc jobhist (2) show that at least yast2 packages need rebuilds
I thought there was automatic rebuild of unresolvable in OBS, is it disabled for this project ?
The project is set to rebuild="local"¹. So rebuilds are only triggered on source changes or manually. There's also a script that can be used in rebuild=local mode to trigger rebuilds of unresolvables². It's not enabled for 15.1 PPC as it is only halfway safe with rebuild=local which it doesn't actually check for.
Nevertheless rebuild=local is not a clean way to build the distro. So unless you are very short on build power or have other constraints that outweigh the disadvantages of rebuild=local I would recommend to use at least rebuild=direct.
Michal, as per Ludwig suggestion, could you change meta to rebuild=direct, if you do not other see other drawback ? --- Michel Normand
[1] https://build.opensuse.org/project/meta/openSUSE:Leap:15.1:PowerPC [2] https://github.com/openSUSE/openSUSE-release-tools/blob/master/rebuildpacs.p...
Volunteers to rewrite that script in a less hackish way welcome :-)
-- Michel Normand -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 10 Dec 2018 18:11:35 +0100 Normand <normand@linux.vnet.ibm.com> wrote:
On 03/12/2018 09:45, Ludwig Nussel wrote:
Normand schrieb:
Since 20181119, there are more than 500 unresolvables in Leap:15.1:PowerPC (1) osc jobhist (2) show that at least yast2 packages need rebuilds
I thought there was automatic rebuild of unresolvable in OBS, is it disabled for this project ?
The project is set to rebuild="local"¹. So rebuilds are only triggered on source changes or manually. There's also a script that can be used in rebuild=local mode to trigger rebuilds of unresolvables². It's not enabled for 15.1 PPC as it is only halfway safe with rebuild=local which it doesn't actually check for.
Nevertheless rebuild=local is not a clean way to build the distro. So unless you are very short on build power or have other constraints that outweigh the disadvantages of rebuild=local I would recommend to use at least rebuild=direct.
Michal, as per Ludwig suggestion, could you change meta to rebuild=direct, if you do not other see other drawback ?
--- Michel Normand
Updated. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Andreas Schwab -
Brüns, Stefan -
Jan Engelhardt -
John Paul Adrian Glaubitz -
Ludwig Nussel -
Manfred Hollstein -
Michal Suchánek -
Normand