----- Original Message -----
From: "nicolas mailhot"
<nicolas.mailhot(a)laposte.net>
To: golang(a)lists.fedoraproject.org
Sent: Tuesday, January 16, 2018 11:16:44 AM
Subject: Re: F28 System Wide Change: Golang 1.10a
----- 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)'
Ah... missed that, I have been just quickly scanning the log's first few 100 lines.
What tool are you using for the build? mockchain?
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.
Easy but extremely time consuming. I have nicely structured output from mockchain(so no
need to writer parser for log file(s)), still it is extremely time consuming, especially
when verifying the issues.
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
_______________________________________________
golang mailing list -- golang(a)lists.fedoraproject.org
To unsubscribe send an email to golang-leave(a)lists.fedoraproject.org
One more thing popped on my mind, I can't really investigate the issues if you have
out of the Fedora dependencies(maybe you could fork the packages in pagure??). If you will
give me failures that you want to be investigated(with log and srpm), I will be happy to
take a look(that do look like golang bugs, no broken deps, code issues, etc.).
JC