Next Open NeuroFedora Meeting: 1300 UTC on Monday, 01 February (Today)

Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 1 February at 1300UTC in #fedora-neuro on IRC (Freenode). The meeting is a public meeting, and open for everyone to attend. You can join us over: IRC: https://webchat.freenode.net/?channels=#fedora-neuro or Matrix

Re: Test timeouts in Fedora Copr emulated envs

On Sun, Jan 31, 2021 at 03:35:14PM +0100, Pavel Raiskup wrote: > 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 syste

Re: Test timeouts in Fedora Copr emulated envs

On Monday, February 1, 2021 10:32:04 AM CET Daniel P. Berrangé wrote: > On Sun, Jan 31, 2021 at 03:35:14PM +0100, Pavel Raiskup wrote: > > 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 buil

Re: Test timeouts in Fedora Copr emulated envs

On 01. 02. 21 10:53, Pavel Raiskup wrote: On Monday, February 1, 2021 10:32:04 AM CET Daniel P. Berrangé wrote: On Sun, Jan 31, 2021 at 03:35:14PM +0100, Pavel Raiskup wrote: On Friday, January 29, 2021 4:26:18 PM CET Daniel P. Berrangé wrote: When we attempt to build libvirt in Copr, the test

Re: Test timeouts in Fedora Copr emulated envs

On 31. 01. 21 16:44, Pavel Raiskup wrote: There can be a macro that you would use like this: --timeout %{adjust_timeout 3600} Currently the environment (the copr-rpmbuild wrapper script) guards that mock doesn't run longer than expected (it is not a mock built-in timeout). Not saying it

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

Thanks also for the nmcli tip, it got me out of a pickle today with RedHat 8. From what I've experienced so far it's well implemented. On Mon, 1 Feb 2021 at 08:42, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Dominik 'Rathann' Mierzejewski wrote: > > You can use crudini to man

Re: Fedora 34 Change: PostgreSQL 13 (Self-Contained Change)

On Fri, Jan 29, 2021 at 04:17:02PM +0100, Patrik Novotny wrote: > > > > Hmm, this sounds rather complicated and risky. > > Do I get this right that postgresql will bundle a copy of libpq, > > and a separate unbundled libpq will be provided? > > > > Why not just include a specific Requires on a spec

Fedora rawhide compose report: 20210201.n.0 changes

OLD: Fedora-Rawhide-20210131.n.0 NEW: Fedora-Rawhide-20210201.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:4 Upgraded packages: 53 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:8.03 MiB

Re: Jython maintainer for Fedora needed

On Sun, 31 Jan 2021 at 14:59, Miro Hrončok wrote: > 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 orphan

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

Matthew Miller wrote: > 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? Does this affect what's on disk? David

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

On Sunday, January 31, 2021, 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: 13725

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

V Fri, Jan 29, 2021 at 06:52:29PM +0100, Kevin Kofler via devel napsal(a): > I still think that the best way to do CI would be what I already suggested > at least once: > 1. maintainer pushes the commit to the branch "rawhide" or "fn" > 2. a quick synchronous commit hook validates obvious things s

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

On Mon, Feb 01, 2021 at 01:24:53PM +, David Howells wrote: > Matthew Miller wrote: > > 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 sys

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

On Sun, Jan 31, 2021 at 08:25:22PM +0100, Florian Weimer wrote: > > 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? >

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

On Mon, Feb 01, 2021 at 03:16:32PM +0100, drago01 wrote: > Comparing the hash algorithms in isolation doesn't mean much - does it make > a difference if you try various file system workloads with the different > algorithms? Probably? I'd have to make sample filesystems to test and don't have spare

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Petr Pisar wrote: > Technically you can make multiple builds from the very same branch and > commit. And some of the builds can pass and some fail. But only one of those will be the CI build used to make the decision. So all that is needed is to ensure that we cannot have a non-CI build that suc

perl-GIS-Distance-0.19 license change

perl-GIS-Distance-0.19 changed license from "GPLv3+" to "GPL+ or Artistic". -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fed

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

Matthew Miller wrote: > On Mon, Feb 01, 2021 at 01:24:53PM +, David Howells wrote: >> Matthew Miller wrote: >> > 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

i3 Spin staging site now available

Hi all, Ben Cotton built a preview of the i3 Spin website that will be used for Fedora 34. We need to include descriptions of the apps we will ship; currently, what is shown is for the LXQt desktop. https://spins.stg.fedoraproject.org/i3/ Alternatively, we can also opt to not have any applic

