Hi, since our Koji builds have disabled internet access, I want to do
the same, so I have more Koji consistent builds.
I have the following in /etc/mock/site-defaults.cfg:
config_opts['use_host_resolv'] = True # or False, no difference
config_opts['rpmbuild_networking'] = False
The internet doesn't work (desired), but has large timeouts (undesired).
This is especially tedious when building Python packages that use
intershpinx and they try to fetch stuff from the internet during build
(it fails, but that's OK). For each such request, the build is prolonged
for ~1 minute. I have Python packages that try to download (and fail)
10+ intershpinx inventories during build. That's 10+ minutes waiting for
something that'll fail anyway. I've been adding hacks to sphinx calls to
make intersphinx timeout sooner, but it's unnecessary clutter in the spec.
So I decided to test this. I've added the following to the spec:
time curl http://example.com/
Here are the times:
* my mock: real 0m56.595s Could not resolve host
* Koji: real 0m0.030s Could not resolve host
This seems to be just about resolving hosts. See with IP address:
time curl http://126.96.36.199/
* my mock: real 2m10.953s Connection timed out
* Koji: real 2m11.337s Connection timed out
Is there a trick to make resolving fail early?
I maintain MariaDB.
There is a subpackage containing TokuDB storage engine. (available only for
However the TokuDB can't be build against Jemalloc 5, but on F>=28 there is
no older jemalloc version.
The build without jemalloc is not supported too.
Is it OK to drop the subpackage on F28 and later until the upstream adds
the Jemalloc 5 support?
I'm ready to drop such update to Bodhi.
Here's a bugzilla for this issue:
So far, on F>=28 the TokuDB was build without jemalloc.
It may be risky to rely on, yet no one complained.
That's why I'm asking users mailing list too, to get a feedback for such
pontential users, i would be otherwise unable to reach.
Associate Software Engineer
Core Services - Databases Team
On 29-04-18 09:25, Hans de Goede wrote:
> Hi All,
> I'm sending this to the fedora-kernel and -devel lists
> both to get the kernel team aware of this and because it
> is not entirely clear to me how to best deal with this.
> I guess we should get this added to the release-notes /
> common-bugs page for F28, but I'm not sure what the
> procedure is for that ?
> I've just become aware that at least for some users
> the use of SATA LPM in F28 causes the Lenovo 50
> series laptops (confirmed X250, T450s G50-80) freeze/
> hang hard under certain conditions when using SATA
> LPM, independent of the disk used (*).
> This is currently being tracked in:
> A known workaround is to add: "ahci.mobile_lpm_policy=0"
> to the kernel boot command line.
> Can someone help me to get this documented? Once we've
> figured out what is going on I hope to be able to fix this
> with a kernel update, but people may still need the
> workaround to install Fedora 28.
> Also if people are using Fedora 28 on a 50 series Lenovo
> laptop without issues, please let me know.
Some more info on this, the user with a x250 is reporting
the problem is hard-freeze about once a day, which goes
away when disabling LPM, so if you have a 50 series Lenovo
laptop and are seeing the occasional hard-freeze this may
be the cause.
(sorry if this gets posted twice; previous attempt was sent from wrong
address and will hopefully bounce anyway)
Thrift in rawhide is currently 0.10.0. My intention is move to Thrift
0.11.0 in rawhide.
Affected packages seem to be:
accumulo (ctubbsii, mizdebsk, milleruntime)
avro (ricardo, gil, lef)
golang-opencensus (eclipseo, nim, jchaloup)
hive (orphan, pmackinn, coolsvap, moceap)
python-elasticsearch (dbruno, apevec, piotrp)