Re: jpegxl soname bump

2021-11-21 Thread Björn 'besser82' Esser
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

2021-11-19 Thread Björn 'besser82' Esser
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

2021-11-16 Thread Björn 'besser82' Esser
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

2021-11-13 Thread Björn 'besser82' Esser
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

2021-11-12 Thread 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


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

2021-11-11 Thread Björn 'besser82' Esser
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

2021-11-07 Thread Björn 'besser82' Esser
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

2021-11-04 Thread Björn 'besser82' Esser
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

2021-11-04 Thread 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


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

2021-11-03 Thread Björn 'besser82' Esser
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

2021-11-03 Thread 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.

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

2021-10-30 Thread Björn 'besser82' Esser
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

2021-10-30 Thread Björn 'besser82' Esser
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

2021-10-14 Thread Björn 'besser82' Esser
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

2021-10-13 Thread Björn 'besser82' Esser
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

2021-10-13 Thread Björn 'besser82' Esser
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

2021-10-13 Thread 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


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

2021-10-06 Thread Björn 'besser82' Esser
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

2021-10-01 Thread Björn 'besser82' Esser
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

2021-08-20 Thread Björn 'besser82' Esser
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?

2021-08-20 Thread Björn 'besser82' Esser
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?

2021-08-19 Thread Björn 'besser82' Esser
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

2021-08-19 Thread Björn 'besser82' Esser
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

2021-08-19 Thread Björn 'besser82' Esser
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
> > > > > > > > quazip
> > > >

Re: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed

2021-08-19 Thread 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.

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

2021-08-19 Thread Björn 'besser82' Esser
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
> > > > > > a
> > > > > > conflict w

Re: Updating quazip to version 1.1 in rawhide - rebuild of several packages in side-tag needed

2021-08-19 Thread 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
> 
> 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

2021-08-19 Thread 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


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

2021-08-19 Thread Björn 'besser82' Esser
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

2021-08-18 Thread Björn 'besser82' Esser
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

2021-08-18 Thread Björn 'besser82' Esser
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?

2021-08-17 Thread Björn 'besser82' Esser
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

2021-08-13 Thread Björn 'besser82' Esser
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

2021-08-13 Thread Björn 'besser82' Esser
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)

2021-08-12 Thread Björn 'besser82' Esser
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)

2021-08-11 Thread Björn 'besser82' Esser
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)

2021-08-11 Thread 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


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

2021-08-05 Thread Björn 'besser82' Esser
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

2021-08-05 Thread Björn 'besser82' Esser
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

2021-08-05 Thread 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


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

2021-07-27 Thread Björn 'besser82' Esser
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?

2021-07-06 Thread Björn 'besser82' Esser
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

2021-06-17 Thread Björn 'besser82' Esser
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

2021-06-17 Thread 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.


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

2021-06-16 Thread 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.

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)

2021-06-08 Thread Björn 'besser82' Esser
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)

2021-06-08 Thread Björn 'besser82' Esser
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)

2021-06-08 Thread Björn 'besser82' Esser
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)

2021-06-08 Thread Björn 'besser82' Esser
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

2020-06-23 Thread Björn 'besser82' Esser
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)

2020-06-18 Thread Björn 'besser82' Esser
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)

2020-06-18 Thread Björn 'besser82' Esser
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

2020-05-31 Thread Björn 'besser82' Esser
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

2020-05-31 Thread 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.

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

2020-05-30 Thread Björn 'besser82' Esser
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

2020-05-30 Thread Björn 'besser82' Esser
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

2020-05-30 Thread Björn 'besser82' Esser
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

2020-05-30 Thread 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

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?

2020-05-27 Thread Björn 'besser82' Esser
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

2020-05-25 Thread Björn 'besser82' Esser
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

2020-05-25 Thread 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.

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

2020-04-30 Thread Björn 'besser82' Esser
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

2020-04-23 Thread Björn 'besser82' Esser
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)

2020-04-22 Thread Björn 'besser82' Esser
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)

2020-04-22 Thread Björn 'besser82' Esser
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)

2020-04-22 Thread Björn 'besser82' Esser
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)

2020-04-20 Thread Björn 'besser82' Esser
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)

2020-04-19 Thread Björn 'besser82' Esser
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

2020-04-02 Thread Björn 'besser82' Esser
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)

2019-11-16 Thread Björn 'besser82' Esser
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)

2019-11-15 Thread 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.

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

2019-08-03 Thread Björn 'besser82' Esser
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?

2019-08-03 Thread Björn 'besser82' Esser
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

2019-07-16 Thread Björn 'besser82' Esser
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

2019-07-16 Thread Björn 'besser82' Esser
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

2019-07-16 Thread Björn 'besser82' Esser
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

2019-07-16 Thread Björn 'besser82' Esser
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

2019-07-16 Thread Björn 'besser82' Esser
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

2019-07-03 Thread Björn 'besser82' Esser
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

2019-07-03 Thread 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

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)

2019-07-03 Thread Björn 'besser82' Esser
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)

2019-07-02 Thread Björn 'besser82' Esser
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

2019-06-26 Thread Björn 'besser82' Esser
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

2019-06-25 Thread Björn 'besser82' Esser
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)

2019-05-09 Thread Björn 'besser82' Esser
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

2019-04-23 Thread Björn 'besser82' Esser
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

2019-04-17 Thread Björn 'besser82' Esser
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

2019-04-17 Thread 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  > 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

2019-03-17 Thread Björn 'besser82' Esser
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

2019-03-07 Thread Björn 'besser82' Esser
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=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

2019-02-25 Thread Björn 'besser82' Esser
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

2019-02-24 Thread Björn 'besser82' Esser
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

2019-02-24 Thread 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


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

2019-02-24 Thread Björn 'besser82' Esser
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

2019-02-16 Thread Björn 'besser82' Esser
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

2019-02-14 Thread Björn 'besser82' Esser
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

2019-02-14 Thread Björn 'besser82' Esser
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

2019-02-12 Thread Björn 'besser82' Esser
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

2019-02-12 Thread Björn 'besser82' Esser
> 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

2019-02-09 Thread Björn 'besser82' Esser
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


  1   2   3   >