Re: [i3] i3 Spin staging site now available

Hello Justin and team, Hi all, > > Ben Cotton built a preview of the i3 Spin website that will be used for > Fedora 34. We need to include descriptions of the apps we will ship; > currently, what is shown is for the LXQt desktop. > > https://spins.stg.fedoraproject.org/i3/ > It looks awesome.

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

Missing expected images: Minimal raw-xz armhfp Xfce 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: 39/123 (aarch64), 32/181 (x86_64

Planned Outage - Fedora Packager Dashboard - 2021-02-02 08:00 UTC

There will be an outage starting at 2021-02-02 08:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-02-02 08:00UTC' Reason for outage: Moving the project from its temporary

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

On Sat, Jan 30, 2021, at 1:54 PM, Vitaly Zaitsev via devel wrote: > On 30.01.2021 18:50, clime wrote: > > Hey, what do you mean by this? > > https://docs.fedoraproject.org/en-US/fedora-coreos/alternatives/ > > > Why should scriplets usage be incompatible with immutable Fedora > > releases? > >

Fedora CoreOS Virtual Meetup this week

Hi all, We are going to hold a virtual meetup this Thursday (2021-02-04) . The meetup will cover 2 topics * Growing Fedora CoreOS Community - from 15:00 to 15:50 UTC [0] and * Fedora CoreOS as an Official Edition - from 16:00 to 16:50 UTC [1] The goal is to have an open discussion and come up w

ECL soname bump

A new version of ECL has been released, with an soname bump on the shared library. Only maxima and sagemath depend on ECL, so I will rebuild both of them after updating ECL in about a week. I will do test builds in advance to identify any problems with the upgrade. -- Jerry James http://www.jame

Re: Fedora CoreOS Virtual Meetup this week

On Mon, Feb 01, 2021 at 05:27:54PM +0100, Clement Verna wrote: > The goal is to have an open discussion and come up with a way forward for > both of these topics. If you are interested to listen or contribute please > join us here[2] Sounds interesting -- I'll be there! -- Matthew Miller Fedor

Re: Test timeouts in Fedora Copr emulated envs

On 29. 01. 21 16:26, Daniel P. Berrangé wrote: Is there a good way to detect that the build is in an emulated copr env rather than native. Does Copr / mock set any env variable to show that you're emulated ? I've talked to Pavel Raiskup on IRC about this. Copr uses mock's --forcearch option to

Re: ECL soname bump

On Monday, February 1, 2021 4:53:25 PM WET Jerry James wrote: > A new version of ECL has been released, with an soname bump on the > shared library. Only maxima and sagemath depend on ECL, so I will > rebuild both of them after updating ECL in about a week. I will do > test builds in advance to i

Jami (formerly Ring) P2P softphone packaging?

Has anybody tested the Jami softphone from Savoir-Faire Linux? It was formerly known as Ring. They distribute RPMs directly from the web site[1]. It is already[2] in Debian for some time. They distribute[3] their DHT as a library, OpenDHT, for use in other projects. Regards, Daniel 1. https

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

On Mon, Feb 01, 2021 at 04:06:37PM +0100, Kevin Kofler via devel wrote: > I guess the real question is: does it increase the required disk space or > does it only fill up bits that would otherwise be padding bits? Josef tells me that 32 bytes are reserved _anyway_, with 4 used for crc32c or 8 use

Re: Planned Outage - Fedora Packager Dashboard - 2021-02-02 08:00 UTC

On Mon, Feb 01, 2021 at 05:15:04PM +0100, Frantisek Zatloukal wrote: > There will be an outage starting at 2021-02-02 08:00 UTC, > which will last approximately 2 hours. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > dat

Re: Fedora 34 Mass Rebuild

Fedora 34 mass rebuild of rpms is done and we started running the mass rebuild of modules. FTBFS tickets [0] are being filed now. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1868278 On Tue, Jan 26, 2021 at 1:25 PM Mohan Boddu wrote: > > On Tue, Jan 26, 2021 at 10:52 AM Fabio Valentini wro

Re: Fedora 34 Mass Rebuild

On Mon, Feb 1, 2021 at 3:04 PM Mohan Boddu wrote: > > Fedora 34 mass rebuild of rpms is done and we started running the mass > rebuild of modules. FTBFS tickets [0] are being filed now. > A mass-rebuild of ELN packages is also underway right now. ___ de

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

On Mon, Feb 01, 2021 at 09:44:40AM -0500, Matthew Miller wrote: > On Mon, Feb 01, 2021 at 03:16:32PM +0100, drago01 wrote: > > Comparing the hash algorithms in isolation doesn't mean much - does it make > > a difference if you try various file system workloads with the different > > algorithms? >

Re: Fedora 34 Mass Rebuild

On Mon, Feb 01, 2021 at 03:03:07PM -0500, Mohan Boddu wrote: > Fedora 34 mass rebuild of rpms is done and we started running the mass > rebuild of modules. FTBFS tickets [0] are being filed now. > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=1868278 Additionally, the eln mass rebuild is runn

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

On Mon, Feb 1, 2021 at 8:10 AM Kevin Kofler via devel wrote: > > Matthew Miller wrote: > > > On Mon, Feb 01, 2021 at 01:24:53PM +, David Howells wrote: > >> Matthew Miller wrote: > >> > Plus, it's 64 bit instead of 32 bit. The 256-bit algorithms are > >> > obviously much, much slower and prob

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

On Sun, Jan 31, 2021 at 11:57 AM 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:

Re: Jami (formerly Ring) P2P softphone packaging?

Hello All! Regarding Jami - looks like this is the last opensource SIP-client around which works out-of-the box (no need for extra patches for recent versions of various libraries, local rebuilds, or git knowledge required). I use it for SIP testing (OpenSIPS, Kamailio, SEMS, Asterisk servers) and

Re: Jami (formerly Ring) P2P softphone packaging?

On Mon, Feb 1, 2021 at 1:58 PM Daniel Pocock wrote: > Has anybody tested the Jami softphone from Savoir-Faire Linux? It was > formerly known as Ring. > I haven't looked at it in a couple of years, but last I looked at it, the packaging was awful, and the interdependencies between sub-packages

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

- Original Message - > From: "Fabio Valentini" > To: "Development discussions related to Fedora" > > Sent: Monday, January 25, 2021 4:43:21 PM > Subject: Policy proposal (draft): Don't push knowingly broken or > work-in-progress work to dist git > > On Mon, Jan 25, 2021 at 4:37 PM Step

Re: ECL soname bump

On Mon, Feb 1, 2021 at 11:29 AM José Abílio Matos wrote: > Maxima failed to build on rawhide due to a crash on gcl on the configure > stage: > > https://kojipkgs.fedoraproject.org//work/tasks/9904/60929904/build.log Thank you for pointing that out. I think I see the problem. I'm testing a fix

Re: Jami (formerly Ring) P2P softphone packaging?

Daniel Pocock wrote: > Has anybody tested the Jami softphone from Savoir-Faire Linux? It was > formerly known as Ring. > > They distribute RPMs directly from the web site[1]. It is already[2] in > Debian for some time. Jami has a mandatory dependency on FFmpeg and as such is unsuitable for Fed

Re: Jami (formerly Ring) P2P softphone packaging?

Hi, On Mon, 2021-02-01 at 19:49 +0100, Daniel Pocock wrote: > Has anybody tested the Jami softphone from Savoir-Faire Linux? It > was > formerly known as Ring. > > They distribute RPMs directly from the web site[1]. It is already[2] > in > Debian for some time. > > They distribute[3] their DHT

Re: Jami (formerly Ring) P2P softphone packaging?

On Mon, 2021-02-01 at 22:39 +0100, Peter Lemenkov wrote: > Hello All! > Regarding Jami - looks like this is the last opensource SIP-client > around which works out-of-the box (no need for extra patches for > recent versions of various libraries, local rebuilds, or git > knowledge > required). I use

Re: Jami (formerly Ring) P2P softphone packaging?

On Tue, 2021-02-02 at 00:28 +, Sérgio Basto wrote: > Hi, > > On Mon, 2021-02-01 at 19:49 +0100, Daniel Pocock wrote: > > Has anybody tested the Jami softphone from Savoir-Faire Linux? It > > was > > formerly known as Ring. > > > > They distribute RPMs directly from the web site[1]. It is >

Request to Become Maintainer of a Retired Package (diffuse) + Brief Intro

Hey everyone! Fedora user and long-time GNU/Linux enthusiast here. I am doing my best at attempting to complete the requisite steps[1] for re-introducing the diffuse diff utility to the official Fedora repositories. This is a light - yet very capable - GUI diff tool, that integrates nicely with

Fedora-Rawhide-20210201.n.1 compose check report

(aarch64) New failures (same test not failed in Fedora-Rawhide-20210201.n.0): ID: 767601 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/767601 ID: 767673 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests