We've been over this. You are being pushy. The answer is and always has been "no". It's not going to change no matter how many times you ask it and no matter how many places you make the request.

Lazarus supports targeting multiple GUI libraries to build interfaces. It does it at compile-time in the IDE, so I'm guessing qt5pas is the wrapper for it. I'd rather not require qt5 as a hard dependency for Lazarus, so I think patterning it out into a qt5pas package makes sense, so long as that library doesn't end up with a circular dep.

Sorry, I'm blind.

Let us know how things go after 4.2 is out (please don't ask for an ETA).

Is this still an issue on the latest Mesa?

I can't see a reason not to, but we might still need the static libs for some things. So testing needed.

10. Export Restriction. You agree that the Software will not be shipped, transferred or exported into any country or used in any manner prohibited by the United States Export Administration Act or any other export laws, restrictions or regulations.

Known bug. Won't be fixed until the installer rewrite.

Normally I'd give this in-depth analysis, but it's written Java and we really don't another bittorrent client. If you don't like that, you are welcome to download and run the JAR yourself.

We currently don't ship any software that would use a system-wide shared library for V8. Everything that we do support (e.g. nodejs) whip with their own vendored release for compatibility reasons.

If this needs the kernel driver, it will be blocking for a bit.

While I appreciate the amount of detail you've gone into, I don't really know enough to say what the root cause is. You'll probably want to reach out to the Firefox team and get their opinion. It's possible that it's not supported at all on Linux for various reasons.

We haven't hear back in over a month, so I'm going to assume this patch hasn't been tested. Without testing, I won't just add it to our kernels. If @stalebrim wants to go through the effort of testing it and upstreaming it,I have no problem using a kernel with those fixes or backporting it to one of our kernels.

With the exception Dolby ProLogic and some other things, there's no way to inform the OS how to handle remixing stereo audio for surround sound. If PulseAudio doesn't support something like Dolby remixing, then that's their problem, not something we can fix. Otherwise, it's a codec issue where the audio you are trying to play can't communicate that information either. It may be the Windows or macOS have a fallback for these scenarios, but no such thing exists on Linux to the best of my knowledge.

I'd rather not change those settings for everyone since it is more likely to break working systems than just fix yours.

The installer won't detect drives that don't have partition tables. You'll need to add a partition table using something like GParted before it will detect them. I agree that not detecting windows is an issue, but that's been reported elsewhere.

If you can get me a PCI Id or a USB ID, I can check compatibility.

Will you actually use this? I'd rather not just add things for the sake of adding them.

No stable releases. We don't ship alpha or beta software unless absolutely necessary and always with the intent of getting onto a stable release ASAP.

Probably no one requested it. I'll add it to my list.

What are the advantages of this over neofetch and screenfetch?

Please give me a better idea of what python things we'd need to support this.

This isn't a problem that can be solved by upgrading to the newer Mesa. You need the improved Intel Vulkan driver that hasn't shipped yet. Probably Mesa 20.3

The only reason we ship netcat is for compatibility. I see no reason to package the BSD version when there are other applications like socat that are actively maintained and support what you are looking to do.

What GPU do you have? Which games? Freesync is not widely supported on Linux yet.

Please file a Package Request as specified here: https://getsol.us/articles/packaging/request-a-package/en/

This is accepted, but LLVM needs an update to 11 first.

In the future, please refrain from asking me specifically to do things. People know which packages are mine.

We aren't comfortable with the legal ramifications of a Youtube viewer that automatically downloads content without forcing you to engage with the Youtube ToS in some way. We can't take the legal risk of being sued for shipping an application which makes piracy, intentional or otherwise, so easy. This isn't like a podcast downloader where the content provider expects you to download the audio for consumption and it's not like a bittorrent client where anything can be downloaded. It's a client for service which provides primarily copyrighted material which is not distributed under a Creative Commons license.

We aren't going to ship two different versions of vulkan-tools, especially not a version that isn't designed to work our vulkan stack. As I've said in other tasks, your issue with Intel is probably that the supported version of Vulkan is too old and you will need to wait for a newer Mesa (> 20.3).

FYI. This won't actually fix your problem because the newer Vulkan support for Intel on Mesa hasn't yet been included in an actual release. It only just landed in master on 11/2 and that means you won't see it until Mesa 20.3 at the earliest.

Yeah, I think I had to disable it at one point for compatibility issues.

https://getsol.us/articles/software/third-party/en/#spideroak

This is already available through Third-Party.

1. This is not the proper way to request an update. This is: https://getsol.us/articles/packaging/request-a-package-update/en/
2. Upgrading ghc requires updated and full rebuilds of every single haskell package (~300 packages). I'm around 90% of the way through a local rebuild of all of those, but it's going to be at least another month before I can devote time to finishing it. Please be patient.

I'm going to leave this open since we still don't have root-cause.

We confirmed on IRC that this system booted using systemd-boot by checking LoaderInfo with efivar. This means we don't need to worry about using bootctl to switch to systemd-boot.

Sure thing.

@algent then I misunderstood the premise of this request and am hereby rescinding my approval to make this change. There is absolutely no reason why they should be using full paths for those executables. The function they are using to run commands is already equipped for searching PATH for anything it needs: https://valadoc.org/glib-2.0/GLib.Process.spawn_command_line_sync.html

You need to build a kernel against the new package...

No one was reported any cache issues in over 2 years now. Tentatively closing this, but please reopen if you are experiencing this issue.

Now that Qt5 has been upgraded, this is likely not an issue anymore. Please reopen if that's not the case.

Given that Arc has been passed around a few times from fork to fork, there's very little chance this will be fixed in the future.

Per P6 this appears to be fixed. Please reopen if that is not the case.

Per P6 this doesn't appear to still be happening.

Marking this as resolved until further notice.

Per P6 this appears to be fixed now.

This has since been fixed.

It's been over a year and no one has stepped up to maintain GRASS or OCI. Closing until that changes.

I'd like to see everything in /usr/lib moved to /usr/share and no /usr/share/java.

So, by the looks of it he abandoned gotop in favor of ytop and then stopped developing ytop. bottom is just something he recommended as a replacement. If you go back to the gotop repo now, he's advertising a maintained fork here: https://github.com/xxxserxxx/gotop

For future reference, filing a new Package Request is not the way to get a deprecated package back. Someone needs to step up and maintain it.

LGTM. Thanks!

We have no plans of adding any additional software to Third Party. I personally use the Flatpak with Zoom and it works fine for my needs.

We don't ship pre-release versions of software unless absolutely necessary. You will need to wait until this lands in a stable release or compile it yourself.