Re: cxxtools-2.2.1 fails to compile on rawhide with gcc11 with /usr/include/c++/11/string_view:98:21: error: static assertion failed

The issue has now been resolved with this patch: +++ include/cxxtools/char.h 2021-01-30 18:28:23.87739 +0100 @@ -68,9 +68,7 @@ typedef int32_t value_type; //! Constructs a character with a value of 0. -Char() -: _value(0) -{}

Re: bootstrapping without .spec modification

On Sat, Jan 30, 2021 at 12:03:21PM -0800, Kevin Fenzi wrote: > On Fri, Jan 29, 2021 at 03:49:28PM +0100, Miro Hrončok wrote: > > > > Currently a Koji task says: > > > > Source: > > git+https://src.fedoraproject.org/rpms/python3.9.git#563b4f4b59a9f81095acfe30899fdc4b040c1b9b > > Build Target: f34

[Test-Announce] Fedora 34 Rawhide 20210131.n.0 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora 34 Rawhide 20210131.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki

Fedora rawhide compose report: 20210131.n.0 changes

OLD: Fedora-Rawhide-20210130.n.0 NEW: Fedora-Rawhide-20210131.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 24 Dropped packages:0 Upgraded packages: 49 Downgraded packages: 0 Size of added packages: 119.05 MiB Size of dropped packages:0

Re: bootstrapping without .spec modification

On 1/31/21 11:55, Zbigniew Jędrzejewski-Szmek wrote: I think those worries are overblown. When a packager has the rights to build an rpm (in a side-tag or not), they also have the right to commit whatever they want to the spec file. Just taking a sentence out of context here: I believe you are

Re: Help for FTBFS packages: apcupsd and firefox-pkcs11-loader

Il giorno dom 31 gen 2021 alle ore 01:38 Robert-André Mauchin ha scritto: > It seems out of tree builds are not supported by the build script. > Just copy the xpi to the build directory to make it work: > > cp -a *.xpi %{_vpath_builddir}/ > > (after the %cmake call) Thank you, it worked!

Fedora-IoT-34-20210131.0 compose check report

Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 9/15 (aarch64), 4/16 (x86_64) New failures (same test not failed in Fedora-IoT-34-20210130.0): ID: 766208 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/76

Re: Fedora rawhide compose report: 20210129.n.0 changes

On 30. 01. 21 19:12, Kevin Fenzi wrote: resubmit should resubmit it just the way it was, ie, against f34-rebuild. A new build should get a new taskid, but this seemed to be the same one the releng one had. Dunno. Perhaps we could ask the people doing this? I've recently did: $ koji tag f34-pen

Re: Test timeouts in Fedora Copr emulated envs

On Friday, January 29, 2021 4:26:18 PM CET Daniel P. Berrangé wrote: > When we attempt to build libvirt in Copr, the test suite times out on > s390 builds. > > IIUC, this is because s390 in Copr is using a QEMU emulated system, > not native hardware, and thus is massively slower to execute. > > W

Fedora-Rawhide-20210131.n.0 compose check report

