----- Mail original -----
De: "Jakub Cajka" <jcajka(a)redhat.com>
À: golang(a)lists.fedoraproject.org
Envoyé: Mardi 16 Janvier 2018 10:16:19
Objet: Re: F28 System Wide Change: Golang 1.10a
>> De: "Jakub Cajka"
> From: "nicolas mailhot"
De: "Jakub Cajka"
> If you don't share how, why it fails we can be just speculating(maybe it is
> bug in your > packaging, build setup). I wouldn't assume google in name ==
> it always works ;).
> I sent you the logs by PM ("only" 5 MiB compressed with xz -9). Did you
not
> receive them ?
Yes I did, and I replied to you.
I see your message now, I had missed it, sorry :(
Thinking about it now as both logs are ~100M text blobs, could you
give me an list of packages
that have failed for you(ideally, but no necessarily with fragments of log where the
failure is
visible)
1. You have a summary of the successes and failures at the end of the log files
2. each failed build run of a package ends with 'Done processing $spec (failure)'
So it's pretty easy to check what package failed and then locate the part of the log
dealing with the last build attempt of this package.
Then check if it's because of a missing dep or a go 1.10 specific problem (of course
the missing dep may be because of the dep failed due to go 1.10). If it's not obvious
the go 1.9 logs provide the logs of the same builds with go 1.9
and srpm link so I can reproduce/investigate the issue?
I'll try to revive my old apache instance to give you access to the files. Ideally I
should redo a full copr run but that takes days to run even only on devel x86_64 (and I
haven't checked how to force go 1.9 in copr to provide a comparison point). Local full
build 'only' takes 8 to 10 hours. On go 1.10 it may be faster so many things fail
:(
I'd love to work on go 1.10 but right now my priority is to finish the bootstraping of
the baseline on go 1.9 so there's no package in the set waiting on a dep or a dep
update to build in full mode. The big remaining bits are docker and maybe kubernetes (some
deps want up to date kubernetes libs, not sure yet if it requires updating kubernetes
itself to latest stable release). Though it is getting easier so many bits have been
updated there are fewer weird failures due to an obsolete part when creating a new
package.
Regards,
--
Nicolas Mailhot