Hi Eli and Sebastian, OK, I see the orphan request got approved. Certainly, wasn't looking to draw outrage, but get advice on what the appropriate action. I will update the relevant pythia, xrootd and submit deletion request myself for the others.
As to the package signing, I already know how to detach sign. I also know about the source signing. What is not clear to me is repo-add --sign. The docs say it will update 'the package database'. Which package database? Does AUR keep such info? I though that was for Trusted Users and official repos. What I want to do is essentially to provide a convenient way for people to build or directly download pre-built packages, if they choose to, and be able to verify them, without too much hassle. What do you recommend? Should I just make a *-bin version on AUR with my signature and detach sign the binaries on my own repo? I thought this was also not the AUR way? Could I get someone's workflow for signed packages as an example? Regards, Konstantin On Fri, Mar 17, 2017 at 5:28 PM, Eli Schwartz via aur-general < aur-general@archlinux.org> wrote: > On 03/17/2017 09:48 AM, Konstantin Gizdov wrote: > > xrootd-abi0 (this exists as a work around for other maintainer not > updating > > package) > > Don't do this. It violates the rules of the AUR and now that you have > drawn our attention to it, expect someone to file a deletion request. > > > [...] Pythia, XRootD, Unuran are such extensions which were > > not available or broken in Arch. So I had to make 'pythia8' and > > 'xrootd-abi0' as workarounds. I have now finally been able to adopt > > 'pythia' and plan on making a major re-write and optimization. I still > have > > to keep 'xrootd-abi0' as the current maintainer does not really update or > > fix his package when new versions/problems arise. I do not plan on making > > an orphan request, as I do not want to cause trouble for people. > > > > However, I do wish to make the current environment as good as possible > for > > the people that actually use it and would welcome any input from you. > > Thanks in advance. > > What you say makes no sense. You want it to work well, but the current > maintainer[s] is not actually maintaining the package[s]? And yet you > don't want to file an orphan request because somehow, in some > unidentified manner, an abandoned package getting a new maintainer > constitutes "trouble for people"? > > So instead you violate the rules of the AUR by making forked packages > and confusing people about what is actually needed or available, you > trick people into potentially using the *real* but non-working packages, > and fail dismally at "mak[ing] the current environment as good as > possible". > > Good job! /s > > ... > > Now, go ahead and file that orphan request you should have filed a long > time ago, apparently. > > > Apart from that I wanted to understand better if and how package signing > > works with AUR. I tried the wiki and a bit of Google, but so far it seems > > package signing is only for official repos/trusted users. I did not want > to > > try it out myself before getting some advice as I was afraid messing up > > will prevent people from installing them. > > Signing is for anyone who wants to sign things. The real question is, > what are you trying to sign? > > - Built packages ==> `makepkg --sign`, or retroactively there is always > `gpg --detach-sign builtpkg-1.0-1-any.pkg.tar.xz` > - self-hosted package repository ==> repo-add --sign > - PKGBUILD ==> they don't need to be signed since users are expected to > read them... but there is always `git config commit.gpgsign true` > which users are free to check although AUR helpers certainly won't > - PKGBUILD source=() downloads ==> convince upstream to sign their > release tarballs > > -- > Eli Schwartz > >