Quoting Levente Polyak via aur-general (2018-11-15 05:19:10)
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.
Agreed. Will do.
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
Noted.
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
Done.
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.
It was split for people who don't need to change options on the fly. Also because I thought it would be kinda neat. :p I don't mind merging them back together.
- 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.
This took me for a ride until I realized I just needed to switch to `CPPFLAGS +=` in the config.mk. A lesson I won't soon forget.
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 :-)
-- Best, polyzen