Re: IP-routing fails after upgrade F33->F34

[Tim Evans]

On 5/4/21 8:33 AM, Jouk Jansen wrote:

Hi All,

I'm using one of my Fedora machines as a router between 2 networks. The two
network devices on the machine are called enp0s25 and tun0. On F33 it worked
as expected. However, after an upgrade to F34 It looks like it does not work
anymore.


Jouk, have you resolved this?  Anyone else seen it?

Wanting to upgrade my F33 router/NAT/firewall system.

Thanks.
--
Tim Evans   |   5 Chestnut Court
|   Owings Mills, MD 21117
|   443-394-3864
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: pulseaudio -> pipewire

[Steve Underwood]

On 29/05/2021 15:31, George N. White III wrote:
On Sat, 29 May 2021 at 11:00, Steve Underwood > wrote:


> [...]
When I upgraded from F32 to F33 pulseaudio changed from something
with a
few quirks, to something very troublesome. The main issue was I
had to
restart pulseaudio several times after logging in before it would
actually find my audio devices. I found the cure was to switch to
pipewire. The main long term quirk I had with pulseaudio was that
sometimes starting an app, particularly chrome, would make the sound
distort, and pulseaudio had to be restarted to recover from this. I
haven't seen this problem since changing to pipewire. pipewire
does seem
to show up in a "top" report as using a bit more CPU. This might be
because it is mixing in floating point, or because it just hasn't
been
that well optimised so far, but its CPU load is only a few percent.


You don't mention how capable a CPU you have.  There are tradeoffs.
Modern processors often have "spare" CPU cycles that are used to
advantage, e.g., by measures that reduce memory usage, add
features, etc.   Many people have vastly overpowered CPU's for
their workloads, so developers may be tempted to add features that
would not have made sense a few years ago.

With linux, they who develop software chose tradeoffs. Most of them
are unlikely to have access to bottom-end hardware for testing  It is
inevitable that some use cases will suffer collateral damage.  This
might include your issues with pulseaudio on F34. Collateral damage
can occur when drivers are modified to use new capabilities, or when
legacy quirks needed to support older modules are removed when a
new module eliminates a legacy problem.

--
George N. White III

I have no issues with the CPU power that pipewire is taking. Someone 
else mentioned that it uses more than pulseaudio, and I concur that this 
is the case. Since its only a few percent of one core, I don't really care.


Steve

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: pulseaudio -> pipewire

[George N. White III]

On Sat, 29 May 2021 at 11:00, Steve Underwood  wrote:

> > [...]
> When I upgraded from F32 to F33 pulseaudio changed from something with a
> few quirks, to something very troublesome. The main issue was I had to
> restart pulseaudio several times after logging in before it would
> actually find my audio devices. I found the cure was to switch to
> pipewire. The main long term quirk I had with pulseaudio was that
> sometimes starting an app, particularly chrome, would make the sound
> distort, and pulseaudio had to be restarted to recover from this. I
> haven't seen this problem since changing to pipewire. pipewire does seem
> to show up in a "top" report as using a bit more CPU. This might be
> because it is mixing in floating point, or because it just hasn't been
> that well optimised so far, but its CPU load is only a few percent.
>

You don't mention how capable a CPU you have.  There are tradeoffs.
Modern processors often have "spare" CPU cycles that are used to
advantage, e.g., by measures that reduce memory usage, add
features, etc.   Many people have vastly overpowered CPU's for
their workloads, so developers may be tempted to add features that
would not have made sense a few years ago.

With linux, they who develop software chose tradeoffs.  Most of them
are unlikely to have access to bottom-end hardware for testing  It is
inevitable that some use cases will suffer collateral damage.  This
might include your issues with pulseaudio on F34.   Collateral damage
can occur when drivers are modified to use new capabilities, or when
legacy quirks needed to support older modules are removed when a
new module eliminates a legacy problem.

-- 
George N. White III
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: pulseaudio -> pipewire

[Steve Underwood]

On 26/05/2021 09:15, Frank Elsner via users wrote:

Hi,

I'm a podcaster and therefore I need a functional audio environment.
Currently I use pulseaudio on a Fedora 33 system. Works for me.

Will this also work if I upgrade to Fedora 34?

Is there an equivalent to pavucontrol? I need it to adjust
the level of my external audio interface?

I'm heavy interested in any experience - especially pitfalls - before
I start the upgrade.

When I upgraded from F32 to F33 pulseaudio changed from something with a 
few quirks, to something very troublesome. The main issue was I had to 
restart pulseaudio several times after logging in before it would 
actually find my audio devices. I found the cure was to switch to 
pipewire. The main long term quirk I had with pulseaudio was that 
sometimes starting an app, particularly chrome, would make the sound 
distort, and pulseaudio had to be restarted to recover from this. I 
haven't seen this problem since changing to pipewire. pipewire does seem 
to show up in a "top" report as using a bit more CPU. This might be 
because it is mixing in floating point, or because it just hasn't been 
that well optimised so far, but its CPU load is only a few percent.


I have not used the jack side of pipewire. I have no idea how well that 
works.


___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Segmentation Fault using gdal with Python 3

[George N. White III]

On Fri, 28 May 2021 at 17:22, Clifford Snow  wrote:

> Thanks everyone for their suggestions. I believe my problem is that I've
> installed postgis from the postgresql PGDG repository and it's conflicting
> with the Fedora python gdal files. Not sure If I need to just use Fedora's
> postgresql version or if there is another workaround.
>

You should report the problem to PGDG.   You may need to use python
environments or even
a separate Python install (Anaconda?) if fedora's gdal configuration
doesn't work for your use case.
In my field there is a "mission critical" application that hasn't moved
past Python 3.6 (due to testing
resource constraints, only 3.6 has been properly tested and is available to
the developers when
they need to duplicate a problem) so it is routine to have a Python 3.6
install just for that application.

Anaconda has activate/deactivate scripts, but you can also use
environment-modules or Lmod to
"enable" a specific python version.

environment-modules.x86_64 : Provides dynamic modification of a user's
environment
Lmod.x86_64 : Environmental Modules System in Lua

-- 
George N. White III
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure