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

[Daniel M. Capella]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181115/d7ce66ce/attachment.asc>