I often use multilib as well for WINE and gaming in general.
I would appreciate continued support in some form or another!
Not technically proficient to do packaging myself, but you'll see me posting bug reports here sometimes.
I often use multilib as well for WINE and gaming in general.
I would appreciate continued support in some form or another!
Not technically proficient to do packaging myself, but you'll see me posting bug reports here sometimes.
Hyperspace I would appreciate continued support in some form or another!
I forgot to mention that what motivated my obmultilib question was that 1) I'm seeing more and more systemd deps creep up all over the place (even when such place is unexpected) and that kind of work can quickly demoralize a maintainer (the next update to the xdg-desktop-portal implementations is anything but trivial for example), and 2) I was under the impression that obmultilib was gone for good given the server's response:
sudo pacman -Syy
error: obcommunity: missing required signature
:: Synchronizing package databases...
obcore 38.9 KiB 50.0 KiB/s 00:01 [##########################################] 100%
obextra 233.9 KiB 252 KiB/s 00:01 [##########################################] 100%
obcommunity 30.5 KiB 59.7 KiB/s 00:01 [##########################################] 100%
observice 27.9 KiB 49.8 KiB/s 00:01 [##########################################] 100%
obmultilib.db failed to download
error: failed retrieving file 'obmultilib.db' from cloud.server.obarun.org : The requested URL returned error: 403
error: failed retrieving file 'obcommunity.db.sig' from cloud.server.obarun.org : The requested URL returned error: 404
error: failed to synchronize all databases (unexpected error)
I was going to say that lib32-dbus needs an update, but it's not clear where that update would eventually land.
I've just created lib32-dbus and lib32-p11-kit in obcommunity earlier today based on the their previous obmultilib packaging. They are now up to date.
Something is not entirely right with the trust on my GPG key used for signing, so they unfortunately have to be installed with SigLevel=Never or the key manually added to pacman. Perhaps the key needs to be added to the Obarun keyring?
For the lib32-p11-kit package, I think you forgot to add the GPG key info in the Variables section of the CI/CD Settings page.
Your other package looks ok locally on my machine, although I haven't tried to install it.
❯ pacman -Si lib32-dbus
Repository : obcommunity
Name : lib32-dbus
Version : 1.14.10-2
Description : Freedesktop.org message bus system (32-bit)
Architecture : x86_64
URL : https://wiki.freedesktop.org/www/Software/dbus/
Licenses : GPL custom
Groups : None
Provides : lib32-libdbus libdbus-1.so=3-32
Depends On : dbus
Optional Deps : None
Conflicts With : lib32-libdbus
Replaces : lib32-libdbus
Download Size : 140.60 KiB
Installed Size : 407.93 KiB
Packager : advesperascit <----------------@---------.com>
Build Date : Thu Oct 26 08:01:00 2023
Validated By : MD5 Sum SHA-256 Sum Signature
nfg
Thank you for notifying me! I have added the CI/CD variable and successfully run the deploy job. Now that I look closer at the Arch package I see the systemd dependency for lib32-p11-kit must have been removed since the creation of the old obmultilib package. This is good. Will removing the obcommunity repository also remove the package?
Regarding the lib32-dbus key, if you try to install the package without SigLevel=Never or manually adding the key you'll get:
error: lib32-dbus: signature from "advesperascit <----.-----------@----------.com>" is unknown trust
:: File /var/cache/pacman/pkg/lib32-dbus-1.14.10-2-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Regarding the lib32-dbus key, if you try to install the package without SigLevel=Never or manually adding the key you'll get: ...
Yes, I see that now as I'm having the same problem with trying to install packages I added to the obcommuity repo.
In the meantime (& as you may have already noticed), Eric has setup an obcommunity-keyring package in the obcommunity repo. Follow the instructions to add your key. The package will rebuild, but it isn't installable yet b/c @eric still need to publish the obcommunity packaging key to a keyserver. :)
For now, if you want to test obcommunity-keyring package locally, comment out the first line of the obcommunity-trusted file, and build & install it. The issue with the "unknown trust" of your key for packages like lib32-dbus should go away.
Now that I look closer at the Arch package I see the systemd dependency for lib32-p11-kit must have been removed since the creation of the old obmultilib package. This is good. Will removing the obcommunity repository also remove the package?
I'm not quite sure I follow. The Arch package continues to have make dependencies on lib32-systemd & systemd, so I think you should definitely keep your version in the obcommunity repo.
I see what you mean; there is no final dependency on systemd but there is spooky systemd crud baked into the software during make. I'll keep the package :)
nfg In the meantime (& as you may have already noticed), Eric has setup an obcommunity-keyring package in the obcommunity repo. Follow the instructions to add your key. The package will rebuild, but it isn't installable yet b/c @eric still need to publish the obcommunity packaging key to a keyserver. :)
I've been thinking about the current key setup and I find that in order to avoid difficulties and potential cybersecurity risks down the line we should probably aim for the following:
The setup described has the following advantages:
Does anyone find any part of this suggestion problematic?
First, i need to make an announcement for users about the installation of obcommunity-keyring package. You're quicker than me guys 🙂.
cdop installing packages from obcommunity is always a very deliberate (rather than accidental) action, because it requires two steps (uncommenting the repo and installing the keyring);
the steps are still individually trivial, which means that installing packages from obcommunity is deliberate but not a headache.
obcommunity-keyring is managed in the same way as obarun-keyring; same procedure, same infrastructure.
You fully understood my point.
By default, maintainer do not need to incorporate a personnal GPG key. The obcommunity group provide a sane GPG_SIGN_KEY variable for each obcommunity project. This is avoid the "> cdop maintainers can see each other's private keys issue".
But i let the ability to maintainers to provide their own key if they want. In this case, the maintainer need to update the obcommunity-keyring.
As obcommunity is a none official repo, we have no reason to provide the keyring from the obextra repo. For sure it will be easier for user to use the obcommunity repo but as you said @cdop this force the user to understand the risks.
Well, if you have already set a GPG_SIGN_KEY CI/CD variable at your project, consider to remove it, or do not forget to make change at obcommunity-keyring project.
Usefull link:
obcommunity-keyring documentation
prototype-pkg template documentation changes
Guys you will see a new tag at the forum called Obcommunity. Please use this tag to talk about obcommunity repository
eric new tag at the forum called Obcommunity. Please use this tag to talk about obcommunity
Good idea. In addition to discussion of the repo and its infrastructure, I expect that there will be threads requesting new packages and/or flagging them out of date. And since these packages are not officially supported, any bug reports regarding packages from obcommunity should also be under that tag.
Powered by Obarun