[aur-general] TU Application: Daniel M. Capella

Levente Polyak anthraxx at archlinux.org
Thu Nov 15 10:19:10 UTC 2018

On 11/15/18 5:50 AM, Daniel M. Capella via aur-general wrote:
>> - tests are awesome <3 run them whenever possible! more is better!
>>   pulling sources from github is favorable when you get free tests
>>   and sometimes manpages/docs
> Will work with the upstreams to distribute these. I prefer to use published
> offerings as they are what the authors intend to be used. GitHub autogenerated
> tarballs are also subject to change:
> https://marc.info/?l=openbsd-ports&m=151973450514279&w=2

Well source tree is the source of truth as that's where processed stuff
comes from :P

If you can't convince all upstream do distribute their tests and
especially not convince them to distribute the sources for generating
docs I would still say please go for source tree instead as the value of
such additional content is high. We love tests.

Side note, nowadays there are lots of python and other project that git
sign their latest tags and commits but have no other way of detatched
signatures, this adds a big gain as well. Remember two of your packages
had upstream tag signatures but i forgot to point them out.
If I can't convince them to use detatched sinatures as well I nowadays
just switch to pull git and use ?signed

>> python-soco:
>> - maybe distribute some docs as well like manpages from docs dir
> I don't see any manpages there. This is a library.

make -C doc man
Manpages are not exclusive for tools, they are for any kind of
documentation like library APIs
try running:
man 3 sprintf

>> razercfg:
>> - do we _really_ need to split razer mouse tool UI and daemon here?
>> doubt it tbh.
> The UI is completely optional. ¯\_(ツ)_/¯

My point is, its the same source and the packages are not huge and it
doesn't have crazy dependency hells.
Only split up if it really makes sense, if there is no real reason we
keep them combined, like tools + libs + headers and don't go as crazy as
debian about splitting up everything.

>> - CPPFLAGS are not respected and should be populated properly
>>   an upstream patch for that would be best
> Will have to figure that out.

All you need in the PR is add $CPPFLAGS where you already see $CFLAGS.
For time being either backport this patch or just export
CFLAGS="${CFLAGS} ${CPPFLAGS} until its done.

> Thank you very much for the review. Go LDFLAGS is still on the todo. Packaging
> for Go has perhaps been more traumatizing than even Node.js.

You're welcome, always a plesure if people are happy about it :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181115/672f47de/attachment.asc>

More information about the aur-general mailing list