https://forum.obarun.org/d/1760-pacman-repositories

Crazy idea: instead of bugging you with MR's can we bring back obmultilib, but in the same model as the new obcommunity (no official support, if you want a package make the PKGBUILD/patches for it yourself, etc...)?

If you (Eric) don't use multilib yourself it could reduce your workload. The lazy way would be to just add those packages to the new obcommunity but I think that should be disallowed in order to make the lives of people who want pure 64bit systems a bit easier.

(It's just my opinion though, I'm kind of curious about what others think about this. I do use multilib and would probably take over one or two packages.)

This announcement was made over a month ago, and so far, no one has raised any concerns or complaints about it. Let's first check if anyone else requests the same changes.

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.

  • cdop replied to this.

    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.

      cdop

      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?

      • nfg replied to this.

        advesperascit

        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))

          • nfg replied to this.

            advesperascit

            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.

            • cdop replied to this.

              advesperascit

              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.

                nfg

                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:

                • no obcommunity maintainer keys (because maintainers can see each other's private keys);
                • one keyring for obcommunity, to sign all the packages for that repo and separate from the normal obarun-keyring;
                • obcommunity-keyring signed with keys from obarun-keyring, so that it can be easily installed without having to jump through hoops with pacman-key;
                • maybe: obcommunity-keyring made available in obextra and not obcommunity, if it makes the above procedures easier.

                The setup described has the following advantages:

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

                Does anyone find any part of this suggestion problematic?

                • eric replied to this.

                  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

                  • cdop replied to this.

                    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