Re: Fedora 18 Beta Go/No-Go Meeting, Thursday, November 22 @ 20:00 UTC (3pm Eastern, 12pm Pacific)
From: Ric Wheeler rwhee...@redhat.com Friday is a normal work day for most people (although some people will take it off to get a longer weekend :)) You know it's a Red Hat paid holiday, right? -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Announcing Fedora 19 ARM remix for Allwinner SOCs release 2
On 10/01/2013 01:10 PM, Niels de Vos wrote: On Sat, Sep 14, 2013 at 09:55:38PM +0200, Hans de Goede wrote: Hi All, I'm very happy to announce the second release (r2) of my Fedora 19 ARM remix images for Allwinner A10, A10s, A13 and A20 based devices. This release is based on the official Fedora 19 Final for ARM images, with u-boot and kernel(s) from the linux-sunxi project: http://linux-sunxi.org/ Thanks for the new image! I've tried to run it on my Cubieboard (1024MB) but it fails to boot. This seems to be the same on the 1st image, sorry I did not check that earlier :-/ Which reminds me that I meant to report my results. The r1 remix worked, and continues to work, fine on my gooseberry. The r2 remix does not boot. Any chance you could make things like the r2 kernel RPM available in a YUM repo or stand-alone? I looked quickly, but did not find it. Perhaps I did not look hard enough. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SystemD service stop behavior
On 10/23/2013 11:09 AM, Miroslav Suchý wrote: On 10/23/2013 04:25 PM, Simo Sorce wrote: If glusterfs feels people need to run the bricks and the main daemons separately then they should probably split service files and have a dependency to bring one up when the other comes up, yet still be allowed to take the daemon down w/o taking down the bricks. +1 Either split it into more service or when I say stop, then stop everything you started. -1 Maybe people could be bothered to actually look at what's in the package? There already is a separate glusterfsd.service file. And it's a wonder to me why people who don't use it and don't know anything about it would try to shoehorn it into some kind of one-size-fits-all policy. It is the way it is because that's how the users of it want it to work. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SystemD service stop behavior
On 10/23/2013 11:57 AM, Michael Cronenworth wrote: Perhaps I need to file the bug against the glusterfsd unit file? Yes, you should certainly do that. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
package foo is blocked for tag dist-6E-epel-testing-candidate
I unretired the el6 branch and took ownership for a package I maintain. Now I'm getting the $subject build error when I do a fedpkg build. Scratch builds are successful. Is there some built-in delay between unretiring before I can do builds or is there another step I've missed (and don't find any mention of.) Thanks -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
sys/sysctl.h and bits/sysctl.h in rawhide/f18?
About a week ago I did a scratch build of one of my packages that includes sys/sysctl.h and it built successfully. Today I did another scratch build and it broke with: ... Making all in src CC fuse-helpers.lo CC fuse-resolve.lo CC fuse-bridge.lo CC misc.lo In file included from fuse-helpers.c:24:0: /usr/include/sys/sysctl.h:63:25: fatal error: bits/sysctl.h: No such file or directory compilation terminated. ... Is this a known problem? Some new package I need to add as a BuildRequires? Thanks -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sys/sysctl.h and bits/sysctl.h in rawhide/f18?
A scratch build on koji if that wasn't apparent. - Original Message - From: Kaleb Keithley kkeit...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, May 31, 2012 1:38:32 PM Subject: sys/sysctl.h and bits/sysctl.h in rawhide/f18? About a week ago I did a scratch build of one of my packages that includes sys/sysctl.h and it built successfully. Today I did another scratch build and it broke with: ... Making all in src CC fuse-helpers.lo CC fuse-resolve.lo CC fuse-bridge.lo CC misc.lo In file included from fuse-helpers.c:24:0: /usr/include/sys/sysctl.h:63:25: fatal error: bits/sysctl.h: No such file or directory compilation terminated. ... Is this a known problem? Some new package I need to add as a BuildRequires? Thanks -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deleting a package from f18/rawhide builds?
How do I do this? (The package is hekafs.) I have retired the package in f18. I have removed the f18 tag from all the fc18 builds. But the rawhide build is still pulling the fc17 version of the package. There are no dependencies on it. And FWIW, the latest glusterfs rpm Obsoletes hekafs. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: well!
On 03/13/2013 12:17 PM, Stef Walter wrote: On 03/12/2013 08:17 PM, Till Maas wrote: On Tue, Mar 12, 2013 at 12:47:07AM -0400, Digimer wrote: On 03/12/2013 12:41 AM, Charles Zeitler wrote: i don't like giving up control over my machine (partitioning), so i won't be upgrading to Fedora 18. i'll watch the web site for a return to sanity. charles zeitler Setting aside the drama, you can manually partition F18. Unless anaconda crashes (live image) or does not recognise the partitions (DVD image). :-/ Reference: https://bugzilla.redhat.com/show_bug.cgi?id=905669 Btw.: Ideas how to install F18 anyhow are welcome. If I'm honest, I couldn't get F18 Anaconda to install to the partition I wanted either :S I have multiple Linux OS partitions (Fedora 18, Rawhide, Ubuntu), and one big home directory partition, and I wanted Anaconda to replace one of them. Eventually I gave up, installed F18 to a VM, and then used rsync + restorecon + grub2-mkconfig (!) to get it into the partition I wanted. That was my experience as well. LVMs though instead of partitions. I solved it by deleting the LVM I wanted to replace and letting Anaconda create a new LVM using the space from the old one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: glusterfs
On 05/14/2013 08:15 AM, build...@fedoraproject.org wrote: glusterfs has broken dependencies in the F-19 tree: On x86_64: glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift = 0:1.8.0 On i386: glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-0.4.beta1.fc19.noarch requires openstack-swift = 0:1.8.0 Please resolve this as soon as possible. g. These packages exist in f19. Then what's the correct way to make sure they're installed when glusterfs-ufo is installed without breaking dependencies? Just: Requires: openstack-swift = 1.8.0 doesn't get them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd network-online.target question
I need glusterd to start before any _netdev mounts (NFS or glusterfs) take place. reading the system.special man page it talks about ...pulling in network-online.target and order themselves after it. Would adding a Before=network-online.target to the glusterd.service be the right thing to do or is there a better solution? (It already has After=network.target rpcbind.service) Thanks, -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/23/2013 04:41 PM, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Perhaps it could be made lighter? I didn't think that glusterfsd the translators were required for a pure client. /usr/sbin/glusterfs is a symlink to /usr/sbin/glusterfsd; glusterfs(d) is absolutely required for a client-side fuse mount, as are most of the translators — that's how gluster works. You can't predict, you can't second guess which translators will be required by any client — that's determined by how the server administrator configures the volumes. Rich. $ rpm -ql glusterfs /etc/logrotate.d/glusterd /etc/logrotate.d/glusterfs-fuse /etc/logrotate.d/glusterfsd /etc/sysconfig/glusterd /etc/sysconfig/glusterfsd /usr/lib64/glusterfs /usr/lib64/glusterfs/3.4.0beta4 /usr/lib64/glusterfs/3.4.0beta4/auth /usr/lib64/glusterfs/3.4.0beta4/auth/addr.so /usr/lib64/glusterfs/3.4.0beta4/auth/login.so /usr/lib64/glusterfs/3.4.0beta4/rpc-transport /usr/lib64/glusterfs/3.4.0beta4/rpc-transport/socket.so /usr/lib64/glusterfs/3.4.0beta4/xlator /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/afr.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/dht.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/distribute.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/nufa.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/pump.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/replicate.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/stripe.so /usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/switch.so /usr/lib64/glusterfs/3.4.0beta4/xlator/debug /usr/lib64/glusterfs/3.4.0beta4/xlator/debug/error-gen.so /usr/lib64/glusterfs/3.4.0beta4/xlator/debug/io-stats.so /usr/lib64/glusterfs/3.4.0beta4/xlator/debug/trace.so /usr/lib64/glusterfs/3.4.0beta4/xlator/encryption /usr/lib64/glusterfs/3.4.0beta4/xlator/encryption/rot-13.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features /usr/lib64/glusterfs/3.4.0beta4/xlator/features/access-control.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/index.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/locks.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/mac-compat.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/marker.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/quiesce.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/quota.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/read-only.so /usr/lib64/glusterfs/3.4.0beta4/xlator/features/worm.so /usr/lib64/glusterfs/3.4.0beta4/xlator/mount /usr/lib64/glusterfs/3.4.0beta4/xlator/performance /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/io-cache.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/io-threads.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/md-cache.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/open-behind.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/quick-read.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/read-ahead.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/stat-prefetch.so /usr/lib64/glusterfs/3.4.0beta4/xlator/performance/write-behind.so /usr/lib64/glusterfs/3.4.0beta4/xlator/protocol /usr/lib64/glusterfs/3.4.0beta4/xlator/protocol/client.so /usr/lib64/glusterfs/3.4.0beta4/xlator/system /usr/lib64/glusterfs/3.4.0beta4/xlator/system/posix-acl.so /usr/lib64/glusterfs/3.4.0beta4/xlator/testing /usr/lib64/glusterfs/3.4.0beta4/xlator/testing/performance /usr/lib64/glusterfs/3.4.0beta4/xlator/testing/performance/symlink-cache.so /usr/lib64/libgfrpc.so.0 /usr/lib64/libgfrpc.so.0.0.0 /usr/lib64/libgfxdr.so.0 /usr/lib64/libgfxdr.so.0.0.0 /usr/lib64/libglusterfs.so.0 /usr/lib64/libglusterfs.so.0.0.0 /usr/libexec/glusterfs /usr/libexec/glusterfs/gsyncd /usr/libexec/glusterfs/python /usr/libexec/glusterfs/python/syncdaemon /usr/libexec/glusterfs/python/syncdaemon/README.md /usr/libexec/glusterfs/python/syncdaemon/__init__.py /usr/libexec/glusterfs/python/syncdaemon/__init__.pyc /usr/libexec/glusterfs/python/syncdaemon/__init__.pyo /usr/libexec/glusterfs/python/syncdaemon/configinterface.py /usr/libexec/glusterfs/python/syncdaemon/configinterface.pyc /usr/libexec/glusterfs/python/syncdaemon/configinterface.pyo /usr/libexec/glusterfs/python/syncdaemon/gconf.py /usr/libexec/glusterfs/python/syncdaemon/gconf.pyc /usr/libexec/glusterfs/python/syncdaemon/gconf.pyo /usr/libexec/glusterfs/python/syncdaemon/gsyncd.py /usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyc /usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyo /usr/libexec/glusterfs/python/syncdaemon/ipaddr.py /usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyc /usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyo /usr/libexec/glusterfs/python/syncdaemon
Re: Why does so much virt stuff depend on glusterfs?
On 07/23/2013 05:20 PM, Richard W.M. Jones wrote: On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote: On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote: On 07/23/2013 03:44 PM, Richard W.M. Jones wrote: Not sure if glusterfs could be split into client and server parts and/or if that would help (only a client bit is needed). glusterfs already exists in client (glusterfs and/or glusterfs-api and associated -devel rpms) and server (glusterfs-server) parts. Hmm, I wonder if there's another QEMU linkage problem here. QEMU seems to only use glfs_* functions in its code, but it is linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could probably link to just libgfapi.so, and thus only depend on glusterfs-api and not main glusterfs RPM. Ah yes, that's the key ... $ rpm -ql glusterfs-api /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so /usr/lib64/libgfapi.so.0 /usr/lib64/libgfapi.so.0.0.0 Even if libgfapi (from glusterfs-api) is used instead of client-side gluster fuse mount you still need the translators (from glusterfs) -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/23/2013 05:34 PM, Matthew Miller wrote: On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote: $ rpm -ql glusterfs-api /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so /usr/lib64/libgfapi.so.0 /usr/lib64/libgfapi.so.0.0.0 Even if libgfapi (from glusterfs-api) is used instead of client-side gluster fuse mount you still need the translators (from glusterfs) Can this work without any client-side configuration? Huh? qemu, when it's using glusterfs, is — by definition — a glusterfs client. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does so much virt stuff depend on glusterfs?
On 07/24/2013 12:29 AM, Peter Robinson wrote: Can't you split the translators into a glusterfs-common (or something) The glusterfs RPM already is the glusterfs-common RPM that you want. If you look, you'll see that the other things in the glusterfs RPM really aren't that big; moving the translators to a different RPM doesn't buy you anything. that libgfapi depends on and then have glusterfs-fuse and other sub packages. An in the case of translators why no split out all but the defaults and any others the server admin should deal with. Again, you can't second guess which translators are defaults. Server admins configure volumes and options and the client-side could need any of them. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/15/2013 11:32 AM, Reindl Harald wrote: Am 15.08.2013 17:17, schrieb Ralf Corsepius: On 08/15/2013 04:36 PM, Paul Wouters wrote: On Thu, 15 Aug 2013, Reindl Harald wrote: Am 15.08.2013 15:40, schrieb Paul Wouters: We can't tell people to re-install from scratch every 6 months. What we need is an apt-get dist-upgrade equivalent. *we have* http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum i currently count 450 dist-upgrade this way and the oldest setups are upgraded from Fedora 9 to Fedora 18 - the only stupid is that instead spend more effort in the yum-upgrades waste all the time with preupgrade/fedup and whatever the next inkarnation is known And yet another issue is the fedora-distribution occasionally carrying packages with greater NEVRs in older releases than in newer release. what does *not* matter in case of yum distro-sync because it does also It seemed to matter yesterday when I tried to update a Fedora 19 vm to rawhide. Try it and see. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
.spec file Source0 magic for github release source tarballs?
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? Thanks, -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On 01/21/2014 12:39 PM, Richard Shaw wrote:
On Tue, Jan 21, 2014 at 11:25 AM, Alec Leamas leamas.a...@gmail.com
mailto:leamas.a...@gmail.com wrote:
Actually, the GL are pretty clear here: the source should be
referenced using the full commit, nothing else. There is some
reasoning why. The tag should got to Version: (as long its 'sane').
Besides that this is the existing GL, there is also a subtle
difference in git-archive (which supposedly runs this). When
archiving a tag, the sources gets today's date. OTOH, when
archiving a commit, the sources modification dates are their commit
date. Last time I checked this was also true on github.
Of course github could change it at any time but it looks to be working
properly right now, in the case of OpenColorIO:
Source0:
https://github.com/%{upstream}/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz
Yes, that's the magick I needed. Works for me in nfs-ganesha.
Thanks,
--
Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unresponsive reviewer, glusterfs-openstack-swift,
Hi, The gluster community has been trying to get its glusterfs-openstack-swift package reviewed since August (2013). See https://bugzilla.redhat.com/show_bug.cgi?id=1003089 I realize that reviewers are often unpaid volunteers working on their own time. On the flip side, the package owner, who is trying to get this package reviewed, has never done this before and is learning as he goes. This package is intended to replace an obsolete sub-package (glusterfs-ufo) that was removed in August; the Gluster and Swift communities are suffering from the lack of a replacement. Is there anything that can be done to wrap up this package review so that we can move forward? Thanks for your consideration, -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review, or review swap?
libntirpc. It's currently bundled in nfs-ganesha with a bundling exception through Fedora 23, but it's ready now. https://bugzilla.redhat.com/show_bug.cgi?id=1204898 Thanks, -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
can't submit updates for f22?
I must have missed some announcement?
Submitting from an up to date f22 box I get:
% fedpkg update
/usr/lib/python2.7/site-packages/fedpkg/cli.py:169: DeprecationWarning:
Commands._hash_file is deprecated and will be removed eventually.
Please use Commands.lookasidecache.hash_file instead.
hash = self.cmd._hash_file('bodhi.template', 'sha1')
Creating a new update for glusterfs-3.6.5-1.fc22
Password for kkeithle:
Creating a new update for glusterfs-3.6.5-1.fc22
ServerError(https://admin.fedoraproject.org/updates/save, 404, Not Found)
Traceback (most recent call last):
File /usr/bin/bodhi, line 225, in main
data = bodhi.save(**update_args)
File /usr/lib/python2.7/site-packages/fedora/client/bodhi.py, line
111, in save
'bugs': bugs,
File /usr/lib/python2.7/site-packages/fedora/client/baseclient.py,
line 379, in send_request
auth_params=auth_params, retries=retries, timeout=timeout)
File /usr/lib/python2.7/site-packages/fedora/client/proxyclient.py,
line 505, in send_request
raise ServerError(url, http_status, msg)
ServerError: ServerError(https://admin.fedoraproject.org/updates/save,
404, Not Found)
Could not generate update request: Command 'bodhi --new --release f22
--file bodhi.template glusterfs-3.6.5-1.fc22 --username kkeithle'
returned non-zero exit status 255
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: can't submit updates for f22?
On 08/25/2015 12:03 PM, Jan Chaloupka wrote:
Happened to me as well. How many times did you repeated 'fedpkg update'
before it worked? For me it takes from 1 to 3 times before it works.
I've repeated it enough times to establish -- per Albert Einstein --
that I'm probably insane; none of them has worked.
The new web interface worked, once I figured out what the correct inputs
were.
On 08/25/2015 06:38 AM, Kaleb KEITHLEY wrote:
I must have missed some announcement?
Submitting from an up to date f22 box I get:
% fedpkg update
/usr/lib/python2.7/site-packages/fedpkg/cli.py:169:
DeprecationWarning: Commands._hash_file is deprecated and will be
removed eventually.
Please use Commands.lookasidecache.hash_file instead.
hash = self.cmd._hash_file('bodhi.template', 'sha1')
Creating a new update for glusterfs-3.6.5-1.fc22
Password for kkeithle:
Creating a new update for glusterfs-3.6.5-1.fc22
ServerError(https://admin.fedoraproject.org/updates/save, 404, Not Found)
Traceback (most recent call last):
File /usr/bin/bodhi, line 225, in main
data = bodhi.save(**update_args)
File /usr/lib/python2.7/site-packages/fedora/client/bodhi.py, line
111, in save
'bugs': bugs,
File /usr/lib/python2.7/site-packages/fedora/client/baseclient.py,
line 379, in send_request
auth_params=auth_params, retries=retries, timeout=timeout)
File
/usr/lib/python2.7/site-packages/fedora/client/proxyclient.py, line
505, in send_request
raise ServerError(url, http_status, msg)
ServerError: ServerError(https://admin.fedoraproject.org/updates/save,
404, Not Found)
Could not generate update request: Command 'bodhi --new --release f22
--file bodhi.template glusterfs-3.6.5-1.fc22 --username kkeithle'
returned non-zero exit status 255
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pushed package to stable four days ago, is it stuck?
On 04/07/2016 06:45 AM, Peter Robinson wrote: I pushed glusterfs-3.7.9-1.fc23 to stable four days ago. It has +4 karma. It's still pending. Is it stuck? Can someone please give it a kick? >>> >>> All the updates are already in process of being kicked by me, should >>> hopefully be moving again shortly. >>> >> >> Thanks, >> >> I have several more that seem to be stuck again... >> >> Do we know why this happens? > > I doubt that they are "stuck" and updates have been going out each day > this week. So without any information as to what the exact NVRs my > guess for them being stuck is "Treacle!" IE I have no means of > actually telling you without the actual details. > > The push process requires human intervention as it requires signing > etc so the exact timing depends on who is on push duty and what other > priorities they have, what time zone they''re in and likely a bunch of > other points. From a couple days ago, push to stable: nfs-ganesha-2.3.1-2.el6 nfs-ganesha-2.3.1-2.el7 From yesterday, push to testing: nfs-ganesha-2.3.1-4.fc23 nfs-ganesha-2.3.1-4.el7 nfs-ganesha-2.3.1-3.el6 -- Kaleb -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: pushed package to stable four days ago, is it stuck?
On 04/05/2016 08:55 AM, Peter Robinson wrote: > On Tue, Apr 5, 2016 at 1:51 PM, Kaleb KEITHLEY <kkeit...@redhat.com> wrote: >> >> I pushed glusterfs-3.7.9-1.fc23 to stable four days ago. It has +4 karma. >> >> It's still pending. Is it stuck? Can someone please give it a kick? > > All the updates are already in process of being kicked by me, should > hopefully be moving again shortly. > Thanks, I have several more that seem to be stuck again... Do we know why this happens? Thanks -- Kaleb -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
pushed package to stable four days ago, is it stuck?
I pushed glusterfs-3.7.9-1.fc23 to stable four days ago. It has +4 karma. It's still pending. Is it stuck? Can someone please give it a kick? Thanks -- Kaleb -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
nfs-ganesha -stable request stalled
Hi, Would someone please give the nfs-ganesha-2.4.0-0.8dev21.fc24 a kick? I've had two other updates pushed to -stable since, and they've gone through. Been waiting ~4 days now. Status page says the update is locked and can't be modified, but I don't know why. Thanks, -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
autoconf test for deprecated readdir_r
Hi, Does anyone have a good/working autoconf test for checking for deprecated readdir_r (for Fedora 25) ? I'm not having much luck. (Have tried AC_COMPILE_IFELSE, among other things.) Alternatively it would be nice if there was a some kind of feature test define in dirent.h. Thanks, -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
more problems with koji builders for f26
Hi, Trying to build latest nfs-ganesha–– Yesterday (for me, 02:00 UTC, 24 Jan) I was getting (on both a fedpkg build and koji scratch builds): DEBUG util.py:435: Error: package pkgconf-pkg-config-1.2.0-1.fc26.ppc64le conflicts with pkgconfig < 1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.ppc64le on ppc64, ppc64le, and aarch64 (x86_64, i686, armv7hl built succuessfully). See, e.g., https://kojipkgs.fedoraproject.org//work/tasks/7502/17397502/root.log Today (for me, 11:00 UTC, 24 Jan) on a koji scratch build of the same srpm as above I'm getting DEBUG util.py:435: Error: nothing provides libproj.so.9()(64bit) needed by qt-mobility-location-1.2.2-0.24.20140317git169da60c.fc26.x86_64 on all six platforms. see, e.g., https://kojipkgs.fedoraproject.org//work/tasks/697/17400697/root.log f25 scratch builds worked both yesterday and today. Any ideas? Thanks -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: more problems with koji builders for f26
Okay, thanks for the info. I'll hold off until later. - Original Message - > From: "Peter Robinson" <pbrobin...@gmail.com> > To: "Development discussions related to Fedora" > <devel@lists.fedoraproject.org> > Sent: Tuesday, January 24, 2017 6:21:52 AM > Subject: Re: more problems with koji builders for f26 > > On Tue, Jan 24, 2017 at 11:07 AM, Kaleb Keithley <kkeit...@redhat.com> wrote: > > Hi, > > > > Trying to build latest nfs-ganesha–– > > > > Yesterday (for me, 02:00 UTC, 24 Jan) I was getting (on both a fedpkg build > > and koji scratch builds): > >DEBUG util.py:435: Error: package > >pkgconf-pkg-config-1.2.0-1.fc26.ppc64le conflicts with pkgconfig < > >1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.ppc64le > > on ppc64, ppc64le, and aarch64 (x86_64, i686, armv7hl built succuessfully). > > See, e.g., > > https://kojipkgs.fedoraproject.org//work/tasks/7502/17397502/root.log > > > > > > Today (for me, 11:00 UTC, 24 Jan) on a koji scratch build of the same srpm > > as above I'm getting > > DEBUG util.py:435: Error: nothing provides libproj.so.9()(64bit) needed > > by qt-mobility-location-1.2.2-0.24.20140317git169da60c.fc26.x86_64 > > on all six platforms. see, e.g., > > https://kojipkgs.fedoraproject.org//work/tasks/697/17400697/root.log > > > > f25 scratch builds worked both yesterday and today. > > A feature in F-26 needs a new dnf on the builders, other versions are > unaffected and hence f25 scratch or otherwise are unaffected. > > > Any ideas? > > There was a miscommunication and there's updates that need to be > pushed to those arches. They will be fixed today but of course the > package signing is taking eons. It's a known problem and it's being > actively worked on and will be solved as soon as I can push out the > signed updates. > > > Thanks > > > > -- > > > > Kaleb > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
are the armv7hl builders healthy?
I'm trying to build ceph-12.2.0 for f28, So far the build has failed twice on armv7hl during %install trying to install a file that was seeminlyly successfully built. That's two different files. The first time it was cephfs-journal-tool, the second time it was the one immediately after: cephfs-table-tool. The other six archs builds are successful and building 12.1.4 a week ago worked. Am I running into quotas or some other file system space limitation? The most recent build log is at https://kojipkgs.fedoraproject.org//work/tasks/3484/21583484/build.log The previous build log is at https://kojipkgs.fedoraproject.org//work/tasks/7134/21537134/build.log Any thoughts? Thanks -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: are the armv7hl builders healthy?
Einstein's advice about insanity not withstanding, I tried building again – the third time was successful. (Expecting the same on f27 now. :-/ ) - Original Message - > From: "Kaleb Keithley" <kkeit...@redhat.com> > To: "Development discussions related to Fedora" > <devel@lists.fedoraproject.org> > Sent: Friday, September 1, 2017 8:17:11 AM > Subject: are the armv7hl builders healthy? > > > I'm trying to build ceph-12.2.0 for f28, So far the build has failed twice > on armv7hl during %install trying to install a file that was seeminlyly > successfully built. > > That's two different files. The first time it was cephfs-journal-tool, the > second time it was the one immediately after: cephfs-table-tool. > > The other six archs builds are successful and building 12.1.4 a week ago > worked. > > Am I running into quotas or some other file system space limitation? > > The most recent build log is at > https://kojipkgs.fedoraproject.org//work/tasks/3484/21583484/build.log > > The previous build log is at > https://kojipkgs.fedoraproject.org//work/tasks/7134/21537134/build.log > > Any thoughts? > > Thanks > > -- > > Kaleb > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
two Ceph updates for f28, f29, stuck in pending testing for six days
https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8 https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a Would someone please give them a kick? Thanks -- Kaleb ___ 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
Are the s390x builders healthy?
I'm trying to build Ceph again for f31 after the branching.
It built before the branching, eight days ago.
The x86_64[1] part of number two below got further than either of the two
examples below before I killed it. I'm guessing it would have finished
successfully if I had let it. I have another running now to confirm.
But I'm getting strange errors on s390x.
One, e.g. (
https://kojipkgs.fedoraproject.org//work/tasks/6799/32926799/build.log)
BUILDSTDERR: {standard input}: Assembler messages:
BUILDSTDERR: {standard input}:464309: Warning: end of file not at end
of a line; newline inserted
BUILDSTDERR: {standard input}:465519: Error: invalid operands (*UND*
and .gcc_except_table sections) for `-'
BUILDSTDERR: c++: fatal error: Killed signal terminated program cc1plus
BUILDSTDERR: compilation terminated.
An earlier one
(https://kojipkgs.fedoraproject.org//work/tasks/3857/32923857/build.log)
BUILDSTDERR: {standard input}: Error: .size expression for
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_16StringConstraintESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE7_M_copyINSF_20_Reuse_or_alloc_nodeEEEPSt13_Rb_tree_nodeIS9_EPKSJ_PSt18_Rb_tree_node_baseRT_
does not evaluate to a constant
BUILDSTDERR: c++: fatal error: Killed signal terminated program cc1plus
BUILDSTDERR: compilation terminated.
Bad disk? Out of disk space? Any thoughts?
thanks,
[1]https://kojipkgs.fedoraproject.org//work/tasks/3856/32923856/build.log
--
Kaleb
___
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: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Mon, Mar 11, 2019 at 7:35 AM Daniel P. Berrangé wrote: > The ability to have multiple different builds of the same software which > users can choose between, sounds alot like the use case for modularity. > Abusing Epoch to try to address this kind of situation feels like a pretty > undesirable approach, as this problem with suddenly clashing Epochs will > illustrate. > If only there had been modularity before f29 that might have been reasonable a reasonable claim, IMO. But it wasn't. My issue is that there's no way to fix things when a mistake is made. Perhaps I misunderstand the purpose of rawhide. I appreciate that "we" try to _not_ break things in rawhide, but when they do, there should be a way to fix them. -- Kaleb ___ 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: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Mon, Mar 11, 2019 at 8:22 AM Neal Gompa wrote: > Heck, the spec file > that is in Fedora is basically an openSUSE spec with Fedora > conditionals in it. > The ceph.spec file in Fedora is based on the upstream ceph.spec.in file; not on anything in/from openSUSE. The upstream ceph.spec.in file is full of Fedora and SUSE conditionals. If openSUSE also used the upstream spec file then it shouldn't surprise anyone that they are similar. -- Kaleb ___ 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
On not bumping the epoch in ceph-14, f30 and f31/rawhide
The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x in f30/rawhide. I reset it to 1 in subsequent builds. Now adamwill is running builds with it bumped to 2 again. I would prefer that it not be bumped. Ceph has their own builds (for Fedora even I think) where they have epoch=2. I see this as a feature that lets someone install Ceph's epoch=2 packages on a system and not risk inadvertently updating with the Fedora Ceph packages. Is there really no other way to get rid of the one or two "bad builds" where epoch=2 and keep shipping epoch=1 in Fedora? By untagging the builds perhaps? Thanks, -- Kaleb ___ 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: two Ceph updates for f28, f29, stuck in pending testing for six days
On Tue, Feb 19, 2019 at 3:18 AM Kevin Fenzi wrote: > On 2/18/19 12:56 PM, Kaleb Keithley wrote: > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8 > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a > > > > Would someone please give them a kick? > > For some reason autosign likes to not process these correctly. > > I've retagged them to get it to do another pass... > > Sorry for not fixing them sooner. > Looks like another Ceph build is stuck. https://bodhi.fedoraproject.org/updates/FEDORA-2019-16c36506c1 Would someone kick it please? Thanks -- Kaleb ___ 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
Another ceph build stuck in pending testing, four days
Hi, https://bodhi.fedoraproject.org/updates/FEDORA-2019-60ba61b5ab Why does this happen every time? Would someone please kick it? Thanks -- Kaleb ___ 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: Another ceph build stuck in pending testing, four days
Thanks for opening the ticket, but the update is still stuck, now going on nine days. Would someone with the necessary privs please kick it. Thanks On Mon, Jun 3, 2019 at 1:52 PM Randy Barlow wrote: > On Sun, 2019-06-02 at 18:03 -0400, Kaleb Keithley wrote: > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-60ba61b5ab > > > > Why does this happen every time? > > > > Would someone please kick it? Thanks > > I filed an issue about this for you: > > https://pagure.io/fedora-infrastructure/issue/7871 > ___ > 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
ceph packages submitted to testing four days ago still haven't been pushed
ceph-12.2.12 for f28 and f29. Happens every time. Someone please give them a kick. Thanks. -- Kaleb ___ 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: two Ceph updates for f28, f29, stuck in pending testing for six days
Two more are stuck again. https://bodhi.fedoraproject.org/updates/FEDORA-2019-3b8418 https://bodhi.fedoraproject.org/updates/FEDORA-2019-399f5bd105 On Fri, Mar 22, 2019 at 3:08 PM Kevin Fenzi wrote: > On 3/21/19 5:45 PM, Kaleb Keithley wrote: > > On Tue, Feb 19, 2019 at 3:18 AM Kevin Fenzi wrote: > > > >> On 2/18/19 12:56 PM, Kaleb Keithley wrote: > >>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8 > >>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a > >>> > >>> Would someone please give them a kick? > >> > >> For some reason autosign likes to not process these correctly. > >> > >> I've retagged them to get it to do another pass... > >> > >> Sorry for not fixing them sooner. > >> > > > > Looks like another Ceph build is stuck. > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-16c36506c1 > > > > Would someone kick it please? Thanks > > Fixed, and I looked and asked upstream and this is fixed in sigul 1.0. > > So, hopefully we won't have to keep doing this too much longer. > > kevin > > > ___ > 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
Re: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches
On Mon, Aug 5, 2019 at 6:17 PM Kevin Kofler wrote: > > > > Please feel free though to add your thoughts to the issue. > > > > [1] https://github.com/gluster/glusterfs/issues/702 > > The upstream issue actually says they want to keep building 32-bit in > their > CI, so it should compile just fine, they just won't test it. > It's already the case that it's not tested. It hasn't been tested in all the years that I've been packaging it. The upstream issue is about finally making it official that 32-bit is not supported. Building it on 32-bit in the CI is only to ensure correctness of sprintf format strings. It's a compile-only test. -- Kaleb ___ 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: when will bodhi (updates) recognize fc31/f31 updates
On Thu, Aug 15, 2019 at 10:21 AM Alexander Bokovoy wrote: > On to, 15 elo 2019, Kaleb Keithley wrote: > >I've tried to submit a build on f31 to testing, using both the cli and via > >the web site, and both are failing > > > >On the web site I get a popup with: Builds : Cannot find release > associated > >with build: nfs-ganesha-2.8.2-5.fc31, tags: ['f31'] > > > >fedpkg update gets: Could not execute update: Could not generate update > >request: Cannot find release associated with build: > >nfs-ganesha-2.8.2-5.fc31, tags: ['f31'] > My understanding is that F31 doesn't need bodhi right now -- all > packages built for it appear in the distro, as with rawhide before. > > Branched will get bodhi activated later this month. > Well, it's confusing (to me anyway), because before branching, new f31/rawhide builds showed up automatically as "stable" in bodhi. And now new f32/rawhide builds show up automatically as "stable." Making me wonder what is status of the new f31 build(s) I've just done? They don't show up in bodhi at all. -- Kaleb ___ 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
when will bodhi (updates) recognize fc31/f31 updates
I've tried to submit a build on f31 to testing, using both the cli and via the web site, and both are failing On the web site I get a popup with: Builds : Cannot find release associated with build: nfs-ganesha-2.8.2-5.fc31, tags: ['f31'] fedpkg update gets: Could not execute update: Could not generate update request: Cannot find release associated with build: nfs-ganesha-2.8.2-5.fc31, tags: ['f31'] Thanks -- Kaleb ___ 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
ambiguous python in f29+ builds,
All the python files in one of my packages (nfs-ganesha) have #!/usr/bin/python[23] shebangs. The nfs-ganesha.spec does _not_ have python-unversioned-command as a BuildRequires: I do not have python-unversioned-command installed on my f30 box. AIUI, setup.py alters the shebangs to match the python that's in the path when it runs. When I build (rpmbuild or mock) on my f30 box, the shebangs are left unchanged. Yet the packages built in koji all have their python shebangs changed to /usr/bin/python (by setup.py.) The build.logs show that python-unversioned-command is not installed. Where did it get /usr/bin/python from? -- Kaleb ___ 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: ambiguous python in f29+ builds,
Never mind, false alarm. Waiting for coffee to kick in. On Mon, Aug 19, 2019 at 8:49 AM Kaleb Keithley wrote: > > All the python files in one of my packages (nfs-ganesha) have > #!/usr/bin/python[23] shebangs. > > The nfs-ganesha.spec does _not_ have python-unversioned-command as a > BuildRequires: > > I do not have python-unversioned-command installed on my f30 box. > > AIUI, setup.py alters the shebangs to match the python that's in the path > when it runs. > > When I build (rpmbuild or mock) on my f30 box, the shebangs are left > unchanged. > > Yet the packages built in koji all have their python shebangs changed to > /usr/bin/python (by setup.py.) The build.logs show > that python-unversioned-command is not installed. Where did it get > /usr/bin/python from? > > -- > > Kaleb > > > > > ___ 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
python38-3.8.0~b3-1.fc30 on my f30 machine? how?
Also python36, python35, and python34. I'm 100% confident that I never explicitly installed these. Having python38 broke my devel setup due to there being no Cython in /usr/lib64/python3.8/site-packages/... I don't know how long it was broken. Very annoying to discover this. How do I prevent this from happening again? (Yes, I know I can put explicit excludes in my /etc/yum.repos.d/fedora-updates.repo file.) Seems like I shouldn't need to and that it shouldn't have happened in the first place. -- Kaleb ___ 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] Fedora 32 Python 3.8 rebuilds have started in a side tag
On Wed, Aug 21, 2019 at 1:23 PM Miro Hrončok wrote: > On 15. 08. 19 0:18, Miro Hrončok wrote: > > Hello, in order to deliver Python 3.8, we are running a coordinated > rebuild in a > > side tag. > > > > The side tag was merged. Build in regular rawhide now. Thanks. > /me wonders why my `dnf update` on my f32/rawhide box isn't updating to python-3.8. Should it be? Both rawhide-modular and rawhide repos are enabled. Thanks, -- Kaleb ___ 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
f32/rawhide, nothing provides module(platform:f31)
`dnf update` on my f32/rawhide machine is giving me: Problem 1: conflicting requests - nothing provides module(platform:f31) needed by module bat:latest:3120190714171319:22d7e2a5-0.x86_64 Problem 2: conflicting requests - nothing provides module(platform:f31) needed by module exa:latest:3120190721165838:22d7e2a5-0.x86_64 Problem 3: conflicting requests - nothing provides module(platform:f31) needed by module libgit2:0.28:3120190714114509:f636be4b-0.x86_64 Problem 4: conflicting requests - nothing provides module(platform:f31) needed by module silver:rolling:3120190728135623:22d7e2a5-0.x86_64 What do I need to do for this? Thanks, -- Kaleb ___ 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
is this update stuck? Ceph-14.2.3-1.fc32
https://bodhi.fedoraproject.org/updates/FEDORA-2019-6f5be50fd9 Two other ceph updatest submitted around the same time moved to testing okay. If it is stuck, can someone with appropriate privs please kick it. Thanks, -- Kaleb ___ 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: mass rebuild, glusterfs build failed
On Fri, Jul 26, 2019 at 1:31 PM Kevin Fenzi wrote: > On 7/25/19 11:05 AM, Kaleb Keithley wrote: > > hmmm. from the root.log > > > > DEBUG util.py:585: BUILDSTDERR: Error: > > DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests > > DEBUG util.py:585: BUILDSTDERR: - nothing provides kernel >= 4.18.0 > > needed by firewalld-0.6.4-1.fc31.noarch > > > > how to deal with this? Wait for a new firewalld package? > > Yep. > > I have asked the 'dropping i686 kernels' change owner to file bugs on > these packages. > > Looks like: > > firewalld-0.7.1-1.fc31.src.rpm > https://bugzilla.redhat.com/show_bug.cgi?id=1733602 One of the suggestions there is to "drop the arch." I.e. i686. If that ends up being the solution that pretty much would force me to drop the arch too for glusterfs. (GlusterFS has a bit of plumbing around opening ports in the firewall. It might just fail — silently or not so silently. It's hard to know, nobody has tested it. I suspect dropping the arch might cause some amount of heartache in some circles. OTOH, I haven't paid close enough attention to really understand what it means to stop building i686 kernels. Does that mean no Fedora distribution for i686 hardware? Does it even make sense to keep building glusterfs for i686? -- Kaleb ___ 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 32 System-Wide Change: glusterfs dropping 32-bit arches
On Mon, Aug 5, 2019 at 11:29 AM Peter Robinson wrote: > On Mon, Aug 5, 2019 at 3:44 PM Kaleb Keithley wrote: > > > > > > There is a proposal[1] in upstream GlusterFS to drop 32-bit arches. > > > > The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 > will land in Fedora 31/rawhide soon. More than likely though it will not be > official until GlusterFS-8, which will probably land, accordingly, after > Fedora 31 GA in Fedora 32/rawhide. > > Will clients still work, is this server only? > Existing 32-bit GlusterFS clients (glusterfs-7 and earlier) should continue to work just fine — AFAIK — connecting to 64-bit glusterfs servers. The proposal[1] as it stands is to drop all aspects of 32-bit support, i.e. client, server, gfapi, etc., going forward from glusterfs-8. This should be considered advanced notice that consumers that have dependencies need to plan accordingly. Please feel free though to add your thoughts to the issue. [1] https://github.com/gluster/glusterfs/issues/702 ___ 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 32 System-Wide Change: glusterfs dropping 32-bit arches
On Mon, Aug 5, 2019 at 9:57 AM Miro Hrončok wrote:
> On 05. 08. 19 15:36, Kaleb Keithley wrote:
> > There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
> >
> > The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7
> will land
> > in Fedora 31/rawhide soon. More than likely though it will not be
> official until
> > GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA
> in Fedora
> > 32/rawhide.
> >
> >
> >
> > [1] https://github.com/gluster/glusterfs/issues/702
>
> What about the dependent packages?
>
> $ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-devel
> glusterfs-api-devel-0:6.4-3.fc31.i686
> glusterfs-api-devel-0:6.4-3.fc31.x86_64
> libvirt-0:5.5.0-2.fc31.src
> qemu-2:4.1.0-0.1.rc2.fc31.src
> samba-2:4.10.6-0.fc31.2.src
> uwsgi-0:2.0.18-2.fc31.src
>
Er, what about them? AIUI, there isn't going to be a i686 Fedora in F31
and beyond. That just leaves armv7hl. Is anyone really running libvirt,
qemu, or storage on such platforms? If they are, the number must be
vanishingly small. (My own experience with virt on ARM makes me believe
that the that the number must be truly microscopic.) Of those that are, is
there a reason they can't keep running glusterfs-7 on F30 or F31
indefinitely if they really need 32-bit gluster?
$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-api-devel
> gluster-block-0:0.4-4.fc31.src
> glusterfs-coreutils-0:0.3.1-2.fc31.src
> libvirt-0:5.5.0-2.fc31.src
> nfs-ganesha-0:2.8.2-3.fc31.src
> qemu-2:4.1.0-0.1.rc2.fc31.src
> samba-2:4.10.6-0.fc31.2.src
> scsi-target-utils-0:1.0.70-9.fc31.src
> tcmu-runner-0:1.1.3-2.fc26.src
> uwsgi-0:2.0.18-2.fc31.src
tcmu-runner and scsi-target-utils is only for gluster-block, which, by
extension should also drop 32-bit at the same time. Likewise,
glusterfs-coreutils should also drop 32-bit support.
That only leaves ganesha and samba, which can drop their FSAL_GLUSTER and
VFS_GLUSTER plug-ins on 32-bit. Something they have already had to do for
Ceph-14 in Fedora 30.
--
Kaleb
___
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
Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches
There is a proposal[1] in upstream GlusterFS to drop 32-bit arches. The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide. [1] https://github.com/gluster/glusterfs/issues/702 -- Kaleb ___ 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
Fwd: Fedora 32 System-Wide Change: glusterfs dropping 32-bit arches
There is a proposal[1] in upstream GlusterFS to drop 32-bit arches. The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land in Fedora 31/rawhide soon. More than likely though it will not be official until GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora 32/rawhide. [1] https://github.com/gluster/glusterfs/issues/702 -- Kaleb ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass rebuild, glusterfs build failed
On Wed, Jul 31, 2019 at 3:43 PM Kevin Fenzi wrote: > On 7/31/19 12:01 PM, Kaleb Keithley wrote: > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1733602 > > > > One of the suggestions there is to "drop the arch." I.e. i686. > > > > If that ends up being the solution that pretty much would force me to > drop > > the arch too for glusterfs. (GlusterFS has a bit of plumbing around > opening > > ports in the firewall. It might just fail — silently or not so silently. > > It's hard to know, nobody has tested it. > > > > I suspect dropping the arch might cause some amount of heartache in some > > circles. > > > > OTOH, I haven't paid close enough attention to really understand what it > > means to stop building i686 kernels. Does that mean no Fedora > distribution > > for i686 hardware? Does it even make sense to keep building glusterfs > for > > i686? > > I would drop the kernel dependency. It doesn't make sense already in > some contexts (containers) and this is a Fedora package for Fedora > users, so I think anyone who would install it would have a kernel, and > if it's a supported Fedora release it would be larger than 4.18.0. > glusterfs is not the package with the dependency on kernel. Its dependency is on firewalld, which is where the kernel dependency comes from. The firewalld packager doesn't seem to know how to add an ExcludeArch: to the .spec or how to remove the 'Requires: kernel ...' line. https://bugzilla.redhat.com/show_bug.cgi?id=1733602 Maybe someone with some authority on the subject can give some guidance? Personally I'd be perfectly happy to stop building glusterfs for 32-bit platforms. I honestly don't think anyone runs on 32-bit and the developers aren't really thinking about 32-bit as they work on it. (I had to add a 32-bit build in the CI just to catch all the 32-bit sprintf format mistakes they were making.) And FWIW, Ceph has abandoned 32-bit platforms starting with Nautilus/14.x.x. I have suggested that GlusterFS officially abandon 32-bit starting with 7.0. Not sure whether that hasn't fallen on deaf ears. -- Kaleb ___ 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
are the ppc64le builders healthy?
I built the latest ceph-14 (14.2.2) on rawhide successfully two days ago. Two different builds on f30 built or are building fine on x86_64, i686, and aarch64, but failed with different errors on ppc64le at different places in the build. One looks like it ran out of space in the file system. The other may have been OOM killed (?). https://kojipkgs.fedoraproject.org//work/tasks/2448/36422448/build.log https://kojipkgs.fedoraproject.org//work/tasks/4819/36444819/build.log Thanks, -- Kaleb ___ 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
YACBSIPT
Yet Another Ceph Build Stuck in Pending Testing https://bodhi.fedoraproject.org/updates/FEDORA-2019-623fb9419e Would someone please give it a kick. Thanks -- Kaleb ___ 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: YACBSIPT
On Thu, Jul 25, 2019 at 1:11 PM Kevin Fenzi wrote: > On 7/25/19 3:48 AM, Kaleb Keithley wrote: > > Yet Another Ceph Build Stuck in Pending Testing > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-623fb9419e > > > > Would someone please give it a kick. > > Done. > Thanks > > And sorry again this continues to happen. ;( > > kevin > > sorry to keep pestering you with this stuff. Regards, -- Kaleb ___ 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
mass rebuild, glusterfs build failed
hmmm. from the root.log DEBUG util.py:585: BUILDSTDERR: Error: DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests DEBUG util.py:585: BUILDSTDERR: - nothing provides kernel >= 4.18.0 needed by firewalld-0.6.4-1.fc31.noarch how to deal with this? Wait for a new firewalld package? -- Kaleb ___ 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: 15 nonresponsive maintainers
On Fri, Jul 19, 2019 at 2:12 PM Miro Hrončok wrote: > > ktdre...@ktdreyer.com ktdreyer > https://bugzilla.redhat.com/show_bug.cgi?id=1731540 > https://bugzilla.redhat.com/show_bug.cgi?id=1706223 Use kdre...@redhat.com instead. He is currently on paternity leave and may not be responding to work emails. -- Kaleb ___ 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
YACBSIPT, rawhide ceph build stuck in bodhi, again
Someone with privs please kick it. Thanks https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953 ___ 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: YACBSIPT, rawhide ceph build stuck in bodhi, again
On Thu, Sep 19, 2019 at 2:18 PM Kevin Fenzi wrote: > On 9/19/19 5:26 AM, Kaleb Keithley wrote: > > Someone with privs please kick it. Thanks > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953 > > Done. Do note that you can do this too, just untag it from f32-pending > and tag it again into f32-pending. > Okay, cool. I wish someone had told me sooner, I'd have stopped bothering people for this. :-) Thanks -- Kaleb ___ 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: are the ppc64le builders low on memory?
On Mon, Nov 11, 2019 at 1:39 PM Kevin Fenzi wrote: > On Mon, Nov 11, 2019 at 01:10:07PM -0500, Kaleb Keithley wrote: > > Last week I built ceph 14.2.4-2 and it built fine on both fc31 and > rawhide. > > > > I fixed a typo for a Requires: and the ppc64le builds today are getting > > killed. > > > > https://kojipkgs.fedoraproject.org//work/tasks/7359/38917359/build.log > > Can you please provide links to the top level task? > https://koji.fedoraproject.org/koji/taskinfo?taskID=38917295 https://koji.fedoraproject.org/koji/taskinfo?taskID=38913962 > I can't tell what builder this was on, and it looks like you > resubmitted? > > Anyhow, I guess I will reduce the number of cpus on the ppc builders. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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
are the ppc64le builders low on memory?
Last week I built ceph 14.2.4-2 and it built fine on both fc31 and rawhide. I fixed a typo for a Requires: and the ppc64le builds today are getting killed. https://kojipkgs.fedoraproject.org//work/tasks/7359/38917359/build.log thanks -- Kaleb ___ 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: YACBSIPT, rawhide ceph build stuck in bodhi, again
On Thu, Sep 19, 2019 at 7:33 PM Kaleb Keithley wrote: > On Thu, Sep 19, 2019 at 2:18 PM Kevin Fenzi wrote: > >> On 9/19/19 5:26 AM, Kaleb Keithley wrote: >> > Someone with privs please kick it. Thanks >> > >> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953 >> >> Done. Do note that you can do this too, just untag it from f32-pending >> and tag it again into f32-pending. > > Question: you did it. I did it. In Koji[1] it has f32 and f32-updates-candidate tags. And in bodhi[2] it's still showing as pending testing. What should it be? What should I do at this point to get it out of pending testing and into testing? [1]https://koji.fedoraproject.org/koji/buildinfo?buildID=1379110 [2]https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953 Thanks -- Kaleb ___ 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: YACBSIPT, rawhide ceph build stuck in bodhi, again
On Fri, Sep 20, 2019 at 11:41 AM Kevin Fenzi wrote: > On 9/20/19 6:07 AM, Kaleb Keithley wrote: > > On Thu, Sep 19, 2019 at 7:33 PM Kaleb Keithley > wrote: > > > >> On Thu, Sep 19, 2019 at 2:18 PM Kevin Fenzi wrote: > >> > >>> On 9/19/19 5:26 AM, Kaleb Keithley wrote: > >>>> Someone with privs please kick it. Thanks > >>>> > >>>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953 > >>> > >>> Done. Do note that you can do this too, just untag it from f32-pending > >>> and tag it again into f32-pending. > >> > >> > > Question: you did it. I did it. In Koji[1] it has f32 and > > f32-updates-candidate tags. And in bodhi[2] it's still showing as > pending > > testing. What should it be? What should I do at this point to get it out > of > > pending testing and into testing? > > There is no testing for rawhide. > > The f32 tag means it should be in composes. > > The issue here is that you created this bodhi update... for rawhide > gating it just does all the work, you should not create updates for > rawhide. > > I can see if I can get someone to poke it and make it reflect reality, > but it's already stable and there's nothing further to do (except clean > up what bodhi thinks). > Okay. Other builds I've done for f32 (gluster, nfs-ganesha, earlier ceph builds even) all went straight to stable in bodhi, but this one didn't, despite waiting several hours. Then there's the ceph build for f31[1] that's still stuck in pending testing after two days. And the ceph build for f30[2] that's been in testing for 15 days that isn't allowing me push it to stable. ??? Thanks for your help though, greatly appreciated. Regards, [1]https://bodhi.fedoraproject.org/updates/FEDORA-2019-62e251afd9 [2]https://bodhi.fedoraproject.org/updates/FEDORA-2019-f47093cc3d -- Kaleb ___ 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: YACBSIPT, rawhide ceph build stuck in bodhi, again
And for https://bodhi.fedoraproject.org/updates/FEDORA-2019-6f79c53e44 I don't have permission to untag and retag the f30-signing-pending tag. Many thanks for your help. On Sun, Sep 22, 2019 at 4:02 PM Kevin Fenzi wrote: > On Fri, Sep 20, 2019 at 12:12:58PM -0400, Kaleb Keithley wrote: > > > Okay. Other builds I've done for f32 (gluster, nfs-ganesha, earlier ceph > > builds even) all went straight to stable in bodhi, but this one didn't, > > despite waiting several hours. > > Well, all of those likely were autosubmitted by gating? It looks like > you submitted the ceph one manually before the gating could catch it. ;( > https://bodhi.fedoraproject.org/updates/FEDORA-2019-6ebb10dcbc > "This update was automatically created" > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953 > "This update has been submitted for testing by kkeithle." > > I know the folks working on gating were trying to make it so this > happened before anyone could submit a manual update. It would be nice if > it just blocked that entirely. > > > Then there's the ceph build for f31[1] that's still stuck in pending > > testing after two days. > > I got that one unstuck. > > > And the ceph build for f30[2] that's been in testing for 15 days that > isn't > > allowing me push it to stable. > > > > ??? > > I think it's due to it being a critical path update... > > > Thanks for your help though, greatly appreciated. > > Thanks for bringing this stuff up, we need to improve things. ;( > > kevin > -- > > > > Regards, > > > > [1]https://bodhi.fedoraproject.org/updates/FEDORA-2019-62e251afd9 > > [2]https://bodhi.fedoraproject.org/updates/FEDORA-2019-f47093cc3d > > > > -- > > > > Kaleb > ___ 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 for libntirpc coming soon in f32/rawhide
I don't believe anything except nfs-ganesha uses libntirpc, but on the off-chance that there is— libntirpc will bump from 1.8 to 3.0 -- Kaleb ___ 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: Ceph license change
On Tue, Feb 4, 2020 at 3:45 PM Miro Hrončok wrote: > > Iff the above is correct, the license field should say: > > (LGPL-2.1 or LGPL-3.0) and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and > BSD-3-Clause > and MIT > > > (If we ignore that those are probably SPDX license identifiers and not > what > Fedora uses. > Using Fedora short names from [1], and in English (vs. pseudo-code), this is what I'm tentatively planning to change the ceph.spec file in Fedora to: License:LGPLv2.1 or LGPLv3, CC-BY-SA-3.0, GPLv2, Boost-1.0, BSD, and MIT [1] https://fedoraproject.org/wiki/Licensing:Main -- Kaleb ___ 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
Ceph license change
Coming in Ceph-15 (octopus) From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause and MIT To: LGPL-2.1 and LGPL-3.0 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause and MIT Note: I'm tentatively planning on landing ceph-15 in rawhide after f32 branch. -- Kaleb ___ 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: Ceph license change
On Mon, Feb 3, 2020 at 11:35 PM Daniel P. Berrangé wrote: > On Mon, Feb 03, 2020 at 11:26:46PM +0530, Kaleb Keithley wrote: > > Coming in Ceph-15 (octopus) > > > > From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause > > and MIT > > To: LGPL-2.1 and LGPL-3.0 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 > and > > BSD-3-Clause and MIT > > Do you have info on which parts of Ceph are covered by the newly > introduced LGPLv3.0 ? > Not off hand no. Maybe the new seastar bits? Sage (cc'd) made the change to the upstream .spec file. Sage? > > I'm mostly wondering if this is pre-existing code changing license in > a way that could impact existing apps/libs linking to Ceph libaries ? > > eg QEMU would have a problem with LGPLv3.0 in the Ceph libraries, since > parts of the code in QEMU are GPLv2.0-only > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ceph license change
On Mon, Feb 3, 2020 at 11:35 PM Daniel P. Berrangé wrote: > On Mon, Feb 03, 2020 at 11:26:46PM +0530, Kaleb Keithley wrote: > > Coming in Ceph-15 (octopus) > > > > From: LGPL-2.1 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 and BSD-3-Clause > > and MIT > > To: LGPL-2.1 and LGPL-3.0 and CC-BY-SA-3.0 and GPL-2.0 and BSL-1.0 > and > > BSD-3-Clause and MIT > > Do you have info on which parts of Ceph are covered by the newly > introduced LGPLv3.0 ? > > I'm still waiting for a reply to the email I sent Sage. In the meantime I did a cursory inspection of the source and don't see anything new that is licensed with LGPL 3.0. (I'm not a lawyer and I did not do an exhaustive search.) What I do see that is new is the top-level license file (i.e. COPYING file) has been changed to add "... or LGPL-3..." Again, I'm not a lawyer, but AFAIK that magic word "or" in the phrase "LGPL-2.1 or LGPL-3" should make it acceptable for things like QEMU that are GPLv2.0 only. > I'm mostly wondering if this is pre-existing code changing license in > a way that could impact existing apps/libs linking to Ceph libaries ? > > eg QEMU would have a problem with LGPLv3.0 in the Ceph libraries, since > parts of the code in QEMU are GPLv2.0-only > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
s390x builder problem? disk full, or ?
several of my `koji --scratch --arch-overide=s390x ...` builds have failed with error; reading package header (after the rebuildSRPM) Latest is https://koji.fedoraproject.org/koji/taskinfo?taskID=41622496 (guess I could reopen my s390x disk full ticket. Or open a new one.) -- Kaleb ___ 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: s390x builder problem? disk full, or ?
On Tue, Feb 18, 2020 at 9:59 PM Kevin Fenzi wrote: > On Tue, Feb 18, 2020 at 04:41:42PM -0800, Kevin Fenzi wrote: > > On Tue, Feb 18, 2020 at 02:05:07PM -0500, Kaleb Keithley wrote: > > > several of my `koji --scratch --arch-overide=s390x ...` builds have > failed > > > with error; reading package header (after the rebuildSRPM) > > > > > > Latest is https://koji.fedoraproject.org/koji/taskinfo?taskID=41622496 > > > > > > (guess I could reopen my s390x disk full ticket. Or open a new one.) > > > > Sure, but thats not going to magicially make us solve the problem. ;( > > > > It seems to happen sporadically, when the s390x builders are under heavy > > load. It seems to happen to the Zvm instances more than the Kvm > > instances. :( > > > > I think they might be in odd states, so I am going to try and reboot > > them tonight when things aren't as busy and see if that helps any. > > FWIW, I have rebooted all the s390x builders now. > > Hopefully that will help with this issue... > The original issue seemed to clear itself up. Or at least by random chance I got a builder that wasn't full. But since you rebooted I've fired off a build, only to have it die at the very end writing the rpm files. :-( https://koji.fedoraproject.org/koji/getfile?taskID=41651353=DEFAULT=build.log=-4000 it's not the kernel, but never the less, these aren't quick builds, especially on s390x so it's very frustrating. Let's push it back up the hill -- Kaleb ___ 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
out of disk space (on s390x builders)
https://koji.fedoraproject.org/koji/taskinfo?taskID=40326373 Is it a transient problem or something that needs to be fixed? thanks -- Kaleb ___ 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: gcc 10: Default to -fno-common, multiple definitions of ...
On Tue, Jan 21, 2020 at 7:36 AM Miro Hrončok wrote: > ... glusterfs... > > glusterfs and nfs-ganesha are already fixed upstream. They'll be fixed in their next minor release before it becomes necessary, or I will respin with patches sooner. -- Kaleb ___ 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
glusterfs-7.1 update stuck in pending->testing for 10 days
related to bodhi having gone down? Can someone kick it please? Thanks -- Kaleb ___ 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 32 System-Wide Change proposal: GCC10
One (the only) thing I've noticed so far about gcc-10 is that (sloppily) defined variables in header files that lack an extern qualifier and that don't have an explicit defn in a .c file are no longer 'common' or .comm but are now .global .bss and cause link errors due to duplicate definitions. This very well might be because I made a mistake in the way I built gcc-10. I'm not sure I have any way to know. If it's not a mistake on my part then this change has revealed a few bugs in the other applications that I work on. These bugs should be fixed of course, but it's something to be aware of when considering a major change like this, this late in the f32/rawhide development cycle. Almost certainly a lot of other things will have similar bugs. On Thu, Jan 2, 2020 at 10:12 AM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/GCC10 > > == Summary == > Switch GCC in Fedora 32 to 10.x.y, rebuild all packages with it, or > optionally rebuild just some packages with it and rebuild all packages > only in Fedora 33. > > == Owner == > * Name: [[User:Jakub|Jakub Jelínek]] > * Email: ja...@redhat.com > > == Detailed Description == > > GCC 10 is currently in stage3, switching to stage4 in January, at > which point it will be in a prerelease state with only regression > bugfixes and documentation fixes allowed. The release will happen > probably in the middle of April. rpms will be built in early January, > but Jeff Law has been testing x86_64 Fedora test mass rebuilds with > GCC 10 snapshots for a while. > > > == Benefit to Fedora == > > See http://gcc.gnu.org/gcc-10/changes.html for the list of changes. > > == Scope == > * Proposal owners: > Prepare rpms for the new compiler, push them into rawhide, watch > voluntary rebuilds, fix bugs as they are reported, watch fallout from > mass rebuild. > > * Other developers: N/A (not a System Wide Change) > Adjust for what will be written in > https://gcc.gnu.org/gcc-10/porting_to.html , fix bugs in packages that > will show up after rebuild or report if there are bugs on the compiler > side. > > * Release engineering: Perform a mass rebuild, which will be needed > for the LTO System Wide change too. > > * Policies and guidelines: N/A (not a System Wide Change) > I don't think so, this is a usual system compiler update that is being > done every year. I think we have skipped GCC 4.2, so in Fedora this > is likely the 15th such System Wide change. > * Trademark approval: N/A (not needed for this Change) > > > == Upgrade/compatibility impact == > No impact > > == How To Test == > GCC has its own testsuite, which is run during the package build, plus > many other packages with automated tests also help to test the new > gcc. > > == User Experience == > Users will be able to see compiled code improvements and use the newly > added features. > Developers will notice a newer compiler, and might need to adjust > their codebases acording to http://gcc.gnu.org/gcc-10/porting_to.html, > or, if they detect a GCC bug, report it. > > == Dependencies == > libtool, annobin, gcc-python-plugin depend on exact gcc version, those > need to be rebuilt. > > == Contingency Plan == > If bugs are discovered, I'd appreciate help from the package owners in > preparing self-contained testcases to speed up analysis and fixing the > bugs. Don't have time to debug issues in 12000+ packages, especially > when in many cases it could be caused by undefined code in the > packages etc. I don't expect we'll have to fall back to the older > gcc, we've never had to do it in the past, > but worst case we can mass rebuild everything with older gcc again. > Jeff Law has performed test mass rebuild on x86_64. > > * Contingency mechanism: (What to do? Who will do it?) Revert to > older gcc, mass rebuild everything again > * Contingency deadline: Before release > * Blocks release? Yes > * Blocks product? No > > == Documentation == > http://gcc.gnu.org/gcc-10/ > > == Release Notes == > Fedora 32 comes with GCC 10.1 as primary compiler, see > http://gcc.gnu.org/gcc-10/changes.html for user visible changes in it. > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: glusterfs-7.1 update stuck in pending->testing for 10 days
And now it's just "pending". On Thu, Jan 2, 2020 at 7:40 PM Kevin Fenzi wrote: > On Thu, Jan 02, 2020 at 09:14:30AM -0500, Kaleb Keithley wrote: > > related to bodhi having gone down? > > > > Can someone kick it please? > > I would if I could. This is due to the ongoing koji issues. > > Hopefully bodhi folks are going to look at it tomorrow morning and we > can at least get updates flowing again. > > I'd like to thank everyone for their patience on this, it's been very > frustrating for me personally. ;( I'm sure we will find a fix as more > folks come back from holidays and dig into this issue. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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
disks full build errors again, was Re: s390x builder problem? disk full, or ?
Hi, I've had four ceph builds die in the last 12ish hours. One of them was a scratch build on x86_64; the others were regular builds, one on ppc64le, and the other two on x86_64. I don't know if this is a new problem or just repeat occurrences of a long standing problem. Anyway, just FYI. (I can provide the tasks, if you're unable to find them easily in koji.) On Tue, Feb 18, 2020 at 2:05 PM Kaleb Keithley wrote: > > several of my `koji --scratch --arch-overide=s390x ...` builds have > failed with error; reading package header (after the rebuildSRPM) > > Latest is https://koji.fedoraproject.org/koji/taskinfo?taskID=41622496 > > (guess I could reopen my s390x disk full ticket. Or open a new one.) > > -- > > Kaleb > > ___ 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: disks full build errors again, was Re: s390x builder problem? disk full, or ?
Now five. ppc64le this time. On Tue, Mar 24, 2020 at 7:10 AM Kaleb Keithley wrote: > > > > Hi, > > I've had four ceph builds die in the last 12ish hours. One of them was a > scratch build on x86_64; the others were regular builds, one on ppc64le, > and the other two on x86_64. > > I don't know if this is a new problem or just repeat occurrences of a long > standing problem. > > Anyway, just FYI. (I can provide the tasks, if you're unable to find them > easily in koji.) > > > > > On Tue, Feb 18, 2020 at 2:05 PM Kaleb Keithley > wrote: > >> >> several of my `koji --scratch --arch-overide=s390x ...` builds have >> failed with error; reading package header (after the rebuildSRPM) >> >> Latest is https://koji.fedoraproject.org/koji/taskinfo?taskID=41622496 >> >> (guess I could reopen my s390x disk full ticket. Or open a new one.) >> >> -- >> >> Kaleb >> >> ___ 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: disks full build errors again, was Re: s390x builder problem? disk full, or ?
On Tue, Mar 24, 2020 at 1:13 PM Kevin Fenzi wrote: > On Tue, Mar 24, 2020 at 09:28:35AM -0400, Kaleb Keithley wrote: > > Now five. ppc64le this time. > > I've cleaned these up now. > > Mostly it was due to the upgrade on the builders this weekend pulling in > mock 2.1 and enabling it's 'bootstrap' mode, so it made bootstrap cache > files for everything. I've downgraded to 1.4.21 until we can make the > needed changes in koji and removed all these leftover caches. > > Just out of curiosity... why is ceph so gigantic? It looks like it's > 70-80GB unpacked, which I think makes it bigger than libreoffice. > Are there really big test files? Just a lot of code? > It has always been big. The source tarball has gotten nearly 50% bigger just since 14.1.0. (About one year ago.) There are a lot of things bundled into it too for the cases where the platform doesn't have the bleeding edge dependencies that they seem to think they need to use. IMO they kinda paint themselves into a corner with some of those, e.g. boost. They don't necessarily always build them though so some of that is just a bloated source tarball. :-/ Even if current rawhide updates to boost-1.71 (which it really should do I suppose) it'll still be bundled into the source. (Note that the ceph build only builds selected bits of boost, not the whole thing.) There are probably other, similar kinds of things in there, but I don't have detailed knowledge of all the things that are bundled in it. Convincing them to pick a set of common denominator dependencies that are in all the Linux distributions they intend to support and code to that has — AFAIK — fallen on deaf ears. I know I'm not the only one who has tried. -- Kaleb ___ 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
Requires: libgtest.so, libgmock.so, libgmock_main.so question
In rawhide the ceph ceph-test subpackage is deriving a Requires: for
$subject, and even with gmock and gtest installed the requires is not
satisfied.
And the gtest and gmock rpms (somehow) do not provide them. (Is this a bug
in the gtest and gmock rpms?)
(They do provide libgtest.so.1.10.0 libgmock.so.1.10.0 and
libgmock_main.so.1.10.0 though.)
Is there some magic that if I were to add BuildRequires: gtest gmock the
magic that derives the Requires might come up with
libg{test,mock,mock_main}.so.1.10.0 instead?
Otherwise I'm tempted to just disable the build of ceph-test for Fedora RPM
builds.
I'm stumped.
--
Kaleb
___
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: Requires: libgtest.so, libgmock.so, libgmock_main.so question
On Wed, May 20, 2020 at 8:52 AM Neal Gompa wrote:
> On Wed, May 20, 2020 at 8:39 AM Kaleb Keithley
> wrote:
> >
> > In rawhide the ceph ceph-test subpackage is deriving a Requires: for
> $subject, and even with gmock and gtest installed the requires is not
> satisfied.
> >
> > And the gtest and gmock rpms (somehow) do not provide them. (Is this a
> bug in the gtest and gmock rpms?)
> >
> > (They do provide libgtest.so.1.10.0 libgmock.so.1.10.0 and
> libgmock_main.so.1.10.0 though.)
> >
> > Is there some magic that if I were to add BuildRequires: gtest gmock the
> magic that derives the Requires might come up with
> libg{test,mock,mock_main}.so.1.10.0 instead?
> >
> > Otherwise I'm tempted to just disable the build of ceph-test for Fedora
> RPM builds.
> >
> > I'm stumped.
> >
>
> The gtest-devel and gmock-devel packages provide the unversioned
> sonames.
>
It doesn't look that way to me, e.g.
$ rpm -q --provides gtest-devel
cmake(GTest) = 1.10.0
cmake(gtest) = 1.10.0
gtest-devel = 1.10.0-1.fc33
gtest-devel(x86-64) = 1.10.0-1.fc33
pkgconfig(gtest) = 1.10.0
pkgconfig(gtest_main) = 1.10.0
$ rpm -q --provides gmock-devel
gmock-devel = 1.10.0-1.fc33
gmock-devel(x86-64) = 1.10.0-1.fc33
pkgconfig(gmock) = 1.10.0
pkgconfig(gmock_main) = 1.10.0
--
Kaleb
___
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
question about ELN builds of glusterfs and ceph?
I confess I'm a bit ignorant about how the ELN builds are going to be used. Especially the ELN builds of glusterfs and ceph. That aside— Red Hat ships GlusterFS and Ceph (RHGS and RHCS respectively) as products, and generally speaking glusterfs and ceph packages are not included in RHEL; at least they haven't been so far. There are special builds of RHGS in the RHEL base that are a subset of the RHGS product packages. And I'm not sure what, if any, subset of RHCS product packages are provided in the RHEL base. And at RHEL 8.0 (actually before 8.0) there were issues with RHEL 8 having inherited the Fedora glusterfs packages into the RHEL base which conflicted with what the product team was going to be providing — incorrect version, no subset, etc. I'd like to avoid a repeat of those issues. I hope the people working on ELN are coordinating with RHGS and RHCS product teams to avoid a recurrence of them. -- Kaleb ___ 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] F33 Boost 1.73.0 rebuilds starting in a side tag
On Thu, May 28, 2020 at 4:46 AM Jonathan Wakely wrote: > I'm starting the rebuilds for Boost 1.73.0 and packages that depend on > it, using the f33-boost side tag. > > Is this still in progress? I don't see that ceph-15.2.2 has been rebuilt nor is it being rebuilt now. Should I build the new release of Ceph-15.2.3 in the side tag? Thanks, > If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your > packages, please do not make another update. Instead co-ordinate with > me to use the side tag for your update (if your package also depends > on Python then also talk to Miro Hrončok). > > If your package depends on Boost and you don't see "Rebuilt for Boost > 1.73.0" in the %changelog yet, it might be worth checking with me > anyway, as I'll probably be starting it soon. > > The new Boost will include the following changes: > > - rename boost-jam package to boost-b2, and /usr/bin/bjam with >/usr/bin/b2 (it looks nothing in Fedora uses this anyway) > > - obsolete the separate boost-nowide package, as Boost 1.73.0 includes >the Boost.Nowide library now > > jhogarth, please confirm you're aware of the nowide change. The > existing boost-nowide package will need to be retired in rawhide. > > > New changes already in rawhide: > > - boost-python3-devel subpackage removed, those files are provided by >boost-devel now. > > - Boost libraries no longer link to libpython. > > Thanks for your help. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
s390x builders are short on disk space?
Hi, three different builds of ceph have failed in the last 15 min. for lack of space to untar the source. Would someone check them out please? thanks -- Kaleb ___ 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: s390x builders are short on disk space?
My bad. Only one. The second failed because the first had not finished on the other arches, despite canceling it. The third is actually x86_64 and failed for a different reason. On Tue, May 26, 2020 at 11:54 AM Kaleb Keithley wrote: > Hi, > > three different builds of ceph have failed in the last 15 min. for lack of > space to untar the source. > > Would someone check them out please? > > thanks > > -- > > Kaleb > ___ 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] F33 Boost 1.73.0 rebuilds starting in a side tag
On Tue, Jun 2, 2020 at 10:58 AM Jonathan Wakely wrote: > > >Up to now it hasn't. > > > >I've been waiting to get boost > 1.71 so that it can be built with the > >system boost instead of its bundled copy. > > > >If the side tag build is going to be going on for a while then I'm going > to > >rebuild it for f33 with boost-1.69, and/but I will also build it again > with > >higher NVR for f33-boost. > > The side tag is merging right now, you just have to wait for 100+ > packages to be signed, and they'll be in rawhide. > ah, excellent. Thanks for the update. -- Kaleb ___ 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] F33 Boost 1.73.0 rebuilds starting in a side tag
On Tue, Jun 2, 2020 at 10:25 AM Jonathan Wakely wrote: > ... > ceph was not in my list, because it isn't returned by the first query > shown at https://fedoraproject.org/wiki/Changes/F33Boost173#Dependencies > > Does it actually depend on any libboost_*.so libraries, or just use > the header-only libraries? If it only uses the header-only parts it > doesn't necessarily need to be rebuilt (there won't be broken deps > when the previous boost release gets replaced in the rawhide repo, > although it's possible that other things that link to ceph or that > ceph links to will have been rebuilt, which can cause problems). > > Hmm, I do see this in ceph.spec: > > BuildRequires: boost-devel > BuildRequires: boost-random > > But the repoquery doesn't say it needs them. > Up to now it hasn't. I've been waiting to get boost > 1.71 so that it can be built with the system boost instead of its bundled copy. If the side tag build is going to be going on for a while then I'm going to rebuild it for f33 with boost-1.69, and/but I will also build it again with higher NVR for f33-boost. -- Kaleb ___ 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] F33 Boost 1.73.0 rebuilds starting in a side tag
On Tue, Jun 2, 2020 at 10:48 AM Tomasz Torcz wrote: > > Hmm, I do see this in ceph.spec: > > > > BuildRequires:boost-devel > > BuildRequires:boost-random > > > > But the repoquery doesn't say it needs them. > > Thats interesting, as boost is in RPM requires. > For example ceph-common-2:15.2.3-1.fc33.aarch64.rpm > (https://koji.fedoraproject.org/koji/rpminfo?rpmID=21717030) has: > > libboost_context.so.1.73.0()(64bit) > libboost_program_options.so.1.73.0()(64bit) > libboost_thread.so.1.73.0()(64bit) > Not really. ceph-15.2.3 built in the f33-boost side tag is the first version that builds with the system's boost packages. Off hand I'm not sure what, if any, repo would reflect that. Yet. -- Kaleb ___ 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] F33 Boost 1.73.0 rebuilds starting in a side tag
Is the rebuild in the side tag something that's still in progress? I sent Jonathan an email asking, but didn't get a reply. I've built a new release of ceph (ceph-15.2.3) in the f33-boost side tag but if this is something that's on hold I'll need to build it for f33. Thanks On Thu, May 28, 2020 at 4:46 AM Jonathan Wakely wrote: > I'm starting the rebuilds for Boost 1.73.0 and packages that depend on > it, using the f33-boost side tag. > > If you see "Rebuilt for Boost 1.73.0" in the changelog for one of your > packages, please do not make another update. Instead co-ordinate with > me to use the side tag for your update (if your package also depends > on Python then also talk to Miro Hrončok). > > If your package depends on Boost and you don't see "Rebuilt for Boost > 1.73.0" in the %changelog yet, it might be worth checking with me > anyway, as I'll probably be starting it soon. > > The new Boost will include the following changes: > > - rename boost-jam package to boost-b2, and /usr/bin/bjam with >/usr/bin/b2 (it looks nothing in Fedora uses this anyway) > > - obsolete the separate boost-nowide package, as Boost 1.73.0 includes >the Boost.Nowide library now > > jhogarth, please confirm you're aware of the nowide change. The > existing boost-nowide package will need to be retired in rawhide. > > > New changes already in rawhide: > > - boost-python3-devel subpackage removed, those files are provided by >boost-devel now. > > - Boost libraries no longer link to libpython. > > Thanks for your help. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!
On Mon, Jul 20, 2020 at 1:48 PM Neal Gompa wrote: > > > Your spec file is a complete mess, so I have not yet touched it to fix it. > Not _my_ spec file. Is this another episode of whinging about %ifdef SUSE, then I suggest you direct your comments at https://github.com/ceph/ceph/blob/master/ceph.spec.in. I'm sure they will appreciate your usual candor. Because I'm sure what everyone wants is to maintain two files that are 99% the same. Especially when there are conditionals. > Here's an example of how I fixed one package: > > https://src.fedoraproject.org/rpms/allegro5/c/2a59aa1daea345823b81c9b396f5766cba54da78 That might actually be helpful. More constructive comments. Less snark. -- Kaleb ___ 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: Using "rawhide" for the dist-git branch for Fedora Rawhide
Whatever name is picked: devel, main, rawhide, next, etc., how about setting the default branch. E.g. `git symbolic-ref HEAD refs/heads/rawhide` This way when someone clones the repo they don't need to know or remember which name Fedora is using as the mainline development branch. On Wed, Jul 8, 2020 at 9:57 AM Miro Hrončok wrote: > On 08. 07. 20 15:48, Till Maas wrote: > > On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote: > >> Hi, > >> > >> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git > >> branch for Fedora Rawhide "rawhide" to clarify the purpose of that > >> branch. There was also some feedback that Rawhide might not be the best > >> name and it could be renamed. In that case, the branch could be named as > >> this. This is just the first step to check if there is enough support > >> for this to move forward. The next step would be to start a change > >> process. > > > > Just had another idea, how about instead of branch down from the rawhide > > branch to new branched to make Rawhide always use the fxy version that > > it develops. So instead of creating branched f33 later we would rename > > master to f33 now and then once we need to branch we branch of Rawhide > > as f34? There could still be a symbolic ref called rawhide for the > > latest rawhide for convenience. What do you think? > > I like that idea. However IMHO packagers tend to forget about branching if > they > are not following Fedora development closely. > > When they do that now, they still do changes in rawhide and they might not > update their package in branched -- however in long term, this does not > matter > because their change is in all future versions. > > When they do that after this, their change will be in branched but not in > rawhide and in the long term, it will be lost. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ 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
cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!
On 2020-07-17 I built ceph-15.2.4-5 (and ceph-15.2.4-6 --target=f33-java11) with cmake-3.18.0-1.fc33 and the build(s) were successful. Today, with cmake-3.18.0-2.fc33 (which I guess is a respin of cmake- 3.18.0-1.fc33.1, a.k.a. 3.18.0-1.1) my scratch builds are failing with: ... + make -j5 make: *** No targets specified and no makefile found. Stop. see, e.g., https://koji.fedoraproject.org/koji/watchlogs?taskID=47508501 No changes to the .spec other than Release and %changelog. Anyone else seeing this? -- Kaleb ___ 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: ceph's builds started to fail in Fedora rawhide
On Tue, Jan 12, 2021 at 3:27 AM wrote: > Notification time stamped 2021-01-12 08:26:20 UTC > > ceph's builds started to fail in Fedora rawhide > https://apps.fedoraproject.org/koschei/package/ceph?collection=f34 > > I updated my rawhide box yesterday and it builds fine on that. There is no compiler/compilation error in the build logs, just make terminating. OOM killed perhaps? What has changed recently in the builders? Memory? Disk space? gcc version -- Kaleb ___ 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: ceph's builds started to fail in Fedora rawhide
On Wed, Jan 13, 2021 at 8:19 AM Miro Hrončok wrote: > On 13. 01. 21 14:17, Kaleb Keithley wrote: > > > > On Tue, Jan 12, 2021 at 3:27 AM > <mailto:notificati...@fedoraproject.org>> wrote: > > > > Notification time stamped 2021-01-12 08:26:20 UTC > > > > ceph's builds started to fail in Fedora rawhide > > https://apps.fedoraproject.org/koschei/package/ceph?collection=f34 > > <https://apps.fedoraproject.org/koschei/package/ceph?collection=f34> > > > > > > I updated my rawhide box yesterday and it builds fine on that. > > > > There is no compiler/compilation error in the build logs, just make > > terminating. OOM killed perhaps? > > > > What has changed recently in the builders? Memory? Disk space? gcc > version > > gcc version, see https://bugzilla.redhat.com/show_bug.cgi?id=1915803 > > /me wonders why updating my rawhide box yesterday did not get gcc-11.0.0-0.12. Mine is still -0.11. Updating and trying again. -- Kaleb ___ 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: ceph's builds started to fail in Fedora rawhide
On Wed, Jan 13, 2021 at 8:17 AM Kaleb Keithley wrote: > > On Tue, Jan 12, 2021 at 3:27 AM wrote: > >> Notification time stamped 2021-01-12 08:26:20 UTC >> >> ceph's builds started to fail in Fedora rawhide >> >> https://apps.fedoraproject.org/koschei/package/ceph?collection=f34 >> >> > I updated my rawhide box yesterday and it builds fine on that. > > There is no compiler/compilation error in the build logs, just make > terminating. OOM killed perhaps? > I.e. in the build.logs of the the koji scratch builds I have run. > > What has changed recently in the builders? Memory? Disk space? gcc version > > -- > > Kaleb > > ___ 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
