Re: jpegxl soname bump
Am Sonntag, dem 21.11.2021 um 15:40 -0500 schrieb Scott Talbert: > Hi @eclipseo, > > Looks like jpegxl soname was bumped, breaking a bunch of stuff: > > 2021-11-21 20:20:51 > Package resolution failed > > Problem: package gd-2.3.3-3.fc36.x86_64 requires > libavif.so.12()(64bit), but none of the providers can be installed > - package graphviz-2.49.3-2.fc36.x86_64 requires > libgd.so.3()(64bit), > but none of the providers can be installed > - package libavif-0.9.2-2.fc35.x86_64 requires > libaom.so.3()(64bit), > but none of the providers can be installed > - conflicting requests > - nothing provides libjxl.so.0()(64bit) needed by > libaom-3.1.2-1.fc35.x86_64 > - nothing provides libjxl.so.0(JXL_0)(64bit) needed by > libaom-3.1.2-1.fc35.x86_64 > Problem: package graphviz-2.49.3-2.fc36.x86_64 requires > libgd.so.3()(64bit), but none of the providers can be installed > - package gd-2.3.3-3.fc36.x86_64 requires libavif.so.12()(64bit), > but > none of the providers can be installed > - package doxygen-2:1.9.1-12.fc36.x86_64 requires graphviz, but > none > of the providers can be installed > - package libavif-0.9.2-2.fc35.x86_64 requires > libaom.so.3()(64bit), > but none of the providers can be installed > - conflicting requests > - nothing provides libjxl.so.0()(64bit) needed by > libaom-3.1.2-1.fc35.x86_64 > - nothing provides libjxl.so.0(JXL_0)(64bit) needed by > libaom-3.1.2-1.fc35.x86_64 libaom is not rebuildable, as it requires the doxygen package for being built. I've requested the new jpegxl build to be untagged from Rawhide [1], and expired the buildroot-overrides for F35 and F34. This needs proper preparation and coordination for the rebuilds. I will take of that in a side-tag as soon as Rawhide is back to a usable state. Björn [1] https://pagure.io/releng/issue/10397 signature.asc Description: This is a digitally signed message part ___ 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: xorg-macros
Am Freitag, dem 19.11.2021 um 06:17 + schrieb Globe Trotter via devel: > Hi, > > oclock has been orphaned from F35 so i was trying to roll my own rpm > (building off the spec file for F34). I noticed that the spec file > contains: > > BuildRequires: pkgconfig(xorg-macros) >= 1.8 > > but I can not find this in the F34 repos. Where do I get this? If I > succeed with rolling a oclock rpm, I would like to submit and maintain > the package. Simply ask dnf: ``` $dnf whatprovides 'pkgconfig(xorg-macros)'; DNSSEC extension: Testing already imported keys for their validity. Last metadata expiration check: 0:28:05 ago on Fri Nov 19 10:08:01 2021. xorg-x11-util-macros-1.19.3-3.fc35.noarch : X.Org X11 Autotools macros Repo: fedora Matched from: Provide: pkgconfig(xorg-macros) = 1.19.3 ``` Björn signature.asc Description: This is a digitally signed message part ___ 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: libnsl.so.2.0.1 updated to libnsl.so.3.0.0 without coordination, broke rawhide
Am Dienstag, dem 16.11.2021 um 15:32 +0100 schrieb Miro Hrončok: > On 13. 11. 21 11:03, Björn 'besser82' Esser wrote: > > Am Freitag, dem 12.11.2021 um 21:33 +0100 schrieb Björn 'besser82' > > Esser: > > > Am Donnerstag, dem 11.11.2021 um 15:54 +0100 schrieb Miro Hrončok: > > > > Hello, > > > > > > > > Since this update: > > > > > > > > https://src.fedoraproject.org/rpms/libnsl2/c/d2e2fab5e3ab07228a34f35ab8ec1954581153d0?branch=rawhide > > > > > > > > Nothing in rawhide builds, because Python and hence dnf is not > > > > installable: > > > > > > > > Error: > > > > Problem 1: package python3-dnf-4.10.0-1.fc36.noarch requires > > > > python3-libdnf, > > > > but none of the providers can be installed > > > > - package python3-dnf-4.10.0-1.fc36.noarch requires python3- > > > > libdnf > > > > > = > > > > 0.65.0, but none of the providers can be installed > > > > - package dnf-4.10.0-1.fc36.noarch requires python3-dnf = > > > > 4.10.0- > > > > 1.fc36, but > > > > none of the providers can be installed > > > > - package python3-libdnf-0.65.0-1.fc36.ppc64le requires > > > > libpython3.10.so.1.0()(64bit), but none of the providers can be > > > > installed > > > > - conflicting requests > > > > - nothing provides libnsl.so.2()(64bit) needed by > > > > python3-libs-3.10.0-3.fc36.ppc64le > > > > - nothing provides libnsl.so.2(LIBNSL_1.0)(64bit) needed by > > > > python3-libs-3.10.0-3.fc36.ppc64le > > > > Problem 2: package python3-dnf-plugins-core-4.0.24- > > > > 1.fc36.noarch > > > > requires > > > > python3-hawkey >= 0.46.1, but none of the providers can be > > > > installed > > > > - package dnf-plugins-core-4.0.24-1.fc36.noarch requires > > > > python3-dnf-plugins-core = 4.0.24-1.fc36, but none of the > > > > providers > > > > can be > > > > installed > > > > - package python3-hawkey-0.65.0-1.fc36.ppc64le requires > > > > libpython3.10.so.1.0()(64bit), but none of the providers can be > > > > installed > > > > - conflicting requests > > > > - nothing provides libnsl.so.2()(64bit) needed by > > > > python3-libs-3.10.0-3.fc36.ppc64le > > > > - nothing provides libnsl.so.2(LIBNSL_1.0)(64bit) needed by > > > > python3-libs-3.10.0-3.fc36.ppc64le > > > > (try to add '--skip-broken' to skip uninstallable packages) > > > > > > > > > > > > Additionally, the following packages (and everything that > > > > depends on > > > > them) will > > > > fail to install: > > > > > > > > $ repoquery -q --repo=rawhide --whatrequires > > > > 'libnsl.so.2()(64bit)' > > > > autofs-1:5.1.8-1.fc36.x86_64 > > > > exim-0:4.95-1.fc36.x86_64 > > > > exim-mon-0:4.95-1.fc36.x86_64 > > > > libnsl2-devel-0:1.3.0-4.fc35.x86_64 > > > > nss_nis-0:3.1-9.fc35.x86_64 > > > > pam-0:1.5.2-6.fc36.x86_64 > > > > postfix-2:3.6.2-6.fc36.x86_64 > > > > python2.7-0:2.7.18-15.fc36.x86_64 > > > > python3-debug-0:3.10.0-2.fc36.x86_64 > > > > python3-libs-0:3.10.0-2.fc36.x86_64 > > > > python3.11-0:3.11.0~a1-1.fc36.x86_64 > > > > python3.6-0:3.6.15-2.fc36.x86_64 > > > > python3.7-0:3.7.12-2.fc36.x86_64 > > > > python3.8-0:3.8.12-2.fc36.x86_64 > > > > python3.9-0:3.9.8-1.fc36.x86_64 > > > > rwall-0:0.17-60.fc35.x86_64 > > > > rwall-server-0:0.17-60.fc35.x86_64 > > > > sendmail-0:8.17.1-2.fc36.x86_64 > > > > slapi-nis-0:0.56.7-2.fc35.x86_64 > > > > tcp_wrappers-0:7.6-98.fc35.x86_64 > > > > tcp_wrappers-libs-0:7.6-98.fc35.x86_64 > > > > yp-tools-0:4.2.3-10.fc35.x86_64 > > > > ypbind-3:2.7.2-5.fc35.x86_64 > > > > ypserv-0:4.2-1.fc36.x86_64 > > > > > > > > I've requested the package to be untagged: > > > > > > > > https://pagure.io/releng/issue/10380 > > > > > > > > This change needs to be coordinated. > > > > > > > > > I can take care to coordinate the rebuilds in a side-tag, if you > > > don't > > > mind. > > > > > > Thanks, > > > Björn > > > > > > All required rebuilds have finished successfully and the side-tag is > > merged with Rawhide. > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-bc52d69ab2 > > Thanks you very much for doing this, Björn, you are awesome! You're welcome! =) signature.asc Description: This is a digitally signed message part ___ 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: libnsl.so.2.0.1 updated to libnsl.so.3.0.0 without coordination, broke rawhide
Am Freitag, dem 12.11.2021 um 21:33 +0100 schrieb Björn 'besser82' Esser: > Am Donnerstag, dem 11.11.2021 um 15:54 +0100 schrieb Miro Hrončok: > > Hello, > > > > Since this update: > > > > https://src.fedoraproject.org/rpms/libnsl2/c/d2e2fab5e3ab07228a34f35ab8ec1954581153d0?branch=rawhide > > > > Nothing in rawhide builds, because Python and hence dnf is not > > installable: > > > > Error: > > Problem 1: package python3-dnf-4.10.0-1.fc36.noarch requires > > python3-libdnf, > > but none of the providers can be installed > > - package python3-dnf-4.10.0-1.fc36.noarch requires python3-libdnf > > > = > > 0.65.0, but none of the providers can be installed > > - package dnf-4.10.0-1.fc36.noarch requires python3-dnf = 4.10.0- > > 1.fc36, but > > none of the providers can be installed > > - package python3-libdnf-0.65.0-1.fc36.ppc64le requires > > libpython3.10.so.1.0()(64bit), but none of the providers can be > > installed > > - conflicting requests > > - nothing provides libnsl.so.2()(64bit) needed by > > python3-libs-3.10.0-3.fc36.ppc64le > > - nothing provides libnsl.so.2(LIBNSL_1.0)(64bit) needed by > > python3-libs-3.10.0-3.fc36.ppc64le > > Problem 2: package python3-dnf-plugins-core-4.0.24-1.fc36.noarch > > requires > > python3-hawkey >= 0.46.1, but none of the providers can be installed > > - package dnf-plugins-core-4.0.24-1.fc36.noarch requires > > python3-dnf-plugins-core = 4.0.24-1.fc36, but none of the providers > > can be > > installed > > - package python3-hawkey-0.65.0-1.fc36.ppc64le requires > > libpython3.10.so.1.0()(64bit), but none of the providers can be > > installed > > - conflicting requests > > - nothing provides libnsl.so.2()(64bit) needed by > > python3-libs-3.10.0-3.fc36.ppc64le > > - nothing provides libnsl.so.2(LIBNSL_1.0)(64bit) needed by > > python3-libs-3.10.0-3.fc36.ppc64le > > (try to add '--skip-broken' to skip uninstallable packages) > > > > > > Additionally, the following packages (and everything that depends on > > them) will > > fail to install: > > > > $ repoquery -q --repo=rawhide --whatrequires 'libnsl.so.2()(64bit)' > > autofs-1:5.1.8-1.fc36.x86_64 > > exim-0:4.95-1.fc36.x86_64 > > exim-mon-0:4.95-1.fc36.x86_64 > > libnsl2-devel-0:1.3.0-4.fc35.x86_64 > > nss_nis-0:3.1-9.fc35.x86_64 > > pam-0:1.5.2-6.fc36.x86_64 > > postfix-2:3.6.2-6.fc36.x86_64 > > python2.7-0:2.7.18-15.fc36.x86_64 > > python3-debug-0:3.10.0-2.fc36.x86_64 > > python3-libs-0:3.10.0-2.fc36.x86_64 > > python3.11-0:3.11.0~a1-1.fc36.x86_64 > > python3.6-0:3.6.15-2.fc36.x86_64 > > python3.7-0:3.7.12-2.fc36.x86_64 > > python3.8-0:3.8.12-2.fc36.x86_64 > > python3.9-0:3.9.8-1.fc36.x86_64 > > rwall-0:0.17-60.fc35.x86_64 > > rwall-server-0:0.17-60.fc35.x86_64 > > sendmail-0:8.17.1-2.fc36.x86_64 > > slapi-nis-0:0.56.7-2.fc35.x86_64 > > tcp_wrappers-0:7.6-98.fc35.x86_64 > > tcp_wrappers-libs-0:7.6-98.fc35.x86_64 > > yp-tools-0:4.2.3-10.fc35.x86_64 > > ypbind-3:2.7.2-5.fc35.x86_64 > > ypserv-0:4.2-1.fc36.x86_64 > > > > I've requested the package to be untagged: > > > > https://pagure.io/releng/issue/10380 > > > > This change needs to be coordinated. > > > I can take care to coordinate the rebuilds in a side-tag, if you don't > mind. > > Thanks, > Björn All required rebuilds have finished successfully and the side-tag is merged with Rawhide. https://bodhi.fedoraproject.org/updates/FEDORA-2021-bc52d69ab2 signature.asc Description: This is a digitally signed message part ___ 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: libnsl.so.2.0.1 updated to libnsl.so.3.0.0 without coordination, broke rawhide
Am Donnerstag, dem 11.11.2021 um 15:54 +0100 schrieb Miro Hrončok: > Hello, > > Since this update: > > https://src.fedoraproject.org/rpms/libnsl2/c/d2e2fab5e3ab07228a34f35ab8ec1954581153d0?branch=rawhide > > Nothing in rawhide builds, because Python and hence dnf is not > installable: > > Error: > Problem 1: package python3-dnf-4.10.0-1.fc36.noarch requires > python3-libdnf, > but none of the providers can be installed > - package python3-dnf-4.10.0-1.fc36.noarch requires python3-libdnf > >= > 0.65.0, but none of the providers can be installed > - package dnf-4.10.0-1.fc36.noarch requires python3-dnf = 4.10.0- > 1.fc36, but > none of the providers can be installed > - package python3-libdnf-0.65.0-1.fc36.ppc64le requires > libpython3.10.so.1.0()(64bit), but none of the providers can be > installed > - conflicting requests > - nothing provides libnsl.so.2()(64bit) needed by > python3-libs-3.10.0-3.fc36.ppc64le > - nothing provides libnsl.so.2(LIBNSL_1.0)(64bit) needed by > python3-libs-3.10.0-3.fc36.ppc64le > Problem 2: package python3-dnf-plugins-core-4.0.24-1.fc36.noarch > requires > python3-hawkey >= 0.46.1, but none of the providers can be installed > - package dnf-plugins-core-4.0.24-1.fc36.noarch requires > python3-dnf-plugins-core = 4.0.24-1.fc36, but none of the providers > can be > installed > - package python3-hawkey-0.65.0-1.fc36.ppc64le requires > libpython3.10.so.1.0()(64bit), but none of the providers can be > installed > - conflicting requests > - nothing provides libnsl.so.2()(64bit) needed by > python3-libs-3.10.0-3.fc36.ppc64le > - nothing provides libnsl.so.2(LIBNSL_1.0)(64bit) needed by > python3-libs-3.10.0-3.fc36.ppc64le > (try to add '--skip-broken' to skip uninstallable packages) > > > Additionally, the following packages (and everything that depends on > them) will > fail to install: > > $ repoquery -q --repo=rawhide --whatrequires 'libnsl.so.2()(64bit)' > autofs-1:5.1.8-1.fc36.x86_64 > exim-0:4.95-1.fc36.x86_64 > exim-mon-0:4.95-1.fc36.x86_64 > libnsl2-devel-0:1.3.0-4.fc35.x86_64 > nss_nis-0:3.1-9.fc35.x86_64 > pam-0:1.5.2-6.fc36.x86_64 > postfix-2:3.6.2-6.fc36.x86_64 > python2.7-0:2.7.18-15.fc36.x86_64 > python3-debug-0:3.10.0-2.fc36.x86_64 > python3-libs-0:3.10.0-2.fc36.x86_64 > python3.11-0:3.11.0~a1-1.fc36.x86_64 > python3.6-0:3.6.15-2.fc36.x86_64 > python3.7-0:3.7.12-2.fc36.x86_64 > python3.8-0:3.8.12-2.fc36.x86_64 > python3.9-0:3.9.8-1.fc36.x86_64 > rwall-0:0.17-60.fc35.x86_64 > rwall-server-0:0.17-60.fc35.x86_64 > sendmail-0:8.17.1-2.fc36.x86_64 > slapi-nis-0:0.56.7-2.fc35.x86_64 > tcp_wrappers-0:7.6-98.fc35.x86_64 > tcp_wrappers-libs-0:7.6-98.fc35.x86_64 > yp-tools-0:4.2.3-10.fc35.x86_64 > ypbind-3:2.7.2-5.fc35.x86_64 > ypserv-0:4.2-1.fc36.x86_64 > > I've requested the package to be untagged: > > https://pagure.io/releng/issue/10380 > > This change needs to be coordinated. I can take care to coordinate the rebuilds in a side-tag, if you don't mind. Thanks, Björn signature.asc Description: This is a digitally signed message part ___ 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: spec file error
Am Donnerstag, dem 11.11.2021 um 09:27 +0100 schrieb Vitaly Zaitsev via
devel:
> On 10/11/2021 21:15, Globe Trotter via devel wrote:
> > Version: %ver
> > Release: %rel
>
> You shouldn't use macroses here, because this behavior can break
> release
> bumps from different bots or proven-packager scripts.
I agree with you, that at least the macro for the package version should
be dropped. For the package release it is permittable to use
`baserelease` as a macro, as that is useable for `rpmdev-bumpspec`:
```
%global baserelease 1
Version: X.Y.Z
Release: %{baserelease}%{?dist}
```
Anyways, macros in the spec file must be defined using the expanded at
definition time `%global`, if there is no reasonable justification to
use the lazy-expanding `%define`.
signature.asc
Description: This is a digitally signed message part
___
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: protobuf 3.19.0 update coming to rawhide
Am Sonntag, dem 07.11.2021 um 16:48 +0900 schrieb Mamoru TASAKA: > Adrian Reber wrote on 2021/11/07 7:25: > > All builds have finished and the side tag was merged. > > > > Although everything was built successful in COPR for the real rebuild > > two rebuilds failed: > > > > * qgis > > This is recently upgraded grass 7.8.6 packaging mistake which causes > qgis to fail to detect grass, and grass modules not built, so %files in > qgis.spec complains about missng files, filed against grass: > > https://bugzilla.redhat.com/show_bug.cgi?id=2020907 That has been fixed and the qgis build [1] should finish soon. Björn [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=78468505 > signature.asc Description: This is a digitally signed message part ___ 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: [SONAME BUMP] jsoncpp 1.9.5
Am Donnerstag, dem 04.11.2021 um 21:40 +0100 schrieb Björn 'besser82' Esser: > Am Donnerstag, dem 04.11.2021 um 08:54 +0100 schrieb Adrian Reber: > > On Wed, Nov 03, 2021 at 08:10:58PM +0100, Björn 'besser82' Esser > > wrote: > > > jsoncpp 1.9.5 has just been released and it bumps its library > > > soname > > > from 24 to 25. The following packages are affected: > > > > > > * cmake > > > * domoticz > > > * guayadeque > > > * libopenshot > > > * minetest > > > * notekit > > > * oomd > > > * openxr > > > * paraview > > > * pcl > > > * polybar > > > * qpid-proton > > > * raceintospace > > > * radiotray-ng > > > * torque > > > * vfrnav > > > * vtk > > > * waybar > > > > > > I'll take care of rebuilding in the `f36-build-side-47369` side- > > > tag > > > for > > > all consumers myself, when updating jsoncpp, as it needs some > > > bootstrapping cycle for cmake. > > > > What is your timeline? Usually it is a week between announcing the > > change > > of a SO name and doing the actual builds. You did not mention when > > you > > are planing to do the rebuilds. Just asking as you have packages in > > your > > rebuild list I also have in my protobuf 3.19.0 rebuild list. > > > > Adrian > > > All build have been finished successfully. The side-tag has been > submitted as an update to Bodhi [1] and should be merged with Rawhide > within the next two hours. > > Björn > > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-f230a6fe6a The side-tag is fully merged with Rawhide now. signature.asc Description: This is a digitally signed message part ___ 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: [SONAME BUMP] jsoncpp 1.9.5
Am Donnerstag, dem 04.11.2021 um 08:54 +0100 schrieb Adrian Reber: > On Wed, Nov 03, 2021 at 08:10:58PM +0100, Björn 'besser82' Esser > wrote: > > jsoncpp 1.9.5 has just been released and it bumps its library soname > > from 24 to 25. The following packages are affected: > > > > * cmake > > * domoticz > > * guayadeque > > * libopenshot > > * minetest > > * notekit > > * oomd > > * openxr > > * paraview > > * pcl > > * polybar > > * qpid-proton > > * raceintospace > > * radiotray-ng > > * torque > > * vfrnav > > * vtk > > * waybar > > > > I'll take care of rebuilding in the `f36-build-side-47369` side-tag > > for > > all consumers myself, when updating jsoncpp, as it needs some > > bootstrapping cycle for cmake. > > What is your timeline? Usually it is a week between announcing the > change > of a SO name and doing the actual builds. You did not mention when you > are planing to do the rebuilds. Just asking as you have packages in > your > rebuild list I also have in my protobuf 3.19.0 rebuild list. > > Adrian All build have been finished successfully. The side-tag has been submitted as an update to Bodhi [1] and should be merged with Rawhide within the next two hours. Björn [1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-f230a6fe6a signature.asc Description: This is a digitally signed message part ___ 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: [SONAME BUMP] jsoncpp 1.9.5
Am Mittwoch, dem 03.11.2021 um 20:10 +0100 schrieb Björn 'besser82' Esser: > Hi, > > jsoncpp 1.9.5 has just been released and it bumps its library soname > from 24 to 25. The following packages are affected: > > * cmake > * domoticz > * guayadeque > * libopenshot > * minetest > * notekit > * oomd > * openxr > * paraview > * pcl > * polybar > * qpid-proton > * raceintospace > * radiotray-ng > * torque > * vfrnav > * vtk > * waybar > > I'll take care of rebuilding in the `f36-build-side-47369` side-tag > for > all consumers myself, when updating jsoncpp, as it needs some > bootstrapping cycle for cmake. I forgot to mention * lgogdownloader The libopenshot package is not part of Fedora, it belongs to a third- party repo actually. signature.asc Description: This is a digitally signed message part ___ 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
[SONAME BUMP] jsoncpp 1.9.5
Hi, jsoncpp 1.9.5 has just been released and it bumps its library soname from 24 to 25. The following packages are affected: * cmake * domoticz * guayadeque * libopenshot * minetest * notekit * oomd * openxr * paraview * pcl * polybar * qpid-proton * raceintospace * radiotray-ng * torque * vfrnav * vtk * waybar I'll take care of rebuilding in the `f36-build-side-47369` side-tag for all consumers myself, when updating jsoncpp, as it needs some bootstrapping cycle for cmake. Thanks, Björn aka besser82 signature.asc Description: This is a digitally signed message part ___ 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: Checking part of package version number in spec file
Am Samstag, dem 30.10.2021 um 23:09 +0200 schrieb Alexander Ploumistos: > Thanks a lot Björn, this is very helpful! You're welcome, Alexander! =) > All the best, > A. Best wishes in return! Björn signature.asc Description: This is a digitally signed message part ___ 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: Checking part of package version number in spec file
Am Samstag, dem 30.10.2021 um 22:00 +0200 schrieb Alexander Ploumistos:
> Hello,
>
> I'm wondering if there's an "elegant" and "rpm" way to do the
> following, without calling an external tool (and maybe adding another
> dependency to a package):
>
> Project "foo" tracks the development of project "bar" and both use
> basic semantic versioning, X.Y.Z. Project "bar" rarely increments the
> patch version and only for internal development purposes. Regular
> releases always carry a patch version of 0, e.g. 16.5.0. Project "foo"
> follows the same major and minor versions as "bar", but they also
> publish releases with incremented patch versions. Any given foo
> release should be built against a bar release with the same major and
> minor versions. Does rpm provide a way to require that part of the
> version string, e.g. for foo-16.5.4:
> Requires: bar >= 16.5
> without hard coding the actual values?
This should solve your problem as described:
```
# These lines go *after* the package version has been set.
# Name: foo
# Version: X.Y.Z
# …
%global ver_major %(echo %{version} | cut -d. -f1)# X
%global ver_minor %(echo %{version} | cut -d. -f2)# Y
%global ver_minor_next %(echo $((%{ver_minor}+1))) # Y+1
# BuildRequires with versioning
BuildRequires: bar-devel >= %{ver_major}.%{ver_minor} # X.Y
BuildRequires: bar-devel < %{ver_major}.%{ver_minor_next} # X.(Y+1)
# Archful runtime Requires with versioning
Requires: bar%{?_isa} >= %{ver_major}.%{ver_minor}
Requires: bar%{?_isa} < %{ver_major}.%{ver_minor_next}
# Archless runtime Requires with versioning, if bar is noarch.
Requires: bar >= %{ver_major}.%{ver_minor}
Requires: bar < %{ver_major}.%{ver_minor_next}
```
This does not take into account if bar has an epoch in its EVR.
Björn
signature.asc
Description: This is a digitally signed message part
___
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
cmake-3.22.0-rc1 hits Rawhide
Hi, I just wanted to inform you, that cmake-3.22.0-rc1 [1] will hit Rawhide within about the next hour. The upstream ChangeLog [2] doesn't show any obvious breaking changes. If problems arise with your packages, feel free to file bugs on RHBZ. Thanks, Björn [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77231340 [2] https://cmake.org/cmake/help/v3.22/release/3.22.html signature.asc Description: This is a digitally signed message part ___ 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: final link failed: memory exhausted on armv7l
Building with lto disabled is a bad idea, as Fedora intentionally enabled lto by default. What you describe as lto requires a lot of memory is caused by building lto along with non-lto in the same object file requires significantly more memory. For that reason one can disable building non-lto along with lto using the `-f-no-fat-lto-objects` compiler flags instead of `-f-fat-lto-objects`, if and *only IF* the package in question does *NOT* ship static libraries. Björn signature.asc Description: This is a digitally signed message part ___ 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: final link failed: memory exhausted on armv7l
Am Mittwoch, dem 13.10.2021 um 16:51 +0200 schrieb Björn 'besser82'
Esser:
> Am Mittwoch, dem 13.10.2021 um 15:44 +0200 schrieb Iñaki Ucar:
> > Hi,
> >
> > RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide
> > [3, 4] with this message (memory exhausted). The same build on the
> > same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going
> > on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to
> > fix this?
> >
> > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159810
> > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170457
> > [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159795
> > [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170370
> > [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159829
>
>
> As the package doesn't build any *distributed* static library, you can
> try to avoid building the linker object files to contain non-lto code:
>
> %global optflags %(echo '%{optflags}' | sed -e 's!-ffat-lto-objects!-
> fno-fat-lto-objects!g')
>
> That should drastically cut the amount of memory the linker needs to
> create the final ELF binary. It doesn't hurt to do that on all arches /
> releases, as it will also result in significantly shorter build time.
>
> Björn
Works as suggested in a scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=77177126
signature.asc
Description: This is a digitally signed message part
___
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: final link failed: memory exhausted on armv7l
Am Mittwoch, dem 13.10.2021 um 15:44 +0200 schrieb Iñaki Ucar:
> Hi,
>
> RStudio is failing consistently on armv7l on F35 [1, 2] and rawhide
> [3, 4] with this message (memory exhausted). The same build on the
> same machine (CPU and RAM) succeeds on F34 [5]. Any clue what's going
> on? Why rawhide and F35 and not F34? Anything I can do in the SPEC to
> fix this?
>
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159810
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170457
> [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159795
> [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=77170370
> [5] https://koji.fedoraproject.org/koji/taskinfo?taskID=77159829
As the package doesn't build any *distributed* static library, you can
try to avoid building the linker object files to contain non-lto code:
%global optflags %(echo '%{optflags}' | sed -e 's!-ffat-lto-objects!-
fno-fat-lto-objects!g')
That should drastically cut the amount of memory the linker needs to
create the final ELF binary. It doesn't hurt to do that on all arches /
releases, as it will also result in significantly shorter build time.
Björn
signature.asc
Description: This is a digitally signed message part
___
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: [RFC] Remove supoort for NIS(+) from PAM
Am Freitag, dem 01.10.2021 um 09:31 -0400 schrieb Stephen John Smoogen: > On Fri, 1 Oct 2021 at 06:14, Björn 'besser82' Esser > wrote: > > > > Hello, > > > > I'm currently doing some experiments with replacing the - upstream > > mostly unmaintained - pam_unix module (authentication with user > > passwd) > > with something using less bloated and cleaner code. This topic is > > currently also discussed with the upstream maintainer of pam_unix. > > > > Replacing parts of a software for the sake of less complexity > > usually > > comes with a cut-down of features; in this particular case it would > > be > > dropping support for NIS(+), which has already been abandoned by its > > initial developer SUN / Oracle for about 10 years [1]. > > > > Before starting some more concrete plans, I'd like to get some > > feedback > > from the Fedora community how they feel about removing NIS(+) > > support in > > PAM. Is it even still actively used anywhere and/or by anyone in > > the > > Fedora universe? > > > > The places I have seen it still being used are in Universities run by > people who learned sysadmin in the 1990's and early 2000's. It is a > light weight system which is simple to set up and tends to be the > goto-stick for a lot of 'we put this together in 1999 with RHL6 and > upgraded ever since' places. > > That said, NIS in most setups causes all kinds of security problems > and audit failures that those areas are probably rapidly going away. > [And the ones I know have been moving to Debian because it keeps > various other technologies we jettisoned long ago.] > > If we drop this from pam_unix, should we look to dropping ypbind and > similar tools? Yes, finally dropping the ypbind, yp-tools, and ypserv packages seems to make sense in this context, as from my understanding they won't be of any practical use anymore. Maybe libnsl, libnsl2, nss_nis, and slapi-nis can be evaluated to be dropped also. Björn signature.asc Description: This is a digitally signed message part ___ 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
[RFC] Remove supoort for NIS(+) from PAM
Hello, I'm currently doing some experiments with replacing the - upstream mostly unmaintained - pam_unix module (authentication with user passwd) with something using less bloated and cleaner code. This topic is currently also discussed with the upstream maintainer of pam_unix. Replacing parts of a software for the sake of less complexity usually comes with a cut-down of features; in this particular case it would be dropping support for NIS(+), which has already been abandoned by its initial developer SUN / Oracle for about 10 years [1]. Before starting some more concrete plans, I'd like to get some feedback from the Fedora community how they feel about removing NIS(+) support in PAM. Is it even still actively used anywhere and/or by anyone in the Fedora universe? Thanks, Björn [1] https://www.oracle.com/solaris/technologies/end-of-feature-notices-solaris11.html signature.asc Description: This is a digitally signed message part ___ 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: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed
Am Donnerstag, dem 19.08.2021 um 15:04 +0200 schrieb Björn 'besser82' Esser: > Am Donnerstag, dem 19.08.2021 um 12:49 +0200 schrieb Björn 'besser82' > Esser: > > Am Donnerstag, dem 19.08.2021 um 12:43 +0200 schrieb Ondrej Mosnacek: > > > On Thu, Aug 19, 2021 at 12:34 PM Björn 'besser82' Esser > > > wrote: > > > > Am Mittwoch, dem 18.08.2021 um 10:45 +0200 schrieb Ondrej > > > > Mosnacek: > > > > > Hello, > > > > > > > > > > I would like to update quazip to version 1.1 in rawhide (i.e. > > > > > future > > > > > F36) [1][2], but since this update will change sonames > > > > > (libquazip.so > > > > > -> libquazip1-qt4.so and libquazip5.so -> libquazip1-qt5.so), I > > > > > will > > > > > need the dependent packages' maintainers (in Bcc) to rebuild > > > > > them in > > > > > a > > > > > side tag (I'm not a provenpackager, so I can't do that myself, > > > > > although Nicolas (@kwizart) offered to help if needed). > > > > > > > > > > Affected packages: > > > > > bletchmame > > > > > ckb-next > > > > > fritzing > > > > > gimagereader > > > > > GLC_lib > > > > > keepassxc > > > > > krita > > > > > nomacs > > > > > qcad > > > > > qmapshack > > > > > texstudio > > > > > > > > > > Even though the library/include/CMake paths changed, there seem > > > > > to > > > > > be > > > > > no breaking API changes and I added compat symlinks/files to the > > > > > -devel packages so that all packages using the old paths will > > > > > still > > > > > build (and link against the new soname) without modification (I > > > > > tested > > > > > this in COPR, see [3]). So a simple release bump + rebuild into > > > > > the > > > > > side tag should be enough. > > > > > > > > > > After the side tag is merged, I will try to gradually submit PRs > > > > > to > > > > > migrate the dependent packages to use the new paths (either via > > > > > pkgconfig or the CMake modules). Once all dependent packages are > > > > > migrated, it will be possible to remove the compat hacks from - > > > > > devel > > > > > packages (though we might want to keep them longer for user > > > > > convenience). > > > > > > > > > > Current plan: > > > > > 1. I request a side tag, merge [2], and build the new quazip in > > > > > the > > > > > side tag. > > > > > 2. I announce the side-tag in this thread and ask for dependent > > > > > packages to be rebuilt in it. > > > > > 3. Once all the packages are successfully built in the side tag, > > > > > I > > > > > get > > > > > the side tag merged. > > > > > > > > > > If there are no objections, I will execute steps 1 and 2 > > > > > sometime > > > > > next > > > > > week (or sooner if I get a positive acknowledgement for all > > > > > packages). > > > > > Maintainers, please let me know if you are ready to do the side- > > > > > tag > > > > > rebuild, or if you'd prefer to defer this a bit (for example due > > > > > to > > > > > a > > > > > conflict with other group rebuild). > > > > > > > > > > Thanks! > > > > > > > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1895170 > > > > > [2] https://src.fedoraproject.org/rpms/quazip/pull-request/2 > > > > > [3] https://copr.fedorainfracloud.org/coprs/omos/quazip/monitor/ > > > > > > > > > > > > As everything seems prepared readily, and there a currently no > > > > conflicting rebuilds going on, I'm going to do a rebuild of all > > > > packages > > > > in sidetag: f36-build-side-44792 > > > > > > > > I'll give short notice, as soon as the sidetag is merged with > > > > rawhide. > > > > > > OK, I was going to kick it off in the evening [CEST], but I'm > > > perfectly fine with you doing it all in one go, since you made sure > > > there are no apparent conflicts. Thank you! > > > > > > You're welcome! > > > > Chain-build is running in sidetag: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=74131380 > > > Sidetag f36-build-side-44792 has been merged with Rawhide: > https://bodhi.fedoraproject.org/updates/FEDORA-2021-cfc992d3e9 > > I'll take care of rebuilding nomacs, as soon as vtk is installable in > Rawhide again. nomacs has been rebuilt successfully on Rawhide. https://bodhi.fedoraproject.org/updates/FEDORA-2021-62a95ee375 So things should be fully finished now. signature.asc Description: This is a digitally signed message part ___ 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: Any recent changes to the arm builders?
Am Mittwoch, dem 18.08.2021 um 16:23 -0400 schrieb Rich Mattes: > On 8/17/21 10:21 AM, Orion Poplawski wrote: > > On 8/14/21 10:19 AM, Kevin Fenzi wrote: > > > On Fri, Aug 13, 2021 at 09:34:11PM -0600, Orion Poplawski wrote: > > > > Have there been any recent changes to the arm (32bit) builders? > > > > It > > > > seems > > > > like I'm having much more issues there with builds likely > > > > running out of > > > > memory or similar. > > > > > > Yes. They were mistakenly running the normal kernel (so they had > > > ~3GB > > > memory available). I moved them back to the lpae kernel (so they > > > see > > > 40GB memory), but this causes > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1920183 > > > > > > basically OOM kills kojid, which restarts kojid, which restarts > > > the > > > build, which kills kojid, etc... > > > > > > I've tried all kinds of things here, but haven't been able to find > > > any > > > way to make it work. Arm folks can't duplicate it on non koji > > > builders. > > > I suspect the number of people using lpae on 32bit arm is... low. > > > We could just go back to non lpae, but that breaks building some > > > other > > > packages (llvm fails to build for example). > > > > > > It makes me wonder if we should consider letting 32bit arm go... > > > (insert pitchforks and torches). > > > > > > Anyhow, if anyone has any ideas, let me know. > > > > > > kevin > > > > Looks like the vtk build just as it was about to finish (after 11+ > > hours > > - had completed extracting debuginfo and was on to checking the > > build > > root last I saw) restarted. This is pretty unworkable. > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=73984672 > > > > I'm waiting on VTK to complete to do a rebuild of PCL. VTK should be fine on Rawhide now. signature.asc Description: This is a digitally signed message part ___ 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: Any recent changes to the arm builders?
Am Donnerstag, dem 19.08.2021 um 07:38 -0600 schrieb Orion Poplawski: > On 8/18/21 2:23 PM, Rich Mattes wrote: > > On 8/17/21 10:21 AM, Orion Poplawski wrote: > > > On 8/14/21 10:19 AM, Kevin Fenzi wrote: > > > > On Fri, Aug 13, 2021 at 09:34:11PM -0600, Orion Poplawski wrote: > > > > > Have there been any recent changes to the arm (32bit) > > > > > builders? It > > > > > seems > > > > > like I'm having much more issues there with builds likely > > > > > running > > > > > out of > > > > > memory or similar. > > > > > > > > Yes. They were mistakenly running the normal kernel (so they had > > > > ~3GB > > > > memory available). I moved them back to the lpae kernel (so they > > > > see > > > > 40GB memory), but this causes > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1920183 > > > > > > > > basically OOM kills kojid, which restarts kojid, which restarts > > > > the > > > > build, which kills kojid, etc... > > > > > > > > I've tried all kinds of things here, but haven't been able to > > > > find any > > > > way to make it work. Arm folks can't duplicate it on non koji > > > > builders. > > > > I suspect the number of people using lpae on 32bit arm is... > > > > low. > > > > We could just go back to non lpae, but that breaks building some > > > > other > > > > packages (llvm fails to build for example). > > > > > > > > It makes me wonder if we should consider letting 32bit arm go... > > > > (insert pitchforks and torches). > > > > > > > > Anyhow, if anyone has any ideas, let me know. > > > > > > > > kevin > > > > > > hours - had completed extracting debuginfo and was on to checking > > > the > > > build root last I saw) restarted. This is pretty unworkable. > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=73984672 > > > > > > > I kicked this off again to see if the ARM builder kernel changes > > help. > > I'm waiting on VTK to complete to do a rebuild of PCL. > > > > Rich > > Well, that build unfortunately failed due to gcc getting killed (the > usual arm OOM symptom). Looks like another try has been started. If > that fails I think I'll need to bump down ncpus yet more (already > dropped from 5 to 3). Looks like this time the build is likely going to pass, as it already reached the "extracting debuginfo" step. =) signature.asc Description: This is a digitally signed message part ___ 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: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed
Am Donnerstag, dem 19.08.2021 um 17:40 +0200 schrieb Dan Horák: > On Thu, 19 Aug 2021 17:25:56 +0200 > Björn 'besser82' Esser wrote: > > > Am Donnerstag, dem 19.08.2021 um 15:03 +0200 schrieb Ondrej > > Mosnacek: > > > On Thu, Aug 19, 2021 at 2:43 PM Björn 'besser82' Esser > > > wrote: > > > > Am Donnerstag, dem 19.08.2021 um 14:14 +0200 schrieb Ondrej > > > > Mosnacek: > > > > > On Thu, Aug 19, 2021 at 1:41 PM Björn 'besser82' Esser > > > > > wrote: > > > > > > Am Donnerstag, dem 19.08.2021 um 12:49 +0200 schrieb Björn > > > > > > 'besser82' > > > > > > Esser: > > > > > > > Am Donnerstag, dem 19.08.2021 um 12:43 +0200 schrieb > > > > > > > Ondrej > > > > > > > Mosnacek: > > > > > > > > On Thu, Aug 19, 2021 at 12:34 PM Björn 'besser82' Esser > > > > > > > > wrote: > > > > > > > > > Am Mittwoch, dem 18.08.2021 um 10:45 +0200 schrieb > > > > > > > > > Ondrej > > > > > > > > > Mosnacek: > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > I would like to update quazip to version 1.1 in > > > > > > > > > > rawhide > > > > > > > > > > (i.e. > > > > > > > > > > future > > > > > > > > > > F36) [1][2], but since this update will change > > > > > > > > > > sonames > > > > > > > > > > (libquazip.so > > > > > > > > > > -> libquazip1-qt4.so and libquazip5.so -> > > > > > > > > > > libquazip1- > > > > > > > > > > qt5.so), I > > > > > > > > > > will > > > > > > > > > > need the dependent packages' maintainers (in Bcc) to > > > > > > > > > > rebuild > > > > > > > > > > them in > > > > > > > > > > a > > > > > > > > > > side tag (I'm not a provenpackager, so I can't do > > > > > > > > > > that > > > > > > > > > > myself, > > > > > > > > > > although Nicolas (@kwizart) offered to help if > > > > > > > > > > needed). > > > > > > > > > > > > > > > > > > > > Affected packages: > > > > > > > > > > bletchmame > > > > > > > > > > ckb-next > > > > > > > > > > fritzing > > > > > > > > > > gimagereader > > > > > > > > > > GLC_lib > > > > > > > > > > keepassxc > > > > > > > > > > krita > > > > > > > > > > nomacs > > > > > > > > > > qcad > > > > > > > > > > qmapshack > > > > > > > > > > texstudio > > > > > > > > > > > > > > > > > > > > Even though the library/include/CMake paths changed, > > > > > > > > > > there > > > > > > > > > > seem > > > > > > > > > > to > > > > > > > > > > be > > > > > > > > > > no breaking API changes and I added compat > > > > > > > > > > symlinks/files > > > > > > > > > > to > > > > > > > > > > the > > > > > > > > > > -devel packages so that all packages using the old > > > > > > > > > > paths > > > > > > > > > > will > > > > > > > > > > still > > > > > > > > > > build (and link against the new soname) without > > > > > > > > > > modification > > > > > > > > > > (I > > > > > > > > > > tested > > > > > > > > > > this in COPR, see [3]). So a simple release bump + > > > > > > > > > > rebuild > > > > > > > > > > into > > > > >
Re: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed
Am Donnerstag, dem 19.08.2021 um 15:03 +0200 schrieb Ondrej Mosnacek: > On Thu, Aug 19, 2021 at 2:43 PM Björn 'besser82' Esser > wrote: > > Am Donnerstag, dem 19.08.2021 um 14:14 +0200 schrieb Ondrej Mosnacek: > > > On Thu, Aug 19, 2021 at 1:41 PM Björn 'besser82' Esser > > > wrote: > > > > Am Donnerstag, dem 19.08.2021 um 12:49 +0200 schrieb Björn > > > > 'besser82' > > > > Esser: > > > > > Am Donnerstag, dem 19.08.2021 um 12:43 +0200 schrieb Ondrej > > > > > Mosnacek: > > > > > > On Thu, Aug 19, 2021 at 12:34 PM Björn 'besser82' Esser > > > > > > wrote: > > > > > > > Am Mittwoch, dem 18.08.2021 um 10:45 +0200 schrieb Ondrej > > > > > > > Mosnacek: > > > > > > > > Hello, > > > > > > > > > > > > > > > > I would like to update quazip to version 1.1 in rawhide > > > > > > > > (i.e. > > > > > > > > future > > > > > > > > F36) [1][2], but since this update will change sonames > > > > > > > > (libquazip.so > > > > > > > > -> libquazip1-qt4.so and libquazip5.so -> libquazip1- > > > > > > > > qt5.so), I > > > > > > > > will > > > > > > > > need the dependent packages' maintainers (in Bcc) to > > > > > > > > rebuild > > > > > > > > them in > > > > > > > > a > > > > > > > > side tag (I'm not a provenpackager, so I can't do that > > > > > > > > myself, > > > > > > > > although Nicolas (@kwizart) offered to help if needed). > > > > > > > > > > > > > > > > Affected packages: > > > > > > > > bletchmame > > > > > > > > ckb-next > > > > > > > > fritzing > > > > > > > > gimagereader > > > > > > > > GLC_lib > > > > > > > > keepassxc > > > > > > > > krita > > > > > > > > nomacs > > > > > > > > qcad > > > > > > > > qmapshack > > > > > > > > texstudio > > > > > > > > > > > > > > > > Even though the library/include/CMake paths changed, there > > > > > > > > seem > > > > > > > > to > > > > > > > > be > > > > > > > > no breaking API changes and I added compat symlinks/files > > > > > > > > to > > > > > > > > the > > > > > > > > -devel packages so that all packages using the old paths > > > > > > > > will > > > > > > > > still > > > > > > > > build (and link against the new soname) without > > > > > > > > modification > > > > > > > > (I > > > > > > > > tested > > > > > > > > this in COPR, see [3]). So a simple release bump + rebuild > > > > > > > > into > > > > > > > > the > > > > > > > > side tag should be enough. > > > > > > > > > > > > > > > > After the side tag is merged, I will try to gradually > > > > > > > > submit > > > > > > > > PRs > > > > > > > > to > > > > > > > > migrate the dependent packages to use the new paths > > > > > > > > (either > > > > > > > > via > > > > > > > > pkgconfig or the CMake modules). Once all dependent > > > > > > > > packages > > > > > > > > are > > > > > > > > migrated, it will be possible to remove the compat hacks > > > > > > > > from - > > > > > > > > devel > > > > > > > > packages (though we might want to keep them longer for > > > > > > > > user > > > > > > > > convenience). > > > > > > > > > > > > > > > > Current plan: > > > > > > > > 1. I request a side tag, merge [2], and build the new > > > > > > >
Re: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed
Am Donnerstag, dem 19.08.2021 um 12:49 +0200 schrieb Björn 'besser82' Esser: > Am Donnerstag, dem 19.08.2021 um 12:43 +0200 schrieb Ondrej Mosnacek: > > On Thu, Aug 19, 2021 at 12:34 PM Björn 'besser82' Esser > > wrote: > > > Am Mittwoch, dem 18.08.2021 um 10:45 +0200 schrieb Ondrej > > > Mosnacek: > > > > Hello, > > > > > > > > I would like to update quazip to version 1.1 in rawhide (i.e. > > > > future > > > > F36) [1][2], but since this update will change sonames > > > > (libquazip.so > > > > -> libquazip1-qt4.so and libquazip5.so -> libquazip1-qt5.so), I > > > > will > > > > need the dependent packages' maintainers (in Bcc) to rebuild > > > > them in > > > > a > > > > side tag (I'm not a provenpackager, so I can't do that myself, > > > > although Nicolas (@kwizart) offered to help if needed). > > > > > > > > Affected packages: > > > > bletchmame > > > > ckb-next > > > > fritzing > > > > gimagereader > > > > GLC_lib > > > > keepassxc > > > > krita > > > > nomacs > > > > qcad > > > > qmapshack > > > > texstudio > > > > > > > > Even though the library/include/CMake paths changed, there seem > > > > to > > > > be > > > > no breaking API changes and I added compat symlinks/files to the > > > > -devel packages so that all packages using the old paths will > > > > still > > > > build (and link against the new soname) without modification (I > > > > tested > > > > this in COPR, see [3]). So a simple release bump + rebuild into > > > > the > > > > side tag should be enough. > > > > > > > > After the side tag is merged, I will try to gradually submit PRs > > > > to > > > > migrate the dependent packages to use the new paths (either via > > > > pkgconfig or the CMake modules). Once all dependent packages are > > > > migrated, it will be possible to remove the compat hacks from - > > > > devel > > > > packages (though we might want to keep them longer for user > > > > convenience). > > > > > > > > Current plan: > > > > 1. I request a side tag, merge [2], and build the new quazip in > > > > the > > > > side tag. > > > > 2. I announce the side-tag in this thread and ask for dependent > > > > packages to be rebuilt in it. > > > > 3. Once all the packages are successfully built in the side tag, > > > > I > > > > get > > > > the side tag merged. > > > > > > > > If there are no objections, I will execute steps 1 and 2 > > > > sometime > > > > next > > > > week (or sooner if I get a positive acknowledgement for all > > > > packages). > > > > Maintainers, please let me know if you are ready to do the side- > > > > tag > > > > rebuild, or if you'd prefer to defer this a bit (for example due > > > > to > > > > a > > > > conflict with other group rebuild). > > > > > > > > Thanks! > > > > > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1895170 > > > > [2] https://src.fedoraproject.org/rpms/quazip/pull-request/2 > > > > [3] https://copr.fedorainfracloud.org/coprs/omos/quazip/monitor/ > > > > > > > > > As everything seems prepared readily, and there a currently no > > > conflicting rebuilds going on, I'm going to do a rebuild of all > > > packages > > > in sidetag: f36-build-side-44792 > > > > > > I'll give short notice, as soon as the sidetag is merged with > > > rawhide. > > > > OK, I was going to kick it off in the evening [CEST], but I'm > > perfectly fine with you doing it all in one go, since you made sure > > there are no apparent conflicts. Thank you! > > > You're welcome! > > Chain-build is running in sidetag: > https://koji.fedoraproject.org/koji/taskinfo?taskID=74131380 Sidetag f36-build-side-44792 has been merged with Rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cfc992d3e9 I'll take care of rebuilding nomacs, as soon as vtk is installable in Rawhide again. Cheers, Björn signature.asc Description: This is a digitally signed message part ___ 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: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed
Am Donnerstag, dem 19.08.2021 um 14:14 +0200 schrieb Ondrej Mosnacek: > On Thu, Aug 19, 2021 at 1:41 PM Björn 'besser82' Esser > wrote: > > Am Donnerstag, dem 19.08.2021 um 12:49 +0200 schrieb Björn > > 'besser82' > > Esser: > > > Am Donnerstag, dem 19.08.2021 um 12:43 +0200 schrieb Ondrej > > > Mosnacek: > > > > On Thu, Aug 19, 2021 at 12:34 PM Björn 'besser82' Esser > > > > wrote: > > > > > Am Mittwoch, dem 18.08.2021 um 10:45 +0200 schrieb Ondrej > > > > > Mosnacek: > > > > > > Hello, > > > > > > > > > > > > I would like to update quazip to version 1.1 in rawhide > > > > > > (i.e. > > > > > > future > > > > > > F36) [1][2], but since this update will change sonames > > > > > > (libquazip.so > > > > > > -> libquazip1-qt4.so and libquazip5.so -> libquazip1- > > > > > > qt5.so), I > > > > > > will > > > > > > need the dependent packages' maintainers (in Bcc) to rebuild > > > > > > them in > > > > > > a > > > > > > side tag (I'm not a provenpackager, so I can't do that > > > > > > myself, > > > > > > although Nicolas (@kwizart) offered to help if needed). > > > > > > > > > > > > Affected packages: > > > > > > bletchmame > > > > > > ckb-next > > > > > > fritzing > > > > > > gimagereader > > > > > > GLC_lib > > > > > > keepassxc > > > > > > krita > > > > > > nomacs > > > > > > qcad > > > > > > qmapshack > > > > > > texstudio > > > > > > > > > > > > Even though the library/include/CMake paths changed, there > > > > > > seem > > > > > > to > > > > > > be > > > > > > no breaking API changes and I added compat symlinks/files to > > > > > > the > > > > > > -devel packages so that all packages using the old paths > > > > > > will > > > > > > still > > > > > > build (and link against the new soname) without modification > > > > > > (I > > > > > > tested > > > > > > this in COPR, see [3]). So a simple release bump + rebuild > > > > > > into > > > > > > the > > > > > > side tag should be enough. > > > > > > > > > > > > After the side tag is merged, I will try to gradually submit > > > > > > PRs > > > > > > to > > > > > > migrate the dependent packages to use the new paths (either > > > > > > via > > > > > > pkgconfig or the CMake modules). Once all dependent packages > > > > > > are > > > > > > migrated, it will be possible to remove the compat hacks > > > > > > from - > > > > > > devel > > > > > > packages (though we might want to keep them longer for user > > > > > > convenience). > > > > > > > > > > > > Current plan: > > > > > > 1. I request a side tag, merge [2], and build the new quazip > > > > > > in > > > > > > the > > > > > > side tag. > > > > > > 2. I announce the side-tag in this thread and ask for > > > > > > dependent > > > > > > packages to be rebuilt in it. > > > > > > 3. Once all the packages are successfully built in the side > > > > > > tag, > > > > > > I > > > > > > get > > > > > > the side tag merged. > > > > > > > > > > > > If there are no objections, I will execute steps 1 and 2 > > > > > > sometime > > > > > > next > > > > > > week (or sooner if I get a positive acknowledgement for all > > > > > > packages). > > > > > > Maintainers, please let me know if you are ready to do the > > > > > > side- > > > > > > tag > > > > > > rebuild, or if you'd prefer to defer this a bit (for example > > > > > > due > > > > > > to > > > > >
Re: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed
Am Donnerstag, dem 19.08.2021 um 12:49 +0200 schrieb Björn 'besser82' Esser: > Am Donnerstag, dem 19.08.2021 um 12:43 +0200 schrieb Ondrej Mosnacek: > > On Thu, Aug 19, 2021 at 12:34 PM Björn 'besser82' Esser > > wrote: > > > Am Mittwoch, dem 18.08.2021 um 10:45 +0200 schrieb Ondrej > > > Mosnacek: > > > > Hello, > > > > > > > > I would like to update quazip to version 1.1 in rawhide (i.e. > > > > future > > > > F36) [1][2], but since this update will change sonames > > > > (libquazip.so > > > > -> libquazip1-qt4.so and libquazip5.so -> libquazip1-qt5.so), I > > > > will > > > > need the dependent packages' maintainers (in Bcc) to rebuild > > > > them in > > > > a > > > > side tag (I'm not a provenpackager, so I can't do that myself, > > > > although Nicolas (@kwizart) offered to help if needed). > > > > > > > > Affected packages: > > > > bletchmame > > > > ckb-next > > > > fritzing > > > > gimagereader > > > > GLC_lib > > > > keepassxc > > > > krita > > > > nomacs > > > > qcad > > > > qmapshack > > > > texstudio > > > > > > > > Even though the library/include/CMake paths changed, there seem > > > > to > > > > be > > > > no breaking API changes and I added compat symlinks/files to the > > > > -devel packages so that all packages using the old paths will > > > > still > > > > build (and link against the new soname) without modification (I > > > > tested > > > > this in COPR, see [3]). So a simple release bump + rebuild into > > > > the > > > > side tag should be enough. > > > > > > > > After the side tag is merged, I will try to gradually submit PRs > > > > to > > > > migrate the dependent packages to use the new paths (either via > > > > pkgconfig or the CMake modules). Once all dependent packages are > > > > migrated, it will be possible to remove the compat hacks from - > > > > devel > > > > packages (though we might want to keep them longer for user > > > > convenience). > > > > > > > > Current plan: > > > > 1. I request a side tag, merge [2], and build the new quazip in > > > > the > > > > side tag. > > > > 2. I announce the side-tag in this thread and ask for dependent > > > > packages to be rebuilt in it. > > > > 3. Once all the packages are successfully built in the side tag, > > > > I > > > > get > > > > the side tag merged. > > > > > > > > If there are no objections, I will execute steps 1 and 2 > > > > sometime > > > > next > > > > week (or sooner if I get a positive acknowledgement for all > > > > packages). > > > > Maintainers, please let me know if you are ready to do the side- > > > > tag > > > > rebuild, or if you'd prefer to defer this a bit (for example due > > > > to > > > > a > > > > conflict with other group rebuild). > > > > > > > > Thanks! > > > > > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1895170 > > > > [2] https://src.fedoraproject.org/rpms/quazip/pull-request/2 > > > > [3] https://copr.fedorainfracloud.org/coprs/omos/quazip/monitor/ > > > > > > > > > As everything seems prepared readily, and there a currently no > > > conflicting rebuilds going on, I'm going to do a rebuild of all > > > packages > > > in sidetag: f36-build-side-44792 > > > > > > I'll give short notice, as soon as the sidetag is merged with > > > rawhide. > > > > OK, I was going to kick it off in the evening [CEST], but I'm > > perfectly fine with you doing it all in one go, since you made sure > > there are no apparent conflicts. Thank you! > > > You're welcome! > > Chain-build is running in sidetag: > https://koji.fedoraproject.org/koji/taskinfo?taskID=74131380 > > Cheers > Björn Things went fine so far, except for nomacs to fails, because vtk is installable on Rawhide currently. Are there any plans to bring this into F35 as well? vtk is installable there, FYI. signature.asc Description: This is a digitally signed message part ___ 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: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed
Am Donnerstag, dem 19.08.2021 um 12:43 +0200 schrieb Ondrej Mosnacek: > On Thu, Aug 19, 2021 at 12:34 PM Björn 'besser82' Esser > wrote: > > Am Mittwoch, dem 18.08.2021 um 10:45 +0200 schrieb Ondrej Mosnacek: > > > Hello, > > > > > > I would like to update quazip to version 1.1 in rawhide (i.e. future > > > F36) [1][2], but since this update will change sonames (libquazip.so > > > -> libquazip1-qt4.so and libquazip5.so -> libquazip1-qt5.so), I will > > > need the dependent packages' maintainers (in Bcc) to rebuild them in > > > a > > > side tag (I'm not a provenpackager, so I can't do that myself, > > > although Nicolas (@kwizart) offered to help if needed). > > > > > > Affected packages: > > > bletchmame > > > ckb-next > > > fritzing > > > gimagereader > > > GLC_lib > > > keepassxc > > > krita > > > nomacs > > > qcad > > > qmapshack > > > texstudio > > > > > > Even though the library/include/CMake paths changed, there seem to > > > be > > > no breaking API changes and I added compat symlinks/files to the > > > -devel packages so that all packages using the old paths will still > > > build (and link against the new soname) without modification (I > > > tested > > > this in COPR, see [3]). So a simple release bump + rebuild into the > > > side tag should be enough. > > > > > > After the side tag is merged, I will try to gradually submit PRs to > > > migrate the dependent packages to use the new paths (either via > > > pkgconfig or the CMake modules). Once all dependent packages are > > > migrated, it will be possible to remove the compat hacks from -devel > > > packages (though we might want to keep them longer for user > > > convenience). > > > > > > Current plan: > > > 1. I request a side tag, merge [2], and build the new quazip in the > > > side tag. > > > 2. I announce the side-tag in this thread and ask for dependent > > > packages to be rebuilt in it. > > > 3. Once all the packages are successfully built in the side tag, I > > > get > > > the side tag merged. > > > > > > If there are no objections, I will execute steps 1 and 2 sometime > > > next > > > week (or sooner if I get a positive acknowledgement for all > > > packages). > > > Maintainers, please let me know if you are ready to do the side-tag > > > rebuild, or if you'd prefer to defer this a bit (for example due to > > > a > > > conflict with other group rebuild). > > > > > > Thanks! > > > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1895170 > > > [2] https://src.fedoraproject.org/rpms/quazip/pull-request/2 > > > [3] https://copr.fedorainfracloud.org/coprs/omos/quazip/monitor/ > > > > > > As everything seems prepared readily, and there a currently no > > conflicting rebuilds going on, I'm going to do a rebuild of all > > packages > > in sidetag: f36-build-side-44792 > > > > I'll give short notice, as soon as the sidetag is merged with rawhide. > > OK, I was going to kick it off in the evening [CEST], but I'm > perfectly fine with you doing it all in one go, since you made sure > there are no apparent conflicts. Thank you! You're welcome! Chain-build is running in sidetag: https://koji.fedoraproject.org/koji/taskinfo?taskID=74131380 Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed
Am Mittwoch, dem 18.08.2021 um 10:45 +0200 schrieb Ondrej Mosnacek: > Hello, > > I would like to update quazip to version 1.1 in rawhide (i.e. future > F36) [1][2], but since this update will change sonames (libquazip.so > -> libquazip1-qt4.so and libquazip5.so -> libquazip1-qt5.so), I will > need the dependent packages' maintainers (in Bcc) to rebuild them in a > side tag (I'm not a provenpackager, so I can't do that myself, > although Nicolas (@kwizart) offered to help if needed). > > Affected packages: > bletchmame > ckb-next > fritzing > gimagereader > GLC_lib > keepassxc > krita > nomacs > qcad > qmapshack > texstudio > > Even though the library/include/CMake paths changed, there seem to be > no breaking API changes and I added compat symlinks/files to the > -devel packages so that all packages using the old paths will still > build (and link against the new soname) without modification (I tested > this in COPR, see [3]). So a simple release bump + rebuild into the > side tag should be enough. > > After the side tag is merged, I will try to gradually submit PRs to > migrate the dependent packages to use the new paths (either via > pkgconfig or the CMake modules). Once all dependent packages are > migrated, it will be possible to remove the compat hacks from -devel > packages (though we might want to keep them longer for user > convenience). > > Current plan: > 1. I request a side tag, merge [2], and build the new quazip in the > side tag. > 2. I announce the side-tag in this thread and ask for dependent > packages to be rebuilt in it. > 3. Once all the packages are successfully built in the side tag, I get > the side tag merged. > > If there are no objections, I will execute steps 1 and 2 sometime next > week (or sooner if I get a positive acknowledgement for all packages). > Maintainers, please let me know if you are ready to do the side-tag > rebuild, or if you'd prefer to defer this a bit (for example due to a > conflict with other group rebuild). > > Thanks! > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1895170 > [2] https://src.fedoraproject.org/rpms/quazip/pull-request/2 > [3] https://copr.fedorainfracloud.org/coprs/omos/quazip/monitor/ As everything seems prepared readily, and there a currently no conflicting rebuilds going on, I'm going to do a rebuild of all packages in sidetag: f36-build-side-44792 I'll give short notice, as soon as the sidetag is merged with rawhide. signature.asc Description: This is a digitally signed message part ___ 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: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed
Am Mittwoch, dem 18.08.2021 um 10:45 +0200 schrieb Ondrej Mosnacek: > Hello, > > I would like to update quazip to version 1.1 in rawhide (i.e. future > F36) [1][2], but since this update will change sonames (libquazip.so > -> libquazip1-qt4.so and libquazip5.so -> libquazip1-qt5.so), I will > need the dependent packages' maintainers (in Bcc) to rebuild them in a > side tag (I'm not a provenpackager, so I can't do that myself, > although Nicolas (@kwizart) offered to help if needed). > > Affected packages: > bletchmame > ckb-next > fritzing > gimagereader > GLC_lib > keepassxc > krita > nomacs > qcad > qmapshack > texstudio I've just checked, whether there are builds of these packages are going on in another sidetag, and it turns none of the packages currently has any builds, that are not tagged for Rawhide / F36 currently. If you want to, you can open a sidetag and build the new version of quazip inside; give me a short note, and I'll take care of rebuilding all the listed consumers, so things can settle within the same day. Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed
Am Mittwoch, dem 18.08.2021 um 18:59 + schrieb Artur Frenszek- Iwicki: > I'm okay with this, but I don't think I've ever used side tags before > (maybe once), > so I could use a quick run-down on how to actually perform that. It's quite easy. From the dist-git branch that is going to be build: `fedpkg build [--nowait] --target=fXX-build-side-Y` Where XX is the release number of Fedora and Y is the number of the sidetag, in which you want the build to perform. signature.asc Description: This is a digitally signed message part ___ 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: Wrong FTBFS in F35?
Am Dienstag, dem 17.08.2021 um 09:15 -0700 schrieb Tom Stellard: > On 8/17/21 8:42 AM, Nicolas Chauvet wrote: > > Le mar. 17 août 2021 à 17:21, Евгений Пивнев a > > écrit : > > > > > > As I found my package qpdfview cannot be build in F35. > > > Package marked as FTBFS: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1987904 > > > > > > Koji build says: > > > > > > DEBUG util.py:444: Error: > > > DEBUG util.py:444: Problem: package qt5-qttools-devel-5.15.2- > > > 6.fc35.x86_64 requires qt5-doctools = 5.15.2-6.fc35, but none of > > > the providers can be installed > > > DEBUG util.py:444: - conflicting requests > > > DEBUG util.py:444: - nothing provides libclang.so.12()(64bit) > > > needed by qt5-doctools-5.15.2-6.fc35.x86_64 > > > DEBUG util.py:444: - nothing provides > > > libclang.so.12(LLVM_12)(64bit) needed by qt5-doctools-5.15.2- > > > 6.fc35.x86_64 > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=74013269 > > > > > > What to do? > > > > I've experienced the same issue with my build (onednn) on f35 (only, > > not rawhide). It was related to an indirect dependency on clang > > (needed by doxygen). > > Seems like the clang12 compatibility package isn't in the buildroot > > yet. > > I've used fedpkg build --target f35-build-side-43964 > > > > Now I wonder if doxygen (and many other packages) shouldn't be > > rebuilt > > for clang-13 instead. > > I'm especially worried that some packages will be rebuilt with > > clang/llvm 13 and others kept as 12. There might be symbol > > versioning > > with clang/llvm ?... but still it's annoying as a dependency mix... > > > > So what's the plan ? > > > > I think there was an issue with how the side-tag was merged, I'm > looking into this. A simple rebuild of doxygen did the trick here. F35 buildroot should be fine for most packages again. signature.asc Description: This is a digitally signed message part ___ 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] evolution-data-server soname version bump in rawhide
Am Freitag, dem 13.08.2021 um 12:44 +0200 schrieb Milan Crha: > On Thu, 2021-08-05 at 16:05 +0200, Björn 'besser82' Esser wrote: > > Just give me short heads up, and I'll rebuild pidgin-chime using my > > proven-packager powers. > > Hi, > thanks for the offer. There are two side tags, due to the f35 > branching: > > f35-build-side-44568 > f36-build-side-44566 > > Both evolution-data-server and evolution are already built there, thus > you can run the build of the pidgin-chime whenever you find time. > Thanks again and bye, > Milan You're welcome! Both builds are finished already. [1,2] Cheers Björn [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1818189 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1818235 signature.asc Description: This is a digitally signed message part ___ 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] evolution-data-server soname version bump in rawhide
Am Donnerstag, dem 05.08.2021 um 16:05 +0200 schrieb Björn 'besser82' Esser: > Am Donnerstag, dem 05.08.2021 um 11:14 +0200 schrieb Milan Crha: > > Hi, > > the upcoming 3.41.2 release of the evolution-data-server next week > > will > > contain a soname version bump of a libcamel library due to ABI > > changes. > > A simple rebuild should be enough for the other packages. > > > > According to `dnf repoquery --whatrequires libcamel-1.2.so* --alldeps` > > there are these affected packages: > > > > evolution-0:3.41.1-2.fc35.x86_64 > > evolution-bogofilter-0:3.41.1-2.fc35.x86_64 > > evolution-chime-0:1.3-11.fc35.x86_64 > > evolution-data-server-devel-0:3.41.1-2.fc35.i686 > > evolution-data-server-devel-0:3.41.1-2.fc35.x86_64 > > evolution-ews-0:3.41.1-2.fc35.x86_64 > > evolution-mapi-0:3.41.1-3.fc35.x86_64 > > evolution-pst-0:3.41.1-2.fc35.x86_64 > > evolution-rspam-0:0.6.0-33.fc35.x86_64 > > evolution-rss-1:0.3.96-7.fc35.x86_64 > > evolution-spamassassin-0:3.41.1-2.fc35.x86_64 > > > > I have commit rights for all but the evolution-chime, which comes from > > pidgin-chime package. > > > > I'll create a side tag once the upstream release is done and I'll > > build > > the packages there. Then I'll send it to this thread. I'd appreciate a > > help with the pidgin-chime rebuild, to be able to merge the side tag > > soon. > > Bye, > > Milan > > > Just give me short heads up, and I'll rebuild pidgin-chime using my > proven-packager powers. > > Cheers, > Björn I've successfully rebuilt the pidgin-chime package into your evolution- data-server sidetags for Rawhide and F35. [1,2] So you can merge them, after you've finished your builds. Cheers Björn [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1818189 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1818235 signature.asc Description: This is a digitally signed message part ___ 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: libgps soname bump (gpsd-3.23)
Am Donnerstag, dem 12.08.2021 um 07:57 +0200 schrieb Miroslav Lichvar: > On Wed, Aug 11, 2021 at 08:27:27PM +0200, Björn 'besser82' Esser wrote: > > All packages have been rebuilt successfully, except for vfrnav, which > > fails for a segfault in inkscape during the testsuite. > > > > Both sidetags can be merged now, as vfrnav hasn't been built > > successfully for a longer period of time, including the recent mass- > > rebuild for fc35. > > I've submitted updates for both sidetags. > > Thanks! You're welcome! Anyways, I've manage to get vfrnav successfully building again, and issued builds for F35 and Rawhide [1,2], as well as rebuilds into the octave 6.3 sidetags [3,4]. Cheers Björn [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1817716 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1817717 [3] https://koji.fedoraproject.org/koji/buildinfo?buildID=1817720 [4] https://koji.fedoraproject.org/koji/buildinfo?buildID=1817721 signature.asc Description: This is a digitally signed message part ___ 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: libgps soname bump (gpsd-3.23)
Am Mittwoch, dem 11.08.2021 um 18:06 +0200 schrieb Björn 'besser82' Esser: > Am Mittwoch, dem 11.08.2021 um 17:20 +0200 schrieb Miroslav Lichvar: > > libgps provided by the gpsd package had another API and ABI break. > > The > > following packages need to be rebuilt: > > > > collectd > > direwolf > > foxtrotgps > > marble > > plasma-workspace > > vfrnav > > viking > > > > I tried to rebuild them locally and it seems only direwolf needs a > > patch. It's here: > > https://fedorapeople.org/~mlichvar/tmp/gpsd/direwolf-gpsapi12.patch > > > > The new gpsd package is built in a rawhide and f35 sidetag. > > Please build your packages with: > > > > fedpkg build --target=f36-build-side-44504 > > fedpkg build --target=f35-build-side-44506 > > > > If a proven packager is willing to take care all of the packages, > > please let us know. > > > I'll take care of the rebuilds as a proven packager. > > Cheers > Björn All packages have been rebuilt successfully, except for vfrnav, which fails for a segfault in inkscape during the testsuite. Both sidetags can be merged now, as vfrnav hasn't been built successfully for a longer period of time, including the recent mass- rebuild for fc35. Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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: libgps soname bump (gpsd-3.23)
Am Mittwoch, dem 11.08.2021 um 17:20 +0200 schrieb Miroslav Lichvar: > libgps provided by the gpsd package had another API and ABI break. The > following packages need to be rebuilt: > > collectd > direwolf > foxtrotgps > marble > plasma-workspace > vfrnav > viking > > I tried to rebuild them locally and it seems only direwolf needs a > patch. It's here: > https://fedorapeople.org/~mlichvar/tmp/gpsd/direwolf-gpsapi12.patch > > The new gpsd package is built in a rawhide and f35 sidetag. > Please build your packages with: > > fedpkg build --target=f36-build-side-44504 > fedpkg build --target=f35-build-side-44506 > > If a proven packager is willing to take care all of the packages, > please let us know. I'll take care of the rebuilds as a proven packager. Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze
Am Donnerstag, dem 05.08.2021 um 13:39 -0400 schrieb Yaakov Selkowitz: > On Thu, 2021-08-05 at 18:39 +0200, Björn 'besser82' Esser wrote: > > Am Donnerstag, dem 05.08.2021 um 17:41 +0200 schrieb Milan Crha: > > > On Thu, 2021-08-05 at 14:00 +0200, Miro Hrončok wrote: > > > > libpst > > > > > > Hi, > > > I do not own the package, only one from my pool depends on it, but > > > looking into the build failure, the autoconf failed to find python > > > binary. Digging deeper, in the autoconf-archive-2021.02.19-2.fc35, > > > the > > > ax_python.m4 still references only up to version 3.9 (and there's > > > no > > > `python` binary during the libpst build, because not installing > > > also > > > python-unversioned-command). Note the libpst does run autoreconf. > > > Maybe > > > more packages using autoconf are affected by this. > > > > > > Should anyone update the autoconf-archive and then rebuild the > > > affected > > > packages? I cannot do it myself, I do not have enough powers. > > > Thanks and bye, > > > Milan > > > > I've added a patch to autoconf-archive for Python 3.10. Build for > > Rawhide is running: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=73342788 > > Another fix is needed for AX_PYTHON_DEVEL, already filed upstream: > > https://github.com/autoconf-archive/autoconf-archive/pull/235 I've updated the patch in the autoconf-archive package with your patch. Thanks! signature.asc Description: This is a digitally signed message part ___ 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: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze
Am Donnerstag, dem 05.08.2021 um 17:41 +0200 schrieb Milan Crha: > On Thu, 2021-08-05 at 14:00 +0200, Miro Hrončok wrote: > > libpst > > Hi, > I do not own the package, only one from my pool depends on it, but > looking into the build failure, the autoconf failed to find python > binary. Digging deeper, in the autoconf-archive-2021.02.19-2.fc35, the > ax_python.m4 still references only up to version 3.9 (and there's no > `python` binary during the libpst build, because not installing also > python-unversioned-command). Note the libpst does run autoreconf. Maybe > more packages using autoconf are affected by this. > > Should anyone update the autoconf-archive and then rebuild the affected > packages? I cannot do it myself, I do not have enough powers. > Thanks and bye, > Milan I've added a patch to autoconf-archive for Python 3.10. Build for Rawhide is running: https://koji.fedoraproject.org/koji/taskinfo?taskID=73342788 Cheers, Björn signature.asc Description: This is a digitally signed message part ___ 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] evolution-data-server soname version bump in rawhide
Am Donnerstag, dem 05.08.2021 um 11:14 +0200 schrieb Milan Crha: > Hi, > the upcoming 3.41.2 release of the evolution-data-server next week > will > contain a soname version bump of a libcamel library due to ABI > changes. > A simple rebuild should be enough for the other packages. > > According to `dnf repoquery --whatrequires libcamel-1.2.so* --alldeps` > there are these affected packages: > > evolution-0:3.41.1-2.fc35.x86_64 > evolution-bogofilter-0:3.41.1-2.fc35.x86_64 > evolution-chime-0:1.3-11.fc35.x86_64 > evolution-data-server-devel-0:3.41.1-2.fc35.i686 > evolution-data-server-devel-0:3.41.1-2.fc35.x86_64 > evolution-ews-0:3.41.1-2.fc35.x86_64 > evolution-mapi-0:3.41.1-3.fc35.x86_64 > evolution-pst-0:3.41.1-2.fc35.x86_64 > evolution-rspam-0:0.6.0-33.fc35.x86_64 > evolution-rss-1:0.3.96-7.fc35.x86_64 > evolution-spamassassin-0:3.41.1-2.fc35.x86_64 > > I have commit rights for all but the evolution-chime, which comes from > pidgin-chime package. > > I'll create a side tag once the upstream release is done and I'll > build > the packages there. Then I'll send it to this thread. I'd appreciate a > help with the pidgin-chime rebuild, to be able to merge the side tag > soon. > Bye, > Milan Just give me short heads up, and I'll rebuild pidgin-chime using my proven-packager powers. Cheers, Björn signature.asc Description: This is a digitally signed message part ___ 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: F35 mass rebuild is finished
Am Dienstag, dem 27.07.2021 um 16:23 +0200 schrieb Tomas Hrcka: > Hi all, > > Per the Fedora 35 schedule[1] we started a mass rebuild for Fedora 35 > on Jul 21st, 2021. We did a mass rebuild for Fedora 35 for: > > https://fedoraproject.org/wiki/Changes/LTOBuildImprovements This change hasn't been implemented as well. signature.asc Description: This is a digitally signed message part ___ 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: Is there a command to expand Source0 from spec file to the final URL?
Am Dienstag, dem 06.07.2021 um 17:15 +0100 schrieb Richard W.M. Jones:
>
> Is this possible? I've got one with lots of %{macros} in it.
>
> It seems like this should be possible using rpmspec, but I can't work
> out how.
>
> Rich.
You can either use `spectool -l rpm.spec` to get the URL ('SourceX:[
\t]*' prepended) printed to stdout with the macros expanded, or if you
want to download the files to $PWD you can use `spectool -g rpm.spec`.
`spectool -h` will give you information about more usage options.
Cheers,
Björn
signature.asc
Description: This is a digitally signed message part
___
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
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. signature.asc Description: This is a digitally signed message part ___ 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
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. signature.asc Description: This is a digitally signed message part ___ 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
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. Cheers, Björn signature.asc Description: This is a digitally signed message part ___ 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: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
Am Dienstag, dem 08.06.2021 um 15:08 +0100 schrieb Tom Hughes via devel: > On 08/06/2021 14:51, Stephen Gallagher wrote: > > > I was thinking about suggesting a similar PAM module to convert > > existing hashes, but I suspect that we'd be coming up against some > > issues with security policy and separation of actions. Right now, I > > expect that SELinux permits PAM processes to have read-only access > > to > > /etc/shadow, but such a change would necessitate read/write access, > > which is riskier. It's also why PAM has separate activities for > > authentication, authorization and password-change. > > Surely it has to allow write as well because any authentication can > already prompt for a password change if the password is expired? Well, extending the pam_unix module in such a way, may be the best solution: * User logs in. * PAM checks password * hash is not $y$ * silently rehash plain password with yescrypt * update shadow ___ 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: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
Am Dienstag, dem 08.06.2021 um 09:22 -0500 schrieb Martin Jackson: > > On 6/8/21 9:13 AM, Ewoud Kohl van Wijngaarden wrote: > > On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser > > wrote: > > > Unfortunately there is no automatic way to update the hash from > > > anything, but yescrypt, to yescrypt without knowing / entering the > > > actual user password; in the future existing yescrypt hashes can be > > > updated to new yescrypt hashes with stronger salts and/or cost > > > parameters in-place without changing the password, and without user > > > interaction. > > > > > > Has anyone some better idea? > > > > they use older distros that don't support it, it'll end up flapping > > where one system sets it to the older hashing and one to the newer. > > > > Or maybe I'm just the only person who does this. > > Indeed you are not the only one. Even in large LDAP shops, there > could > be a local "break-glass" account, so managing hashes could still be a > factor in those environments. > > One of the pain points of managing a large-scale Puppet infrastructure > is supporting different hashes for different OS's. I've seen this > done, > and the result is...not always pretty. > > What does usage of yescrypt look like in the rest of the ecosystem? > Are > other major distros moving to it, or likely to? Debian is moving to yescrypt; ALT Linux and Kali Linux have already switched. Most other distributions, that ship libxcrypt >= 4.3 have support for yescrypt and are able to deal with $y$ shadow hashes out of the box; they simply just lack the adaption of the tools (shadow-utils, pam, etc.) to use it as hash method for *creating* shadow hashes. ___ 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: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
Am Di., 8. Juni 2021 um 15:46 Uhr schrieb Zbigniew Jędrzejewski-Szmek : > > On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote: > > Am Di., 8. Juni 2021 um 14:35 Uhr schrieb Richard W.M. Jones > > : > > > > > > On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote: > > > > == Dependencies == > > > > * anaconda: https://github.com/rhinstaller/anaconda/pull/3431 > > > > * authselect: https://github.com/authselect/authselect/pull/253 > > > > * libuser: WIP ongoing > > > > * shadow-utils: > > > > https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10 > > > > > > > > * pam: Is already capable to use yescrypt. > > > > * libxcrypt: Is already capable for computing yescrypt hashes. > > > > > > libguestfs (virt-customize etc.) might also need changing. What > > > happens if a new user account is created with (eg) $6$ sha512. Does > > > it use that scheme forever? Attempt to upgrade it? Break? > > > > Well, yes, that needs to be updated, too, but it's written in OCAML… > > I suppose, you want to volunteer, and get a well deserved F35 change > > badge for doing so?! :P > > > > If a user account is created with a sha512crypt hash, it will keep it > > as long as the password remains unchanged. I'm currently thinking of > > a way to migrate all local users to use yescrypt hashes, but it's not > > that easy: Human users could be prompted on first login to change > > their password, if the hash in shadow is not yescrypt - there is a way > > to force that. But what about local users with older password hashes > > that get logged in by any non-human interaction, like www-cron; those > > would need to be updated manually by the system admin. Maybe I can > > write a CLI-tool for doing so. > > > > Unfortunately there is no automatic way to update the hash from > > anything, but yescrypt, to yescrypt without knowing / entering the > > actual user password; > > I think it's better to leave existing passwords in place. You can't > really force people to log in as all users, so the only realistic > scenario is to keep existing passwords if there's more than one user. > > And I don't think there's a reason to try to force immediate password > switch. As far as we know, previous defaults like sha256 are OK. > > > in the future existing yescrypt hashes can be > > updated to new yescrypt hashes with stronger salts and/or cost > > parameters in-place without changing the password, and without user > > interaction. > > Interesting. How does this work? You can find a basic description here: https://www.sjoerdlangkemper.nl/2018/01/31/client-independent-upgrade-in-hash-functions/ ___ 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: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
Am Di., 8. Juni 2021 um 14:35 Uhr schrieb Richard W.M. Jones : > > On Mon, Jun 07, 2021 at 02:59:54PM -0400, Ben Cotton wrote: > > == Dependencies == > > * anaconda: https://github.com/rhinstaller/anaconda/pull/3431 > > * authselect: https://github.com/authselect/authselect/pull/253 > > * libuser: WIP ongoing > > * shadow-utils: > > https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10 > > > > * pam: Is already capable to use yescrypt. > > * libxcrypt: Is already capable for computing yescrypt hashes. > > libguestfs (virt-customize etc.) might also need changing. What > happens if a new user account is created with (eg) $6$ sha512. Does > it use that scheme forever? Attempt to upgrade it? Break? Well, yes, that needs to be updated, too, but it's written in OCAML… I suppose, you want to volunteer, and get a well deserved F35 change badge for doing so?! :P If a user account is created with a sha512crypt hash, it will keep it as long as the password remains unchanged. I'm currently thinking of a way to migrate all local users to use yescrypt hashes, but it's not that easy: Human users could be prompted on first login to change their password, if the hash in shadow is not yescrypt - there is a way to force that. But what about local users with older password hashes that get logged in by any non-human interaction, like www-cron; those would need to be updated manually by the system admin. Maybe I can write a CLI-tool for doing so. Unfortunately there is no automatic way to update the hash from anything, but yescrypt, to yescrypt without knowing / entering the actual user password; in the future existing yescrypt hashes can be updated to new yescrypt hashes with stronger salts and/or cost parameters in-place without changing the password, and without user interaction. Has anyone some better idea? Björn ___ 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: client.cpp:104:47: error: '_1' was not declared in this scope
Am Dienstag, den 23.06.2020, 12:41 + schrieb Martin Gansser: > Sorry, can't access your posted links. > Regards > Martin A solution for this problem was posted in one of the links by Jonathan Wakely: > I believe in most cases this can be fixed by changing > to and adding "using boost::placeholders::_1;" > somewhere. signature.asc Description: This is a digitally signed message part ___ 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
Re: libgps soname bump (gpsd-3.20)
Am Donnerstag, den 18.06.2020, 16:34 +0200 schrieb Miroslav Lichvar: > A new version of gpsd is ready to be build in rawhide. This is a > second attempt. It now bumps the libgps soname. Per repoquery the > following packages have a dependency on libgps and will need a > rebuild: > > collectd > direwolf > foxtrotgps > marble > plasma-workspace > qlandkartegt > vfrnav > viking > > Some packages already carry a patch for the new libgps API. Some will > need to be fixed. I've uploaded the patches here: > > https://mlichvar.fedorapeople.org/tmp/gpsd > > vfrnav doesn't build for me due to a C++ issue, so I'm not sure if the > gps fix is complete. > > If a proven packager could add/merge the patches and rebuild all > the packages, please me know. Otherwise, I'll rebuild gpsd sometimes > next week and let the maintainers fix their packages. I've built gpsd-3.20-1, and rebuilt all listed packages. The contents of the side-tag has been filed as an update [1]. The following packages are FTBFS, but not related to the gpsd update: * plasma-workspace - missing dependencies * vfrnav - looks like some problems with recent Boost I leave it up to the corresponding maintainers to fix them. Cheers Björn [1] https://bodhi.fedoraproject.org/updates/FEDORA-2020-bc46691249 signature.asc Description: This is a digitally signed message part ___ 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
Re: libgps soname bump (gpsd-3.20)
Am Donnerstag, den 18.06.2020, 16:34 +0200 schrieb Miroslav Lichvar: > A new version of gpsd is ready to be build in rawhide. This is a > second attempt. It now bumps the libgps soname. Per repoquery the > following packages have a dependency on libgps and will need a > rebuild: > > collectd > direwolf > foxtrotgps > marble > plasma-workspace > qlandkartegt > vfrnav > viking > > Some packages already carry a patch for the new libgps API. Some will > need to be fixed. I've uploaded the patches here: > > https://mlichvar.fedorapeople.org/tmp/gpsd > > vfrnav doesn't build for me due to a C++ issue, so I'm not sure if the > gps fix is complete. > > If a proven packager could add/merge the patches and rebuild all > the packages, please me know. Otherwise, I'll rebuild gpsd sometimes > next week and let the maintainers fix their packages. Hi, I can do the rebuilds during later today or tomorrow in the morning (CEST). Please push your changes to the gpsd package, do not build yet. I'll do the build and any neccessary rebuilds in a side-tag and will push an update after everything has finished. Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: Soname bump gloox libgloox.so.13 -> 17
Am Sonntag, den 31.05.2020, 11:49 +0200 schrieb Björn 'besser82' Esser: > Am Sonntag, den 31.05.2020, 11:29 +0200 schrieb David Schwörer: > > If a proven packager could rebuild 0ad and uwsgi and submit an > > update, > > that would be great. > > Done so. Waiting for the builds to finish. Updates will be pushed > asap then. Updates have been submitted. * fRH: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ad6b1fe937 * f32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-167b67cb12 * f31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b068f5ebc9 Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: Soname bump gloox libgloox.so.13 -> 17
Am Sonntag, den 31.05.2020, 11:29 +0200 schrieb David Schwörer: > If a proven packager could rebuild 0ad and uwsgi and submit an update, > that would be great. Done so. Waiting for the builds to finish. Updates will be pushed asap then. Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: [SO-NAME-BUMP] jsoncpp.so.22 -> 24
Am Samstag, den 30.05.2020, 18:36 +0200 schrieb Björn 'besser82' Esser: > The rebuilds have been finished successfully so far, except: > > * domoticz [1], and > * polybar [2], > > which I have filed FTBFS bugs [1,2] for. I've fixed those FTBFS in the mean time, as they were easy fixes to be applied. Cheers Björn aka besser82 > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1842068 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1842069 signature.asc Description: This is a digitally signed message part ___ 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
Re: Packaging problem
Am Samstag, den 30.05.2020, 21:20 +0200 schrieb
ycollette.nos...@free.fr:
> Hello,
>
> I've got a problem with a package.
> I am trying to clean up a spec file before sending it to review and
> I've got an error:
>
> erreur : Empty %files file /home/artelys/rpmbuild/BUILD/jamulus-
> c6b6e3ab02d7ec1e93edeeb8042a89a561924826/debugsourcefiles.list
>
> The code is Qt-5 / c++. It's an application which allows to perform
> live rehearsale via an internet connection.
>
> On the gcc / c++ command line, I can see the -g flags.
>
> The build section:
>
> %{set_build_flags}
>
> %_qt5_qmake Jamulus.pro CONFIG+=opus_shared_lib
>
> %make_build VERBOSE=1
>
> The install section (the qmake file defines no install rule so I must
> install everything manually):
>
> %__install -m 755 -d %{buildroot}/%{_bindir}/
> %__install -m 755 Jamulus %{buildroot}%{_bindir}/jamulus
>
> %__install -m 755 -d %{buildroot}/%{_datadir}/applications/
> %__install -m 644 distributions/jamulus.desktop
> %{buildroot}%{_datadir}/applications/
>
> %__install -m 755 -d %{buildroot}/%{_datadir}/pixmaps/
> %__install -m 644 distributions/jamulus.png
> %{buildroot}%{_datadir}/pixmaps/
>
> How can I build the debug part of the package ?
>
> The only solution I've found is to add:
>
> %global debug_package %{nil}
>
> At the beginning of the spec file ...
Without a scratch build and/or a link to the spec file / srpm its hard
to help, I guess…
Cheers
Björn
signature.asc
Description: This is a digitally signed message part
___
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
Re: [SO-NAME-BUMP] jsoncpp.so.22 -> 24
Am Samstag, den 30.05.2020, 12:13 +0200 schrieb Björn 'besser82' Esser: > Hello, > > I'm going to update jsoncpp to v1.9.3 in Rawhide, which implies a so- > name bump from jsoncpp.so.22 to jsoncpp.so.24, during today. > > I will take care of rebuilding all its consumers, which are: > > * cmake > * domoticz > * guayadeque > * libjson-rpc-cpp > * minetest > * oomd > * orthanc > * paraview > * passenger > * polybar > * qpid-proton > * raceintospace > * radiotray-ng > * vfrnav > * vrpn > * vtk > * waybar The rebuilds have been finished successfully so far, except: * domoticz [1], and * polybar [2], which I have filed FTBFS bugs [1,2] for. The following packages are still building by the time of this writing, but are likely to finish successfully some time during tonight: * paraview, and * vtk Cheers Björn aka besser82 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1842068 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1842069 signature.asc Description: This is a digitally signed message part ___ 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
[SO-NAME-BUMP] jsoncpp.so.22 -> 24
Hello, I'm going to update jsoncpp to v1.9.3 in Rawhide, which implies a so- name bump from jsoncpp.so.22 to jsoncpp.so.24, during today. I will take care of rebuilding all its consumers, which are: * cmake * domoticz * guayadeque * libjson-rpc-cpp * minetest * oomd * orthanc * paraview * passenger * polybar * qpid-proton * raceintospace * radiotray-ng * vfrnav * vrpn * vtk * waybar Cheers Björn aka besser82 signature.asc Description: This is a digitally signed message part ___ 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
Re: Packages still using %{?_smp_mflags} manually?
Am Donnerstag, den 21.05.2020, 17:53 +0200 schrieb Igor Raits:
> > In the spec file of another one that I've inherited, I see "make V=1
> > %{?_smp_mflags}".
>
> %make_build V=1
Not even neccessary since `V=1` already gets injected by the
`%make_build` macro at least since F32:
$ rpm -E %make_build
/usr/bin/make -O -j8 V=1 VERBOSE=1
signature.asc
Description: This is a digitally signed message part
___
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
Re: json-c security update for CVE-2020-12762 in testing
Am Montag, den 25.05.2020, 11:32 +0200 schrieb Björn 'besser82' Esser:
> Hello,
>
> as there has a buffer-overflow vulnerability [1] been discovered in
> json-c recently, I've patched [2] the package to fix the issue and
> pushed updates for F3{2,1,0}. [3,4]
>
> The update for F32 is already in stable, but the updates for the
> earlier
> releases are still in waiting to be tested, and have received very
> little feedback so far.
>
> Can someone please test them and give some karma, please? Esp. for
> the
> F30 update [4], as it should go to stable *before* F30 will go EOL.
The update for F30 [4] just needs one additional karma to go stable…
Anyone who can test during today, please?
> [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12762
> [2] https://github.com/json-c/json-c/pull/611
> [3] https://bodhi.fedoraproject.org/updates/FEDORA-2020-7eb7eac270
> [4] https://bodhi.fedoraproject.org/updates/FEDORA-2020-847ad856ab
signature.asc
Description: This is a digitally signed message part
___
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
json-c security update for CVE-2020-12762 in testing
Hello,
as there has a buffer-overflow vulnerability [1] been discovered in
json-c recently, I've patched [2] the package to fix the issue and
pushed updates for F3{2,1,0}. [3,4]
The update for F32 is already in stable, but the updates for the earlier
releases are still in waiting to be tested, and have received very
little feedback so far.
Can someone please test them and give some karma, please? Esp. for the
F30 update [4], as it should go to stable *before* F30 will go EOL.
Thanks
Björn
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12762
[2] https://github.com/json-c/json-c/pull/611
[3] https://bodhi.fedoraproject.org/updates/FEDORA-2020-7eb7eac270
[4] https://bodhi.fedoraproject.org/updates/FEDORA-2020-847ad856ab
signature.asc
Description: This is a digitally signed message part
___
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
Re: Fedora+Lenovo
Am Donnerstag, den 30.04.2020, 21:18 + schrieb Mark Pearson: > Hi all, > > Adam Williamson suggested I stick a note in the mailing list saying > “hi” - so I’ve achieved that and officially upgraded myself from > lurker! He also suggested I take questions from the community - and > I’m very happy to do that. > So - if there are any questions from Fedora developers on the Lenovo > announcement let me know and I will answer them as best I can….if I > don’t know the answer I’ll do the try to find out. > > I will lurk around the mailing list but generally if there is anything > that might be important for Lenovo to look at/respond to/etc and I > don’t respond do feel free to send me a note directly saying “Look at > the mailing list” 😊 > > Mark Hi Mark, nice to have you around in the list. My first question regarding Lenovo support for Fedora is: Will there be any working driver or any other kind of support from Lenovo for the "Intel Corporation XMM7360 LTE Advanced Modem" aka. Fibocom L850-GL LTE modem, e.g. a BIOS update to operate the card in USB-mode or a Linux driver for operating the device in PCIe mode? Thanks Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: App updates for the new AAA solution
Am Donnerstag, den 23.04.2020, 18:00 +0100 schrieb Richard W.M. Jones: > On Thu, Apr 23, 2020 at 05:22:01PM +0100, Stephen Coady wrote: > > Hi, > > > > Development work has begun on the API which will give applications > > access > > to the new AAA solution. As part of our effort to migrate to this > > new AAA > > solution we need to identify applications which consume the old FAS > > API in > > some way. > > "AAA"? > > I find it good to go with the Economist (a newspaper) style guide > which invites writers to define every term before use. I guess "AAA" stands for: Anticipate Awkward Abbrevations *scnr* signature.asc Description: This is a digitally signed message part ___ 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
Re: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
Am Mittwoch, den 22.04.2020, 20:02 +0200 schrieb Miro Hrončok: > On 22. 04. 20 19:47, Björn 'besser82' Esser wrote: > > Hi Dan, > > > > I created the list of packages with the following chain of commands: > > > > dnf --releasever=rawhide repoquery --whatrequires json-c | \ > > xargs dnf --releasever=rawhide info | \ > > grep -i 'source' | sed -e 's!^.*: !!g' | sort -u; > > > > I ran that on Fedora 32 x86_64, and unfortunately the `s390utils` > > was > > not amoung the listed packages for some reason. > > Because it has: > > ExclusiveArch: s390 s390x Is there any better command that will work regardless of the system's arch? signature.asc Description: This is a digitally signed message part ___ 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
Re: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
Am Mittwoch, den 22.04.2020, 19:02 +0200 schrieb Dan Horák: > On Wed, 22 Apr 2020 12:00:37 +0200 > Björn 'besser82' Esser wrote: > > > The SONAME bump has been done, and the re-builds of all packages > > have > > finished successfully. > > looks you have missed s390utils with the rebuilds and it's also > missing > in the initial list of packages. How did you created the list - > searching for the library soname in binary rpms or for json-c-devel in > source rpms? I took care of the rebuild, that's not a problem. Hi Dan, I created the list of packages with the following chain of commands: dnf --releasever=rawhide repoquery --whatrequires json-c | \ xargs dnf --releasever=rawhide info | \ grep -i 'source' | sed -e 's!^.*: !!g' | sort -u; I ran that on Fedora 32 x86_64, and unfortunately the `s390utils` was not amoung the listed packages for some reason. Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
The SONAME bump has been done, and the re-builds of all packages have finished successfully. signature.asc Description: This is a digitally signed message part ___ 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
Re: [SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
Am Sonntag, den 19.04.2020, 18:22 +0200 schrieb Björn 'besser82' Esser: > gluster-block is currently FTBFS for some reason related to the > glusterfs package [2]. The reason for gluster-block has been FTBFS was fixed [1]. There was a clash between config.h in the build-tree and located in /usr/include/. So there are currently (and hopfully will be) no FTBFS packages for the upcoming rebuild so far. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=43552367 signature.asc Description: This is a digitally signed message part ___ 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
[SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
Hello together, as json-c 0.14 has been released today, I'm going to push an updated package to Rawhide within the next days. Within that procedure I'll take care of all needed rebuilds. I don't expect any major FTBFS, since I've already added patches to the packages that needed. The patches have been submitted to upstream as well. The patches were about fixing FTBFS due to the removal of the defines for TRUE and FALSE, which have been (int)1 for TRUE and (int)0 for FALSE in the previous versions, in json-c. There is a COPR with builds against the bumped SONAME at [1]. gluster-block is currently FTBFS for some reason related to the glusterfs package [2]. The rebuilds need to be done in two stages, as the intercircular- dependency between systemd and cryptsetup needs to be broken first. This bootstrap cycle will happen in a side-tag and gets merged back to Rawhide in one shot to reduce churn as much as possible. Bootstrap cycle: 1. Build systemd in bootstrap mode, so it has no depency on cryptsetup 2. Chain-build: json-c : cryptsetup : systemd (bootstrap disabled) 3. Merge side-tag with Rawhide After the side-tag has been merged the following build-chains are rebuild in Rawhide directly: * gdal : postgis * libstorj : filezilla * libu2f-host libu2f-server : pam-u2f * riemann-c-client : syslog-ng * satyr : libdnf libreport : abrt google-compute-engine-oslogin subscription-manager xrootd : dmlite : lcgdm-dav The following packages are independent from each other and any other build-chain, and thus will be rebuild in individual builds on Rawhide after the side-tag has been merged: bind bluez bti clamav device-mapper-multipath fastd fcitx freeradius frr fwts gdcm gfal2 girara gluster-block igt-gpu-tools libmypaint libmypaint2 libstorj libverto-jsonrpc libvmi mpris-scrobbler mraa nbd- runner ndctl newsbeuter newsboat opae openhpi opensips rpminspect rpm- ostree strongswan sway systemtap tlog tpm2-tss trace-cmd zmap The whole rebuild will likely not take longer than a few hours, except for the gdal : postgis chain, as gdal . The following packages are affected: * abrt * bind * bluez * bti * clamav * cryptsetup * device-mapper-multipath * dmlite * fastd * fcitx * filezilla * freeradius * frr * fwts * gdal * gdcm * gfal2 * girara * gluster-block * google-compute-engine-oslogin * igt-gpu-tools * lcgdm-dav * libdnf * libmypaint * libmypaint2 * libreport * libstorj * libu2f-host * libu2f-server * libverto-jsonrpc * libvmi * mpris-scrobbler * mraa * nbd-runner * ndctl * newsbeuter * newsboat * opae * openhpi * opensips * pam-u2f * postgis * riemann-c-client * rpminspect * rpm-ostree * satyr * strongswan * subscription-manager * sway * syslog-ng * systemtap * tlog * tpm2-tss * trace-cmd * xrootd * zmap Cheers Björn [1] https://copr.fedorainfracloud.org/coprs/besser82/json-c-test [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=43532093 signature.asc Description: This is a digitally signed message part ___ 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
Re: Heads-up: RPM 4.16 alpha coming to rawhide
Am Mittwoch, den 01.04.2020, 14:36 +0300 schrieb Panu Matilainen: > On 3/31/20 8:24 PM, Gary Buhrmaster wrote: > > On Tue, Mar 31, 2020 at 6:43 AM Panu Matilainen > > wrote: > > > > > Based on rpm-specs-latest.tar.xz from this morning, there are > > > thirtysome > > > packages relying on this behavior, which will need fixing to be > > > buildable with 4.16. > > > > Is there a list of those thirty something packages > > somewhere so that those particular packagers > > can potentially get a heads up? > > Here you go (was easier to extract from the output than I initially > thought): > > airnef.spec:83: bad %if condition: python3 == python3 > arbor.spec:34: bad %if > condition: fb5d4ea736282dce14c3284bc5db748b082db957 > cgit.spec:26: bad %if condition: 0 >= 7 && ! ( x86_64 == ppc64le || > x86_64 == x86_64 ) > copr-rpmbuild.spec:47: bad %if condition: python3 == "python2" > CQRlib.spec:33: bad %if condition: lib64 == lib64 > CTL.spec:90: bad %if condition: lib64 == "lib64" > CVector.spec:39: bad %if condition: lib64 == lib64 > dayplanner.spec:82: bad %if condition: include_holidayparser > desktop-backgrounds.spec:21: bad %if condition: png != png > doxygen.spec:53: bad %if condition: ON == "ON" > gdl.spec:193: bad %if condition: lib64 != "lib" > ghdl.spec:494: bad %if condition: lib64 != lib > git.spec:207: bad %if condition: 031 || 0 == 6 || ( 0 >= 7 && ( > x86_64 > == ppc64le || x86_64 == x86_64 ) ) > gsignond.spec:115: bad %if condition: session != p2p > gwenview.spec:35: bad %if condition: !(0 == 8 && ( x86_64 == > "aarch64" > > > x86_64 == "s390x" )) > hdf.spec:207: bad %if condition: lib64 == lib64 > kdegraphics-thumbnailers.spec:4: bad %if condition: !(0 == 8 && ( > x86_64 == "aarch64" || x86_64 == "s390x" )) > kf5-akonadi-contacts.spec:49: bad %if condition: !(0 == 8 && ( > x86_64 > == "aarch64" || x86_64 == "s390x" )) > lmdb.spec:83: bad %if condition: 0 == 6 && x86_64 == "ppc64" > magic.spec:81: bad %if condition: x64 == x64 > mariadb.spec:42: bad %if condition: x86_64 == x86_64 && 031 > MUSIC.spec:251: bad %if condition: lib64 == "lib64" > NetworkManager.spec:24: bad %if condition: "x" != x > newlisp.spec:38: bad %if condition: lib64 == lib64 > nwchem.spec:409: bad %if condition: LINUX64 == LINUX > OpenEXR_Viewers.spec:82: bad %if condition: lib64 == lib64 > python-pivy.spec:66: bad %if condition: lib64 == "lib64" > python-ryu.spec:98: bad %if condition: python3 == python3 > qt3.spec:404: bad %if condition: lib64 == lib64 > rubygem-scruffy.spec:7: bad %if condition: (prerelease) > sagator.spec:33: bad %if condition: redhat == "suse" > scribus.spec:111: bad %if condition: lib64 == lib64 > SkyX.spec:67: bad %if condition: lib64 == "lib64" > zabbix.spec:61: bad %if condition: zabbix != zabbix I've fixed all the packages on the list. Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: [SO-NAME-BUMP] jsoncpp.so.21 -> jsoncpp.so.22 (1.9.1 -> 1.9.2)
Am Freitag, den 15.11.2019, 09:09 +0100 schrieb Björn 'besser82' Esser: > Hello, > > I'm going to update jsoncpp in Rawhide, which includes a so name bump. > > I'll take care of bootstrapping CMake and rebuilding of all affected > packages during today. > > There is an impact for third party repos, too, which needs to be > handled > by them. The rebuilds have finished and jsoncpp is updated to 1.9.2 (so.22) in Rawhide. The maintainers of third party repos may want to check whether some of their packages need a rebuild. Two packages, qpid-proton [1] and vfrnav [2], were FTBFS for unrelated reasons. See the FTBFS bugs below. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1773179 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1773181 signature.asc Description: This is a digitally signed message part ___ 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
[SO-NAME-BUMP] jsoncpp.so.21 -> jsoncpp.so.22 (1.9.1 -> 1.9.2)
Hello, I'm going to update jsoncpp in Rawhide, which includes a so name bump. I'll take care of bootstrapping CMake and rebuilding of all affected packages during today. There is an impact for third party repos, too, which needs to be handled by them. Cheers, besser82 signature.asc Description: This is a digitally signed message part ___ 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
Re: python2->python3 mass rebuild and auto tools
Am Donnerstag, den 01.08.2019, 17:44 -0400 schrieb Steve Grubb: > On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote: > > On 01. 08. 19 4:43, Steve Grubb wrote: > > > Audit. But is seems that autotools shoul hard code the old > > > sematics so > > > that all packages do the right thing. It seems that python3 > > > equivalents > > > have been introduced. They do the right thing with the python > > > migration. > > > But there are things that are expectd to defaulto python 2. > > > > https://src.fedoraproject.org/rpms/audit/pull-request/4 > > > > Autotools usually already does the right thing, aka choosing python2 > > if it > > cannot find python. Using "python" in Fedora packages is forbidden > > anyway. > > I applied your patch. Thanks. > > But I am concerned that this is a bandaid because it patches the spec > file and > all distributions will have to do the same thing. Just until the end of this year, as Python2 will be finally dead on 2020-01-01. Anyways, there are easy ways in Autotools to archieve this, and I can craft a patch, if you guide me to the canonical upstream of audit. Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: How do I remove GLIBCXX_ASSERTIONS?
Am Donnerstag, den 01.08.2019, 14:28 -0400 schrieb Steven A. Falco: > The upstream KiCAD project has requested that I remove > GLIBCXX_ASSERTIONS from the Fedora package, as described here: > https://bugs.launchpad.net/kicad/+bug/1838448 > > What is the best way to do that? I can add "%undefine > _hardened_build" (which I am testing now) but I think that will remove > other hardening features that I might want to leave enabled. > > Steve Simply add this to your spec file: # Upstream recommends to turn off _GLIBCXX_ASSERTIONS. # See: $UPSTREAM_BUG %global optflags %optflags -U_GLIBCXX_ASSERTIONS signature.asc Description: This is a digitally signed message part ___ 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
Re: nettle: heads up soname bump
Am Dienstag, den 16.07.2019, 19:49 +0200 schrieb Kevin Kofler: > Björn 'besser82' Esser wrote: > > We have a circular dependency in the minimal buildroot: > > > > systemd --> cryptsetup-libs --> json-c > > > > > > cryptsetup needs json-c for LUKS2 and there is no option to disable > > LUKS2 during build. > > > > However systemd can *possibly* be build without support for > > cryptsetup. > > Why does the minimal buildroot need to contain systemd at all? It > does > nothing in a chroot. If we can get that fixed, the many dependencies > of > systemd shouldn't be a bootstrapping issue anymore. Which even then would still remain an issue, as cryptsetup build- requires device-mapper-devel, which requires systemd for some unknown reason… signature.asc Description: This is a digitally signed message part ___ 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
Re: nettle: heads up soname bump
Am Dienstag, den 16.07.2019, 19:26 +0200 schrieb Nicolas Mailhot via devel: > Le mardi 16 juillet 2019 à 18:53 +0200, Björn 'besser82' Esser a > écrit : > > > > Which build chain does look cleaner, shorter, and more semantically > > correct? > > > > 1. systemd (no cryptsetup) --> json-c (new so-ver) --> cryptsetup > > --> systemd (with cryptsetup) --> other consumers in chains > > > > 2. json-c (double so-ver) --> cryptsetup and all other consumers > > --> json-c (new so-ver) > > > > The second may look shorter but it is certainly not more correct. At > the end of it you still can't be sure everything has been built using > the new so-ver, so you need to add at least one rebuild stage using > the > new json-c to be sure the result is self-hosting. > > Any way you look at it, the last stage should involve rebuilding all > dependant packages over a repo state that includes only the final > state > of the changed package, or you may unadvertently still depend on > things > you think you removed That example was a bit shortened… My actual build-chain in that case is: json-c (double so-ver) --> cryptsetup --> json-c (new so-ver) --> all other consumers signature.asc Description: This is a digitally signed message part ___ 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
Re: nettle: heads up soname bump
Am Dienstag, den 16.07.2019, 20:45 +0200 schrieb Igor Gnatenko: > Because of systemd-libs… It is a dependency of util-linux at least. > That ships logger and lslogins utilities which link against > libsystemd. Which I assume are not really useful nor needed in a minimal buildroot? signature.asc Description: This is a digitally signed message part ___ 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
Re: nettle: heads up soname bump
Am Dienstag, den 16.07.2019, 12:00 +0200 schrieb Kevin Kofler: > Björn 'besser82' Esser wrote: > > > Am Dienstag, den 16.07.2019, 00:20 +0200 schrieb Kevin Kofler: > > > Miro Hrončok wrote: > > > > gnutls now cannot be rebuilt: > > > > > > > > nothing provides libnettle.so.6 needed by gnutls-3.6.8- > > > > 1.fc31.armv7hl > > > > > > Don't you love circular dependencies? > > > > > > This is really the biggest issue that we have: There are more and > > > more > > > circular dependencies. Each of them is a major PITA when trying to > > > upgrade a > > > library. > > > > Here[1] is a nice example of how to break the cycle by building both > > so- > > versions in a bootstrap build. > > I don't like this example, at all. This puts the burden of working > around > the circular dependency on the library, which is likely not even part > of the > actual cycle. (It just happens to be used by something that has a > circular > dependency and that hence cannot be simply rebuilt against the new > version > of the library.) We have a circular dependency in the minimal buildroot: systemd --> cryptsetup-libs --> json-c cryptsetup needs json-c for LUKS2 and there is no option to disable LUKS2 during build. However systemd can *possibly* be build without support for cryptsetup. > The original idea of bootstrap builds was to actually break the cycle, > e.g., > to find a way to build gnutls without requiring gnutls itself. This > is > usually done by disabling some optional functionality in some library. > But > of course, it only works if upstream did think of the bootstrap issue > and > actually made the circular dependency optional. If all dependencies in > the > cycle are mandatory, we are stuck. Technically I could do a bootstrap build of systemd without cryptsetup, but that would touch a package, which does not have a direct dependency on json-c, and thus wouldn't need to be rebuilt in any cycle at all. > But your approach of stuffing 2 versions of a library in a single RPM > is a > really ugly hack that really should not be needed. But it is getting > used > more and more often because of a lack of proper bootstrap logic (or > of > upstream support for it). In my conclusion I consider it to be "cleaner" to have a build with two versions of a library for a *single* step of the whole rebuild process involved, then to touch an unrelated package to break the dependency cycle. Which build chain does look cleaner, shorter, and more semantically correct? 1. systemd (no cryptsetup) --> json-c (new so-ver) --> cryptsetup --> systemd (with cryptsetup) --> other consumers in chains 2. json-c (double so-ver) --> cryptsetup and all other consumers --> json-c (new so-ver) signature.asc Description: This is a digitally signed message part ___ 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
Re: nettle: heads up soname bump
Am Dienstag, den 16.07.2019, 00:20 +0200 schrieb Kevin Kofler: > Miro Hrončok wrote: > > gnutls now cannot be rebuilt: > > > > nothing provides libnettle.so.6 needed by gnutls-3.6.8- > > 1.fc31.armv7hl > > Don't you love circular dependencies? > > This is really the biggest issue that we have: There are more and > more > circular dependencies. Each of them is a major PITA when trying to > upgrade a > library. Here[1] is a nice example of how to break the cycle by building both so- versions in a bootstrap build. With the bootstrap build one can chain-build all consumers to use the new so-version. After that has been finished one simply rebuilds the lib without bootstrap to just get the new so-version. Let me know if you want me to change the nettle spec file accordingly to the given example and trigger a working rebuild chain. Cheers, Björn [1] https://src.fedoraproject.org/rpms/json-c/blob/master/f/json-c.spec signature.asc Description: This is a digitally signed message part ___ 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
Re: [SO-NAME BUMP] jsoncpp-1.9.0
Am Mittwoch, den 03.07.2019, 13:50 +0200 schrieb Björn 'besser82' Esser: > Hello, > > jsoncpp-1.9.0 has been released recently, and I'm planning to update > the > package during today, which includes a so-name bump. > > I'll take care of rebuilding all its consumers, which are: > > cmake > libjson-rpc-cpp > minetest > orthanc > paraview > passenger > qpid-proton > vfrnav > vrpn > vtk jsoncpp has been updated to 1.9.0 (libjsoncpp.so.21). All builds, that require cmake should be back to normal again; the other consumers are currently being rebuilt. Sry for the short fallout! Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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
[SO-NAME BUMP] jsoncpp-1.9.0
Hello, jsoncpp-1.9.0 has been released recently, and I'm planning to update the package during today, which includes a so-name bump. I'll take care of rebuilding all its consumers, which are: cmake libjson-rpc-cpp minetest orthanc paraview passenger qpid-proton vfrnav vrpn vtk Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: libgps soname bump (gpsd-3.19)
Am Mittwoch, den 03.07.2019, 10:39 +0200 schrieb Miroslav Lichvar: > On Tue, Jul 02, 2019 at 09:31:53PM +0200, Björn 'besser82' Esser > wrote: > > Am Dienstag, den 02.07.2019, 16:09 +0200 schrieb Miroslav Lichvar: > > > The following packages will need a rebuild: > > > > > > collectd-5.8.1-6.fc31 > > > direwolf-1.5-1.fc30 > > > foxtrotgps-1.2.1-6.fc31 > > > gpsdrive-2.11-51.fc31 > > > marble-19.04.2-1.fc31 > > > plasma-workspace-5.16.2-1.fc31 > > > qlandkartegt-1.8.1-19.fc30 > > > vfrnav-20190212-1.fc30 > > > viking-1.7-2.fc30 > > To coordinate the rebuild of all consumers, you should ask a > > provenpackager for a helping hand. > > > > If you don't know any, I'd volunteer. Preferrably we can do those > > builds on Friday or over the weekend. Feel free to contact me about > > coordinating. > > Ok, thanks. Please rebuild the packages when you feel it is > appropriate. I have pushed the changes to the gpsd repo. All dependent > packages except direwolf should rebuild with no changes. A patch for > direwolf is attached. > Mission accomplished! https://koji.fedoraproject.org/koji/taskinfo?taskID=36015773 Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: libgps soname bump (gpsd-3.19)
Am Dienstag, den 02.07.2019, 16:09 +0200 schrieb Miroslav Lichvar: > A new version of gpsd was released. It breaks the ABI and API of > libgps again. If there are no objections, I'll build the package in > the next few days. > > The incompatibilities are minor (reordered struct, removed redundant > field) and I don't expect it to affect most of the client > applications. Patching should be straightforward in any case. Please > let me know if there are any issues. > > The following packages will need a rebuild: > > collectd-5.8.1-6.fc31 > direwolf-1.5-1.fc30 > foxtrotgps-1.2.1-6.fc31 > gpsdrive-2.11-51.fc31 > marble-19.04.2-1.fc31 > plasma-workspace-5.16.2-1.fc31 > qlandkartegt-1.8.1-19.fc30 > vfrnav-20190212-1.fc30 > viking-1.7-2.fc30 Hello Miroslav, sounds good, but with a small suggestion: To coordinate the rebuild of all consumers, you should ask a provenpackager for a helping hand. If you don't know any, I'd volunteer. Preferrably we can do those builds on Friday or over the weekend. Feel free to contact me about coordinating. Can you please do test builds in a COPR, also? Cheers, Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: Bootstrapped Packages
Am Mittwoch, den 26.06.2019, 12:53 +0200 schrieb Brian (bex) Exelbierd: > Hi, > > Can someone point me at step by step instructions for how to handle > new packages that require bootstrapping because of a circular > depedency? > > I am about to request the first of the repos and want to make sure I > follow the process correctly. My goal is to wind up with both > packages built fully in rawhide, and later other versions. > > The package that requires a boot strap received it's ack today. I > suspect the other review is waiting on the bootstrap to "appear." > > thank you for the guidance. > > regards, > > bex Sure, I can help out with that. It would be good, if you can point me to the reviews in question, so I can get familiar with the packages and what actually needs bootstrapping and in which ways. Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: [HEADS UP] Unannounced soname bump of qrencode
Am Dienstag, den 25.06.2019, 17:52 -0400 schrieb Paul Wouters: > This was a mistake on my end. I thought I was the owner of the > package, but I think I was only the owner of it back in el6. I assume > systemd then wasn't depending on it. I saw a PR the other day, assumed > it was to me as package owner, and saw no reason to not upgrade since > it was long over due. I didn't realise this would break systemd. > > Note, it is a bit worrying that systemd depends on this package, which > wasn't updated in 5 years, and for which the upstream changelog mostly > states "bug fixes". > > nirik untagged the package for me. I pinged Zbyszek to coordinate > things. I've reverted the commits for f29 and f30 (no updates were > issued for these branches yet) > > Ironically, this seems to not be the first time this happened either. > I see someone else made the exact same mistake in January 2018 and > reverted their changes to the package. So let's see if we can fix this > now in rawhide so it does not happen again in another year. > > Paul I've fixed the package in a way so-name bumps can be detected easily. If bootstrapping for such a bump (the next one) is needed one can do that now by simply editing some lines of the spec-file. During that fix, I've rebuilt systemd and the other consumers of qrencode against the new so-name. Cheers Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)
Am Donnerstag, den 09.05.2019, 10:21 -0700 schrieb Japheth Cleaver:
> On 5/9/2019 7:46 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote:
> > > On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > > Hi,
> > > >
> > > > let's drop the requirement and ordering on systemd (as
> > > > implemented by
> > > > %systemd_requires) from packages which provide systemd units.
> > > >
> > > > I now filed [1], which removes the recommendation to use
> > > > %systemd_requires.
> > > > Quoting from that ticket:
> > > >
> > > > Nowadays systemd.rpm does a preset-all call when it is
> > > > installed.
> > > > This means that individual packages which provide systemd
> > > > units and
> > > > call %systemd_post in their %post will work fine no matter
> > > > if they
> > > > are installed *before* or *after* systemd.
> > >
> > > Is this true for the version of systemd in RHEL 7 and compatible
> > > as well?
> > > How will this affect EPEL packages?
> > systemd in RHEL generally follows the changes in Fedora, with a
> > delay.
> > If this is changed in F31, then it wouldn't filter down to RHEL
> > until
> > the next RHEL release. Similarly, such changes should not be
> > propagated to
> > packages in EPEL7.
> >
> > Zbyszek
>
> RHEL8 has been out for all of two days. EPEL8 is still to come.
>
> So long as EPEL (and Rawhide, tbh) are under the aegis of Fedora, it
> would be nice at least /some/ effort was made not to toss over
> incompatible changes, or a broad need for dist conditionals, across
> the
> package ecosystem with such cavilerity.
>
> -jc
The impact of this change is not too bad considering a few things:
The use of the `%systemd_requires` macros must be changed to
`%{?systemd_requires}` in each spec file. That way rpmbuild will
evaluate whether the macro is defined and after that will fill in the
body of the macro. If it is not defined rpmbuild will simply replace
the `%{?systemd_requires}` with %nil.
That way the definition of that macro can be fully dropped from F-31+
(and thus get reintroduced at any time later, if needed for $reasons),
while still keeping the spec file fully compatible with any prior
releases (including EPEL / RHEL).
Cheers,
Björn
signature.asc
Description: This is a digitally signed message part
___
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
Re: cloud-init FTBFS
Am Dienstag, den 23.04.2019, 16:39 +0200 schrieb Miro Hrončok: > Hello cloud-init maintainers, > > cloud-init FTBFS in Fedora rawhide and it will be a problem for the > update to > Python 3.8. > > https://bugzilla.redhat.com/show_bug.cgi?id=1695953 > > Since there has been no update by the maintainers, I'm trying to reach > you via > e-mail. I've fixed the issue as a proven packager in cloud-init-17.1-9.fc30 [1] and cloud-init-17.1-10.fc31 [2]. Cheers, Björn [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1253877 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1253879 signature.asc Description: This is a digitally signed message part ___ 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
Re: openmpi breakage on Rawhide
Am Mittwoch, den 17.04.2019, 18:09 +0200 schrieb Björn 'besser82' Esser: > Am Mittwoch, den 17.04.2019, 09:59 -0600 schrieb Christoph Junghans: > > I think a rebuild will fix the problem: > > https://src.fedoraproject.org/rpms/openmpi/pull-request/5 > > > > On Wed, Apr 17, 2019 at 9:53 AM Christoph Junghans < > > jungh...@votca.org > > > wrote: > > > Hi all, > > > > > > Some of my packages failed to build due to a openmpi breakage > > > > > > DEBUG util.py:554: BUILDSTDERR: Error: > > > DEBUG util.py:554: BUILDSTDERR: Problem: package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi.so.40()(64bit)(openmpi-x86_64), but none of the providers > > > can > > > be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi_cxx.so.40()(64bit)(openmpi-x86_64), but none of the > > > providers > > > can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi_mpifh.so.40()(64bit)(openmpi-x86_64), but none of the > > > providers > > > can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi_usempif08.so.40()(64bit)(openmpi-x86_64), but none of the > > > providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi_usempi_ignore_tkr.so.40()(64bit)(openmpi-x86_64), but none > > > of > > > the providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > libmpi_java.so.40()(64bit)(openmpi-x86_64), but none of the > > > providers > > > can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > > liboshmem.so.40()(64bit)(openmpi-x86_64), but none of the > > > providers > > > can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > openmpi-devel-3.1.3-3.fc31.x86_64 requires openmpi = 3.1.3-3.fc31, > > > but > > > none of the providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - conflicting requests > > > DEBUG util.py:554: BUILDSTDERR: - nothing provides > > > libosmcomp.so.4()(64bit) needed by openmpi-3.1.3-3.fc31.x86_64 > > Merged and building. > > https://koji.fedoraproject.org/koji/taskinfo?taskID=34241927 Unfortunately the build failed on S390X arch for some infrastructural reason. I've resubmitted the task: https://koji.fedoraproject.org/koji/taskinfo?taskID=34242038 signature.asc Description: This is a digitally signed message part ___ 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
Re: openmpi breakage on Rawhide
Am Mittwoch, den 17.04.2019, 09:59 -0600 schrieb Christoph Junghans: > I think a rebuild will fix the problem: > https://src.fedoraproject.org/rpms/openmpi/pull-request/5 > > On Wed, Apr 17, 2019 at 9:53 AM Christoph Junghans > wrote: > > Hi all, > > > > Some of my packages failed to build due to a openmpi breakage > > > > DEBUG util.py:554: BUILDSTDERR: Error: > > DEBUG util.py:554: BUILDSTDERR: Problem: package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi.so.40()(64bit)(openmpi-x86_64), but none of the providers can > > be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi_cxx.so.40()(64bit)(openmpi-x86_64), but none of the providers > > can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi_mpifh.so.40()(64bit)(openmpi-x86_64), but none of the > > providers > > can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi_usempif08.so.40()(64bit)(openmpi-x86_64), but none of the > > providers can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi_usempi_ignore_tkr.so.40()(64bit)(openmpi-x86_64), but none of > > the providers can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > libmpi_java.so.40()(64bit)(openmpi-x86_64), but none of the > > providers > > can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires > > liboshmem.so.40()(64bit)(openmpi-x86_64), but none of the providers > > can be installed > > DEBUG util.py:554: BUILDSTDERR: - package > > openmpi-devel-3.1.3-3.fc31.x86_64 requires openmpi = 3.1.3-3.fc31, > > but > > none of the providers can be installed > > DEBUG util.py:554: BUILDSTDERR: - conflicting requests > > DEBUG util.py:554: BUILDSTDERR: - nothing provides > > libosmcomp.so.4()(64bit) needed by openmpi-3.1.3-3.fc31.x86_64 Merged and building. https://koji.fedoraproject.org/koji/taskinfo?taskID=34241927 signature.asc Description: This is a digitally signed message part ___ 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
Re: rpmlint: new "executable stack" warnings on rawhide
Am Sonntag, den 17.03.2019, 15:00 +0100 schrieb Fabio Valentini: > On Sun, Mar 17, 2019 at 2:49 PM John Reiser > wrote: > > > I've noticed that as of some days ago, some packages I build on > > > rawhide are now triggering the "W: executable-stack" warning for > > > all included executables and shared libraries. > > > > > > I'm not sure which change might be the cause of this, but meson > > > 0.50.0 seems to be a good candidate, since all my affected > > > packages are built with meson and the new version landed six days > > > ago. > > > > > > Is that new warning something we should worry about? > > > > Yes. The warning means that an executable is not as secure as it > > could be against malware. > > > > The likely cause is some assembly-language source file that lacks a > > line such as > > .section.note.GNU-stack,"",@progbits > > which tells the assembler and static binder (/usr/bin/ld) that "the > > code in this file > > does not need an executable stack." > > No, that's not it. The packages that now trigger this warning don't > contain any assembly sources, only Vala (which is compiled to C) and > C. > For example: > https://taskotron.fedoraproject.org/artifacts/all/2ac7eb02-48a6-11e9-a48a-525400fc9f92/tests.yml/elementary-code-3.1.1-1.fc31.log > > Fabio > > > To identify the files that lack the line: > > find src -name '*.S' | sort > files-S.txt > > grep -l note.GNU-stack $(< files-S.txt) > files-non-W- > > stack.txt > > comm -3 files-S.txt files-non-W-stack.txt > > > > To remove the warning: append the line to the end of each file > > listed > > in the output from 'comm'. Did you examine the C code files generated from the Vala sources not to have local functions that are called through function pointers? See [1] as a reference. [1] https://www.win.tue.nl/~aeb/linux/hh/protection.html signature.asc Description: This is a digitally signed message part ___ 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
Re: libvirt uninstallable in F30 Koji because of broken ceph dep
Am Donnerstag, den 07.03.2019, 09:53 + schrieb Richard W.M. Jones: > On Thu, Mar 07, 2019 at 09:47:51AM +, Daniel P. Berrangé wrote: > > On Thu, Mar 07, 2019 at 08:29:52AM +, Richard W.M. Jones wrote: > > > On Thu, Mar 07, 2019 at 08:02:00AM +, Richard W.M. Jones > > > wrote: > > > > DEBUG util.py:554: BUILDSTDERR: Error: > > > > DEBUG util.py:554: BUILDSTDERR: Problem: package libvirt- > > > > daemon-kvm-5.1.0-1.fc30.x86_64 requires libvirt-daemon-driver- > > > > storage = 5.1.0-1.fc30, but none of the providers can be > > > > installed > > > > DEBUG util.py:554: BUILDSTDERR: - package libguestfs- > > > > 1:1.40.2-2.fc30.x86_64 requires libvirt-daemon-kvm >= 0.10.2-3, > > > > but none of the providers can be installed > > > > DEBUG util.py:554: BUILDSTDERR: - package libvirt-daemon- > > > > driver-storage-5.1.0-1.fc30.x86_64 requires libvirt-daemon- > > > > driver-storage-rbd = 5.1.0-1.fc30, but none of the providers can > > > > be installed > > > > DEBUG util.py:554: BUILDSTDERR: - package libguestfs-devel- > > > > 1:1.40.2-2.fc30.x86_64 requires libguestfs.so.0()(64bit), but > > > > none of the providers can be installed > > > > DEBUG util.py:554: BUILDSTDERR: - package libguestfs-devel- > > > > 1:1.40.2-2.fc30.x86_64 requires libguestfs(x86-64) = 1:1.40.2- > > > > 2.fc30, but none of the providers can be installed > > > > DEBUG util.py:554: BUILDSTDERR: - package libvirt-daemon- > > > > driver-storage-rbd-5.1.0-1.fc30.x86_64 requires > > > > librados.so.2()(64bit), but none of the providers can be > > > > installed > > > > DEBUG util.py:554: BUILDSTDERR: - conflicting requests > > > > DEBUG util.py:554: BUILDSTDERR: - nothing provides > > > > libcrc32.so()(64bit) needed by librados2-1:14.1.0-1.fc30.x86_64 > > > > > > > > (from > > > > https://kojipkgs.fedoraproject.org//work/tasks/15/33260015/root.log > > > > ) > > > > > > > > This looks like it might be fixed by ceph-14.1.0-2.fc30. > > > > > > > > Do we just need to add a build override, or does this require a > > > > further fix in libvirt and/or ceph? > > > > > > To answer my own question - I added a 5 day build override and > > > that > > > seems to have fixed things. > > > > So I guess there was a ceph override already when we built it, and > > this > > this expired preventing installs until you re-added the override ? > > I'm not sure if the libvirt build would have been affected by this? > In any case the 5 day override fixes things for now. > > There is no Bodhi update for ceph however. I'm not sure if we need > one. Up til quite recently Bodhi was not required for F30, but I see > now updates appearing: > > https://bodhi.fedoraproject.org/updates/?releases=F30&status=pending Hi, the recent build of ceph was made after the bodhi activation point, so an update for it needs to be submitted. As we are in the beta freeze for now, you should also ask for a freeze exception. You should tag the buildroot override for ceph up until Apr 4th, to make sure it will be available during the hole possible time of the beta freeze. Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: Broken dependency for devscripts in f29
Am Sonntag, den 24.02.2019, 19:11 +0100 schrieb Björn 'besser82' Esser: > Am Sonntag, den 24.02.2019, 23:06 +0900 schrieb Mamoru TASAKA: > > Björn 'besser82' Esser wrote on 2019/02/24 21:22: > > > Am Sonntag, den 24.02.2019, 10:39 +0100 schrieb Dridi Boukelmoune: > > > > Hi, > > > > > > > > Somehow this slipped through the cracks: > > > > > > > > > Dependencies resolved. > > > > > > > > > > Problem: cannot install the best update candidate for > > > > > package > > > > > devscripts-2.18.4-1.fc29.x86_64 > > > > >- nothing provides perl(GitLab::API::v4::Constants) needed > > > > > by > > > > > devscripts-2.19.2-3.fc29.x86_64 > > > > > > > > I tried this too but no luck there: > > > > > > > > > $ sudo dnf install 'perl(GitLab::API::v4::Constants)' -- > > > > > enablerepo > > > > > updates-testing > > > > > [...] > > > > > No match for argument: perl(GitLab::API::v4::Constants) > > > > > Error: Unable to find a match > > > > > > > > Dridi > > > > > > Thanks for the catch! This also affects Rawhide and f30. > > > > > > I've already filed a bug [1] about this and submitted the needed > > > dependency chain for review [2,3,4,5,6]. Help with the (almost > > > less > > > then trivial) reviews is appreciated. > > > > > > > > > > Ummm... Can't you fix this broken dependency until the reviews gets > > passed? > > Looks like just killing /usr/bin/salsa (and Salsa.pm and so on) > > resolves the issue for a moment - Actually /usr/bin/salsa did not > > exist > > in devscripts-2.18.9 , which suggests that /usr/bin/salsa script is > > "enhancement" so once killing that script should not hurt. > > > > Regards, > > Mamoru > > The needed dependency chain has been reviewed and is waiting for the > SCM-admin to create the repos and branches. As soon as that happened, > I'll build the packages and push updates, if needed. This should be > at > sometime during tomorrow. > > Thanks, > Björn The needed package dependencies have been built for Rawhide and f28 up to f30. For f29 I've additonally tagged the builds into the buildroot override until the actual update goes stable, so the devscripts package is installable again for Koji builds consuming it. Cheers, Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: Broken dependency for devscripts in f29
Am Sonntag, den 24.02.2019, 10:39 +0100 schrieb Dridi Boukelmoune: > Hi, > > Somehow this slipped through the cracks: > > > Dependencies resolved. > > > > Problem: cannot install the best update candidate for package > > devscripts-2.18.4-1.fc29.x86_64 > > - nothing provides perl(GitLab::API::v4::Constants) needed by > > devscripts-2.19.2-3.fc29.x86_64 > > I tried this too but no luck there: > > > $ sudo dnf install 'perl(GitLab::API::v4::Constants)' --enablerepo > > updates-testing > > [...] > > No match for argument: perl(GitLab::API::v4::Constants) > > Error: Unable to find a match > > Dridi If one needs the dependencies immediately for local use, they can use my COPR [1] for f28, f29, f30 / Rawhide until the reviewed packages have been imported and built. Björn [1] https://copr.fedorainfracloud.org/coprs/besser82/perl-GitLab-API-v4/ signature.asc Description: This is a digitally signed message part ___ 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
Re: Broken dependency for devscripts in f29
Am Sonntag, den 24.02.2019, 23:06 +0900 schrieb Mamoru TASAKA: > Björn 'besser82' Esser wrote on 2019/02/24 21:22: > > Am Sonntag, den 24.02.2019, 10:39 +0100 schrieb Dridi Boukelmoune: > > > Hi, > > > > > > Somehow this slipped through the cracks: > > > > > > > Dependencies resolved. > > > > > > > > Problem: cannot install the best update candidate for package > > > > devscripts-2.18.4-1.fc29.x86_64 > > > >- nothing provides perl(GitLab::API::v4::Constants) needed by > > > > devscripts-2.19.2-3.fc29.x86_64 > > > > > > I tried this too but no luck there: > > > > > > > $ sudo dnf install 'perl(GitLab::API::v4::Constants)' -- > > > > enablerepo > > > > updates-testing > > > > [...] > > > > No match for argument: perl(GitLab::API::v4::Constants) > > > > Error: Unable to find a match > > > > > > Dridi > > > > Thanks for the catch! This also affects Rawhide and f30. > > > > I've already filed a bug [1] about this and submitted the needed > > dependency chain for review [2,3,4,5,6]. Help with the (almost less > > then trivial) reviews is appreciated. > > > > > Ummm... Can't you fix this broken dependency until the reviews gets > passed? > Looks like just killing /usr/bin/salsa (and Salsa.pm and so on) > resolves the issue for a moment - Actually /usr/bin/salsa did not > exist > in devscripts-2.18.9 , which suggests that /usr/bin/salsa script is > "enhancement" so once killing that script should not hurt. > > Regards, > Mamoru The needed dependency chain has been reviewed and is waiting for the SCM-admin to create the repos and branches. As soon as that happened, I'll build the packages and push updates, if needed. This should be at sometime during tomorrow. Thanks, Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: Broken dependency for devscripts in f29
Am Sonntag, den 24.02.2019, 10:39 +0100 schrieb Dridi Boukelmoune: > Hi, > > Somehow this slipped through the cracks: > > > Dependencies resolved. > > > > Problem: cannot install the best update candidate for package > > devscripts-2.18.4-1.fc29.x86_64 > > - nothing provides perl(GitLab::API::v4::Constants) needed by > > devscripts-2.19.2-3.fc29.x86_64 > > I tried this too but no luck there: > > > $ sudo dnf install 'perl(GitLab::API::v4::Constants)' --enablerepo > > updates-testing > > [...] > > No match for argument: perl(GitLab::API::v4::Constants) > > Error: Unable to find a match > > Dridi Thanks for the catch! This also affects Rawhide and f30. I've already filed a bug [1] about this and submitted the needed dependency chain for review [2,3,4,5,6]. Help with the (almost less then trivial) reviews is appreciated. Björn [1] https://bugzilla.redhat.com/show_bug.cgi?id=1680371 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1680372 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1680373 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1680374 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1680375 [6] https://bugzilla.redhat.com/show_bug.cgi?id=1680376 signature.asc Description: This is a digitally signed message part ___ 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
Re: mass rebuild failure page failure
Am Samstag, den 16.02.2019, 12:04 +0100 schrieb Fabio Valentini: > On Sat, Feb 16, 2019 at 10:29 AM Zbigniew Jędrzejewski-Szmek > wrote: > > https://kojipkgs.fedoraproject.org/mass-rebuild/f30-failures.html > > now says "21 failed builds". I assume that nobody fixed the other > > 1k+ > > failures during the night and this result is bogus. > > I think besser82 ran a rebuild loop over all failed packages to weed > out the ones that failed only due to koji or networking issues. > It looks like that removed all rebuilt packages from the list, whether > or not they succeeded to build. > > Fabio Yes, for some unknown reason the packages are removed from the mentioned page as soon as someone starts a build for them. Maybe this should be fixed somehow. Anyways, the need-rebuild page [1] still shows them as failed. Björn [1] https://kojipkgs.fedoraproject.org/mass-rebuild/f30-need-rebuild.html signature.asc Description: This is a digitally signed message part ___ 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
Re: Fedora 30 Mass Rebuild
Am Donnerstag, den 14.02.2019, 14:41 +0100 schrieb Fabio Valentini: > On Thu, Feb 14, 2019 at 2:29 PM Miro Hrončok > wrote: > > On 04. 02. 19 21:48, Mohan Boddu wrote: > > > Hi all, > > > > > > Per the Fedora 30 schedule[1] we started a mass rebuild for Fedora > > > 30 > > > on Jan 31st 2019. We did a mass rebuild for Fedora 30 for the > > > changes listed in: > > > > > > https://pagure.io/releng/issue/8086 > > > > > > Mass rebuild was done in a side tag (f30-rebuild) and are now > > > getting moved over > > > to f30. > > > > > > Failures can be seen > > > https://kojipkgs.fedoraproject.org/mass-rebuild/f30-failures.html > > Some packages disappeared from the list. > > > > Fore example: python2-django1.11 > > My 4 packages (agenda, elementary-photos, gitg, and > golang-github-oschwald-maxminddb-golang) vanished as well. > > Fabio That might have happened, because I've run a dumb loop over all FTBFS packages to have them build at least a second time. It actually fixed about 180 packages by just submitting them a second time. Sry, for br3aking stuff… :( Anyways, this list still apears to be correct: https://kojipkgs.fedoraproject.org/mass-rebuild/f30-need-rebuild.html Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: Unannounced soname bumps: proj and geos
Am Donnerstag, den 14.02.2019, 07:13 -0500 schrieb Elliott Sales de Andrade: > Hi, > > On Tue, 5 Feb 2019 at 17:12, Devrim Gündüz wrote: > > Hi, > > > > On Mon, 2019-02-04 at 21:09 -0500, Elliott Sales de Andrade wrote: > > > The recent bump of proj in Rawhide from 4.9.3 to 5.2.0 also bumped > > > the > > > soname from libproj.so.12 to libproj.so.13. > > > The bump of geos in Rawhide from 3.6.1 to 3.7.1 also bumped the > > > soname > > > from libgeos-3.6.1.so to libgeos-3.7.1.so. > > > > > > These bumps should be announced *before* the build has been made. > > > > Apologies, that was me. I forgot the process. > > > > > Fortunately, as I was already investigating the possibility of > > > updating proj, > > > > Yay! > > > > > I have the list of proj-dependent packages already. I > > > was not looking at geos, but hopefully the list below includes > > > everyone. I have CC'd maintainers on the list to notify them that > > > they > > > will need to rebuild their packages (or I can do it myself at some > > > point if they're busy.) > > > > I am working on it. Fixed libgeotiff, libspatialite ,ogdi. gdal, > > GRASS and > > PostGIS so far. > > > > Thanks for taking care of these. I was able to rebuild my packages as > well without issue, and I see a few others were done by other > maintainers. > There are still six left that have not been rebuilt: perl-PDL, > shapelib-tools, spatialite-gui, merkaartor, qlandkartegt, saga. I may > build these if the maintainers do not get to it before the branch > point or beta freeze. I've taken care of those rebuilds. Björn signature.asc Description: This is a digitally signed message part ___ 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
Re: Attempting to fix hyperscan FTBFS
Am Dienstag, den 12.02.2019, 16:40 -0500 schrieb Jason Taylor: > > > On Tue, Feb 12, 2019, 16:35 Björn 'besser82' Esser < > besse...@fedoraproject.org> wrote: > > > This log has "-mtune=option: not valid". I guess something has > > changed > > > here with gcc 9 that the cmake script doesn't like? > > > > > > I've tailored a patch for CMakeLists.txt to fix the build [1]. If > > you > > agree, I'll push to SCM (including update to v5.1.0) and build it. > > > > Björn > > > > > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=32767716 > > That works for me, thank you! > > JT Allrighty! Here you go: https://koji.fedoraproject.org/koji/buildinfo?buildID=1208802 signature.asc Description: This is a digitally signed message part ___ 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
Re: Attempting to fix hyperscan FTBFS
> This log has "-mtune=option: not valid". I guess something has changed > here with gcc 9 that the cmake script doesn't like? I've tailored a patch for CMakeLists.txt to fix the build [1]. If you agree, I'll push to SCM (including update to v5.1.0) and build it. Björn [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=32767716 signature.asc Description: This is a digitally signed message part ___ 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
Re: F29 updates-testing
Am Samstag, den 09.02.2019, 22:54 +1100 schrieb Bojan Smojver:
> Anyone understands why this is not being pushed in recent days?
Most likely because of this [1]. Since autosign was broken for some
time even the packages for F2{8,9} could not be signed for while and
thus not pushed to the testing repository.
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IPAM74PRXPG6CL7UP7IL62WYC6GR7LJB/
signature.asc
Description: This is a digitally signed message part
___
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
