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
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
Just to confirm, do you *really* want me to open 12 Pull Requests to github/gentoo/gentoo? Sure, I can do that.
(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
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.
(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 :) )
(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.
(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?
all done I think, thanks!