Missing expected images: Xfce raw-xz armhfp Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 8 of 43 required tests failed, 8 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 40/123 (aarch64), 33/181 (x86_64

Re: Test timeouts in Fedora Copr emulated envs

On 31. 01. 21 15:35, Pavel Raiskup wrote: I don't know, perhaps we could have some configurable coefficient for timeout_in Copr_ for emulated architectures? If that was say "3", and the --timeout was 3600s, emulated arches would get 10800s instead? There can be a macro that you would use lik

Re: Test timeouts in Fedora Copr emulated envs

On Sunday, January 31, 2021 4:17:04 PM CET Miro Hrončok wrote: > On 31. 01. 21 15:35, Pavel Raiskup wrote: > > I don't know, perhaps we could have some configurable coefficient for > > timeout_in Copr_ for emulated architectures? If that was say "3", and > > the --timeout was 3600s, emulated arch

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

> Am 27.01.2021 um 13:56 schrieb Robert Marcano via devel > : > > On 1/25/21 5:53 AM, Peter Boy wrote: >> With Fedora 33 network configuration is by default persisted in >> /etc/NetworkManager/system-connections/*.nmconnection files. The old >> /etc/sysconfig/network-scripts/ifcfg* files are

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

> Am 27.01.2021 um 13:18 schrieb Dominik 'Rathann' Mierzejewski > : > > On Wednesday, 27 January 2021 at 13:11, Arthur G wrote: >> Too bad NetworkManager persists with the old MS-DOS "INI" file format for >> it's configuration files. At least network-scripts was bash script friendly. > > You c

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

On Sun, Jan 31, 2021 at 11:55 AM Peter Boy wrote: > > > > > Am 27.01.2021 um 13:18 schrieb Dominik 'Rathann' Mierzejewski > > : > > > > On Wednesday, 27 January 2021 at 13:11, Arthur G wrote: > >> Too bad NetworkManager persists with the old MS-DOS "INI" file format for > >> it's configuration fi

[Test-Announce] 2021-02-01 @ 16:00 UTC - Fedora QA Meeting

# Fedora Quality Assurance Meeting # Date: 2021-02-01 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We didn't meet for a couple of weeks, and there are interesting goings- on, so let's meet up tomorrow

btrfs hash algorithm (should xxhash be the default?)

On my Intel i7 laptop, xxhash is a small but clear performance win over crc32c: $ ./hash-speedtest 1000 Block size: 4096 Iterations: 1000 Implementation: builtin NULL-NOP: cycles: 1372543560, c/i 137 NULL-MEMCPY: cycles: 2844174884, c/i

Re: btrfs hash algorithm (should xxhash be the default?)

On Sun, Jan 31, 2021 at 1:57 PM Matthew Miller wrote: > > On my Intel i7 laptop, xxhash is a small but clear performance win over > crc32c: > > $ ./hash-speedtest 1000 > Block size: 4096 > Iterations: 1000 > Implementation: builtin > > NULL-NOP: cycles: 1

Re: btrfs hash algorithm (should xxhash be the default?)

On Sun, Jan 31, 2021 at 02:00:02PM -0500, Neal Gompa wrote: > Could you file an issue on the fedora-btrfs project[1] on it? Done (with exactly the same text as my email here): https://pagure.io/fedora-btrfs/project/issue/40 -- Matthew Miller Fedora Project Leader _

Re: btrfs hash algorithm (should xxhash be the default?)

* Matthew Miller: > Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are obviously > much, much slower and probably not right for a default, but should we > consider making xxhash the default for Fedora Linux systems with > btrfs? Is this for an integrity check? Wouldn't it be wise to

Jython maintainer for Fedora needed

Hello Pythonistas (and especially Jythonistas), I've noticed Jython is orphaned in Fedora. There is a new version 2.7.2 available from March 2020. I took a peek, however there are patches in Fedora's Jython I don't fully understand, so it is not easy for me to rebase them. I'd like to keep J

Re: Jython maintainer for Fedora needed

On Sun, 31 Jan 2021 at 14:29, Miro Hrončok wrote: > Hello Pythonistas (and especially Jythonistas), > > I've noticed Jython is orphaned in Fedora. > > There is a new version 2.7.2 available from March 2020. I took a peek, > however > there are patches in Fedora's Jython I don't fully understand,

Re: Jython maintainer for Fedora needed

On 31. 01. 21 20:44, Stephen John Smoogen wrote: On Sun, 31 Jan 2021 at 14:29, Miro Hrončok > wrote: Hello Pythonistas (and especially Jythonistas), I've noticed Jython is orphaned in Fedora. There is a new version 2.7.2 available from March 2020. I t

Re: Fedora 33 network configuration (ifcfg*) migration guide available?

Dominik 'Rathann' Mierzejewski wrote: > You can use crudini to manage .ini files. Works quite well. There's also > nmcli... You might also be able to work with kreadconfig5 and kwriteconfig5 from kf5- kconfig-core, though I have never tried those on NM configs. Kevin Kofler __

Re: Fedora rawhide compose report: 20210129.n.0 changes

On Sun, Jan 31, 2021 at 03:28:15PM +0100, Miro Hrončok wrote: > On 30. 01. 21 19:12, Kevin Fenzi wrote: > > resubmit should resubmit it just the way it was, ie, against > > f34-rebuild. A new build should get a new taskid, but this seemed to be > > the same one the releng one had. Dunno. Perhaps we

License change: libevdev -> MIT

Thanks to a copy/paste error many years ago, libevdev's COPYING file contained the HPND sell variant [1], not the intended MIT license. This has been fixed upstream with the 1.11.0 release which is currently hitting the Fedora repos. libevdev was always meant to be MIT, from the developer's perspe

Re: [Help wanted] Setting vi/view/vim via alternatives

Thank you, Vitaly and Fabio! That makes sense, I didn't look on the issue from new user's view. Most people who use vi/vim are aware of the differences and wanted vi/vim just work if the other is not installed, so vi/vim are drop-in replacements for them in this matter of speaking. And Vi is just