[Rawhide] Approaching rebase of gpgme to 1.20.0

2023-06-26 Thread Jiri Kucera
Hello,

later today I will start rebasing gpgme to 1.20.0 in Fedora Rawhide. I
checked the scratch build with abidiff and rpminspect. No soname bumps, ABI
stays stable.

The Qt bindings now support Qt6. This requires a slightly change in
packaging (thanks Marie Loise Nolden):
* previously:
  * qgpgme
  * qgpgme-devel
* now:
  * qgpgme-qt5 (provides qgpgme for the backward compatibility)
  * qgpgme-qt5-devel (provides qgpgme-devel for the backward compatibility)
  * qgpgme-qt6
  * qgpgme-qt6-devel

In Fedora, both bindings are enabled. In ELN, Qt5 binding is disabled and
Qt6 binding is enabled.

I built Qt consumers in a copr without any problems or interventions:
https://copr.fedorainfracloud.org/coprs/jkucera/gpgme-1.20.0/builds/

Here are also scratch builds for Rawhide and ENL:
* Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=102603852
* ELN: https://koji.fedoraproject.org/koji/taskinfo?taskID=102604606

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


Re: What is configuration of machines in Koji BS (python-invoke build hangs)?

2023-04-27 Thread Jiri Kucera
Thanks a lot Kevin. This time it completed successfully:
https://koji.fedoraproject.org/koji/taskinfo?taskID=100456381

Looks like I hit some temporary issue in previous builds.

Regards
Jiri

On Thu, Apr 27, 2023 at 7:25 PM Kevin Fenzi  wrote:

