- User Since
- Feb 14 2019, 12:59 AM (117 w, 4 d)
Does running sudo usysconf run -f help at all?
Sat, May 15
- Use tmpfiles to create /var/log/lxd
- Use install command instead of mkdir for creating the docs folder
- Move configure to setup phase
- Use systemd tmpfiles instead of creating a directory manually
- Disable static lib compilation
- Use valid SPDX 3.0 identifier
- Move reconfigure to setup phase
- Disable static lib compilation
- Use valid SPDX 3.0 identifier
- Move reconfigure to setup
Thu, May 13
Use programming.library for the component instead of virt
Use programming.library instead of virt for the component
Tue, May 11
I would note that I am already maintaining the lxc package and would be taking on maintaining this as well. I already have it built and well-tested locally and if approved would like the creation of the following repositories (for LXD and dependencies):
Mon, May 10
@aleksvor Just built your diff locally and VDPAU works 👍
@aleksvor Would it be of use to you to have someone with nvidia hardware test VDPAU?
Somehow missed the series file
I have an update for bluez that I'm currently testing. It might be nice to merge that before this so there are no additional rebuilds.
Fri, May 7
So I have this updated to 0.7.18 locally (I was also trying to get fwupd building), as well as gcab to 1.4 (required for fwupd as well). I have the necessary eopkg packages ported and have tested that the eopkg command and solus-sc seem to be functioning normally.
Update to 1.16.1 instead
Wed, May 5
Tue, May 4
@monbosapin From your log I take it you didn't install the solbuild-config-unstable package. When you just run make it runs it against the unstable profile (you can see this in your log). So to fix this do the following:
Mon, May 3
Sun, May 2
Hexchat with appmenu not part of GTK_MODULES (slow start)
@kyrios123 I don't think LSI Logic controller is something that is used by default and it seems to me to that it is likely to be a pretty uncommon configuration. That's moreso why I was checking with @appmath to see if that's indeed what he is using (but it's very similar to the stacktrace from that bug report so I think it's likely).
@brent this point the issue is well-understood and a fix exists. We're still trying to understand which packages are affected as we need to add the fixed vala-panel-appmenu as a dependency so we make sure the fix gets installed alongside the package.
I think it's this issue, which is resolved in the latest 6.1.22 hotfix version.
Oh I just read your post again and you say you are. Yes, try to use HDMI if you can. I walked someone in IRC through reinstalling the previous driver but it's a bit tricky because there are multiple packages to downgrade and due to dependencies and reverse dependencies there are going to be at at least one additional package that needs to be downgraded (Linux-current) and likely a few more if you have other things that provide kernel modules installed
@szmarczak are you using displayport to connect at least one of your monitors? I believe there's a known issue with the most recent Nvidia driver if so.
Sat, May 1
@si You can search the software center for a different browser. Firefox and Vivaldi are both present and are frankly superior browsers. Google Chrome can be found in the "Third Party" tab of the software center.
@DataDrake I think this variation on that function might be slightly better so as to avoid the possibility if appmenu-gtk-module from being appended multiple times (which I noticed could happen if you launched something from a terminal):
Corrected mistake that the hexchat binary should be moved before the wrapper script is put in its place
So my system didn't have vala-panel-appmenu so I had to add it as a run dep of Hexchat. I also tested and a wrapper script is fine for setting that environmental variable (I think using a wrapper script is the safer approach as it has less of a chance of affecting other things unexpectedly).
Fri, Apr 30
Does this need to be a profile script? Or can it be a wrapper script around the binary instead?
Tue, Apr 27
Add "vcrun2010: update sha256sum" patch
Mon, Apr 26
I have not been able to reproduce it myself. Gnome-mpv works fine for me. Perhaps he updated his system after libplacebo was updated but before mpv was finished rebuilding? The time he opened this issue doesn't really line up with that though...
I would like to note that from discussions with Zach today that he is most likely using unstable right now.
Sun, Apr 25
Hint, set PREFIX to /usr because this commit changed how it worked
Solus doesn't use Wayland right now. Does this work in x11? I checked the the Arch and OpenSUSE packages and they both depend on Wayland so I'm assuming the answer is no.
Sat, Apr 24
OK, I think we can close this then. My only question was "Is there something we can do to improve the Firefox hardware acceleration story for Solus users" and the answer is "No because video hardware acceleration is a non-standardized/buggy mess".
Add maintainers file
Fri, Apr 23
I did some research on this and came across the following article from someone who sounds like they are likely involved in the development effort (I glanced through the code as well and it lined up with what they said):
Wed, Apr 21
I'd like to add that I use GNOME and have had no major issues with this upgrade. I haven't yet tried the new patches yet though.
Apr 17 2021
Apr 15 2021
@DrSheppard Did you update recently from after having last updated in like March (or earlier)?
Apr 12 2021
Just some quick feedback that is in no way exhaustive on the repo you linked:
- Name should be lowercase
- When you change the name be aware that the old name is still going to be installed on your system. You will want to eopkg rm it before you install the package with the corrected name.
- Where are you getting that version string from? It should match the upstream version you're building. If I take a look at the releases page, I do not see 21.07.70 as a version of the source code that they have tagged/released.
- Your source archive is refs/heads/master.zip. This is a dynamic file that github generates that always refers to the latest code of the master branch.
- Solus always requires a tagged version of the code. Building against master or main is not allowed. Basically, you should be able to rebuild the same package weeks/months later and get essentially the same thing as when you first built it (the final output might be a little different if the dependencies have been updated in the meantime but your package should be essentially unchanged)
- Because this is a dynamic reference the package build is going to break as soon as someone pushes to kbackups master branch. The hash of the generated zip will have changed by that point. Your build may have already broken by the time you read this if someone pushes a commit between the time I write this and the time you read it.
- The correct source archive to build from is one from whichever version you are choosing to build. To figure this out go to the releases page I linked above, click on the release you want to build, and then copy the URL of the "Source code (tar.gz)" option (some projects only provide .zip files and that's okay, but if you can choose always choose the tar.* files). The version of the release you're building should match the version field in the package file.
- Your summary can be a bit shorter. Something like "A backup utility from KDE". The summary field is what is shown when people do a eopkg search, so short and concise is preferred.
- You committed the .eopkg file. Don't do this. The eopkg file is created from the package files and are not stored alongside the package files. My favorite way to resolve this is to create a global .gitignore and then add *.eopkg to it. This will cause git to always ignore those files. Not really a big deal in this case because your repo would not be copied to dev.getsol.us anyway but something to keep in mind for the future. Contributions that include .eopkg files will not be accepted until they are modified to not include them.
Apr 11 2021
@JoshStrobl It does seem to work in my testing. I would note though that syncthing-gtk seems to be dead upstream. No commits since Oct 2019, no activity from the author or other maintainers on the numerous open issues, and the package has already been removed from the Arch and Fedora repos. I recommend removal of syncthing-gtk from our repo as well.
This was done on Mar 13
Apr 8 2021
@GladOSkar I think this can be kept open at least for some further discussion. I think this would be a nice thing to generally support for more users.
@alecbcs Does it work if you disable or temporarily remove firewalld?
@GladOSkar One thing I noticed after I got it working was that I still got the VA-API FFmpeg is disabled by platform error message upon startup however I did later see output that it was being processed by VA-API. When it was not working I never saw that output.
Apr 7 2021
So I got this working locally with the following:
media.ffmpeg.vaapi.enabled true media.ffvpx.enabled false gfx.webrender.all=true media.hardware-video-decoding.force-enabled true
Also, please run the following and respond back with the output:
sudo eopkg it libva-utils vdpauinfo vainfo vdpauinfo sudo journalctl -b | grep -iE 'vdpau | dri driver'
@GladOSkar Can you start Firefox from the terminal with MOZ_LOG="PlatformDecoderModule:5" firefox and see if D/PlatformDecoderModule VA-API FFmpeg is disabled by platform is in the output (which is the case on my system)?
@JoshStrobl This is done.
Apr 6 2021
For reference, here is another similar package request where Sonic Robo Blast 2 got rejected: https://dev.getsol.us/T1051
Just to temper your expectations a bit this one is very unlikely to be accepted. While the code for that fan game is open source (under GPL2) they make heavy use of Sega's intellectual property and as far as I can tell they do not have an actual license or permission to distribute those. They are operating in a bit of a gray area where the only reason they still exist is because they haven't received a C&D from Sega (because Sega is generally pretty lenient towards fan games).
Adding Serebit as I've seen mentioned elsewhere that the Java stack largely falls under their purview.
Apr 3 2021
Apr 2 2021
@JoshStrobl Yeah, I kept an eye out on the Solus bug reports but luckily I appear to have been the only Solus user to hit this issue. I'll test 247.6 and let you know if for some oddball reason this issue still needs a patch.
Apr 1 2021
Ah, thanks for letting me know! I must have been looking at a different repo by mistake when I was looking to see if there was one.
Mar 28 2021
Mar 26 2021
I have a candidate package for this already testing and working. I believe it is up to the standards of the Solus team and can submit it upon acceptance for inclusion.
Mar 24 2021
FYI the previous version of Discord will no longer launch and requires this update to 0.0.14. It would probably be a good idea to expedite this update to the stable channel.
Oct 18 2019
Closing as my issue is resolved.