Hi list,
creating a PKGBUILD[1] for Traefik[2], a reverse proxy, I would like to
have it reviewed, as this is the first package I do that is containing
a service.
I tried following the Arch packaging standards[3] but am fairly sure I
missed things.
Other than that it's a Golang project, so I jus
On Wed, 15 Mar 2017 15:41:27 +0100
Stefan Auditor via aur-general wrote:
> Hi list,
>
> creating a PKGBUILD[1] for Traefik[2], a reverse proxy, I would like to
> have it reviewed, as this is the first package I do that is containing
> a service.
>
> I tried following the Arch packaging standard
On Wed, 2017-03-15 at 10:10 -0500, Doug Newgard wrote:
> On Wed, 15 Mar 2017 15:41:27 +0100
> Stefan Auditor via aur-general wrote:
>
> > Hi list,
> >
> > creating a PKGBUILD[1] for Traefik[2], a reverse proxy, I would
> > like to
> > have it reviewed, as this is the first package I do that is
>
Would someone be willing to review the gog-pyre package I've put together? I've
included just the PKGBUILD below, but I'm happy to include the entire enchilada
with git-format-patch. IIRC, this mailing list strips attachments, so I've
included the PKGBUILD inline. I've successfully compiled and
On 1/4/19 11:21 AM, JereBear via aur-general wrote:
> Would someone be willing to review the gog-pyre package I've put together?
> I've included just the PKGBUILD below, but I'm happy to include the entire
> enchilada with git-format-patch. IIRC, this mailing list strips attachments,
> so I've i
> >
> > source=("file:/pyre_${pkgver//./_}.sh"
>
> This is not file:// because it is typoed.
>
> But you should use local:// since file:// is an actual makepkg.conf
> protocol and will be downloaded using curl from an on-disk location.
I'll switch to using the local schema. Is there some resource,
On 1/4/19 1:32 PM, JereBear wrote:
>>>
>>> source=("file:/pyre_${pkgver//./_}.sh"
>>
>> This is not file:// because it is typoed.
>>
>> But you should use local:// since file:// is an actual makepkg.conf
>> protocol and will be downloaded using curl from an on-disk location.
>
> I'll switch to usi
> If you like, you can report a bug to the aurweb parser arguing that
> you'd like to use your RFC 3986 right to an empty URI authority in
> combination with a permissive file: scheme. But currently, attempting to
> push that to the AUR will result in failure due to rejecting any source
> that does
On 1/4/19 10:45 PM, JereBear wrote:
> Interesting. In the strictest case, the first phase of parsing the file scheme
> could consist of matching ^file:(\/\/([a-z0-9-]+)?)? and providing default
> values for missing capture groups. But this only makes sense if the file
> scheme is, well, to be suppo
> > Thanks for the info about the local pseudo-scheme. I've made a note to
> > file a feature request on bugs.archlinux.org, asking for documentation.
> > (Obligatory "and maybe a patch, but don't count on it.") And I'll switch to
> > using it.
>
> Documentation is always good! You're not the first
On 1/6/19 2:00 PM, JereBear wrote:
>>> Thanks for the info about the local pseudo-scheme. I've made a note to
>>> file a feature request on bugs.archlinux.org, asking for documentation.
>>> (Obligatory "and maybe a patch, but don't count on it.") And I'll switch to
>>> using it.
>>
>> Documentation
> Also I think all previous cases of people using local:// in a PKGBUILD
> did not use "/filename", so we were happily parsing it as an authority.
> You've actually broken the aurweb in a practical way by actually caring
> about the RFC. :D
That's gratifying!
This bug appears to affect only the a
On 1/7/19 1:20 PM, JereBear wrote:
>> Also I think all previous cases of people using local:// in a PKGBUILD
>> did not use "/filename", so we were happily parsing it as an authority.
>> You've actually broken the aurweb in a practical way by actually caring
>> about the RFC. :D
>
> That's gratify
> BTW I did submit
> https://lists.archlinux.org/pipermail/aur-dev/2019-January/004619.html
> which I think should fix this.
Thanks!
14 matches
Mail list logo
