This will be not that easy as it looks like:
```
[ 63%] Generating
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/src/phonenumbers/test_metadata.cc,
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/src/phonenumbers/test_metadata.h
JAVA_BIN-NOTFOUND -jar
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/../tools/java/cpp-build/target/cpp-build-1.0-SNAPSHOT-jar-with-dependencies.jar
BuildMetadataCppFromXml
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/../resources/PhoneNumberMetadataForTesting.xml
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/src/phonenumbers
test_metadata
gmake[2]: JAVA_BIN-NOTFOUND: No such file or directory
gmake[2]: *** [CMakeFiles/phonenumber_testing.dir/build.make:330:
/builddir/build/BUILD/libphonenumber-8.12.57/cpp/src/phonenumbers/test_metadata.cc]
Error 127
gmake[2]: *** Waiting for unfinished jobs....
```
I will look more closely at how and why Java is used to generate C++
sources and how it can be replaced by something else in the build process.
Jiri
On Fri, Dec 2, 2022 at 9:37 PM Jiri Kucera <jkuc...@redhat.com> wrote:
> Hmm, concerning `libphonenumber` there is no Java binding, only the C++
> port of the original Java library. Moreover, nothing Java-related is
> distributed in the RPMs. That means that `BuildRequires: java-devel` is
> redundant here. I will try to do a scratch build.
>
> Regards,
> Jiri
>
> On Fri, Dec 2, 2022 at 9:25 PM Jiri Kucera <jkuc...@redhat.com> wrote:
>
>> Yes, builds in [1] were built with the `f38-build-side-60497` side tag.
>> In [1] there are two errors that were not here in time I hit the submit
>> button (maybe I should wait a bit longer):
>> * `nothing provides libqgpgme.so.7 needed by
>> kdepim-addons-22.08.3-1.fc38.i686` - this one was
>> caused by not building `kdepim-addons` on `i686` since missing
>> `libphonenumber` on `i686`.
>> `libphonenumber` is not built for `i686` anymore due to `ExclusiveArch:
>> %{java_arches}`. This
>> can be fixed by skipping building the Java binding for `i686` only.
>> * ```
>> Undeclared file conflicts:
>> kleopatra-*.i686 provides ... which is also provided by
>> kleopatra-*.x86_64
>> ...
>> kmail-*.i686 provides ... which is also provided by kmail-*.x86_64
>> ...
>> ```
>> These must have appeared also in the update before, but I cannot find
>> `rpmdeplint` tests
>> here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e8d23a026e
>>
>> I submitted [2] approx. 22h after [1] became stable. Have no idea why the
>> builds from pre-[1] rawhide were picked up. However, `rpmdeplint`
>> repoclosure failures are happening only on `i686` so maybe this is somehow
>> connected with `kdepim-addons` not built for `i686`.
>>
>> Regards and sorry for the chaos,
>> Jiri
>>
>> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b
>> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3
>>
>> On Fri, Dec 2, 2022 at 11:54 AM Miro Hrončok <mhron...@redhat.com> wrote:
>>
>>> On 02. 12. 22 1:46, Adam Williamson wrote:
>>> > On Wed, 2022-11-30 at 13:59 +0100, Jiri Kucera wrote:
>>> >> Thanks for the reminder Petr. I will do the rebase in rawhide only
>>> then.
>>> >
>>> > Thanks for taking care of these dependencies and announcing the bump.
>>> >
>>> > For extra bonus points :D, if it's not too much trouble, it would be
>>> > great if you could do this on a side tag in future - yes, even for
>>> > Rawhide. Without a side tag and combined update, the openQA tests for
>>> > the gpgme update fail:
>>> >
>>> https://openqa.stg.fedoraproject.org/tests/overview?version=38&groupid=2&build=Update-FEDORA-2022-603eea89a3&distri=fedora
>>> > if the gpgme bump and all dependent rebuilds were in the same update,
>>> > the tests would pass (assuming nothing's actually broken).
>>> >
>>> > Right now we're not gating Rawhide updates on test failures, but I do
>>> > check them all, so I had to make sure all the rebuilds had actually
>>> > been done, then add comments noting the tests need to be re-run after
>>> > the next Rawhide compose, then remember to re-run them so all that ugly
>>> > red ink goes away :D If/when we do start gating Rawhide on openQA
>>> > failures, this update would be blocked by gating.
>>>
>>> Interesting. I saw
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2022-4c1b011b1b where
>>> side tag
>>> was used.
>>>
>>> Later, there was
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2022-603eea89a3
>>> which only changed a small portion from the package.
>>>
>>> Why would the tests fails for the second update?
>>>
>>> --
>>> Miro Hrončok
>>> --
>>> Phone: +420777974800
>>> IRC: mhroncok
>>> _______________________________________________
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct:
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>> Do not reply to spam, report it:
>>> https://pagure.io/fedora-infrastructure/new_issue
>>>
>>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
