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

[Eli Schwartz]

On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
> Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
>> - 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

I've seen the occasional *claim* that this happens, but I've yet to see
any actual case where this happens and it isn't because of upstream
force-pushing a tag.

GitHub is supposed to use git-archive(1) for this, which is guaranteed
to be reproducible when generating .tar, although in theory
post-filtering this through a compressor like gzip can result in changes
from one version of git to another. I say in theory because I don't
recall this ever happening, and git-archive uses the fairly boring defaults.

I don't see any reason to use substandard sources in order to avoid
checksum problems I don't believe in.

> For Rust sources there's also this problem:
> https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries
> 
> Crates explicitly filter out lock files. `publish-lockfile` for binary crates
> is still only available in Cargo nightly. Communication is already in
> progress with the relevant upstreams.

I have no clue what this is even supposed to mean. I'm reading your link
and it says that "it's conventional" for upstream developers of rust
applications to commit their lockfiles to git, but not to do so for
libraries. Given that one builds applications, and not libraries, I'm
unsure what the problem is here.

Do you mean to say that crates.io doesn't ship all the files available
in git? Okay, I agree that git is the superior source. I don't generally
trust "intelligent" tools to decide what's important.

Still not sure what this doc describing the split between libraries and
binaries, has to do with anything.

>> firefox-bookmarkdupes:
>> - building from source will have nice signatures
> 
> I check these against upstream checksums:
> `curl -I https://addons.mozilla.org/firefox/downloads/latest/bookmark-dupes/ | grep Digest`
> 
> Building Fx extensions is among the last things I want to do. :p Pretty sure I
> would have to setup an AMO account to then also sign the extension myself.

If upstream is dedicated to PGP-signing the sources, maybe they'd be
willing to PGP-sign a .xpi file too...

>> python-soco:
>> - there are tests available for check() via py.test
> 
> Requires jumping through hoops. See the note:
> https://soco.readthedocs.io/en/latest/development/unittests.html?highlight=test#running-the-unit-tests

Sounds like they have two sets of tests: some unittests for the code
correctness, plus unittests to test the interaction with an online server.

Also sounds like the former, which are all we care about I suppose,
should be easy to do without any hoops, just by running pytest?

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

Why does this mean they cannot be a single package?

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- 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/c42baa45/attachment-0001.asc>