Arch Linux (and alternative installs)

[xenoterracide]

So, the website says that arch has smuxi in repo, but that is no longer true, if ever (I don't know). Assuming it was true, it was pushed out of community and into AUR, which is community maintained. Unfortunately, those builds haven't been updated in 2 years, and the build no longer works due to signing issues with log4net. If possible it might be good to adopt those AUR PKGBUILDs update them, and maintain them. I've looked at updating log4net, but I have no idea how to deal with either the binary, or the source archive. It seems to have changed its structure quite a bit in 2 years.

Alternatively, perhaps it's possible for smuxi to be packaged in snapd or flatpak. I'm not entirely certain how well gnome integration works if you do that, though. I think it should.

[Narrat]

https://aur.archlinux.org/cgit/aur.git/commit/?h=smuxi&id=ff40c9801e8f2777855e5465f79fe0df4bbf86fd it was dropped from [community] end of march 2019

Your error regarding the PGP key looks at first glance more like the issue, that you didn't have said key in your gpg keyring? Or did you make sure to add this key? As a starting point, using the PKGBUILD of log4net before you made some updates and try building the package with makepkg -sr --skippgpcheck

[xenoterracide]

I've tried adding it to my keyring it can't find it, so no luck, and I'm not certain what arch is using for a keyring, but even hand doing it, it didn't work. Either I'm doing something wrong, or these key no longer exist on the pool servers (I was reading something about the pool falling to pieces or something). Even if I had gotten that to work for an updated build there are dependencies that aren't provided in AUR, like gtk glade. Either way, Arch builds no longer work, and aren't up to date.

[Narrat]

The SKS-Pool, which was the keyserver network is gone, yes. Therefore there are some problems in that regard. The new default for gpg is AFAIR the one from ubuntu. In whatever state it is compared to the old SKS. There are attempts for a new network, but will take some time to build one. There seems to be a lot of open questions. If log4net would provide their keys via WKD it wold solve the problem, but this doesn't seem the case.

If they don't exist, they can be added. If they did exist in the past, they can be reactivated. That being said, where exactly is this dep missing? aurweb doesn't highlight a missing dep.

[Narrat]

It's kinda funny. Apart from the key issue log4net 2.0.8 builds just fine. Whereas the source files for 2.0.10, 2.0.12 alone cause some issues, as they dump their files directly into $SRCDIR and cannot be built without some major tinkering. What a mess. I would suggest to revert the state of the PKGBUILD back to 2.0.8, as this is at least creating a package. With this, a check could be done to get a working smuxi package. And leaving log4net for someone who really wants to update it to the latest version.

(And for future consideration: PKGBUILDs, that use precompiled files/binary packages should be named as such. So a log4net PKGBUILD, which uses the precompiled packages from upstream should be uploaded as log4net-bin)

[xenoterracide]

I think the missing dep I got was glade mono or glade sharp, idk, not trying at this exact moment. I could revert it, but to be honest, this entire thing has gone beyond the amount of effort I want to spend on something I've never used. Hence I'm suggesting a change to the website, and possibly either a snap/flatpack, or a fixing of AUR.

[Narrat]

That's understandable. But one note from my point of view. From time to time I also look at OoD and orphaned PKGBUILDS. Easy updates get pushed for sure. But if I run into issues, that will require more time than I want to spent, to get everything into a working state, than I don't push changes at all. Especially in cases like smuxi with its deps. log4net is only required by smuxi and apart from being out of date, the package still seemed to be working. So first thing would be to get smuxi back in order and then looking at those deps, if they can be updated. Different case of course if a dep is used by various packages. But that is just my modus operandi. That being said maybe I will take a look at the current state, as I maintained the -git package quite some time, before I dropped it because of a change in setup.

And regarding the website. Well. Maybe it will be updated or not. Don't know what the current development status of smuxi is.

[xenoterracide]

well, one of the reasons I'm suggesting snapd or flatpack is it seems all the distributions can do that now (at least I know snapd is ubuntu), I had it on Fedora and now Manjaro, so... just an idea to save on time managing long term unless an upstream maintainer also wants to do a build. I'm not fully, always in favor of these. I know I had problems with one package? opera? on fedora installed that way. So of course, test thoroughly. Then if users want it, even if their distribution doesn't want to package it, there's a solution. Hmm, I should probably drink my own koolaid here.

But yeah, I could revert it and remove the pgp keys, and get the older version working. I'm honestly not certain if my updated PKGBUILD doesn't work for log4net, I mean, smuxi build scripts seemed to find it. Also, not sure how well AUR managers take to a full downgrade to a lower version.

I guess if it helps, I could get it to the point of where things were failing for me locally, and put that on AUR.

I've also wondered and kind of tried, but couldn't get it to work. log4net seems to have different builds for different .net versions, and other stuff? I tried to get the log4net PKGBUILD to do all of those, but then smuxi couldn't find log4net. I'm just not familliar with this build stack. It was all java, perl, or node, I could probably figure it out ;).

