Le vendredi 09 mars 2018 à 14:05 +0100, Germano Massullo a écrit : > Hi Nicolas,
Hi Germano > how did you manage to build all of those specs? I have a chainbuild script that: 1. tries to build all the spec fed to him in mock in normal mode then 2. tries to build the specs that failed in bootstrap mode then if successful 3. tries to rebuilt everything that was done in bootstrap mode in normal mode then if successful 4. rebuilds everything in normal mode against the other packages With the appropriate release bumps for everything which is built more than once To be honest, I've not seen it succeed yet when fed the whole 500+ spec stash. There are always at least a handful of failing specs. And I've not yet fixed all the build regressions introduced by some of the choices Jan did. I can post the script if people are interested (it's quick and very dirty) > Is there an > automated tool that provides some almost-ready to use specs? Actually with the macro automation Jan and me did specs are reduced to the bare minimum, so packaging a new Go project is mainly: 1. copying the usual Go spec squeleton 2. identifying the project canonical import path 3. identifying the last project release or the most interesting commit/tag to package 4. filling in description summary and license, identifying the license file and other non .md doc files 5. deciding if the project is going to be an application or a devel only package (in the first case name=application, in the other goname) 6. adding build instructions for commands (trivial if upstream put them in cmd/cmdname, quite non-trivial otherwise) And then try to build and add golang(foo) BuildRequires for everything it complains of not finding. To do more we'd need https://github.com/rpm-software-management/rpm/issues/104 and https://github.com/rpm-software-management/mock/issues/160 This is actually quite simple and fast as long as you do not hit API breaks or projects with scores of tests to check (or broken tests:(). It was a lot more difficult and long before the macros were finalized. Regards, -- Nicolas Mailhot _______________________________________________ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-le...@lists.fedoraproject.org
