Re: [HEADS UP] gpgme rebase to 1.17.1 and libqgpgme SONAME bump

[Jiri Kucera <jkucera@xxxxxxxxxx>]

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 <jkucera@xxxxxxxxxx> 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 <jkucera@xxxxxxxxxx> 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 <mhroncok@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue