Bug 559652 – new ebuilds: dev-ml/ocplib-endian-0.8 dev-ml/ocaml-cstruct-1.7.0 dev-ml/mirage-profile-0.5 dev-ml/ocaml-dns-0.15.3 dev-ml/ocaml-uri-1.9.1 dev-ml/stringext-1.4.0 dev-ml/io-page-1.5.1 dev-ml/ocaml-pcap-0.3.3 dev-ml/odns-0.3 dev-ml/qcheck-0.4.0.1

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description M. B. 2015-09-05 11:15:48 UTC]

I wrote those ebuilds as support-libraries for Skylable's LibreS3 (Bug 559620).

The respective ebuilds can be found in:
https://github.com/tomboy-64/gentoo/commit/5b7959ed0e7ffa23711fa8edba8125d42c679fdf#diff-3d8189bbcf826ce9ebddbb5dcbd60ba2

They will be tracked as:
https://github.com/tomboy-64/gentoo/tree/skylable-libres3
(This branch also includes Skylable SX and Skylable LibreS3, for which I opened separate bugs.)

The following problems I've identified:
- dev-ml/odns-0.3 is old (2013) and clashes with dev-ml/ocaml-dns-0.15.3 from this collection
      -> odns and ocaml-dns block each other
- dev-ml/mirage-profile-0.5 fails FEATURES=test ( https://github.com/mirage/mirage-profile/issues/11 )
- dev-ml/ocaml-cstruct fails to build with USE=doc ( https://github.com/mirage/ocaml-cstruct/issues/73 )
- dev-ml/ocaml-pcap and dev-ml/qcheck are no direct dependencies of libreS3; i created them because they are optional dependencies of the other packages
- most of those packages are part of the mirage project (https://mirage.io), yet i left out support for the mirage modules since I found it to expansive and I am currently not interested in it.

Reproducible: Always

[Comment 1 Alexis Ballier 2015-10-15 12:46:34 UTC]

hmm could you please open a PR on github repos, one per package, as it is hard to review like that and should be easier for you since you're already using git

[Comment 2 M. B. 2015-10-16 10:04:51 UTC]

Just to confirm, do you *really* want me to open 12 Pull Requests to github/gentoo/gentoo?
Sure, I can do that.

[Comment 3 Alexis Ballier 2015-10-16 10:25:42 UTC]

(In reply to M. B. from comment #2)
> Just to confirm, do you *really* want me to open 12 Pull Requests to
> github/gentoo/gentoo?
> Sure, I can do that.

yes, please :)

you'll kill a few electrons but it's much easier to review ebuilds one by one, so that they can be merged independently

[Comment 4 M. B. 2015-10-16 11:42:57 UTC]

Okay.

Should I add metadata.xml files? With me as maintainer?

Just to make this clear, I'm only willing to support them as a whole, as they are dependencies of a package that I am interested in.

[Comment 5 Alexis Ballier 2015-10-16 11:47:04 UTC]

(In reply to M. B. from comment #4)
> Should I add metadata.xml files? With me as maintainer?
> 
> Just to make this clear, I'm only willing to support them as a whole, as
> they are dependencies of a package that I am interested in.

that's even better

put <herd>ml</herd> and <herd>proxy-maintainers</herd> there too; see e.g. dev-ml/xmlm

(proxy-maintainers herd is good to have so that your contributions are not delayed if ml herd, aka me, goes on vacations :) )

[Comment 6 Michał Górny 2015-10-16 13:52:03 UTC]

(In reply to Alexis Ballier from comment #3)
> (In reply to M. B. from comment #2)
> > Just to confirm, do you *really* want me to open 12 Pull Requests to
> > github/gentoo/gentoo?
> > Sure, I can do that.
> 
> yes, please :)
> 
> you'll kill a few electrons but it's much easier to review ebuilds one by
> one, so that they can be merged independently

Please contribute hardware first. Otherwise, *one pull request* is much more welcome.

[Comment 7 Alexis Ballier 2015-10-16 14:59:49 UTC]

(In reply to Michał Górny from comment #6)
> Please contribute hardware first. Otherwise, *one pull request* is much more
> welcome.

slightly OT, but you might want to solve this differently: since the repo is public and anyone can open PRs, you're likely asking for being DOSed here :)
why not just make CI runs manual?

[Comment 8 Alexis Ballier 2015-11-02 12:08:02 UTC]

all done I think, thanks!