@DrSheppard Did you update recently from after having last updated in like March (or earlier)?

Same error: cannot query current apparmor profile: Invalid argument

Can you upload an Xorg log aswell from when it´s failing e.g. /var/log/Xorg.0.log(.old)

also from yesterday: https://paste.ubuntu.com/p/VzgWPxphZj/

Potentially related to screensaver?

Apr 13 20:37:40 solus-pc kernel: gnome-screensav[841]: segfault at 0 ip 0000000000000000 sp 00007ffecb2d15b8 error 14 in gnome-screensaver[400000+8000]
Apr 13 20:37:40 solus-pc kernel: Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
Apr 13 20:37:40 solus-pc audit[841]: ANOM_ABEND auid=4294967295 uid=21 gid=21 ses=4294967295 subj=unconfined pid=841 comm="gnome-screensav" exe="/usr/bin/gnome-screensaver" sig=11 res=1

Can you upload an Xorg log aswell from when it´s failing e.g. /var/log/Xorg.0.log(.old)

This is still an issue.

You saw nothing

Fix package name

Add MAINTAINERS.md

Was not entirely sure if deprecating the klavaro-devel package from solus-sc was necessary but PR pending just in case: https://github.com/getsolus/solus-sc/pull/87

This bug can be fixed by editing /etc/apparmor.d/firejail-default.

@JoshStrobl Would you mind backporting the MimeType patch when you update Go to 1.16.3, now that it has landed upstream? That would mean backporting my patch https://github.com/golang/go/commit/3e8ba91275cdeb0af4c8b30f9cc788fd42cfbbd3 and https://github.com/golang/go/commit/7b19fb1d560908a848e07e091fb5df61f4848389 (for a bug fix making it work better on other Linux distros).

Update to 0.10.3

Update to 1.4.3

It can install VMM? Well, it's got my vote!

I can confirm the issue, desktop compositing in being disabled.

Needless to say, I am certainly available for questions regarding any packaging issues - although I believe the new Meson build is even more straightforward (and gnome-ish) than the old setup.py one

Thanks for the quick reply. The main reason is that I have switched to another distribution as daily driver, meaning that I am not available anymore to maintain the package actively (now it is at 0.2.2). If someone else could maintain the package (or at least update it to 0.2.6 / c20c51951749aa991c72a2937621b07b7a460f48, which uses the Meson build system - since I believe this release will stay the latest for quite a while) then I would be even happier

Like if you don't want to maintain it, that's fine. We can RFC it for a new maintainer, but it being distributed via flatpak is hardly a reason for it to not be included.

Why would we do it via flatpak when we have a native, source repository, and can more easily guarantee that it is using our optimized libraries, interpreters (in the case of python), etc.?

Rejected for inclusion per our Package Inclusion Policy:

3.1.5 soon to be released: https://github.com/wxWidgets/wxWidgets/blob/39c02779423451f7938d36724807ed457b46d7d8/docs/publicity/announce.txt

Manpage generation for glslc.

Setting sync used to be enabled and functional in our builds, but they did break it a while back. I just haven't updated the product.json to reflect that of Microsoft's. Will see if it's viable.

I was thinking there was something about FOSS vs proprietary going on here, so this makes sense. Thanks. I'll close this now.

LGTM, thanks !

Settings sync isn't supported by the open source version of vscode which is used in the Solus repo. If you want this your best bet is downloading the prebuilt tarball from the vscode site and using that official binary, you'll just need to handle updates manually.

@ReillyBrogan Thank you for the feedback. This is my first package so I'm still learning everything.

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.

I've already packaged it and have it installed and running on my Plasma DE. You can view the package.yml and other files from build here https://github.com/brucehankins/solus-kdebackup

@akrenz It actually broke with commit https://dev.getsol.us/R4992:9a0facf8e6aa47f6b7fb61f8ce388afbbd9bfa0a, not the most recent one. Anyway, D10859 fixes it on my system, so just waiting for it to be accepted and committed.

Seems like this is a known issue with JavaFX 11. I'm not sure why it only manifested with the mentioned commit, but in any case, I'm working on a fix. It should also resolve the issues people are having with bisq.

@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.

libavif patch here: D10857

Update summary and description

Thanks! Leaving it up to @Girtablulu on whether it should go in or not. He's the KDE maintainer on Solus :)