This task can be closes. Resolved by 852f18b77f87

I use browsh too occasionally, would love to see it included in the repo as well.

The asdf maintainer is open to making it installed system-wide at some point in the future.

new release few weeks ago

Please use R1417 hub as the basis for subsequent commits (to update hub).

These dependencies aren't necessary - basically, we need only those Qt libs for which we want to have Python bindings. So we need only those libraries that are used by PySide2 revdeps.

This is no longer accepted for inclusion.

I tried to package this. There are needed two new dependencies:

In T8260#171121, @algent wrote:

they should be split in patterns.

I thought that it was a separate package but I see now that python-pyside2 and shiboken2 have same source. If the build succeed they should be split in patterns.

@Jacalz So shiboken2 package needs to be in the Solus repository before this package can be implemented?

You could probably move from python3-devel to pkgconfig(python3). But yeah, as @algent mentioned above. It looks like your issues are from missing shiboken2. We seem to have a shiboken package in the repository but I don't think that it is the correct one.

@vilhelm What about shiboken2?

@algent This is my package.yml so far.

Just wanted to make a small update: I installed wireguard-tools as a snap (https://snapcraft.io/wireguard-ammp), created my private/public keys, defined a wireguard vpn with the Plasma interface and successfully connected to my wireguard enabled router.

@vilhelm can you share your current package.yml file?

@jwinnie I added it and now I am getting this error.

Have you added doxygen as a builddep?

In T8978#171040, @medusalix wrote:

My suggestion was more about that you gate the action of downloading and placing the firmware in the correct place in the filesystem on a post-install user action and not one second before?

I'm currently embedding the firmware in the resulting binary file, so I'd have to make sure the firmware is downloaded before the compilation begins.
I think I'll go with the automatic download though, because that's exactly what scripts like winetricks are doing too. The Update Catalog links to Microsoft's terms of use which - at least to my understanding - explicitly allow end-user use.

My suggestion was more about that you gate the action of downloading and placing the firmware in the correct place in the filesystem on a post-install user action and not one second before?

In T8978#171037, @medusalix wrote:

Yes, the entire driver package can be downloaded from the Microsoft Update Catalog (search for xbox net).
A direct link to the appropriate download also exists: http://download.windowsupdate.com/c/msdownload/update/driver/drvs/2017/07/1cd6a87c-623f-4407-a52d-c31be49e925c_e19f60808bdcbfbd3c3df6be3e71ffc52e43261e.cab
I would have already implemented the firmware download and extraction process in the Makefile, but the maintainer of the Debian package told me it wouldn't solve the licensing issues (not sure if that's true).

@medusalix Thank you very much. I hope you get the permissions. It would be a pity for all the work you have already done.

Yes, the entire driver package can be downloaded from the Microsoft Update Catalog.
A direct link to the appropriate download also exists: http://download.windowsupdate.com/c/msdownload/update/driver/drvs/2017/07/1cd6a87c-623f-4407-a52d-c31be49e925c_e19f60808bdcbfbd3c3df6be3e71ffc52e43261e.cab
I would have already implemented the firmware download and extraction process in the Makefile, but the maintainer of the Debian package told me it wouldn't solve the licensing issues.

In T8978#171035, @medusalix wrote:

Done. I'll have to admit that it was a bad idea to include the firmware without permission in the first place, but here we are.
I hope Microsoft will let me know of their decision before taking down the whole repository. It might be a better idea to completely remove the firmware.bin from the repository right now.

@DataDrake Done. I'll have to admit that it was a bad idea to include the firmware without permission in the first place, but here we are.
I hope Microsoft will let me know of their decision before taking down the whole repository. It might be a better idea to completely remove the firmware.bin from the repository right now.

@medusalix Thank you for reaching out to us. I will hold off on inclusion until this issue is sorted out. In the meantime, can I ask that you add that to the README somewhere? Your current license disclosure makes it seem like you have permission already and I could easily see other distributions making the same mistake. Thanks!

Hi, maintainer here.
I'd like to remind you that I still haven't received a permission from MediaTek and/or Microsoft to redistribute their firmware files.
See this issue on xow's GitHub page. Therefore, I'd advise you to wait for their official approval to avoid any legal issues for Solus.

In T8978#171026, @kaktuspalme wrote:

@ermo I don't know how that could be possible. A Xbox controller can only connect with the dongle if the dongle is initialized. The dongle gets initialized by xow/service. The connection between the dongle and the controller is over wifi but that's just between the dongle and the controller. There's no network traffic or anything. So I can't listen on a socket.

@ermo I don't know how that could be possible. A Xbox controller can only connect with the dongle if the dongle is initialized. The dongle gets initialized by xow/service. The connection between the dongle and the controller is over wifi but that's just between the dongle and the controller. There's no network traffic or anything. So I can't listen on a socket.

Have you played around with socket activation at all?

Yes Gajim has a lot of functionnalities but it is not very... ergonomics.

I am interested in helping package dotnet core started writing the package.yml for this lttng-ust library; unfortunately it looks like it requires the liburcu library v. >=0.12.0. I tried to go through the Update Existing Package walkthrough but I'm forbidden from cloning the liburcu repository, I think because it's archived. The latest archive for liburcu is here: https://lttng.org/files/urcu/userspace-rcu-latest-0.12.tar.bz2

@nelsontkq DO NOT re-open tasks like this. This has still been accepted and is pending someone volunteering to be maintainer and providing a patch. We do not keep old package requests open as it clutters up the bug tracker.

I feel a lot of these comments are outdated. dotnet now comes in a tarball which works with no additional requirements. tarball of the latest stable version

We can't enforce these license terms:

Will do :)

@JeffLabonte As discussed above. Their code repository did not originally tag releases. But they've agreed to start doing so for future releases.

Just giving you a proof @DataDrake :)

Hi! There is a version out, it is 1.2.6!

It has been 3 years since the initial release, it is actively developed and is a re-implementation of author's previous version from 10 years ago. Also the only feature missing is terminal apperance configuration.
And I haven't had any problems for last few months. But obviously the choice is up to you.

"NOTE²: This is an early development version, some feature are missing (see below)."

In T8260#170155, @aleksvor wrote:

In T8260#170123, @vilhelm wrote:

Since this was opened, 5.14.2.1 has been released

Qt for Python should be synced with Qt libraries that we ship, so for now you should build latest 5.13.x release. Mixing different versions of PySide and other Qt libs is not supported and can lead to compilation or runtime issues.