[Narrat]

Oh, of course upstream could use such container/sandbox tech to provide a working "binary". I just didn't comment on it, as I'm not affiliated with this project (just used it a long time) and I personally have my issues with those. Sure they may have some positives, but also possible negatives. Although I must say I'm in that regard not very deeply informed and maybe I'm just a grumpy old person :D But nevertheless a manual/classic installation needs to be possible ;)

Also, not sure how well AUR managers take to a full downgrade to a lower version.

In that regard the answer is easy. AUR helpers can be disregarded ;) It is only required that makepkg works. But this would be an example where epoch could be used (see for example the mpv version), although it isn't required by AUR guidelines. epoch is mainly necessary for binary distribution of packages (e.g. [core], [extra], [community]) which get pulled by pacman where the version can only ever increase. But it is also used for convinience by some users on AUR. But as it can be assumed there are not that much users of those AUR PKGBUILDs around, the use of epoch isn't necessary even for the case of ease of use.

As much as the current build/repackaging process looks like a hack, the package could be working, indeed. But maybe smuxi cannot work with those newer versions. That was my train of thought. And after seeing the ever increasing size of those archives, which kinda suggests massive changes...

2.0.8: 1,3 MB
2.0.10: 2,0 MB (and the associated .asc with 2,5MB, which is kinda curious)
2.0.12: 9,5 MB

And as we both noticed, there were massive changes in building involved with it. Therefore imo best to go back, as that used to work. Then first look at smuxi, then down to the deps.

I'm just not familliar with this build stack.

Same... Smuxi + some deps were my only packages based on .Net/Mono. A lot of comparing with the repo was involved and it worked luckily smooth enough :D And lastly part of a reason why I went for alternatives and dropped it.

[xenoterracide]

But maybe smuxi cannot work with those newer versions

I didn't really try it with the old version of smuxi, I probably should have, I simply decided to upgrade all the things. I stopped when it needed glade gtk # or whatever, which wasn't even a package that existed on AUR. I doubt it's a "doesn't work" thing.

[xenoterracide]

Oh, of course upstream could use such container/sandbox tech to provide a working "binary". I just didn't comment on it, as I'm not affiliated with this project (just used it a long time) and I personally have my issues with those. Sure they may have some positives, but also possible negatives. Although I must say I'm in that regard not very deeply informed and maybe I'm just a grumpy old person :D But nevertheless a manual/classic installation needs to be possible ;)

Yeah, I'm not really in love with them. I'm not entirely certain what problem they are actually solving. Honestly, I'd rather have a user install package manager, so we didn't have to install things as root. Install this program as this user only! Certainly I had more problems than they were worth.

[Narrat]

Puh.. kinda forgot I wanted to look at this. The reason why smuxi cannot be build is a change with gtk-sharp-2. They dropped libglade from the deps (I suspect glade got updated to 3.x by that time and was only compatible with GTK3) https://github.com/archlinux/svntogit-packages/commit/9eefa5aa5b21b4e11990c89cc311a65bdc79d212#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a Therefore glade-sharp cannot be found while building. Two ways to solve this: One needs to build it locally with the change reverted plus the libglade package from the AUR or look at alternatives already at the AUR. Luckily there is one: gtk-sharp-2-git. It never adopted the change from the community package.

Using this as a replacement building smuxi was successfully and the roadmap would kinda look like this: 1) log4net: back to 2.0.8 2) notify-sharp: change the dep to gtk-sharp-2-git (or the git package needs to be installed before manually) 3) smuxi: update to 1.1