Orphaning rubygem-multipart
by Vít Ondruch
Hi,
I don't have any use for rubygem-multipart, therefore I orpahned the
package. There was no upstream change past 10 years and nobody is
probably using the package.
Vít
5 years, 1 month
Scratch build uploads to koji VERY SLOW
by Richard Shaw
Is anyone else experiencing this? I did a speed test on my Xfinity and it
doesn't appear to be on my end.
I'm getting about 100-200kB/s uploads... On larger projects that's very
painful.
Thanks,
Richard
5 years, 1 month
Orphaning Fog (most of rubygem-fog* packages)
by Vít Ondruch
Hi,
I have orphaned most of the Fog stack [1, 2]. Fog is the Ruby cloud
services library, top to bottom, collections provide a simplified
interface, making clouds easier to work with and switch between.
Fog was originally introduced into Fedora just as a dependency of
Vagrant. Since that time, fog-libvirt, which used to be integral part of
Fog was extracted into independent package, which is enough for Vagrant.
Since I don't have any use case for the Fog itself, I have orphaned it,
which means I have orphaned following packages:
rubygem-fog
rubygem-fog-atmos
rubygem-fog-aws
rubygem-fog-brightbox
rubygem-fog-ecloud
rubygem-fog-profitbricks
rubygem-fog-radosgw
rubygem-fog-riakcs
rubygem-fog-sakuracloud
rubygem-fog-serverlove
rubygem-fog-softlayer
rubygem-fog-storm_on_demand
rubygem-fog-terremark
rubygem-fog-vmfusion
rubygem-fog-voxel
I'll keep the following for Vagrant:
rubygem-fog-libvirt
rubygem-fog-core
rubygem-fog-json
rubygem-fog-xml
All the packages are up to date. The upstream is nice and helpful.
Vít
[1] http://fog.io/
[2] https://github.com/fog/fog
5 years, 1 month
Help needed regarding a build failure on x32 for python-twisted, might be kernel related
by Robert-André Mauchin
Hello,
I'm trying to build the new python-twisted 18.9.0, but it fails on 32 bits architecture:
BUILDSTDERR: In file included from /usr/include/asm/socket.h:1,
BUILDSTDERR: from /usr/include/bits/socket.h:393,
BUILDSTDERR: from /usr/include/sys/socket.h:33,
BUILDSTDERR: from src/twisted/python/_sendmsg.c:16:
BUILDSTDERR: src/twisted/python/_sendmsg.c: In function 'init_sendmsg':
BUILDSTDERR: src/twisted/python/_sendmsg.c:158:64: error: '__kernel_long_t' undeclared (first use in this function)
BUILDSTDERR: 158 | if (-1 == PyModule_AddIntConstant(module, "SCM_TIMESTAMP", SCM_TIMESTAMP)) {
BUILDSTDERR: | ^~~~~~~~~~~~~
BUILDSTDERR: src/twisted/python/_sendmsg.c:158:64: note: each undeclared identifier is reported only once for each function it appears in
BUILDSTDERR: error: command 'gcc' failed with exit status 1
https://koji.fedoraproject.org/koji/taskinfo?taskID=33279740
The relevant code in src/twisted/python/_sendmsg.c:
#if defined(SCM_TIMESTAMP)
if (-1 == PyModule_AddIntConstant(module, "SCM_TIMESTAMP", SCM_TIMESTAMP)) {
return;
}
#endif
https://github.com/twisted/twisted/blob/trunk/src/twisted/python/_sendmsg...
This seems related to the recent changes in the kernel regarding year 2038 bug and timestamps:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
Anyone has any insight as to what might be happening and how to solve it?
Thanks,
Robert-André
5 years, 1 month
modular repositories in mock configs: please don't
by Fabio Valentini
Hi everybody,
Recently, modular repositories were enabled in the mock configs for fedora 29+.
Now, I can't build at least one of my packages (elementary-music) in
fedora 29 chroots, due to dependency issues within modules. dnf just
gives up with this rather unhelpful message:
Problem: cannot install the best candidate for the job
- package libpeas-devel-1.22.0-9.module_2123+73a9ef6f.x86_64 is excluded
I don't want or need modules installed for this package to build.
See: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cca3e242eb#comment-90...
IMO it was a mistake to enable modular repositories in mock configs by
default. Now dnf only downloads even more metadata for no benefit (or,
it even breaks dependency resolution, as in this case).
Do I really have to manually edit mock's config files to disable
modular repos, to get builds equivalent to koji (where modules aren't
available / usable either)? I want to test builds locally, before I
push them to koji builders ...
Any insights why this was done?
Can it be fixed please?
Or am I the only one having problems?
Fabio
5 years, 1 month