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

2022-12-05 Thread Miro Hrončok 

On Fri, Dec 2, 2022 Adam Williamson  wrote:

I may think about having openQA Rawhide update tests enable the
buildroot repo that includes packages from the release tag; this would
make it include packages that have gone 'stable' since the previous
Rawhide compose. I'd have to think if there are any potential drawbacks
to doing that. Ironically, Fedora CI currently does that but is
considering *not* doing it any more due to "unpleasant surprises":
https://pagure.io/fedora-ci/general/issue/376 
 . I'm not sure exactly

what the surprises were, I'll have to look into it.


(Replying to a reply because for some reason I have not received the actual 
email from Adam.)


This is exactly the reason I think the buildroot repo should always be enabled 
for tests and why I am concerned by https://pagure.io/fedora-ci/general/issue/376


--
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

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

2022-12-04 Thread Jiri Kucera 
Thanks for the excellent explanation, Adam. It makes me to understand the
problem now.

Jiri

On Fri, Dec 2, 2022 at 10:03 PM Adam Williamson 
wrote:

> On Fri, 2022-12-02 at 21:25 +0100, Jiri Kucera 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
>
> Ahhh, I see what happened!
>
> So, the problem is this. When a Rawhide update "goes stable" in Bodhi,
> all that really *means* is, it gets the release tag applied (so 'f38'
> at the moment). The next time the buildroot repo is composed after that
> (which happens frequently), the packages from the update will be added
> to it.
>
> However, the packages from the update will only show up in the main
> 'rawhide' repository after the next successful Rawhide compose, which
> is an uncertain interval. One compose is run per day automatically, so
> if those all succeed, you'd be sure of an update making it to 'rawhide'
> no more than 24 hours after it reached 'stable'. But sometimes they
> fail. When they fail, we might fix the problem and try again, or it
> might magically go away with the next day's compose, or we might not
> get a successful compose for a while.
>
> Right now, we haven't had a successful compose for several days due to
> various problems, so the current packages in the main 'rawhide' repo
> are the ones from the last successful compose, which I think was
> 20221130.n.0. Nothing that's gone "stable" since then is actually in
> the repo.
>
> openQA update tests for Rawhide updates use the latest packages from
> the main 'rawhide' repo, plus the packages from the update being
> tested. They do *not* include packages from the buildroot repo.
>
> So in the openQA tests, the first update - with all the builds in it -
> passed the tests just fine. But the second update, which only had gpgme
> in it, failed, because it didn't include the rebuilt dependent packages
> from the first update, even though they were now "stable".
>
> Overall I'd say this isn't your problem as the packager; everything you
> did was totally reasonable. In theory what you "should have done" to
> make the tests pass is wait till a Rawhide compose had completed before
> submitting the second update, but obviously that's not a reasonable
> thing to ask. It's more of a problem for me and releng to think about.
>
> I may think about having openQA Rawhide update tests enable the
> buildroot repo that includes packages from the release tag; this would
> make it include packages that have gone 'stable' since the previous
> Rawhide compose. I'd have to think if there are any potential drawbacks
> to doing that. Ironically, Fedora CI currently does that but is
> considering *not* doing it any more due to "unpleasant surprises":
> https://pagure.io/fedora-ci/general/issue/376 . I'm not sure exactly
> what the surprises were, I'll have to look into it.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
>
___
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

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

2022-12-04 Thread Jiri Kucera 
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  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  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  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=2=Update-FEDORA-2022-603eea89a3=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

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

2022-12-02 Thread Jiri Kucera 
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  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  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=2=Update-FEDORA-2022-603eea89a3=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

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

2022-12-02 Thread Jiri Kucera 
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  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=2=Update-FEDORA-2022-603eea89a3=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

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

2022-12-02 Thread Miro Hrončok 

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=2=Update-FEDORA-2022-603eea89a3=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

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

2022-12-02 Thread Petr Pisar 
V Thu, Dec 01, 2022 at 04:46:06PM -0800, Adam Williamson napsal(a):
> 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=2=Update-FEDORA-2022-603eea89a3=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.
> 
There is already a dedicated test for checking RPM dependencies called
fedora-ci.koji-build.rpmdeplint.functional which caught the breakage
:

