Duplicate speedtest-cli packages in the repo.
by Leigh Scott
speedtest-cli and python3-speedtest-cli appear to be the same package.
Downloading Packages:
python3-speedtest-cli-1.0.2-7.fc30.noarch.rpm 364 kB/s | 44 kB 00:00
--------------------------------------------------------------------------------
Total 64 kB/s | 44 kB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
file /usr/lib/python3.7/site-packages/speedtest.py from install of python3-speedtest-cli-1.0.2-7.fc30.noarch conflicts with file from package speedtest-cli-1.0.2-6.fc30.noarch
file /usr/lib/python3.7/site-packages/speedtest_cli.py from install of python3-speedtest-cli-1.0.2-7.fc30.noarch conflicts with file from package speedtest-cli-1.0.2-6.fc30.noarch
file /usr/share/man/man1/speedtest-cli.1.gz from install of python3-speedtest-cli-1.0.2-7.fc30.noarch conflicts with file from package speedtest-cli-1.0.2-6.fc30.noarch
Error Summary
4 years, 7 months
Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression
= Switch RPMs to zstd compression =
== Summary ==
Binary RPMs are currently compressed with xz level 2.
Switching to zstd would increase decompression speed significantly.
== Owner ==
* Name: [[User:dmach| Daniel Mach]]
* Email: dmach(a)redhat.com
== Detailed Description ==
* The change requires setting a new compression algorithm in rpm
macros. Then a mass rebuild of all packages is required.
* The macro for setting the compression is: %define _binary_payload w19.zstdio
* The recommended compression level is 19. The builds will take
longer, but the additional compression time is negligible in the total
build time and it pays off in better compression ratio than xz lvl2
has.
* SRPM payload compression should stay at gzip (there's almost no
benefit in changing the compression, because SRPM's contents is
compressed already)
=== Use case: Firefox installation ===
I rebuilt firefox-66.0.5-1.fc30 with zstd level19.
Then I compared installation times with the original (xz compressed) package:
{| class="wikitable"
|-
! Compression !! Target File System !! Time
|-
| xz level 2 || tmpfs || 8s
|-
| xz level 2 || ext4 on nvme || 11s
|-
| zstd level 19 || tmpfs || 2s
|-
| zstd level 19 || ext4 on nvme || 4s
|-
|}
=== Comparison of compression algorithms and levels ===
Following table shows '''cpio''' and '''compressed cpio''' extraction
times into a tmpfs. Actual times in decompressing RPMs will differ due
to extracting on an actual disk and also some overhead in the RPM tool
(checks, scriptlets).
{| class="wikitable"
|-
! Compression !! Level !! Size B !! Size GiB
!! Compression time !! Compression time, 4 threads !!
Decompression time !! Comment
|-
| CPIO || - || 5016785692 || 4,7
|| - || - || -
||
|-
| xz || 2 || 1615017616 || 1,6
|| 9m55s || - || 1m36s
|| slow decompression
|-
| pxz || 2 || 1631869880 || 1,6
|| - || 6m11s || 1m38s
|| slow decompression
|-
| gzip || 9 || 2086354992 || 2,0
|| 10m23s || - || 31s
|| insufficient compression ratio
|-
| bzip2 || 9 || 1889161565 || 1,8
|| 8m || - || 2m50s
|| very slow decompression; compression ratio could be
better
|-
| zstd || 3 || 1913536587 || 1,8
|| 31s || 29s || 6,5s
||
|-
| zstd || 10 || 1737928978 || 1,7
|| 3m27s || 2m34s || 6,3s
||
|-
| zstd || 15 || 1717303256 || 1,7
|| 9m37s || 6m34s || 6,3s
|| identical compression speed to xz; fast decompression;
slightly worse compression ratio than xz
|-
| zstd || 17 || 1635525492 || 1,6
|| 16m16s || 11m20s || 6,7s
||
|-
| zstd || 19 || 1575843696 || 1,5
|| 24m2s || 18m55s || 7,7s
||
|-
|}
== Benefit to Fedora ==
* Faster installations/upgrades of user systems
* Faster koji builds (installations in build roots)
* Faster container builds
* Lower bandwidth on mirrors if we choose the highest compression level
== Scope ==
* Proposal owners: submit a patch to redhat-rpm-config
* Other developers: redhat-rpm-config maintainer: include the patch
and make a new build
* Release engineering: [https://pagure.io/releng/issue/8345 #8345]
mass rebuild is needed
== Upgrade/compatibility impact ==
* RPM in Fedora supports zstd compression already (from Fedora 28,
rpm-4.14.0-0.rc2.5.fc28). No impact on Fedora users is expected.
* Fedora <= 27 and some other distros will not be able to decompress
zstd-compressed RPMs.
== How To Test ==
* dnf install <package>
* rpm -q --qf "%{PAYLOADCOMPRESSOR} %{PAYLOADFLAGS}\n" <package>
* expected output: zstd 19
Also the overall system installation time should decrease significantly.
== User Experience ==
See '''Benefit to Fedora'''
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Not needed, Fedora will stay at current compression.
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? N/A
== Documentation ==
N/A
== Release Notes ==
RPMs have switched to zstd compression level 19.
Users will benefit from faster package decompression.
Users that build their packages will experience slightly longer build times.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 7 months
Lines disordered in mock's build.log
by Miro Hrončok
Hello,
I've noticed that last couple of weeks, I see disordered lines in mock's
build.log. This happens constantly in local mock, copr and Koji. Example:
25/41 Test #25: List_test ........................ Passed 0.01 sec
Start 26: Particle_test
26/41 Test #26: Particle_test .................... Passed Errors while
running CTest
make[3]: *** [src/core/unit_tests/CMakeFiles/check_unit_tests.dir/build.make:60:
src/core/unit_tests/CMakeFiles/check_unit_tests] Error 8
make[2]: *** [CMakeFiles/Makefile2:2265:
src/core/unit_tests/CMakeFiles/check_unit_tests.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:116: CMakeFiles/check.dir/rule] Error 2
make: *** [Makefile:191: check] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.yUtVju (%check)
0.01 sec
Start 27: for_each_pair_test
...
41/41 Test #41: Span_test ........................ Passed 0.01 sec
98% tests passed, 1 tests failed out of 41
Total Test time (real) = 16.69 sec
The following tests FAILED:
23 - ParticleCache_test (Failed)
make[3]: Leaving directory '/builddir/build/BUILD/espresso/openmpi_build'
make[2]: Leaving directory '/builddir/build/BUILD/espresso/openmpi_build'
make[1]: Leaving directory '/builddir/build/BUILD/espresso/openmpi_build'
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.yUtVju (%check)
See the "error: Bad exit status from /var/tmp/rpm-tmp.yUtVju (%check)" part in
the middle of %check output.
Has something changed? Or is it an rpm 4.15 thing?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 7 months
Updating Rawhide vs GPG keys
by Vít Ondruch
Hi,
Can somebody please enlighten me, how to update Rawhide after branching
and not using --nogpgcheck?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
the package which is still "rawhide" package and has "f31" keys. But
this package was not probably signed, because this directory is empty:
https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.4/data/signed/
Installing anything from Rawhide fails, because of missing GPG keys.
So is there a way to get the GPG keys via DNF? Would it be possible to
sign fedora-repos and fedora-release packages by older key to allow
smooth updates?
Vít
4 years, 8 months
Re: Request for write permission of menu-cache in Fedora
by Zamir SUN
Ping for updates.
I've build menu-cach 1.1.0 in Copr and already tested against LXQt.
If you are not willing to grant me write permission, can you build this
in EPEL directly?
https://copr.fedorainfracloud.org/coprs/zsun/epel7/build/948489/
On 7/15/19 1:58 PM, Zamir SUN wrote:
> Ping for updates.
>
> On Thu, Jul 11, 2019 at 10:59 PM Zamir SUN <sztsian(a)gmail.com> wrote:
>>
>> Hi Christoph,
>>
>> I am the current maintainer of Fedora LXQt spin. Recently I am updating
>> LXQt in EPEL and I found that I need menu-cache 1.1.0 in EPEL. I filed a
>> bug there[1] but no updates. I checked and see only LXQt uses menu-cache
>> in EPEL, so can you please grant me write permission of menu-cache, so
>> that I can update it in EPEL myself?
>>
>> Thanks.
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1724495
>> --
>> Zamir SUN
>> Fedora user
>> GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
--
Zamir SUN
Fedora user
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
4 years, 8 months