libvirt uninstallable in F30 Koji because of broken ceph dep
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? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: GNOME 3.31.92 megaupdate and the F30 Beta freeze
On 3/4/19 17:43, Kalev Lember wrote: It's GNOME 3.31.92 release this week. We have a f30-gnome side tag as usual; if you are helping with builds please do F30 builds with 'fedpkg build --target f30-gnome'. I'll collect all the builds from the side tag and submit a megaupdate to Bodhi later this week. The update is in Bodhi now: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6ce38b68d8 Kalev ___ 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
Question about Python 2 (sub-)package removal in Fedora
Related to: https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal I have some packages which build python 2 subpackages, but they are not "python packages" as such. One example is nbdkit: https://koji.fedoraproject.org/koji/buildinfo?buildID=1225638 This package isn't listed in https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal/List I don't know how that list was constructed, whether this was missed by accident, or design. Anyway my question is should I remove these subpackages myself? Now? And in what releases of Fedora (ie. 31 only? 30 and 31?) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: Question about Python 2 (sub-)package removal in Fedora
On 07. 03. 19 9:11, Richard W.M. Jones wrote: Related to: https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal I have some packages which build python 2 subpackages, but they are not "python packages" as such. One example is nbdkit: https://koji.fedoraproject.org/koji/buildinfo?buildID=1225638 This package isn't listed in https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal/List I don't know how that list was constructed, whether this was missed by accident, or design. Only Python 2 modules (i.e. stuff that installs into /usr/lib(64)?/python2.7) were detected. Yours seem to be like some sort of plugins. Anyway my question is should I remove these subpackages myself? Now? And in what releases of Fedora (ie. 31 only? 30 and 31?) If they are not depended upon, please remove them. Since the beta freeze for Fedora 30 already happened and I don't think this would unblock plenty other packages, I suggest to do it in Fedora 31 only. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: Question about Python 2 (sub-)package removal in Fedora
On Thu, Mar 07, 2019 at 09:15:23AM +0100, Miro Hrončok wrote: > On 07. 03. 19 9:11, Richard W.M. Jones wrote: > > > >Related to: > >https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal > > > >I have some packages which build python 2 subpackages, but they are > >not "python packages" as such. One example is nbdkit: > > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1225638 > > > >This package isn't listed in > >https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal/List > >I don't know how that list was constructed, whether this was missed by > >accident, or design. > > Only Python 2 modules (i.e. stuff that installs into > /usr/lib(64)?/python2.7) were detected. Yours seem to be like some > sort of plugins. Another one would be python2-libguestfs which does install files in /usr/lib64/python2.7 and is present in the list, but wasn't removed by anyone nor was a bug filed against it AFAICS. Anyway I can deal with this one too. > >Anyway my question is should I remove these subpackages myself? Now? > >And in what releases of Fedora (ie. 31 only? 30 and 31?) > > If they are not depended upon, please remove them. > > Since the beta freeze for Fedora 30 already happened and I don't > think this would unblock plenty other packages, I suggest to do it > in Fedora 31 only. OK, it'll be good to finally get rid of Python 2. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: Question about Python 2 (sub-)package removal in Fedora
On 07. 03. 19 9:33, Richard W.M. Jones wrote: On Thu, Mar 07, 2019 at 09:15:23AM +0100, Miro Hrončok wrote: On 07. 03. 19 9:11, Richard W.M. Jones wrote: Related to: https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal I have some packages which build python 2 subpackages, but they are not "python packages" as such. One example is nbdkit: https://koji.fedoraproject.org/koji/buildinfo?buildID=1225638 This package isn't listed in https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal/List I don't know how that list was constructed, whether this was missed by accident, or design. Only Python 2 modules (i.e. stuff that installs into /usr/lib(64)?/python2.7) were detected. Yours seem to be like some sort of plugins. Another one would be python2-libguestfs which does install files in /usr/lib64/python2.7 and is present in the list, but wasn't removed by anyone nor was a bug filed against it AFAICS. Anyway I can deal with this one too. I get this on the latest compose from February: $ dnf repoquery --repo=rawhide --repo=rawhide-source --whatrequires python2-libguestfs imagefactory-0:1.1.11-2.fc30.noarch kimchi-0:1.5.1-11.fc30.noarch oz-0:0.16.0-8.fc30.noarch vdsm-hook-fileinject-0:4.18.999-447.git0bb7717.fc28.noarch While I'd like to get rid of as much Python 2 packages as possible, I'd advise not to remove packages that are being dependent upon (unless properly communicated with the maintainers of the dependent packages). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Question about Python 2 (sub-)package removal in Fedora
On Thu, Mar 07, 2019 at 09:37:12AM +0100, Miro Hrončok wrote: > On 07. 03. 19 9:33, Richard W.M. Jones wrote: > >On Thu, Mar 07, 2019 at 09:15:23AM +0100, Miro Hrončok wrote: > >>On 07. 03. 19 9:11, Richard W.M. Jones wrote: > >>> > >>>Related to: > >>>https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal > >>> > >>>I have some packages which build python 2 subpackages, but they are > >>>not "python packages" as such. One example is nbdkit: > >>> > >>> https://koji.fedoraproject.org/koji/buildinfo?buildID=1225638 > >>> > >>>This package isn't listed in > >>>https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal/List > >>>I don't know how that list was constructed, whether this was missed by > >>>accident, or design. > >> > >>Only Python 2 modules (i.e. stuff that installs into > >>/usr/lib(64)?/python2.7) were detected. Yours seem to be like some > >>sort of plugins. > > > >Another one would be python2-libguestfs which does install files in > >/usr/lib64/python2.7 and is present in the list, but wasn't removed by > >anyone nor was a bug filed against it AFAICS. Anyway I can deal with > >this one too. > > > I get this on the latest compose from February: > > $ dnf repoquery --repo=rawhide --repo=rawhide-source --whatrequires > python2-libguestfs > imagefactory-0:1.1.11-2.fc30.noarch > kimchi-0:1.5.1-11.fc30.noarch > oz-0:0.16.0-8.fc30.noarch > vdsm-hook-fileinject-0:4.18.999-447.git0bb7717.fc28.noarch > > While I'd like to get rid of as much Python 2 packages as possible, > I'd advise not to remove packages that are being dependent upon > (unless properly communicated with the maintainers of the dependent > packages). OK I see, thanks. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ 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
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 ? Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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
On Thu, Mar 07, 2019 at 09:47:51AM +, Daniel P. Berrangé wrote: > On Thu, Mar 07, 2019 at 08:29:52AM +, Richard W.M. Jones wrote: > > On Thu, Mar 07, 2019 at 08:02:00AM +, Richard W.M. Jones wrote: > > > DEBUG util.py:554: BUILDSTDERR: Error: > > > DEBUG util.py:554: BUILDSTDERR: Problem: package > > > libvirt-daemon-kvm-5.1.0-1.fc30.x86_64 requires > > > libvirt-daemon-driver-storage = 5.1.0-1.fc30, but none of the providers > > > can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > libguestfs-1:1.40.2-2.fc30.x86_64 requires libvirt-daemon-kvm >= > > > 0.10.2-3, but none of the providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > libvirt-daemon-driver-storage-5.1.0-1.fc30.x86_64 requires > > > libvirt-daemon-driver-storage-rbd = 5.1.0-1.fc30, but none of the > > > providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > libguestfs-devel-1:1.40.2-2.fc30.x86_64 requires > > > libguestfs.so.0()(64bit), but none of the providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > libguestfs-devel-1:1.40.2-2.fc30.x86_64 requires libguestfs(x86-64) = > > > 1:1.40.2-2.fc30, but none of the providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - package > > > libvirt-daemon-driver-storage-rbd-5.1.0-1.fc30.x86_64 requires > > > librados.so.2()(64bit), but none of the providers can be installed > > > DEBUG util.py:554: BUILDSTDERR: - conflicting requests > > > DEBUG util.py:554: BUILDSTDERR: - nothing provides > > > libcrc32.so()(64bit) needed by librados2-1:14.1.0-1.fc30.x86_64 > > > > > > (from https://kojipkgs.fedoraproject.org//work/tasks/15/33260015/root.log) > > > > > > This looks like it might be fixed by ceph-14.1.0-2.fc30. > > > > > > Do we just need to add a build override, or does this require a > > > further fix in libvirt and/or ceph? > > > > To answer my own question - I added a 5 day build override and that > > seems to have fixed things. > > So I guess there was a ceph override already when we built it, and this > this expired preventing installs until you re-added the override ? I'm not sure if the libvirt build would have been affected by this? In any case the 5 day override fixes things for now. There is no Bodhi update for ceph however. I'm not sure if we need one. Up til quite recently Bodhi was not required for F30, but I see now updates appearing: https://bodhi.fedoraproject.org/updates/?releases=F30&status=pending Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libvirt uninstallable in F30 Koji because of broken ceph dep
Am Donnerstag, den 07.03.2019, 09:53 + schrieb Richard W.M. Jones: > On Thu, Mar 07, 2019 at 09:47:51AM +, Daniel P. Berrangé wrote: > > On Thu, Mar 07, 2019 at 08:29:52AM +, Richard W.M. Jones wrote: > > > On Thu, Mar 07, 2019 at 08:02:00AM +, Richard W.M. Jones > > > wrote: > > > > DEBUG util.py:554: BUILDSTDERR: Error: > > > > DEBUG util.py:554: BUILDSTDERR: Problem: package libvirt- > > > > daemon-kvm-5.1.0-1.fc30.x86_64 requires libvirt-daemon-driver- > > > > storage = 5.1.0-1.fc30, but none of the providers can be > > > > installed > > > > DEBUG util.py:554: BUILDSTDERR: - package libguestfs- > > > > 1:1.40.2-2.fc30.x86_64 requires libvirt-daemon-kvm >= 0.10.2-3, > > > > but none of the providers can be installed > > > > DEBUG util.py:554: BUILDSTDERR: - package libvirt-daemon- > > > > driver-storage-5.1.0-1.fc30.x86_64 requires libvirt-daemon- > > > > driver-storage-rbd = 5.1.0-1.fc30, but none of the providers can > > > > be installed > > > > DEBUG util.py:554: BUILDSTDERR: - package libguestfs-devel- > > > > 1:1.40.2-2.fc30.x86_64 requires libguestfs.so.0()(64bit), but > > > > none of the providers can be installed > > > > DEBUG util.py:554: BUILDSTDERR: - package libguestfs-devel- > > > > 1:1.40.2-2.fc30.x86_64 requires libguestfs(x86-64) = 1:1.40.2- > > > > 2.fc30, but none of the providers can be installed > > > > DEBUG util.py:554: BUILDSTDERR: - package libvirt-daemon- > > > > driver-storage-rbd-5.1.0-1.fc30.x86_64 requires > > > > librados.so.2()(64bit), but none of the providers can be > > > > installed > > > > DEBUG util.py:554: BUILDSTDERR: - conflicting requests > > > > DEBUG util.py:554: BUILDSTDERR: - nothing provides > > > > libcrc32.so()(64bit) needed by librados2-1:14.1.0-1.fc30.x86_64 > > > > > > > > (from > > > > https://kojipkgs.fedoraproject.org//work/tasks/15/33260015/root.log > > > > ) > > > > > > > > This looks like it might be fixed by ceph-14.1.0-2.fc30. > > > > > > > > Do we just need to add a build override, or does this require a > > > > further fix in libvirt and/or ceph? > > > > > > To answer my own question - I added a 5 day build override and > > > that > > > seems to have fixed things. > > > > So I guess there was a ceph override already when we built it, and > > this > > this expired preventing installs until you re-added the override ? > > I'm not sure if the libvirt build would have been affected by this? > In any case the 5 day override fixes things for now. > > There is no Bodhi update for ceph however. I'm not sure if we need > one. Up til quite recently Bodhi was not required for F30, but I see > now updates appearing: > > https://bodhi.fedoraproject.org/updates/?releases=F30&status=pending Hi, the recent build of ceph was made after the bodhi activation point, so an update for it needs to be submitted. As we are in the beta freeze for now, you should also ask for a freeze exception. You should tag the buildroot override for ceph up until Apr 4th, to make sure it will be available during the hole possible time of the beta freeze. Björn signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The state of Zanata Python client (Python 3 support)
On Thu, 2019-03-07 at 12:38 +0800, Jens-Ulrik Petersen wrote: > Thanks to Sundeep, who has already started and worked on this. > So hopefully we will have a working py3 zanata-python-client for F30+ soon. > :-) Nice & thanks in advance! :) Can definitely help testing the new version once it become available. :) > See https://github.com/zanata/zanata-python-client/pull/52 > > Jens > > > On Tue, Mar 5, 2019 at 9:56 PM Martin Kolman wrote: > > Hi, > > > > I come from the tha Anaconda installer project and we use the Python Zanata > > client to push & pull translations from > > the > > > > Fedora Zanata instance where Anaconda is being translated. As far as I > > know, there are many other projects that do > > the > > > > same (Blivet, Blivet-GUI, Storaged, etc.), even though it might not be > > readily apparent due to not directly > > depending on > > > > the python2-zanata-client package, but rather just installing it manually > > on the machine where builds are being > > created. > > > > > > > > As we all know, Python 2 is going away soon (in less than 10 months) and > > Fedora is already doing a lot of work to > > get > > > > remove as many Python 2 packages as possible. > > > > > > > > Therefore it's pretty alarming that something as important as a client for > > the official Fedora translation service > > is > > > > still Python 2-only with not even a hint of Python 3 support being worked > > on as far as I can tell. Python Zanata > > client > > > > upstream[0] has last activity ~year ago, but seems to be mostly dead since > > 2017 with no support for Python 3 in > > sight. > > > > > > > > There are also some bugs & an upstream issue inquiring about Python 3 > > support in the Zanata Python client: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1676408 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1685550 > > > > https://zanata.atlassian.net/browse/ZNTA-2791 > > > > > > > > And at the moment, the client can't even be installed on Rawhide and F30: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1676388 > > > > > > > > This has prompted me to write this email & to CC all people mentioned as > > maintainers on the package page[0]. > > > > > > > > What can be done about this ? Is Python 3 support for the Zanata Python > > client being worked on, so that we won't > > loose > > > > the package ? Or do we just wait for it to be dropped from Fedora - and > > then what ? > > > > > > > > Hopefully someone can answer these questions. :) > > > > > > > > Best Wishes > > > > Martin Kolman > > > > > > > > [0] https://github.com/zanata/zanata-python-client > > > > [1] https://src.fedoraproject.org/rpms/zanata-python-client > > > > ___ > > > > 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 > > > > > ___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 ___ 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
Downgrading glibc from Rawhide removed /bin/sh (!)
$ sudo dnf install glibc-headers.i686 Last metadata expiration check: 0:53:05 ago on Thu 07 Mar 2019 09:42:26 GMT. Dependencies resolved. Package Architecture Version Repository Size Installing: glibc-headers i686 2.29-7.fc30 rawhide 475 k Downgrading: glibc i686 2.29-7.fc30 rawhide 3.7 M glibc x86_64 2.29-7.fc30 rawhide 3.9 M glibc-all-langpacks x86_64 2.29-7.fc30 rawhide25 M glibc-common x86_64 2.29-7.fc30 rawhide 822 k glibc-devel i686 2.29-7.fc30 rawhide 1.0 M glibc-devel x86_64 2.29-7.fc30 rawhide 1.0 M glibc-headers x86_64 2.29-7.fc30 rawhide 474 k glibc-langpack-en x86_64 2.29-7.fc30 rawhide 820 k glibc-static x86_64 2.29-7.fc30 rawhide 1.9 M Transaction Summary Install1 Package Downgrade 9 Packages Total download size: 39 M Is this ok [y/N]: y Downloading Packages: (1/10): glibc-2.29-7.fc30.x86_64.rpm661 kB/s | 3.9 MB 00:06 (2/10): glibc-2.29-7.fc30.i686.rpm 610 kB/s | 3.7 MB 00:06 (3/10): glibc-common-2.29-7.fc30.x86_64.rpm 737 kB/s | 822 kB 00:01 (4/10): glibc-devel-2.29-7.fc30.i686.rpm675 kB/s | 1.0 MB 00:01 (5/10): glibc-devel-2.29-7.fc30.x86_64.rpm 926 kB/s | 1.0 MB 00:01 (6/10): glibc-headers-2.29-7.fc30.x86_64.rpm609 kB/s | 474 kB 00:00 (7/10): glibc-langpack-en-2.29-7.fc30.x86_64.rp 968 kB/s | 820 kB 00:00 (8/10): glibc-headers-2.29-7.fc30.i686.rpm 934 kB/s | 475 kB 00:00 (9/10): glibc-static-2.29-7.fc30.x86_64.rpm 882 kB/s | 1.9 MB 00:02 (10/10): glibc-all-langpacks-2.29-7.fc30.x86_64 1.3 MB/s | 25 MB 00:18 Total 2.0 MB/s | 39 MB 00:20 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing:1/1 Downgrading : glibc-all-langpacks-2.29-7.fc30.x86_641/19 Downgrading : glibc-common-2.29-7.fc30.x86_64 2/19 Downgrading : glibc-langpack-en-2.29-7.fc30.x86_64 3/19 Running scriptlet: glibc-2.29-7.fc30.x86_64 4/19 Downgrading : glibc-2.29-7.fc30.x86_64 4/19 Running scriptlet: glibc-2.29-7.fc30.x86_64 4/19 Running scriptlet: glibc-headers-2.29-7.fc30.x86_64 5/19 Downgrading : glibc-headers-2.29-7.fc30.x86_64 5/19 Downgrading : glibc-devel-2.29-7.fc30.x86_646/19 Running scriptlet: glibc-headers-2.29-7.fc30.i6867/19 Installing : glibc-headers-2.29-7.fc30.i6867/19 Running scriptlet: glibc-2.29-7.fc30.i6868/19 Downgrading : glibc-2.29-7.fc30.i6868/19 Running scriptlet: glibc-2.29-7.fc30.i6868/19 Downgrading : glibc-devel-2.29-7.fc30.i686 9/19 Downgrading : glibc-static-2.29-7.fc30.x86_64 10/19 Cleanup : glibc-devel-2.29.9000-4.fc31.i68611/19 Cleanup : glibc-2.29.9000-4.fc31.i686 12/19 Cleanup : glibc-static-2.29.9000-4.fc31.x86_64 13/19 Cleanup : glibc-devel-2.29.9000-4.fc31.x86_64 14/19 Cleanup : glibc-headers-2.29.9000-4.fc31.x86_6415/19 Cleanup : glibc-langpack-en-2.29.9000-4.fc31.x86_6416/19 Cleanup : glibc-2.29.9000-4.fc31.x86_6417/19 Cleanup : glibc-all-langpacks-2.29.9000-4.fc31.x86_64 18/19 Running scriptlet: glibc-all-langpacks-2.29.9000-4.fc31.x86_64 18/19 Cleanup : glibc-common-2.29.9000-4.fc31.x86_64 19/19 Running scriptlet: glibc-all-langpacks-2.29-7.fc30.x86_64 19/19 Running scriptlet: glibc-common-2.29.9000-4.fc31.x86_64 19/19 error: failed to exec scriptlet interpreter /bin/sh: No such file or directory warning: %triggerin(info-6.5-12.fc30.x86_64) scriptlet failed
Re: Downgrading glibc from Rawhide removed /bin/sh (!)
Actually it's more subtle. It didn't remove the files, but it did break something really fundamental, perhaps execv? Perhaps new binaries cannot link with the slightly older glibc? $ echo /usr/bin/ls /usr/bin/ls $ /usr/bin/ls -bash: /usr/bin/ls: No such file or directory Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: Downgrading glibc from Rawhide removed /bin/sh (!)
Hi, On 07-03-19 11:45, Richard W.M. Jones wrote: Actually it's more subtle. It didn't remove the files, but it did break something really fundamental, perhaps execv? Perhaps new binaries cannot link with the slightly older glibc? $ echo /usr/bin/ls /usr/bin/ls $ /usr/bin/ls -bash: /usr/bin/ls: No such file or directory In my experience with breaking systems through glibc changes, the "No such file or directory" error is not about ls, it is about /lib64/ld-linux.so.2 missing. On my system I have: [hans@shalem ~]$ ls -l /lib/ld-linux.so.2 lrwxrwxrwx. 1 root root 10 14 dec 01:46 /lib/ld-linux.so.2 -> ld-2.28.so I suspect the symlink somehow ended up broken or missing due to the downgrade. Regards, Hans ___ 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: Downgrading glibc from Rawhide removed /bin/sh (!)
* Richard W. M. Jones: > $ sudo dnf install glibc-headers.i686 … > Downgrading: That looks like a bug in itself. The last time I looked at something similar, I saw this: RPM would not adjust a pre-existing symbolic link to a new target very late in the transaction. Like deleting old files which are gone in an update or downgrade, this does *not* happen when the unpacking of the replacement package happens, but towards the conclusion of the transaction. In the meantime, scriptlets run with the broken file system. In your case, maybe one of the scriptlet errors prevented the final step with the adjustment of the symbolic link by RPM. (Just to be clear, the symbolic link is regularly packaged, it's not something that we manage using scripts.) Thanks, Florian ___ 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: Downgrading glibc from Rawhide removed /bin/sh (!)
On Thu, Mar 07, 2019 at 12:13:22PM +0100, Florian Weimer wrote: > * Richard W. M. Jones: > > > $ sudo dnf install glibc-headers.i686 > … > > Downgrading: > > That looks like a bug in itself. > > The last time I looked at something similar, I saw this: RPM would not > adjust a pre-existing symbolic link to a new target very late in the > transaction. Like deleting old files which are gone in an update or > downgrade, this does *not* happen when the unpacking of the replacement > package happens, but towards the conclusion of the transaction. In the > meantime, scriptlets run with the broken file system. > > In your case, maybe one of the scriptlet errors prevented the final step > with the adjustment of the symbolic link by RPM. > > (Just to be clear, the symbolic link is regularly packaged, it's not > something that we manage using scripts.) I fixed this by typing ‘ldconfig’ (thankfully I had a root shell open on the IPMI console ...) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: Proposal: Abandon v8 package
On Thu, 28 Feb 2019 at 16:24, Stephen Gallagher wrote: > > On Wed, Feb 27, 2019 at 7:02 PM Elliott Sales de Andrade > wrote: > > > > Let's try this again, but CC'ing the package owners. > > > > On 2019-02-17 9:12 p.m., Elliott Sales de Andrade wrote: > > > Hi, > > > > > > Sorry for resurrecting a long-dead thread, but a few things happened > > > recently: > > > 1. v8 was just retired last week or so, > > > 2. R-V8 just ported itself from v8-314 to v8 LTS 6/7. > > > > > > Currently, R-V8 supports both v8-314 and v8, but as the latter fixes > > > several downstream package issues, it is the recommended build target. I > > > expect that eventually they will stop supporting 314 as well. This leaves > > > me in a bit of a pickle as it does not bundle v8 and neither I nor > > > upstream have any plans to build it ourselves. > > > > > >> For all of these same reasons, the Node.js SIG opted to carry a bundled > > >> copy of v8 in that package as well. I think we should move to have v8 > > >> considered to be a copylib for all reasonable purposes within Fedora. > > > > > > In Debian, the nodejs package provides a stable *shared* v8 library, and > > > the recommended install is against libnode-dev. Unfortunately, in Fedora, > > > while nodejs-devel provides v8.h, it does *not* provide any shared > > > library. > > > > > > Is this something we can also do in Fedora, i.e., split out a nodejs-libs > > > subpackage, or similar? > > > > > > I've been keeping the Node.js packages in Fedora alive, but on > life-support, for a couple years now. I don't have the cycles to look > into a significant rework of how they're designed. If you have ideas > for how to do what you're asking, I will happily review a pull request > to http://src.fedoraproject.org/rpms/nodejs OK, I've sent a pull-request to do so [1]. It essentially mimics what the Debian package does (pass --shared and then manually install the executable since their script will only install one or the other.) The other changes just make sure paths are correct for tests to work. It works for me [2] to build R-V8 (though copr gets stuck building nodejs on x86_64 for some reason.) [1] https://src.fedoraproject.org/rpms/nodejs/pull-request/4 [2] https://copr.fedorainfracloud.org/coprs/qulogic/nodejs-R-V8/builds/ -- Elliott ___ 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: Downgrading glibc from Rawhide removed /bin/sh (!)
On 3/7/19 1:13 PM, Florian Weimer wrote: * Richard W. M. Jones: $ sudo dnf install glibc-headers.i686 … Downgrading: That looks like a bug in itself. The last time I looked at something similar, I saw this: RPM would not adjust a pre-existing symbolic link to a new target very late in the transaction. Like deleting old files which are gone in an update or downgrade, this does *not* happen when the unpacking of the replacement package happens, but towards the conclusion of the transaction. In the meantime, scriptlets run with the broken file system. In your case, maybe one of the scriptlet errors prevented the final step with the adjustment of the symbolic link by RPM. (Just to be clear, the symbolic link is regularly packaged, it's not something that we manage using scripts.) IIRC the issue is that at when ldconfig runs from the package scripts, on downgrade the newer file is still on disk and thus ldconfig leaves the link the way it is, but at the end of transaction it'll be gone and symlinks can be broken. $ rpm -q --filetriggers glibc-common transfiletriggerin scriptlet (using /bin/sh) -- /lib, /lib64, /usr/lib, /usr/lib64 /sbin/ldconfig transfiletriggerpostun scriptlet (using /bin/sh) -- /lib, /lib64, /usr/lib, /usr/lib64 /sbin/ldconfig The %transfiletriggerpostun would've probably fixed it if it used -p instead of shell. - Panu - ___ 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: Proposal: Abandon v8 package
Great, thanks. I took a look and did a review. I have a couple minor tweaks I'd like to see, then I'll go ahead and merge it (and backport/sideport it to the 8.x and 11.x branches) On Thu, Mar 7, 2019 at 6:44 AM Elliott Sales de Andrade wrote: > > On Thu, 28 Feb 2019 at 16:24, Stephen Gallagher wrote: > > > > On Wed, Feb 27, 2019 at 7:02 PM Elliott Sales de Andrade > > wrote: > > > > > > Let's try this again, but CC'ing the package owners. > > > > > > On 2019-02-17 9:12 p.m., Elliott Sales de Andrade wrote: > > > > Hi, > > > > > > > > Sorry for resurrecting a long-dead thread, but a few things happened > > > > recently: > > > > 1. v8 was just retired last week or so, > > > > 2. R-V8 just ported itself from v8-314 to v8 LTS 6/7. > > > > > > > > Currently, R-V8 supports both v8-314 and v8, but as the latter fixes > > > > several downstream package issues, it is the recommended build target. > > > > I expect that eventually they will stop supporting 314 as well. This > > > > leaves me in a bit of a pickle as it does not bundle v8 and neither I > > > > nor upstream have any plans to build it ourselves. > > > > > > > >> For all of these same reasons, the Node.js SIG opted to carry a bundled > > > >> copy of v8 in that package as well. I think we should move to have v8 > > > >> considered to be a copylib for all reasonable purposes within Fedora. > > > > > > > > In Debian, the nodejs package provides a stable *shared* v8 library, > > > > and the recommended install is against libnode-dev. Unfortunately, in > > > > Fedora, while nodejs-devel provides v8.h, it does *not* provide any > > > > shared library. > > > > > > > > Is this something we can also do in Fedora, i.e., split out a > > > > nodejs-libs subpackage, or similar? > > > > > > > > > > I've been keeping the Node.js packages in Fedora alive, but on > > life-support, for a couple years now. I don't have the cycles to look > > into a significant rework of how they're designed. If you have ideas > > for how to do what you're asking, I will happily review a pull request > > to http://src.fedoraproject.org/rpms/nodejs > > OK, I've sent a pull-request to do so [1]. It essentially mimics what > the Debian package does (pass --shared and then manually install the > executable since their script will only install one or the other.) The > other changes just make sure paths are correct for tests to work. It > works for me [2] to build R-V8 (though copr gets stuck building nodejs > on x86_64 for some reason.) > > [1] https://src.fedoraproject.org/rpms/nodejs/pull-request/4 > [2] https://copr.fedorainfracloud.org/coprs/qulogic/nodejs-R-V8/builds/ > > -- > Elliott ___ 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 31 System-Wide Change proposal: Gating Rawhide - Single package updates
On 3/2/19 5:02 PM, Pierre-Yves Chibon wrote: > On Fri, Mar 01, 2019 at 06:57:48PM -0800, Tom Stellard wrote: >> On 03/01/2019 01:19 PM, Ben Cotton wrote: >>> https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates >>> >>> == Summary == >>> We want to gate packages on test results before they can land in >>> rawhide. This will reduce the amount of broken dependency, >>> uninstallable packages and broken composes leading to a more stable >>> rawhide as well as less work on the infrastructure and rel-eng teams >>> to keep composes working. >>> >> >> Does the gating prevent packages from being tagged at all so that they >> won't even end up in the buildroot, or does it just gate packages from >> going into a compose? > > It gates the package from entering the buildroot, which will impact the > packages > going into a compose, but as a side effect. > Given it blocks packages from entering buildroot, I wonder if it is a good idea to start gating whole Rawhide lifetime, I mean, from the starting of a ready-to-release release branched out of Rawhide? My case is, we have a set of packages to update each release. They cannot do in parallel - they depend on one another. Currently we only update them in Rawhide, because each package can get into buildroot shortly after we build it, and we don't need to file a buildroot-override. Once even packages cannot get into Rawhide automatically (for example, I need to click a "waive test result" or something), this is more like a burden. As for the Single build updates vs multi build updates ratio, I don't quite understand what the number is from - does it comes out of Bodhi? If it means the updates in Bodhi, I want to mention that, in my case, I never want to update multi build updates in a stable (or post-freeze) release. Thus I seldom file multi build updates in bodhi. Especially we don't need to file Bodhi to get packages into Rawhide at this point, this maybe misleading in deciding to enable gating for Rawhide. As a summarize, I think it is a good idea to have some sort of gating. But I think we need to think carefully if we do really need to gate Rawhide. > [...] >>> CI system >>> Nothing should change for the CI system but we will have to confirm >>> this and test in staging that they behave as expected. >>> >> I think this issue might have to be fixed first, otherwise we would end >> up with a lot of false negatives: >> https://pagure.io/fedora-ci/general/issue/20 > > Thanks for your feedback, I'll follow up on this ticket to see if we can get > it > sorted out. > > > Pierre > ___ > 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 > -- Zamir SUN GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ 想了解更多中文资讯，访问 https://zh.fedoracommunity.org/ ___ 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 31 System-Wide Change proposal: Gating Rawhide - Single package updates
On Thu, Mar 07, 2019 at 10:24:00PM +0800, Zamir SUN wrote: > > > On 3/2/19 5:02 PM, Pierre-Yves Chibon wrote: > > On Fri, Mar 01, 2019 at 06:57:48PM -0800, Tom Stellard wrote: > >> On 03/01/2019 01:19 PM, Ben Cotton wrote: > >>> https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates > >>> > >>> == Summary == > >>> We want to gate packages on test results before they can land in > >>> rawhide. This will reduce the amount of broken dependency, > >>> uninstallable packages and broken composes leading to a more stable > >>> rawhide as well as less work on the infrastructure and rel-eng teams > >>> to keep composes working. > >>> > >> > >> Does the gating prevent packages from being tagged at all so that they > >> won't even end up in the buildroot, or does it just gate packages from > >> going into a compose? > > > > It gates the package from entering the buildroot, which will impact the > > packages > > going into a compose, but as a side effect. > > > > Given it blocks packages from entering buildroot, I wonder if it is a > good idea to start gating whole Rawhide lifetime, I mean, from the > starting of a ready-to-release release branched out of Rawhide? > > My case is, we have a set of packages to update each release. They > cannot do in parallel - they depend on one another. Currently we only > update them in Rawhide, because each package can get into buildroot > shortly after we build it, and we don't need to file a > buildroot-override. Once even packages cannot get into Rawhide > automatically (for example, I need to click a "waive test result" or > something), this is more like a burden. So what you are describing is basically the case of multi-packages update. You want to ship as one packages that depend on each other and should be ship as one unit. The current approach specifically does not support this use case. There are two ways to go about this: - Do not opt-in into the gating (ie: do not add a gating.yaml in your dist-git repo) - Do opt-in but when you need something faster, opt-out, by simply building the package in rawhide-candidate (or its equivalent) directly. > As for the Single build updates vs multi build updates ratio, I don't > quite understand what the number is from - does it comes out of Bodhi? They do yes and indeed as you're mentioning they are informative but likely not fully representative of rawhide. > If it means the updates in Bodhi, I want to mention that, in my case, I > never want to update multi build updates in a stable (or post-freeze) > release. Thus I seldom file multi build updates in bodhi. Especially we > don't need to file Bodhi to get packages into Rawhide at this point, > this maybe misleading in deciding to enable gating for Rawhide. The bodhi updates will be filled automatically and if tests pass (or if there are no gating.yaml) the build will land in rawhide, automatically as well, just as it does today. The point of bodhi is to give us a way to see in which state is a package or why a package that was built did not land in the rawhide buildroot in a place that is accessible to everyone in the community. > As a summarize, I think it is a good idea to have some sort of gating. > But I think we need to think carefully if we do really need to gate Rawhide. I don't think there are so many ways to stabilize rawhide so that compose (for example) pass more often than they fail (there hasn't been a successful rawhide compose in a week). CI and gating is one of them and one that is pretty standard in our industry. Pierre ___ 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 31 System-Wide Change proposal: Gating Rawhide - Single package updates
On Thu, Mar 7, 2019 at 10:07 AM Pierre-Yves Chibon wrote: > > On Thu, Mar 07, 2019 at 10:24:00PM +0800, Zamir SUN wrote: > > > > > > On 3/2/19 5:02 PM, Pierre-Yves Chibon wrote: > > > On Fri, Mar 01, 2019 at 06:57:48PM -0800, Tom Stellard wrote: > > >> On 03/01/2019 01:19 PM, Ben Cotton wrote: > > >>> https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates > > >>> > > >>> == Summary == > > >>> We want to gate packages on test results before they can land in > > >>> rawhide. This will reduce the amount of broken dependency, > > >>> uninstallable packages and broken composes leading to a more stable > > >>> rawhide as well as less work on the infrastructure and rel-eng teams > > >>> to keep composes working. > > >>> > > >> > > >> Does the gating prevent packages from being tagged at all so that they > > >> won't even end up in the buildroot, or does it just gate packages from > > >> going into a compose? > > > > > > It gates the package from entering the buildroot, which will impact the > > > packages > > > going into a compose, but as a side effect. > > > > > > > Given it blocks packages from entering buildroot, I wonder if it is a > > good idea to start gating whole Rawhide lifetime, I mean, from the > > starting of a ready-to-release release branched out of Rawhide? > > > > My case is, we have a set of packages to update each release. They > > cannot do in parallel - they depend on one another. Currently we only > > update them in Rawhide, because each package can get into buildroot > > shortly after we build it, and we don't need to file a > > buildroot-override. Once even packages cannot get into Rawhide > > automatically (for example, I need to click a "waive test result" or > > something), this is more like a burden. > > So what you are describing is basically the case of multi-packages update. You > want to ship as one packages that depend on each other and should be ship as > one > unit. > The current approach specifically does not support this use case. > There are two ways to go about this: > - Do not opt-in into the gating (ie: do not add a gating.yaml in your dist-git > repo) > - Do opt-in but when you need something faster, opt-out, by simply building > the > package in rawhide-candidate (or its equivalent) directly. > > > As for the Single build updates vs multi build updates ratio, I don't > > quite understand what the number is from - does it comes out of Bodhi? > > They do yes and indeed as you're mentioning they are informative but likely > not > fully representative of rawhide. > > > If it means the updates in Bodhi, I want to mention that, in my case, I > > never want to update multi build updates in a stable (or post-freeze) > > release. Thus I seldom file multi build updates in bodhi. Especially we > > don't need to file Bodhi to get packages into Rawhide at this point, > > this maybe misleading in deciding to enable gating for Rawhide. > > The bodhi updates will be filled automatically and if tests pass (or if there > are no gating.yaml) the build will land in rawhide, automatically as well, > just > as it does today. > The point of bodhi is to give us a way to see in which state is a package or > why > a package that was built did not land in the rawhide buildroot in a place that > is accessible to everyone in the community. > > > As a summarize, I think it is a good idea to have some sort of gating. > > But I think we need to think carefully if we do really need to gate Rawhide. > > I don't think there are so many ways to stabilize rawhide so that compose (for > example) pass more often than they fail (there hasn't been a successful > rawhide > compose in a week). CI and gating is one of them and one that is pretty > standard > in our industry. > I hate to be the downer here, but I'm generally opposed to this idea as it stands. My ability to develop against Rawhide is principally centered around the fact I can push packages and have them depend on each other. Today, there is no freely accessible way for people to atomically merge changes into the distribution. There's no way for people to freely create spaces to do a bunch of work on a bunch of packages at once and then merge it. We kind of fake this by having to ask releng to grant unto a packager or packagers a side-tag, which work is done there, and then it's merged back into the distribution. But that model has only worked so far because we have nothing like this in place for Rawhide, so we can push all the stuff there, make sure it works, and then merge it into branches. This is how KDE updates are done, for example. And occasionally, the GNOME desktop is updated in the same manner. The fatal misunderstanding here is that people think there's a distinction between "single" and "multi" updates in Rawhide, when in fact that doesn't exist. This proposal is doomed to failure because it assumes stable updates workflows translate to development workflows. And they don't. The reason why single updates
Re: Downgrading glibc from Rawhide removed /bin/sh (!)
* Panu Matilainen: > On 3/7/19 1:13 PM, Florian Weimer wrote: >> * Richard W. M. Jones: >> >>> $ sudo dnf install glibc-headers.i686 >> … >>> Downgrading: >> >> That looks like a bug in itself. >> >> The last time I looked at something similar, I saw this: RPM would not >> adjust a pre-existing symbolic link to a new target very late in the >> transaction. Like deleting old files which are gone in an update or >> downgrade, this does *not* happen when the unpacking of the replacement >> package happens, but towards the conclusion of the transaction. In the >> meantime, scriptlets run with the broken file system. >> >> In your case, maybe one of the scriptlet errors prevented the final step >> with the adjustment of the symbolic link by RPM. >> >> (Just to be clear, the symbolic link is regularly packaged, it's not >> something that we manage using scripts.) > > IIRC the issue is that at when ldconfig runs from the package scripts, > on downgrade the newer file is still on disk and thus ldconfig leaves > the link the way it is, but at the end of transaction it'll be gone > and symlinks can be broken. Is there a chance that RPM will be changed to run more scriptlets with the final disk contents? > $ rpm -q --filetriggers glibc-common > transfiletriggerin scriptlet (using /bin/sh) -- /lib, /lib64, > /usr/lib, /usr/lib64 > /sbin/ldconfig > transfiletriggerpostun scriptlet (using /bin/sh) -- /lib, /lib64, > /usr/lib, /usr/lib64 > /sbin/ldconfig > > The %transfiletriggerpostun would've probably fixed it if it used -p > instead of shell. We switched to the shell for the benefit of rpm-ostree. Thanks, Florian ___ 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: Introducing packit
Hi Miro, sorry for a late reply: I wanted to think it through. Comments inline. On Tue, Feb 26, 2019 at 4:43 PM Miro Hrončok wrote: > > On 20. 02. 19 23:24, Tomas Tomecek wrote: > > Hello, > > > > at DevConf.cz, we have introduced a new project: packit [1] [2]. > > [1] https://www.youtube.com/watch?v=KpF27v6K4Oc > > [2] https://github.com/packit-service/packit > > From the ticket: > > >> FESCo is concerned that the presented idea of how this automation > >> should work is only applicable to a very limited set of packages and > >> would rather see a focus on automating stuff for greater > >> audience. > > > > Yes and no. With source-git [3] this is applicable to any project. > > > > [3] https://github.com/packit-service/packit#ehm-whats-source-git > > This sounds like it is only applicable to projects: > > - controlled by Fedora AND > - not concerned by the separation of concerns between upstream and > downstream. That's correct. Our short-term plan for packit is that people who are upstreams (or are interested in the source-git workflow) would use it to land their releases into Fedora. > > However it says something about source-git only projects as well. This seems > like it is adding one extra level of complexity. Care to elaborate how this > works exactly? > > A) for the package maintain who deliberately chose to do this Such packager would only work in the source-git/upstream repository and would NOT need to touch dist-git in any way: packit would handle everything. Basically: do work in the upstream repo, make a release and packit would propose a PR in Fedora dist-git to update to the upstream release. Very similar steps for source-git. > B) for a provenpackager doing a mass change (e.g. removing py2 subpackages) Just do it. We plan for packit to sync spec file changes back to upstream/source-git (listen to fedmsg events from dist-git). So that they are equal in both places. > C) for releng doing a mass rebuild ^ it's the same I understand that the workflow is not suitable for a bunch of projects. Right now we have a set of goals to fulfill. Once they are done (by Flock), we can start talking about how to make it suitable for everyone. If that makes sense. Tomas ___ 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
license change for python-metar
For your information: the python-metar package has changed license from MIT to BSD, starting with release 1.7.0. see: https://github.com/python-metar/python-metar/releases https://src.fedoraproject.org/rpms/python-metar best regards, Jos de Kloe. ___ 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: Scratch build uploads to koji VERY SLOW
On Wed, Mar 6, 2019 at 6:39 PM Kevin Fenzi wrote: > On 3/6/19 4:14 PM, Richard Shaw wrote: > > > > New since the last couple of weeks but I've been more active working on > > FTBFS issues so can't say exactly when it started. It's never been super > > speedy but also never been this painful. > > Odd. I can't think of anything on the server end that has changed > recently that might cause this. It's just as fast as always for me. > > Has curl been updated on your machine(s) around the time it started? > > Does koji --debug build scratch tag src.rpm > Hah... just tried it and the srpm uploaded at >1MB/sec... Thanks, RIchard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Packaging Question - Building the Binaries of my package
I’m a new maintainer and I’ve been trying to get my package, Open Liberty, into the Fedora repositories.
I currently build my rpms in a public Travis CI build. I do so by using wget to pull a zipped up pre-built openliberty package from “https://public.dhe.ibm.com/ibmdl/export/pub/software/openliberty/runtime/release/“ and simply extract it. The following is what I have in the %install portion of the spec file:
mkdir -p %{buildroot}/usr/share/%{name}
cd %{buildroot}/usr/share/%{name}
tar -zxf %{_topdir}/SOURCES/%{name}-%{version}.tar.gz
Recently, someone advised me that I have to build the binaries from the source code in the %install phase. That is to say that I have to make it transparent how the binaries (ex. jar) are built.
So after tinkering around, I can incorporate the building of the openliberty.zip into the Travis CI build but I cannot directly add it into the %install phase of the rpm spec file. Would that be fine?
Yours Sincerely,
Michael Zhang
Software Developer Test (WAS Install Team)
Phone: 1-9054133415
E-mail: michael.zh...@ibm.com
___
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 rawhide compose report: 20190306.n.1 changes
On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report wrote: > > OLD: Fedora-Rawhide-20190217.n.0 > NEW: Fedora-Rawhide-20190306.n.1 > > = SUMMARY = > Added images:13 > Dropped images: 7 > Added packages: 128 > Dropped packages:174 > Upgraded packages: 1745 > Downgraded packages: 165 Looks like it is second or third time when after report about release some batch of the packages nothing hit the ground/public repos. My understanding is that it is some glitch in release infrastructure. May we know what is the current situation? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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 rawhide compose report: 20190306.n.1 changes
On 3/7/19 11:35 AM, Tomasz Kłoczko wrote: > On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report > wrote: >> >> OLD: Fedora-Rawhide-20190217.n.0 >> NEW: Fedora-Rawhide-20190306.n.1 >> >> = SUMMARY = >> Added images:13 >> Dropped images: 7 >> Added packages: 128 >> Dropped packages:174 >> Upgraded packages: 1745 >> Downgraded packages: 165 > > Looks like it is second or third time when after report about release > some batch of the packages nothing hit the ground/public repos. > My understanding is that it is some glitch in release infrastructure. > May we know what is the current situation? What ground/public repos do you mean here? The master mirror is definitely updated. It's a large pile of changes, so other mirrors may take a bit longer than normal to sync. There's no glitch I am aware of, so more information would be helpful. kevin signature.asc Description: OpenPGP digital signature ___ 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 rawhide compose report: 20190306.n.1 changes
On 07. 03. 19 21:19, Kevin Fenzi wrote: On 3/7/19 11:35 AM, Tomasz Kłoczko wrote: On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report wrote: OLD: Fedora-Rawhide-20190217.n.0 NEW: Fedora-Rawhide-20190306.n.1 = SUMMARY = Added images:13 Dropped images: 7 Added packages: 128 Dropped packages:174 Upgraded packages: 1745 Downgraded packages: 165 Looks like it is second or third time when after report about release some batch of the packages nothing hit the ground/public repos. My understanding is that it is some glitch in release infrastructure. May we know what is the current situation? What ground/public repos do you mean here? The master mirror is definitely updated. It's a large pile of changes, so other mirrors may take a bit longer than normal to sync. There's no glitch I am aware of, so more information would be helpful. This seems quite OK: https://admin.fedoraproject.org/mirrormanager/propgation Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Packaging Question - Building the Binaries of my package
Am 07.03.19 um 19:49 schrieb Michael Zhang: > So after tinkering around, I can incorporate the building of the > openliberty.zip into the Travis CI build but I cannot directly add it into the > %install phase of the rpm spec file. Would that be fine? To the best of my knowledge all building from source has to happen on Fedora infrastructure. (There are - rare - exceptions for bootstrapping compilers but that it likely not the case for OpenLiberty.). Felix ___ 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: Packaging Question - Building the Binaries of my package
On Thu, Mar 07, 2019 at 06:49:12PM +, Michael Zhang wrote: > Recently, someone advised me that I have to build the binaries from the > source code in the %install phase. That is to say that I have to make it > transparent how the binaries (ex. jar) are built. As I understand it, in Debian, developers can build packages on their own systems and upload them. In Fedora, it doesn't work like that -- we have dist-git (https://src.fedoraproject.org/) which holds spec files and patches and references to source code in the look-aside cache. Those source files should be "pure" -- they shouldn't have pre-built binaries. > So after tinkering around, I can incorporate the building of the > openliberty.zip into the Travis CI build but I cannot directly add it > into the %install phase of the rpm spec file. Would that be fine? So, no. :) Travis CI is completely outside of our control, and we don't have a way to verify that the thing built there came from the provided source. And, someone without access to Travis CI wouldn't be able to replicate your build. -- Matthew Miller Fedora Project Leader ___ 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: Packaging Question - Building the Binaries of my package
On Thu, 2019-03-07 at 18:49 +, Michael Zhang wrote: > Recently, someone advised me that I have to build the binaries from > the source code in the %install phase. The building should happein the %build phase. The %install phase is where the resulting artifacts are copied into the 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://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 rawhide compose report: 20190306.n.1 changes
On Thu, 7 Mar 2019 at 15:31, Miro Hrončok wrote: > > On 07. 03. 19 21:19, Kevin Fenzi wrote: > > On 3/7/19 11:35 AM, Tomasz Kłoczko wrote: > >> On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report > >> wrote: > >>> > >>> OLD: Fedora-Rawhide-20190217.n.0 > >>> NEW: Fedora-Rawhide-20190306.n.1 > >>> > >>> = SUMMARY = > >>> Added images:13 > >>> Dropped images: 7 > >>> Added packages: 128 > >>> Dropped packages:174 > >>> Upgraded packages: 1745 > >>> Downgraded packages: 165 > >> > >> Looks like it is second or third time when after report about release > >> some batch of the packages nothing hit the ground/public repos. > >> My understanding is that it is some glitch in release infrastructure. > >> May we know what is the current situation? > > > > What ground/public repos do you mean here? The master mirror is > > definitely updated. It's a large pile of changes, so other mirrors may > > take a bit longer than normal to sync. > > > > There's no glitch I am aware of, so more information would be helpful. > > This seems quite OK: > > https://admin.fedoraproject.org/mirrormanager/propgation > > Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 > There was several weeks of packages needing to be synced out. I expect the mirrors will not be caught up until late Friday or Saturday. -- Stephen J Smoogen. ___ 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
Fedora Atomic Host Two Week Release Announcement: 29.20190306.2
A new Fedora Atomic Host update is available via an OSTree update: Version: 29.20190306.2 Commit(x86_64): 57297da7779ed8b7b7b9a0f39f6f12a703000a40cf451770fe23749a5558f60d Commit(aarch64): df56dcbc9ae6c0653122753b835668b4d729ea3943cb2541114dabd9c1d271bb Commit(ppc64le): d01ba1b8cca9e71bd2a4e549ef2759bc99102f86ce2ff812011b294dc4ce93ef We are releasing images from multiple architectures but please note that x86_64 architecture is the only one that undergoes automated testing at this time. Existing systems can be upgraded in place via e.g. `atomic host upgrade`. Corresponding image media for new installations can be downloaded from: https://getfedora.org/en/atomic/download/ Alternatively, image artifacts can be found at the following links: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190306.2.aarch64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190306.2.aarch64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190306.2.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190306.2.ppc64le.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190306.2.ppc64le.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190306.2.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190306.2.x86_64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190306.2.x86_64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190306.2.x86_64.vagrant-libvirt.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190306.2.x86_64.vagrant-virtualbox.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190306.2.iso Respective signed CHECKSUM files can be found here: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190306.2-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190306.2-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190306.2-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190306.2-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190306.2-x86_64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190306.2/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190306.2-x86_64-CHECKSUM For direct download, the "latest" targets are always available here: x86_64: https://getfedora.org/atomic_qcow2_x86_64_latest https://getfedora.org/atomic_raw_x86_64_latest https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest https://getfedora.org/atomic_dvd_ostree_x86_64_latest aarch64: https://getfedora.org/atomic_qcow2_aarch64_latest https://getfedora.org/atomic_raw_aarch64_latest https://getfedora.org/atomic_dvd_ostree_aarch64_latest ppc64le: https://getfedora.org/atomic_qcow2_ppc64le_latest https://getfedora.org/atomic_raw_ppc64le_latest https://getfedora.org/atomic_dvd_ostree_ppc64le_latest Filename fetching URLs are available here: x86_64: https://getfedora.org/atomic_qcow2_x86_64_latest_filename https://getfedora.org/atomic_raw_x86_64_latest_filename https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename aarch64: https://getfedora.org/atomic_qcow2_aarch64_latest_filename https://getfedora.org/atomic_raw_aarch64_latest_filename https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename ppc64le: https://getfedora.org/atomic_qcow2_ppc64le_latest_filename https://getfedora.org/atomic_raw_ppc64le_latest_filename https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filenam
Help needed regarding a build failure on x32 for python-twisted, might be kernel related
Hello,
I'm trying to build the new python-twisted 18.9.0, but it fails on 32 bits
architecture:
BUILDSTDERR: In file included from /usr/include/asm/socket.h:1,
BUILDSTDERR: from /usr/include/bits/socket.h:393,
BUILDSTDERR: from /usr/include/sys/socket.h:33,
BUILDSTDERR: from src/twisted/python/_sendmsg.c:16:
BUILDSTDERR: src/twisted/python/_sendmsg.c: In function 'init_sendmsg':
BUILDSTDERR: src/twisted/python/_sendmsg.c:158:64: error: '__kernel_long_t'
undeclared (first use in this function)
BUILDSTDERR: 158 | if (-1 == PyModule_AddIntConstant(module,
"SCM_TIMESTAMP", SCM_TIMESTAMP)) {
BUILDSTDERR: |
^
BUILDSTDERR: src/twisted/python/_sendmsg.c:158:64: note: each undeclared
identifier is reported only once for each function it appears in
BUILDSTDERR: error: command 'gcc' failed with exit status 1
https://koji.fedoraproject.org/koji/taskinfo?taskID=33279740
The relevant code in src/twisted/python/_sendmsg.c:
#if defined(SCM_TIMESTAMP)
if (-1 == PyModule_AddIntConstant(module, "SCM_TIMESTAMP", SCM_TIMESTAMP)) {
return;
}
#endif
https://github.com/twisted/twisted/blob/trunk/src/twisted/python/_sendmsg.c#L157
This seems related to the recent changes in the kernel regarding year 2038 bug
and timestamps:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/asm-generic/socket.h?id=887feae36aee6c08e0dafcdaa5ba921abbb2c56b
Anyone has any insight as to what might be happening and how to solve it?
Thanks,
Robert-André
___
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: Help needed regarding a build failure on x32 for python-twisted, might be kernel related
On 3/7/19 2:23 PM, Robert-André Mauchin wrote:
Hello,
I'm trying to build the new python-twisted 18.9.0, but it fails on 32 bits
architecture:
BUILDSTDERR: In file included from /usr/include/asm/socket.h:1,
BUILDSTDERR: from /usr/include/bits/socket.h:393,
BUILDSTDERR: from /usr/include/sys/socket.h:33,
BUILDSTDERR: from src/twisted/python/_sendmsg.c:16:
BUILDSTDERR: src/twisted/python/_sendmsg.c: In function 'init_sendmsg':
BUILDSTDERR: src/twisted/python/_sendmsg.c:158:64: error: '__kernel_long_t'
undeclared (first use in this function)
BUILDSTDERR: 158 | if (-1 == PyModule_AddIntConstant(module,
"SCM_TIMESTAMP", SCM_TIMESTAMP)) {
BUILDSTDERR: |
^
BUILDSTDERR: src/twisted/python/_sendmsg.c:158:64: note: each undeclared
identifier is reported only once for each function it appears in
BUILDSTDERR: error: command 'gcc' failed with exit status 1
https://koji.fedoraproject.org/koji/taskinfo?taskID=33279740
The relevant code in src/twisted/python/_sendmsg.c:
#if defined(SCM_TIMESTAMP)
if (-1 == PyModule_AddIntConstant(module, "SCM_TIMESTAMP", SCM_TIMESTAMP))
{
return;
}
#endif
https://github.com/twisted/twisted/blob/trunk/src/twisted/python/_sendmsg.c#L157
This seems related to the recent changes in the kernel regarding year 2038 bug
and timestamps:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/uapi/asm-generic/socket.h?id=887feae36aee6c08e0dafcdaa5ba921abbb2c56b
Anyone has any insight as to what might be happening and how to solve it?
Thanks,
Robert-André
See https://bugzilla.redhat.com/show_bug.cgi?id=1686419
___
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: Packaging Question - Building the Binaries of my package
Michael Zhang wrote: > Recently, someone advised me that I have to build the binaries from the > source code in the %install phase. That is to say that I have to make it > transparent how the binaries (ex. jar) are built. See https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries -- Rex ___ 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: modular repositories in mock configs: please don't
Dne 06. 03. 19 v 14:00 Mikolaj Izdebski napsal(a): > - create a proper modulemd document > - build some (zero or more) RPM packages using rpmbuild > - create YUM repodata from built packages using createrepo_c > - attach modulemd to repodata using modifyrepo_c Yes. But the first and last steps needs to be automated. No ones wants to do that manually. Miroslav ___ 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 rawhide compose report: 20190306.n.1 changes
-- Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: http://lnkd.in/FXPWxH On Thu, 7 Mar 2019 at 20:37, Miro Hrončok wrote: [..] > > What ground/public repos do you mean here? The master mirror is > > definitely updated. It's a large pile of changes, so other mirrors may > > take a bit longer than normal to sync. > > > > There's no glitch I am aware of, so more information would be helpful. > > This seems quite OK: > > https://admin.fedoraproject.org/mirrormanager/propgation > > Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 For example: ftp://ftp.icm.edu.pl/pub/linux/dist/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/ ftp://mirror.de.leaseweb.net/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/ Just done "dnf clean all" and on "dnf upgrade -vv" have warnings: repo: downloading from remote: rawhide error: Status code: 404 for http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/c1cd3e4d1a46c4f79315b068f1d5a62b36ccc4b5352ac8ac09da1fa56c140296-primary.xml.gz (http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/c1cd3e4d1a46c4f79315b068f1d5a62b36ccc4b5352ac8ac09da1fa56c140296-primary.xml.gz). error: Status code: 404 for http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/7a5d0a2faa3893e6554b0dfcc7f14f4757e3e0b96579d53e64aefe8b7994070c-filelists.xml.gz (http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/7a5d0a2faa3893e6554b0dfcc7f14f4757e3e0b96579d53e64aefe8b7994070c-filelists.xml.gz). error: Status code: 404 for http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/0890e446db7e56de5765c414d7880997ff6dc809b850c766d18ed1ac32167824-comps-Everything.x86_64.xml.xz (http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/0890e446db7e56de5765c414d7880997ff6dc809b850c766d18ed1ac32167824-comps-Everything.x86_64.xml.xz). Fedora - Rawhide - Developmental packages for the next Fedora release 3.3 MB/s | 61 MB 00:18 not found other for: Fedora - Rawhide - Developmental packages for the next Fedora release not found modules for: Fedora - Rawhide - Developmental packages for the next Fedora release not found deltainfo for: Fedora - Rawhide - Developmental packages for the next Fedora release not found updateinfo for: Fedora - Rawhide - Developmental packages for the next Fedora release rawhide: using metadata from Sun 17 Feb 2019 08:11:02 GMT. here kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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 rawhide compose report: 20190306.n.1 changes
On Thu, 7 Mar 2019 at 19:00, Tomasz Kłoczko wrote: > > -- Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: http://lnkd.in/FXPWxH > On Thu, 7 Mar 2019 at 20:37, Miro Hrončok wrote: > [..] > > > What ground/public repos do you mean here? The master mirror is > > > definitely updated. It's a large pile of changes, so other mirrors may > > > take a bit longer than normal to sync. > > > > > > > There's no glitch I am aware of, so more information would be helpful. > > > > This seems quite OK: > > > > https://admin.fedoraproject.org/mirrormanager/propgation > > > > Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 > > For example: > ftp://ftp.icm.edu.pl/pub/linux/dist/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/ > ftp://mirror.de.leaseweb.net/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/ > > Just done "dnf clean all" and on "dnf upgrade -vv" have warnings: > We don't push to mirrors. They sync from either our main servers or a tier 1 or tier 2 mirror which also pull/rsync from the master mirrors. This means it will take time to get stuff down and out. So like I said.. do not expect various mirrors to be in sync until Monday at the latest. The more people trying to get stuff which isn't there just makes this longer as they are usually getting resource limitations. -- Stephen J Smoogen. ___ 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: Help needed regarding a build failure on x32 for python-twisted, might be kernel related
* Robert-André Mauchin: > https://koji.fedoraproject.org/koji/taskinfo?taskID=33279740 Since this has come up repeatedly in other contexts leading to confusion: This is not an x32 build. I don't think Fedora has any x32 builders. x32 is a distinct, incompatible architecture from i386/i686 and x86-64, requiring different binaries. Thanks, Florian ___ 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 rawhide compose report: 20190306.n.1 changes
On Fri, 8 Mar 2019 at 00:37, Stephen John Smoogen wrote: [..] > We don't push to mirrors. They sync from either our main servers or a > tier 1 or tier 2 mirror which also pull/rsync from the master mirrors. > This means it will take time to get stuff down and out. So like I > said.. do not expect various mirrors to be in sync until Monday at the > latest. The more people trying to get stuff which isn't there just > makes this longer as they are usually getting resource limitations. I must be somehow extremely unlucky because after checking +two dozens of the mirrors from https://admin.fedoraproject.org/mirrormanager/mirrors/Fedora/development available over rsync in UK, Poland, Netherlands, France and US I dd not found even one synced :/ Interesting only is that they are all stopped synchronisation in the middle of the Aug 2018 or 17 Feb 2019. Can someone help and point on mirror accessible over rsync which is up-to-date? Today after clean dnf caches again and rerun upgrade seems like at least indexes are propagated correctly however: Transaction Summary = Install 42 Packages Upgrade489 Packages Remove 3 Packages Total download size: 841 M DNF will only download packages for the transaction. Downloading Packages: [MIRROR] gdm-3.31.91-1.fc31.x86_64.rpm: Status code: 404 for https://mirror.vorboss.net/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/g/gdm-3.31.91-1.fc31.x86_64.rpm [FAILED] gdm-3.31.91-1.fc31.x86_64.rpm: No more mirrors to try - All mirrors were already tried without success (2-3/582): gdm-devel-3.31.91-1.fc31.x86_64.rpm 0% [] 103 kB/s | 509 kB139:10 ETA The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Error downloading packages: Cannot download Packages/g/gdm-3.31.91-1.fc31.x86_64.rpm: All mirrors were tried Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync DNF version: 4.1.0 kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