Dependency problems with repos:
nothing provides libqgpgme.so.7 needed by kdepim-addons-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kf5-libkleo-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kf5-mailcommon-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kf5-messagelib-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kget-libs-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kleopatra-libs-22.08.3-1.fc38.i686
nothing provides libqgpgme.so.7 needed by kmail-libs-22.08.3-1.fc38.i686

Unfortunatelly, the results do not affect gating by default.

Actually a build whose CI is half red, as you can see on the link, should not
have been pushed even to Rawhide.

-- Petr



signature.asc
Description: PGP signature
___
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

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

2022-12-01 Thread Adam Williamson 
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=2=Update-FEDORA-2022-603eea89a3=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.

Thanks again!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
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

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

2022-11-30 Thread Kevin Kofler via devel 
Petr Pisar wrote:
> Funilly, kdepimlibs-gpgme already provides a copy of an older
> libqgpgme.so.1.

That is a Qt 4 qgpgme. The Qt 5 port, initially released the same way by 
KDE, was eventually upstreamed from KDE into gpgme and is hence no longer 
available as a separate package from KDE (and a compatibility package for 
that one was not needed because all the affected Qt5/KF5 applications were 
able to be built against the qgpgme from upstream gpgme).

Kevin Kofler
___
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

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

2022-11-30 Thread Jiri Kucera 
Thanks for the reminder Petr. I will do the rebase in rawhide only then.

Regards,
Jiri

On Wed, Nov 30, 2022 at 9:46 AM Petr Pisar  wrote:

> V Tue, Nov 29, 2022 at 10:34:45AM -0500, Yaakov Selkowitz napsal(a):
> > On Tue, 2022-11-29 at 14:56 +0100, Petr Pisar wrote:
> > > V Tue, Nov 29, 2022 at 01:07:19PM +0100, Jiri Kucera napsal(a):
> > > > Hello,
> > > >
> > > > I am going to rebase gpgme to 1.17.1 in rawhide, f37, and f36. This
> > > > bumps the SONAME of libqgpgme.so.7 to libqgpgme.so.15.
> > >
> > > Please, don't. That is an incompatible change which will break a lot of
> > > software. E.g. DNF. We had a long thread "Should the policy documents
> better
> > > reflect real package maintenance practice?"
> > > <
> > >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/t
> > > hread/7QL6UNNCC6WHIUSDQSEZMG222IWWCZEI/>
> > > about it last week.
> > >
> > > Do a coordinate rebase in Rawhide. Backport important fixes to older
> > > Fedoras.
> > >
> > > > Expect pushes to these repositories:
> > > > * isoimagewriter
> > > > * trojita
> > > > * kget
> > > > * kf5-libkleo
> > > > * kleopatra
> > > > * kmail-account-wizard
> > > > * kf5-messagelib
> > > > * kf5-mailcommon
> > > > * kdepim-addons
> > > > * kmail
> > > >
> > > This list is suspiciously short. It's missing libdnf, librepo, libisds
> and
> > > probably many others.
> >
> > Jiri wrote that only lib*q*gpgme is getting an SONAME bump.  This is a Qt
> > binding which is only used by Qt and KDE programs.
> >
> You are right. It's libqgpgme.so.7 only. Then the list of the packages is
> indeed shorter. Though I still think that it's inappropriate to break the
> soname in Fedoras < Rawhide.
>
> Funilly, kdepimlibs-gpgme already provides a copy of an older
> libqgpgme.so.1.
>
> If Jiri really want to rebase the library in stable Fedoras, creating
> a compatibility package with libqgpgme.so.7 there could be a way to go.
>
> -- Petr
> ___
> 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

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

