LGTM. Thanks!

@serebit not likely. Maybe out of date libs installed on the local system though

seeing different symbols locally? https://dev.getsol.us/P14

Until Glimpse is sufficiently technically different to GIMP to warrant inclusion, branding changes are insufficient to meet our Package Inclusion Policy.

@serebit not worth it:

@joebonrichie No, that's not at all what I'm saying. I'm saying that it's fully expected that until ypkg3 is out that there will be situations where UNKNOWN is expected to be in both abi_used_libs and abi_used symbols. No one is saying that having UNKNOWN is unacceptable. I would have made it a fatal error that didn't update the abi reports at all if that were the case.

This was always going to be how this works until the ABI functionality is implemented in ypkg3 and generated while running inside the chroot. That's why it's a non-fatal error. The symbols will still be recorded, they just won't be associated with a library. You will still be able to grep by symbol or library, just not by library and symbol. That's already a major improvement over the current state of things where we don't know which symbols are used at all.

This was fixed with v1.0.6 of abi-wizard and in the latest yabi.

@serebit Please update with the new files now that I've fixed yabi.

Dropping this to Normal since it was already reverted.

As long as (1) someone wants to maintain it and (2) people are willing to deal with the limitations, I don't really see the harm in including it. I still see there being benefits to be compiled on Solus for Solus. ungoogled-chromium has already been addressed several times and at least once by me personally. Sacrificing security for privacy is short-sighted.

LGTM. Thanks!

@AlekEagle This is a Solus bug tracker, not Kubuntu's. There are many many differences in the versions, configurations, and integrations of the packages available to both distros. Unless someone can reproduce this on an up-to-date version of Solus, this Task will remain closed. Closing tasks which have not seen any activity in several months is a normal process on the bug tracker and helps us to ensure active support requests get more attention.

Looking at lightdm-autologin, it's definitely never loading pam_limits so that makes sense.

There's got to be something else at play here. I'm using the file from us and it's working fine. Do you have an /etc/security/limits.d/audio.conf.newconfig or some other config file there?

How exactly are you causing this? I can't seem to make this fail for jackd directly or through qjackctl and I verified everything with ulimit -a. The issue last time was tabs, not spaces.

I don't have a problem with seeing a readline update, but it might might want to wait until after I update all the ABI reports.

I don't have a problem with this so long as it's patterned correctly.

The XXX0 chipsets have notoriously bad support on Linux, so I can't say I'm surprised. I agree that linux-lts might work better for you.

I'd say that hidapi and hidapi-32bit should probably be dependencies of Steam and that is isn't specifically an issue with LSI.

Looks like we probably need CONFIG_VIDEO_SAA7134_DVB enabled in the kernel config.

Like I said for the other tuner, I'll look into the kernel side of this, but I really don't want one-off packages for individual firmware files.

I'll look into the kernel side of this when I have a chance. I don't really want to redistribute the firmware of just a single DVB tuner in a dedicated package though, so we'll need a different solution there unless dropping it into place on your system is adequate.

Waiting for feedback from @moriel5 to confirm if this is resolved.

It's been awhile since I've looked into CAKE, but I remember it being promising. It looks like this is probably just a systemd default that we should either be overriding to what we are actually configured for or enabling FQ_CODEL.

Might we worth running an sudo eopkg check and seeing if you have any Broken packages that aren't helping?

I'd like someone to spend a little time reading thorough their github issues and give me summary of the kinds of problems being reported, with an eye to things like:

• ABI changes
• Compatibility
• Regressions
• Upstream usage of additional ciphers

Let's follow up on this after the inclusion of sof-firmware

Since it's the same project, I'll wave the package request for the new GUI. Someone needs to step up as maintainer though.

Can you please tell us which kernel (-current or -lts) and edition (Budgie, Gnome, MATE, Plasma) you are running? Thanks.

Just so you know, there are some blockers on the dependency side of things that the maintainers are working their way through, so this might take a bit.