------- Original Message ------- On Saturday, May 27th, 2023 at 7:58 PM, é <eclairevoya...@gmail.com> wrote:
> May 27, 2023 16:32:31 Mark Wagie mark.wa...@proton.me: > > > @serebit: It would help if you actually add it to the extra repo before > > deleting it. > > > > Also, I do not appreciate you sloppifying the PKGBUILD and ignoring VCS > > package guidelines for submodules. I spent a lot of time on this package > > doing it right. > > > > Sent with Proton Mail secure email. > > > > ------- Original Message ------- > > On Saturday, May 27th, 2023 at 1:55 PM, > > aur-requests-requ...@lists.archlinux.org > > aur-requests-requ...@lists.archlinux.org wrote: > > > > > Send Aur-requests mailing list submissions to > > > aur-requests@lists.archlinux.org > > > > > > To subscribe or unsubscribe via email, send a message with subject or > > > body 'help' to > > > aur-requests-requ...@lists.archlinux.org > > > > > > You can reach the person managing the list at > > > aur-requests-ow...@lists.archlinux.org > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of Aur-requests digest..."Today's Topics: > > > > > > 1. [PRQ#41615] Deletion Request for booth Accepted > > > (not...@aur.archlinux.org) > > > 2. [PRQ#41412] Deletion Request for rstudio-bin Rejected > > > (not...@aur.archlinux.org) > > > 3. [PRQ#41411] Orphan Request for owncast Accepted > > > (not...@aur.archlinux.org) > > > 4. [PRQ#41674] Deletion Request for googleplay > > > (not...@aur.archlinux.org) > > > 5. [PRQ#41675] Deletion Request for mangohud > > > (not...@aur.archlinux.org) > > > 6. [PRQ#41675] Deletion Request for mangohud Accepted > > > (not...@aur.archlinux.org) > > > 7. [PRQ#41676] Deletion Request for lib32-mangohud > > > (not...@aur.archlinux.org) > > > _______________________________________________ > > > Aur-requests mailing list -- aur-requests@lists.archlinux.org > > > To unsubscribe send an email to aur-requests-le...@lists.archlinux.org > > Well it's not a VCS package anymore (so those guidelines don't apply) nor > does it need to be one since upstream doesn't sign release tags/commits > anyway. Why work harder to get the same code with no tangible benefit? > > The other changes were removing mostly redundant code. Probably the only > change I disagree with is removing the provides arrays... > > > - éclairevoyant It appears my reaction was a bit hasty and sounded rude. I learned this morning from the arch-dev-public list that serebit initially was not able to push lib32-mangohud to multilib. Perhaps using "sloppify" was a little extreme as well. As far as the VCS package guidelines, I was only referring to the use of submodules which mangohud uses. It also uses Meson subprojects. P.S. Is it customary for Arch mailing lists to reply above or below the quote? I know I saw guidelines somewhere, but can't find them now.
