[Rawhide] Approaching rebase of gpgme to 1.20.0
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)?
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)?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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)
- 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
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
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
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++
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
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