2022-11-30 Thread Petr Pisar 
V Tue, Nov 29, 2022 at 10:34:45AM -0500, Yaakov Selkowitz napsal(a):
> On Tue, 2022-11-29 at 14:56 +0100, Petr Pisar wrote:
> > V Tue, Nov 29, 2022 at 01:07:19PM +0100, Jiri Kucera napsal(a):
> > > Hello,
> > > 
> > > I am going to rebase gpgme to 1.17.1 in rawhide, f37, and f36. This
> > > bumps the SONAME of libqgpgme.so.7 to libqgpgme.so.15.
> > 
> > Please, don't. That is an incompatible change which will break a lot of
> > software. E.g. DNF. We had a long thread "Should the policy documents better
> > reflect real package maintenance practice?"
> > <
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/t
> > hread/7QL6UNNCC6WHIUSDQSEZMG222IWWCZEI/>
> > about it last week.
> > 
> > Do a coordinate rebase in Rawhide. Backport important fixes to older
> > Fedoras.
> > 
> > > Expect pushes to these repositories:
> > > * isoimagewriter
> > > * trojita
> > > * kget
> > > * kf5-libkleo
> > > * kleopatra
> > > * kmail-account-wizard
> > > * kf5-messagelib
> > > * kf5-mailcommon
> > > * kdepim-addons
> > > * kmail
> > > 
> > This list is suspiciously short. It's missing libdnf, librepo, libisds and
> > probably many others.
> 
> Jiri wrote that only lib*q*gpgme is getting an SONAME bump.  This is a Qt
> binding which is only used by Qt and KDE programs.
> 
You are right. It's libqgpgme.so.7 only. Then the list of the packages is
indeed shorter. Though I still think that it's inappropriate to break the
soname in Fedoras < Rawhide.

Funilly, kdepimlibs-gpgme already provides a copy of an older libqgpgme.so.1.

If Jiri really want to rebase the library in stable Fedoras, creating
a compatibility package with libqgpgme.so.7 there could be a way to go.

-- Petr


signature.asc
Description: PGP signature
___
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

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

2022-11-29 Thread Yaakov Selkowitz 
On Tue, 2022-11-29 at 14:56 +0100, Petr Pisar wrote:
> V Tue, Nov 29, 2022 at 01:07:19PM +0100, Jiri Kucera napsal(a):
> > Hello,
> > 
> > I am going to rebase gpgme to 1.17.1 in rawhide, f37, and f36. This
> > bumps the SONAME of libqgpgme.so.7 to libqgpgme.so.15.
> 
> Please, don't. That is an incompatible change which will break a lot of
> software. E.g. DNF. We had a long thread "Should the policy documents better
> reflect real package maintenance practice?"
> <
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/t
> hread/7QL6UNNCC6WHIUSDQSEZMG222IWWCZEI/>
> about it last week.
> 
> Do a coordinate rebase in Rawhide. Backport important fixes to older
> Fedoras.
> 
> > Expect pushes to these repositories:
> > * isoimagewriter
> > * trojita
> > * kget
> > * kf5-libkleo
> > * kleopatra
> > * kmail-account-wizard
> > * kf5-messagelib
> > * kf5-mailcommon
> > * kdepim-addons
> > * kmail
> > 
> This list is suspiciously short. It's missing libdnf, librepo, libisds and
> probably many others.

Jiri wrote that only lib*q*gpgme is getting an SONAME bump.  This is a Qt
binding which is only used by Qt and KDE programs.

-- 
Yaakov Selkowitz
Principal Software Engineer - Platform Enablement
Red Hat, Inc.
___
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

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

2022-11-29 Thread Petr Pisar 
V Tue, Nov 29, 2022 at 01:07:19PM +0100, Jiri Kucera napsal(a):
> Hello,
> 
> I am going to rebase gpgme to 1.17.1 in rawhide, f37, and f36. This
> bumps the SONAME of libqgpgme.so.7 to libqgpgme.so.15.

Please, don't. That is an incompatible change which will break a lot of
software. E.g. DNF. We had a long thread "Should the policy documents better
reflect real package maintenance practice?"

about it last week.

Do a coordinate rebase in Rawhide. Backport important fixes to older Fedoras.

> Expect pushes to these repositories:
> * isoimagewriter
> * trojita
> * kget
> * kf5-libkleo
> * kleopatra
> * kmail-account-wizard
> * kf5-messagelib
> * kf5-mailcommon
> * kdepim-addons
> * kmail
> 
This list is suspiciously short. It's missing libdnf, librepo, libisds and
probably many others.

-- Petr


signature.asc
Description: PGP signature
___
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

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

2022-11-29 Thread Jiri Kucera 
Hello,

I am going to rebase gpgme to 1.17.1 in rawhide, f37, and f36. This
bumps the SONAME of libqgpgme.so.7 to libqgpgme.so.15. Expect pushes to
these repositories:
* isoimagewriter
* trojita
* kget
* kf5-libkleo
* kleopatra
* kmail-account-wizard
* kf5-messagelib
* kf5-mailcommon
* kdepim-addons
* kmail

Regards,
Jiri
___
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