> On Thu, Apr 27, 2023 at 03:46:55PM +0200, Jiri Kucera wrote:
> > Hello all,
> >
> > where can I find the source code of the machines' configuration used by
> > Koji build system and scripts/tools that are used for the deployment?
>
> koji builders are currently Fedora 37 vm's/hardware.
> They are configured via ansible.
> See:
>
> https://pagure.io/fedora-infra/ansible/blob/main/f/playbooks/groups/buildvm.yml
>
> https://pagure.io/fedora-infra/ansible/blob/main/f/playbooks/groups/buildhw.yml
>
> > I am asking since I am trying to build a python-invoke for Fedora 38 and
> > everytime it hangs on `pytest`[1][3]. However, it builds smoothly on my
> > local machine in mock. Also, last time I built it for rawhide
> approximately
> > a month ago it also builds smoothly. So my guess why it hangs now are:
> > * pytest receives a signal
> > * pytest is blocked when trying to write its warning summary to the
> output
> > due to some kind of quota (there are tons of deprecation warnings, see
> the
> > rawhide build.log[2])
> > * anything else (any thoughts?)
>
> Koji builders just call mock with a config from koji to enable the right
> repos, etc.
>
> it should be identical to mock on a local machine, unless there's
> something in the koji buildroot thats not in the mock builds you were
> doing.
> >
> > I am about to disable %check to make the build successful, but if anybody
> > has a clue what's going on please let me know.
> >
> > Thanks in advance
> > Jiri
> >
> > [1] Cancelled builds previously hanging:
> > - https://koji.fedoraproject.org/koji/taskinfo?taskID=100408931
> > - https://koji.fedoraproject.org/koji/taskinfo?taskID=100412125
> > [2] Successful rawhide build:
> > - https://koji.fedoraproject.org/koji/buildinfo?buildID=2165115
> > [3] You can see from the build.log the pytest is wrapped inside of expect
> > script allocating a pseudo terminal for it. This is because the mocking
> of
> > tty in upstream tests does not work as expected so the majority of tests
> > are failing when running outside of the terminal device.
>
> If you want to start another build with the tests and ping me ( in
> #releng:fedoraproject.org / #fedora-releng on libera.chat, or via email)
> I can login to the builder and strace where it is stalling.
>
> Off hand I don't know why anything would be different on the builders
> here.
>
> kevin
> ___
> 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


What is configuration of machines in Koji BS (python-invoke build hangs)?

2023-04-27 Thread Jiri Kucera
Hello all,

where can I find the source code of the machines' configuration used by
Koji build system and scripts/tools that are used for the deployment?

I am asking since I am trying to build a python-invoke for Fedora 38 and
everytime it hangs on `pytest`[1][3]. However, it builds smoothly on my
local machine in mock. Also, last time I built it for rawhide approximately
a month ago it also builds smoothly. So my guess why it hangs now are:
* pytest receives a signal
* pytest is blocked when trying to write its warning summary to the output
due to some kind of quota (there are tons of deprecation warnings, see the
rawhide build.log[2])
* anything else (any thoughts?)

I am about to disable %check to make the build successful, but if anybody
has a clue what's going on please let me know.

Thanks in advance
Jiri

[1] Cancelled builds previously hanging:
- https://koji.fedoraproject.org/koji/taskinfo?taskID=100408931
- https://koji.fedoraproject.org/koji/taskinfo?taskID=100412125
[2] Successful rawhide build:
- https://koji.fedoraproject.org/koji/buildinfo?buildID=2165115
[3] You can see from the build.log the pytest is wrapped inside of expect
script allocating a pseudo terminal for it. This is because the mocking of
tty in upstream tests does not work as expected so the majority of tests
are failing when running outside of the terminal device.
___
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&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 

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


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


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


[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


[WIP][gpgme rebase to 1.18.0] Ask for comaintainership of dependant packages

2022-09-14 Thread Jiri Kucera
Hello,

I am planning to update gpgme to 1.18.0 in rawhide and since there is
SONAME bump in libqgpgme, I am asking to be a co-maintainer of these
dependant packages:
- https://src.fedoraproject.org/rpms/isoimagewriter (main admin: lupinix)
- https://src.fedoraproject.org/rpms/kdepim-addons (main admin: rdieter)
- https://src.fedoraproject.org/rpms/kf5-libkleo (main admin: rdieter)
- https://src.fedoraproject.org/rpms/kf5-mailcommon (main admin: rdieter)
- https://src.fedoraproject.org/rpms/kf5-messagelib (main admin: rdieter)
- https://src.fedoraproject.org/rpms/kget (main admin: than)
- https://src.fedoraproject.org/rpms/kleopatra (main admin: rdieter)
- https://src.fedoraproject.org/rpms/kmail-account-wizard (main admin:
rdieter)
- https://src.fedoraproject.org/rpms/kmail (main admin: rdieter)
- https://src.fedoraproject.org/rpms/trojita (main admin: kkofler)

Thanks in advance,
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


[rawhide][approaching SONAME bump][gpgme] libqgpgme.so.7 -> libqgpgme.so.15

2022-03-29 Thread Jiri Kucera
Hello,

I am working on a gpgme update from 1.17.0 to 1.17.1 (bz#2061192). Since
the update changes libqgpgme SONAME from libqgpgme.so.7 to libqgpgme.so.15,
I requested the side tag f37-build-side-52334 and do a build in it:

- commit:
https://src.fedoraproject.org/rpms/gpgme/c/b46b5db21813b39584eb1046239dfba7bb40571e?branch=rawhide
- build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=84893999

The list of dependent packages that possibly need to be rebuild in
f37-build-side-52334 side tag is:
$ dnf --repofrompath=frawhide,
http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/rawhide/Everything/x86_64/os/
--disablerepo='*' --enablerepo='frawhide' --refresh repoquery --whatdepends
qgpgme
Added frawhide repo from
http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/rawhide/Everything/x86_64/os/
frawhide

   187 kB/s | 6.1 kB
  00:00
isoimagewriter-0:0.8-8.fc36.x86_64
kdepim-addons-0:21.12.3-1.fc37.i686
kdepim-addons-0:21.12.3-1.fc37.x86_64
kf5-libkleo-0:21.12.3-1.fc37.i686
kf5-libkleo-0:21.12.3-1.fc37.x86_64
kf5-mailcommon-0:21.12.3-1.fc37.i686
kf5-mailcommon-0:21.12.3-1.fc37.x86_64
kf5-messagelib-0:21.12.3-1.fc37.i686
kf5-messagelib-0:21.12.3-1.fc37.x86_64
kget-libs-0:21.12.3-1.fc37.i686
kget-libs-0:21.12.3-1.fc37.x86_64
kleopatra-0:21.12.3-1.fc37.x86_64
kleopatra-libs-0:21.12.3-1.fc37.i686
kleopatra-libs-0:21.12.3-1.fc37.x86_64
kmail-account-wizard-0:21.12.3-1.fc37.x86_64
kmail-libs-0:21.12.3-1.fc37.i686
kmail-libs-0:21.12.3-1.fc37.x86_64
qgpgme-devel-0:1.17.0-2.fc37.i686
qgpgme-devel-0:1.17.0-2.fc37.x86_64
trojita-0:0.7.0.1-0.13.20220117git266c757.fc36.x86_64

Eventually the list of libqgpgme.so.7 consumers (have no idea why there are
only *.i686 on the list):
$ dnf --repofrompath=frawhide,
http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/rawhide/Everything/x86_64/os/
--disablerepo='*' --enablerepo='frawhide' --refresh repoquery --whatdepends
libqgpgme.so.7
Added frawhide repo from
http://ftp.fi.muni.cz/pub/linux/fedora/linux/development/rawhide/Everything/x86_64/os/
frawhide

   5.1 kB/s | 6.1 kB
  00:01
kdepim-addons-0:21.12.3-1.fc37.i686
kf5-libkleo-0:21.12.3-1.fc37.i686
kf5-mailcommon-0:21.12.3-1.fc37.i686
kf5-messagelib-0:21.12.3-1.fc37.i686
kget-libs-0:21.12.3-1.fc37.i686
kleopatra-libs-0:21.12.3-1.fc37.i686
kmail-libs-0:21.12.3-1.fc37.i686
qgpgme-devel-0:1.17.0-2.fc37.i686

The major difference between 1.17.0 and 1.17.1 is this commit:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commit;h=ad3aabdd8a64156c7e3a75d695ae1ab2c4bec841
fixing the virtual table layout.

I have a plea to maintainers of these packages (or proven packagers) to
build their dependent packages against the f37-build-side-52334 side tag
and then let me know when the build is ready.

Thanks in advance
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Fwd: OpenSceneGraph and gdal need to be rebuild for Fedora 34

2021-06-18 Thread Jiri Kucera
Thanks for your work, Björn!

On Thu, Jun 17, 2021 at 11:13 AM Björn 'besser82' Esser <
besse...@fedoraproject.org> wrote:

> Am Donnerstag, dem 17.06.2021 um 08:55 +0200 schrieb Björn 'besser82'
> Esser:
> > Am Mittwoch, dem 16.06.2021 um 21:18 +0200 schrieb Björn 'besser82'
> > Esser:
> > > Am Mittwoch, dem 16.06.2021 um 19:53 +0200 schrieb Jiri Kucera:
> > > > Adding devel-list for a broader audience. My side tag will expire
> > > > for
> > > > a couple of days. Can some proven packager add me please to gdal,
> > > > OpenSceneGraph, and vtk as a co-maintainer so I can do rebuilds
> > > > for
> > > > libgta?
> > > >
> > > > Cheers,
> > > > Jiri
> > > >
> > > >
> > > > -- Forwarded message -
> > > > From: Jiri Kucera 
> > > > Date: Fri, Jun 11, 2021 at 10:29 AM
> > > > Subject: OpenSceneGraph and gdal need to be rebuild for Fedora 34
> > > > To: , ,
> > > > 
> > > >
> > > >
> > > > Hi Sandro, Ralph, and Orion,
> > > >
> > > > I rebuilt[1] libgta with sidetag f34-build-side-42373 for Fedora
> > > > 34,
> > > > which bumps libgta.so.0 to libgta.so.1. Please,
> > > > rebuild your packages against this sidetag:
> > > > * gdal need to be probably rebased to 3.3.0 (I did a scratch
> > > > build[2]
> > > > against the sidetag from f34 branch and its succeeded, but the
> > > > scratch
> > > > build[3] of OpenSceneGraph failed[4])
> > > > * after gdal OpenSceneGraph and vtk need to be rebuilt
> > > > * last, opencv need to be rebuilt (I do this by myself)
> > > >
> > > > Regards,
> > > > Jiri
> > > >
> > > > [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1766154
> > > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=69770320
> > > > [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=69836182
> > > > [4] Excerpt from the mock_output.log:
> > >
> > >
> > > I'll take care of the needed rebuilds in your sidetag as a
> > > provenpackager, and will give you a short notice, as soon as you can
> > > start rebuilding opencv.
> >
> >
> > gdal and OpenSceneGraph have been seccessfully rebuilt in the sidetag.
> > vtk is still building.
>
>
> vtk has finished successfully, too.
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Fwd: OpenSceneGraph and gdal need to be rebuild for Fedora 34

2021-06-16 Thread Jiri Kucera
Adding devel-list for a broader audience. My side tag will expire for a
couple of days. Can some proven packager add me please to gdal,
OpenSceneGraph, and vtk as a co-maintainer so I can do rebuilds for libgta?

Cheers,
Jiri


-- Forwarded message -
From: Jiri Kucera 
Date: Fri, Jun 11, 2021 at 10:29 AM
Subject: OpenSceneGraph and gdal need to be rebuild for Fedora 34
To: , , 


Hi Sandro, Ralph, and Orion,

I rebuilt[1] libgta with sidetag f34-build-side-42373 for Fedora 34, which
bumps libgta.so.0 to libgta.so.1. Please,
rebuild your packages against this sidetag:
* gdal need to be probably rebased to 3.3.0 (I did a scratch build[2]
against the sidetag from f34 branch and its succeeded, but the scratch
build[3] of OpenSceneGraph failed[4])
* after gdal OpenSceneGraph and vtk need to be rebuilt
* last, opencv need to be rebuilt (I do this by myself)

Regards,
Jiri

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1766154
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=69770320
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=69836182
[4] Excerpt from the mock_output.log:
Error:
 Problem: package gdal-devel-3.2.2-1.fc34.x86_64 requires
libgdal.so.28()(64bit), but none of the providers can be installed

  - package gdal-devel-3.2.2-1.fc34.x86_64 requires gdal-libs(x86-64)
= 3.2.2-1.fc34, but none of the providers can be installed
  - conflicting requests
  - nothing provides libgta.so.0()(64bit) needed by
gdal-libs-3.2.2-1.fc34.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


[HEADS UP] udftools is going to be updated to 2.3

2021-06-09 Thread Jiri Kucera
Hello,

I am going to update udftools to 2.3 plus backport the latest upstream
fixes introduced after this release. This should have no negative impact
(no library is distributed and dnf tells me that nothing depends on
udftools).

The list of changes according to upstream:
* mkudffs:
  * Added support for creating Multisession UDF disc images via new
--startblock option
  * Added new options for specifying owner, organization and contact
information
  * Added new option --bootarea=mbr:sec-size to allow specifying MBR sector
size
  * Added udftools version string into Application Identifier
  * Fixed default value of Packet Length in Sparable Partition for UDF 1.50
and 2.00 rev to 32 blocks
  * Fixed detecting all 33 types of optical discs defined in all versions
of SCSI MMC specifications
  * Fixed filling CHS sector number into MBR partition table
  * Fixed alignment of VAT block for CD-R, DVD-R and BD-R disc
  * Fixed alignment for CD-R discs
  * Fixed generating unclosed CD-R image with blocks more than 3072
* udfinfo & udflabel:
  * Added support for Multisession UDF optical discs via new --startblock
and --lastblock options
  * Added support for showing and changing owner, organization, contact,
appid and impid UDF identifiers
  * Added more checks to validation of UDF structures
  * Throw error when trying to modify UDF disc with unsupported Pseudo
OverWrite partition
* pktsetup:
  * Added new option -i to ignore errors when device is already mapped or
unmapped
  * Added new tool pktcdvd-check which checks if optical disc can be used
by kernel pktcdvd.ko driver for write operations
  * Update udev rule to map only optical discs which are supported for
write operation (check done by pktcdvd-check tool)
* cdrwtool:
  * Fixed formatting of CD-RW disc in modern optical drives according to
MMC-6 standard (via Format Code 1)
  * Fixed support for progress bar

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 on the list, report it: 
https://pagure.io/fedora-infrastructure


[HEADS UP] libgta-1.2.1-5.fc34 successfully built

2021-06-08 Thread Jiri Kucera
Hello,

libgta-1.2.1-5.fc34 was built successfully[1] with side
tag f34-build-side-42373. You can now rebuild your dependent packages
against this side tag so I can create a Bodhi update.

Regards,
Jiri

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1766154
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: [HEADS UP] libgta SONAME bump in Fedora 34

2021-06-08 Thread Jiri Kucera
Good to know, thanks Zbyszek.

On Tue, Jun 8, 2021 at 6:47 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Jun 08, 2021 at 05:43:37PM +0200, Jiri Kucera wrote:
> > Hello,
> >
> > I am planning to fix the FTBFS bug of libgta also for Fedora 34, which
> > bumps its SONAME. The list of affected components is below
>
> There should be no need to rebuild indirect dependencies. If those
> indirect dependencies were to use any symbols from libgta, they would
> be linked directly.
>
> Zbyszek
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: [HEADS UP] libgta SONAME bump in Fedora 34

2021-06-08 Thread Jiri Kucera
Hi Dominik,

from paraview source rpm is produced paraview-devel which is a dependency
of libeml-devel and libmatroska-devel:

[root@fedora ~]# dnf --enablerepo '*-source' repoquery --whatrequires
paraview-devel
Last metadata expiration check: 0:01:10 ago on Tue 08 Jun 2021 05:26:24 PM
UTC.
libebml-devel-0:1.4.2-1.fc34.i686
libebml-devel-0:1.4.2-1.fc34.x86_64
libmatroska-devel-0:1.6.2-2.fc34.i686
libmatroska-devel-0:1.6.2-2.fc34.x86_64
libmatroska-devel-0:1.6.3-1.fc34.i686
libmatroska-devel-0:1.6.3-1.fc34.x86_64

Regards,
Jiri

On Tue, Jun 8, 2021 at 5:55 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> Hi!
>
> On Tuesday, 08 June 2021 at 17:43, Jiri Kucera wrote:
> > Hello,
> >
> > I am planning to fix the FTBFS bug of libgta also for Fedora 34, which
> > bumps its SONAME. The list of affected components is below (the list is
> not
> > complete, the path from some packages to libgta in dependency graph is
> too
> > long):
> >
> > libgta:
> ...
> > paraview:
> >   libebml:
> > gerbera (build requirement)
> > mkvtoolnix
> >   libmatroska
>
> What does paraview have to do with libebml or libmatroska? I can't find
> any dependencies here.
>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


[HEADS UP] libgta SONAME bump in Fedora 34

2021-06-08 Thread Jiri Kucera
Hello,

I am planning to fix the FTBFS bug of libgta also for Fedora 34, which
bumps its SONAME. The list of affected components is below (the list is not
complete, the path from some packages to libgta in dependency graph is too
long):

libgta:
  OpenSceneGraph:
FlightGear
FlightGear-Atlas (build requirement)
SimGear
fgrun
gpick (build requirement)
osgearth
scribus:
  scribus-generator
speed-dreams
  gdal:
GMT
OpenSceneGraph
PDAL
R-rgdal:
  R-rgeos (build requirement):
R-broom (build requirement):
  R-dplyr (build requirement):

  R-geepack
  R-modelr (build requirement)
R-ggplot2 (build requirement):
  
bes:
  ocsinventory-agent
  php-horde-horde:

cloudcompare
dans-gdal-scripts
gazebo:
  fawkes
grass
liblas
libosmium:
  osm2pgsql (build requirement)
  osmium-tool (build requirement)
  pyosmium (build requirement)
mapnik:
  python-mapnik:
nik4
  viking
mapserver
merkaartor
ncl
ogr2osm
opencv:
  
osgearth
paraview:
  libebml:
gerbera (build requirement)
mkvtoolnix
  libmatroska
postgis:
  pgRouting
python-cartopy (build requirement):
  pygrib (build requirement)
  python-geoplot:
python-missingno
python-fiona:
  python-geopandas:
python-earthpy
python-libpysal (build requirement)
python-mapclassify (build requirement)
python-networkx (build requirement):
  
python-phyghtmap
python-rasterio:
  python-contextily
  python-xarray (build requirement):

python-tilestache (build requirement)
qgis
qmapshack
saga
vfrnav
vtk:
  InsightToolkit:
petpvc
  Mayavi:
python-tvb-data
  engrid
  freecad (build requirement)
  libASL
  maxima (build requirement):
sagemath
wxMaxima
  mrpt
  opencascade:
gmsh:
  getdp (build requirement)
kicad
netgen-mesher
  openmeeg (build requirement)
  pcl
  python-cclib
  smesh
xastir (build requirement)

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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: [cdparanoia] License field fix awaiting to be merged

2021-06-08 Thread Jiri Kucera
CC'ing Zbyszek

On Mon, Jun 7, 2021 at 6:27 PM Jiri Kucera  wrote:

> Hi Zbyszek,
>
> reply inline
>
> On Wed, Jun 2, 2021 at 5:42 PM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Wed, Jun 02, 2021 at 01:31:15PM -, Benjamin Beasley wrote:
>> > > So, it doesn't really matter if two source files are distributed
>> under the GPLv2+ license.
>> > > The resulting binary (i.e. /usr/bin/cdparanoia) will always be GPLv2.
>> > > […]
>> > > But Licensing Guidelines make clear that the License: field refers to
>> the
>> > > binary packages not source ones.
>> > >
>> > > BR,
>> > >
>> > > Andrea
>> >
>> > The “effective license” approach you advocated is not mentioned in the
>> packaging guidelines but has historical support in the wiki (
>> https://fedoraproject.org/wiki/Licensing:FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F).
>> It has also come up on the fedora-legal list recently (
>> https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/W57JRNLWVOT55D7TDF7VYFMJT5QMBEGR/
>> ).
>>
>> FWIW, the licensing guidelines live on the wiki. There is nothing
>> "historical" about the Licensing:FAQ document, it is still the official
>> guide of how to interpret the Licensing:Main page.
>>
>> I know Ben wrote something that disagrees with the document, but
>> I think he is wrong. It also goes against the long-established practice.
>> And if we want to change the rules, the document that specifies them
>> should be changed, a post on the mailing list is not enough.
>>
>> > There is, I think, a valid question of how much mechanistic detail to
>> apply to documenting the source files *that contribute to the binary RPM
>> contents.* One approach, which I have favored in my packages, exhaustively
>> lists licenses of such files. The other, which you have advocated,
>> simplifies the license field into an “effective license” when clearly
>> appropriate. Both philosophies seem to be well-established as acceptable.
>> My view is therefore this patch seems to be correct but not absolutely
>> required.
>>
>> No, the patch is wrong. It's not super harmful, but it's still wrong.
>>
>
> So what should be the correct License then? According to [1], the one
> possibility is
>
>   License: (GPLv2 and GPLv2+) and LGPLv2
>
> but according to [2] point 2, this should be shortened to
>
>   License: GPLv2 and LGPLv2
>
> because GPLv2 is stricter. Should the patch be reverted with the comment
> explaining multiple licensing situations?
>
> Regards,
> Jiri
>
> [1]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_mixed_source_licensing_scenario
> [2]
> https://fedoraproject.org/wiki/Licensing:FAQ#How_should_I_handle_multiple_licensing_situations.3F
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: [cdparanoia] License field fix awaiting to be merged

2021-06-07 Thread Jiri Kucera
Hi Zbyszek,

reply inline

On Wed, Jun 2, 2021 at 5:42 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Wed, Jun 02, 2021 at 01:31:15PM -, Benjamin Beasley wrote:
> > > So, it doesn't really matter if two source files are distributed under
> the GPLv2+ license.
> > > The resulting binary (i.e. /usr/bin/cdparanoia) will always be GPLv2.
> > > […]
> > > But Licensing Guidelines make clear that the License: field refers to
> the
> > > binary packages not source ones.
> > >
> > > BR,
> > >
> > > Andrea
> >
> > The “effective license” approach you advocated is not mentioned in the
> packaging guidelines but has historical support in the wiki (
> https://fedoraproject.org/wiki/Licensing:FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F).
> It has also come up on the fedora-legal list recently (
> https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/W57JRNLWVOT55D7TDF7VYFMJT5QMBEGR/
> ).
>
> FWIW, the licensing guidelines live on the wiki. There is nothing
> "historical" about the Licensing:FAQ document, it is still the official
> guide of how to interpret the Licensing:Main page.
>
> I know Ben wrote something that disagrees with the document, but
> I think he is wrong. It also goes against the long-established practice.
> And if we want to change the rules, the document that specifies them
> should be changed, a post on the mailing list is not enough.
>
> > There is, I think, a valid question of how much mechanistic detail to
> apply to documenting the source files *that contribute to the binary RPM
> contents.* One approach, which I have favored in my packages, exhaustively
> lists licenses of such files. The other, which you have advocated,
> simplifies the license field into an “effective license” when clearly
> appropriate. Both philosophies seem to be well-established as acceptable.
> My view is therefore this patch seems to be correct but not absolutely
> required.
>
> No, the patch is wrong. It's not super harmful, but it's still wrong.
>

So what should be the correct License then? According to [1], the one
possibility is

  License: (GPLv2 and GPLv2+) and LGPLv2

but according to [2] point 2, this should be shortened to

  License: GPLv2 and LGPLv2

because GPLv2 is stricter. Should the patch be reverted with the comment
explaining multiple licensing situations?

Regards,
Jiri

[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_mixed_source_licensing_scenario
[2]
https://fedoraproject.org/wiki/Licensing:FAQ#How_should_I_handle_multiple_licensing_situations.3F
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: python-invoke orphaned

2021-06-07 Thread Jiri Kucera
Hello, I took it.

Regards,
Jiri

On Mon, Jun 7, 2021 at 3:58 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Monday, 07 June 2021 at 12:10, Paul Howarth wrote:
> > Hi,
> >
> > I have orphaned python-invoke, whose test suite requires
> > pytest-relaxed, which requires pytest < 5 and fails to build with
> > Python 3.10.
> >
> > I believe this only impacts python-jsonmodels; not sure how big an
> > impact it is.
>
> It also impacts python-filecheck, where it's required to run the test
> suite. If nobody picks it up, I'll be forced to disable running the
> testsuite in F35+ then.
>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: [cdparanoia] License field fix awaiting to be merged

2021-06-03 Thread Jiri Kucera
If the README has the last word here and it does not matter that some
sequences of bits of /usr/bin/cdparanoia are licensed under GPLv2+ and the
rest of it under GPLv2, so be it.

On the other hand,
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_mixed_source_licensing_scenario
states that if /usr/bin/foo is generated from foo1.c licensed under A and
foo2.c licensed under B, where A and B are compatible, but different,
licenses, then this scenario should be handled by "(A and B)" in License
field.

The best way to deal with this situation would be to ask upstream to
re-license those two files to GPLv2, but cdparanoia upstream is
effectively dead.

Regards,
Jiri

On Wed, Jun 2, 2021 at 2:23 PM Andrea Musuruane  wrote:

> I believe this patch is not correct.
>
> "The License: field refers to the licenses of the contents of the *binary*
> rpm."
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
>
> In the README file there is writted: "cdparanoia (the command line tool)
> is released under the GPLv2.  The interface and paranoia libraries are
> covered by the LGPLv2.1."
>
> So, it doesn't really matter if two source files are distributed under the 
> GPLv2+
> license. The resulting binary (i.e. /usr/bin/cdparanoia) will always be
> GPLv2.
>
> BR,
>
> Andrea
>
>
> On Wed, Jun 2, 2021 at 2:03 PM Jiri Kucera  wrote:
>
>> Thanks Neal!
>>
>> On Wed, Jun 2, 2021 at 1:06 PM Neal Gompa  wrote:
>>
>>> On Wed, Jun 2, 2021 at 6:54 AM Neal Gompa  wrote:
>>> >
>>> > On Wed, Jun 2, 2021 at 6:53 AM Jiri Kucera  wrote:
>>> > >
>>> > > Adding broader audience:
>>> https://src.fedoraproject.org/rpms/cdparanoia/pull-request/4
>>> > >
>>> > > Neither @pjones nor @ajax are responding.
>>> > >
>>> >
>>> > I'll deal with it.
>>> >
>>>
>>> This is done, and updates have been proposed for stable releases:
>>>
>>> * Fedora 34:
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2021-31358601f8
>>>
>>> * Fedora 33:
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2021-4c93fe43a0
>>>
>>> Please karma them up for release to stable.
>>>
>>>
>>>
>>>
>>> --
>>> 真実はいつも一つ!/ Always, there's only one truth!
>>>
>>> ___
>> 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 on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: [cdparanoia] License field fix awaiting to be merged

2021-06-02 Thread Jiri Kucera
Thanks Neal!

On Wed, Jun 2, 2021 at 1:06 PM Neal Gompa  wrote:

> On Wed, Jun 2, 2021 at 6:54 AM Neal Gompa  wrote:
> >
> > On Wed, Jun 2, 2021 at 6:53 AM Jiri Kucera  wrote:
> > >
> > > Adding broader audience:
> https://src.fedoraproject.org/rpms/cdparanoia/pull-request/4
> > >
> > > Neither @pjones nor @ajax are responding.
> > >
> >
> > I'll deal with it.
> >
>
> This is done, and updates have been proposed for stable releases:
>
> * Fedora 34:
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-31358601f8
>
> * Fedora 33:
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-4c93fe43a0
>
> Please karma them up for release to stable.
>
>
>
>
> --
> 真実はいつも一つ!/ Always, there's only one truth!
>
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


[cdparanoia] License field fix awaiting to be merged

2021-06-02 Thread Jiri Kucera
Adding broader audience:
https://src.fedoraproject.org/rpms/cdparanoia/pull-request/4

Neither @pjones nor @ajax are responding.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: [LEGAL] License field not match the content of eigen3-devel?

2021-05-26 Thread Jiri Kucera
CC'ing Richard Fontana

- Original Message -
> From: "Jiri Kucera" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, May 26, 2021 4:15:21 PM
> Subject: [LEGAL] License field not match the content of eigen3-devel?
> 
> Hello,
> 
> I do some investigation of eigen3-devel package and found out that there are
> some files distributed under the Minpack license:
> - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMcovar.h
> - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMonestep.h
> - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMpar.h
> - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMqrsolv.h
> -
> /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LevenbergMarquardt.h
> 
> There is no "minpack" identifier in the License field inside the eigen3.spec.
> However, Minpack license claims itself to be BSD-like.
> 
> 1. Should minpack be added to the License field or it is covered by the BSD
> license identifier?
> 2. Are we really need to ship files in the eigen3-devel packages that are
> marked as unsupported?
> 
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
> 
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


[LEGAL] License field not match the content of eigen3-devel?

2021-05-26 Thread Jiri Kucera
Hello,

I do some investigation of eigen3-devel package and found out that there are 
some files distributed under the Minpack license:
- /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMcovar.h
- /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMonestep.h
- /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMpar.h
- /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMqrsolv.h
- 
/usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LevenbergMarquardt.h

There is no "minpack" identifier in the License field inside the eigen3.spec. 
However, Minpack license claims itself to be BSD-like.

1. Should minpack be added to the License field or it is covered by the BSD 
license identifier?
2. Are we really need to ship files in the eigen3-devel packages that are 
marked as unsupported?

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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Automation/gating for handling soname bumps? (was Re: Unannounced soname bump: libgta)

2021-05-26 Thread Jiri Kucera
- Original Message -
> From: "Richard Shaw" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, May 20, 2021 2:06:34 PM
> Subject: Unannounced soname bump: libgta
> 
> Looks like a long standing FTBFS was finally fixed, after previous version
> update attempts failed and the soname bump (0->1) went unnoticed.

My apologies for breaking the rawhide. Do we have some gating/automation that 
keeps new builds gated and additionally rebuilds dependent packages whenever 
the soname change is detected?

Regards and have a nice day,
Jiri

 
> https://src.fedoraproject.org/rpms/libgta/commits/rawhide
> 
> Looks like only two packages need rebuilding:
> gdal
> OpenSceneGraph
> 
> I'll go ahead and kick off builds.
> 
> Thanks,
> Richard
> 
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
> 
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: gpg-agents all over the place

2021-01-05 Thread Jiri Kucera
Hello Roberto,

- Original Message -
> From: "Roberto Ragusa" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, December 24, 2020 5:20:38 PM
> Subject: Re: gpg-agents all over the place
> 
> On 12/23/20 1:56 PM, Oron Peled wrote:
> 
> > More problematic, but possible.
> > 
> > The key is using "--pinentry-mode=loopback" (I don't have my scripts in
> > front of me for further details)
> There are simple use cases that are very problematic.
> Consider this:
> 
> [me@localhost tmp]$ date >date.txt
> [me@localhost tmp]$ gpg --pinentry-mode=loopback -c date.txt   ### this asks
> for a passphrase
> [me@localhost tmp]$ ls -l
> total 8
> -rw-rw-r-- 1 me me  32 Dec 24 16:59 date.txt
> -rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg
> [me@localhost tmp]$ rm date.txt
> [me@localhost tmp]$ gpg --pinentry-mode=loopback date.txt.gpg   ### this does
> not ask!
> gpg: WARNING: no command supplied.  Trying to guess what you mean ...
> gpg: AES encrypted data
> gpg: encrypted with 1 passphrase
> [me@localhost tmp]$ ls -l
> total 8
> -rw-rw-r-- 1 me me  32 Dec 24 17:00 date.txt
> -rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg
> 
> that would be a very simple tutorial about symmetric encryption and it is
> absolutely surprising, since decryption happens without any need to supply
> the passphrase.
> Because an agent was forked and it remembers the symmetric
> passphrase I've used! Crazy.
> 
> So let's see if we can use --batch: using it on encryption conflicts with
> pineentry,
> using it on decryption doesn't disable the gpg-agent usage.
> 
> We should try to avoid the agent, let's see in the man page:
> --use-agent
> --no-use-agent
>This is dummy option. gpg always requires the agent.
> Wow, the option you want, but with a dummy implementation.
> 
> There is a --no-autostart, let's try it: more wasted time.
> 
> The use case I care about is for a script that reads some data
> from an encrypted file, asking me the passphrase when necessary.
> Something like:
> 
> token="$(gpg1 --output - secrets.gpg | grep ^token= | cut -d= -f2)"
> # use $token
> 
> The passphrase should not be hardcoded in the script or remembered by
> a magic gpg-agent forked behind my back.
> 
> My only solution has been:
>dnf install gnupg1

did you try `--no-symkey-cache` option? It disables password caching during the 
session:

# date > date.txt
# gpg --pinentry-mode=loopback --no-symkey-cache -c date.txt
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created

# gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: AES.CFB encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key

# gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: AES.CFB encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key

# gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: AES.CFB encrypted data
gpg: encrypted with 1 passphrase
File 'date.txt' exists. Overwrite? (y/N) N
Enter new filename: date2.txt

# diff date.txt date2.txt 
# rpm -q gnupg2
gnupg2-2.2.23-1.fc33.x86_64


Regards
Jiri

> 
> Regards.
> 
> --
> Roberto Ragusamail at robertoragusa.it
> ___
> 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
> 
___
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


epel8: BuildrootError: could not init mock buildroot

2020-01-30 Thread Jiri Kucera
Hello,

when doing `fedpkg scratch-build --target epel8-candidate --srpm 
sox-14.4.2.0-29.el8.src.rpm`, I get:


[] 100% 00:00:01   1.02 MiB 773.06 KiB/sec
Building sox-14.4.2.0-29.el8.src.rpm for epel8-candidate
Created task: 41245726
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=41245726
Watching tasks (this may be safely interrupted)...
41245726 build (epel8-candidate, sox-14.4.2.0-29.el8.src.rpm): free
41245726 build (epel8-candidate, sox-14.4.2.0-29.el8.src.rpm): free -> FAILED: 
BuildrootError: could not init mock buildroot, mock exited with status 30; see 
root.log for more information
  0 free  0 open  0 done  1 failed
  41245727 rebuildSRPM (noarch): FAILED: BuildrootError: could not init mock 
buildroot, mock exited with status 30; see root.log for more information

41245726 build (epel8-candidate, sox-14.4.2.0-29.el8.src.rpm) failed


When I investigating the logs (both `root.log` and `mock_output.log`), I found 
that `dnf` has problem with package downloading:


Downloading Packages:
Error: Error downloading packages:
  Status code: 404 for 
https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/libarchive-3.3.2-7.el8.x86_64.rpm
 (IP: 10.5.126.23)



I get the same result also with `--target epel8`.

Any ideas how to resolve this issue?

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


Resurrecting python-logilab-common package

2018-06-12 Thread Jiri Kucera
Hello,

I am interested in maintaining python-logilab-common package. It is required by 
python-pylint-common (not yet packaged), which is required by 
python-prospector. I have a plan to add prospector to Fedora. It will be used 
as a csmock plugin if it  catch issues not covered by recent csmock plugins for 
Python.

Thanks in advance
Jiri Kucera
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NHUHJBE6YK5RHL4DP33UVAOWK4RX7SBE/


Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

2018-03-01 Thread Jiri Kucera
fixed in sox, passwd, and usermode
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Hi

2017-10-16 Thread Jiri Kucera
Hi all,

my name is Jiri Kucera and I am a new hire at Red Hat Czech. I will be focusing 
on Go packaging and development and maintenance of tooling for Go source code 
analysis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org