Re: Fedora Jam 33 Beta - Possible Blocker?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Neal,

On 8/26/2020 7:43 PM, Neal Gompa wrote:
On Wed, Aug 26, 2020 at 10:08 PM Erich Eickmeyer
<erich@xxxxxxxxxxxxxxxxxx> wrote:
HI all,

Since the release of Koji 1.22, there has been a bug [1] blocking any
Fedora Jam 33 or Rawhide iso images from being spun. As you can imagine,
this is making me quite nervous. As it turns out, I'm waiting for Koji
1.22 to be released so that images can start building again. If this
isn't done in time for beta, then that means Fedora Jam will be unable
to participate in beta testing.

If you'd like this fix backported to Fedora's Koji instance ASAP, you
should file a ticket with the infrastructure team here:
https://pagure.io/fedora-infrastructure/issues

I did this for the Btrfs stuff a while back:
https://pagure.io/fedora-infrastructure/issue/9138

Ok, will do.

The issue in question is caused because Jam adds "threadirqs" as a boot
argument in addition to the normal boot arguments. This is a way to add
some low-latency characteristics to a kernel that isn't otherwise a
lowlatency kernel and is known to cut-down on xruns in audio production.

However, one question came up as to if threadirqs is a default in the
kernel configuration, but nobody could answer that. I was wondering if
anyone on this list knew?

threadirqs are not default in the Fedora kernel, as far as I recall.

Contrary to popular belief, CONFIG_IRQ_FORCED_THREADING=y does not
default to threaded IRQs. It only enables the ability to turn them on
by passing "threadirqs" as a kernel parameter. Yes, I know this is
stupid and makes no sense, but Kconfigs are not designed to make
sense...

BIG facts.

I don't know if there's a good reason for them _not_ to be on by
default, though. It doesn't really cause a significant impairment in
almost every case I can think of...
Exactly. It is something I've been considering passing as a parameter in Ubuntu Studio as well since that it seems to solve a lot of xrun issues.
I'm also going to be a little more intentional with working with the
pipewire developers on figuring out jack compatibility issues during the
F34 release cycle.

Isn't the idea that PipeWire would replace JACK and PulseAudio for
most, if not all, cases in the Fedora 34 timeframe? The pace of
development there seems to indicate some very intentional drive toward
that.

Yes, that's the goal. Unfortunately, there are multiple instances where packages that use JACK are looking specifically for the .so and aren't finding it, then throwing dnf errors when they don't find what they're looking for. I'm not sure it there needs to be some sort of symbolic link for compatibility reasons, but that's something I'm planning on exploring with the PipeWire team.

--
Erich Eickmeyer
Maintainer
Fedora Jam
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux