Bug 1230233

AFAIK for F-23 it is on the way with docker BuildRequires already updated to be multi-platform.

(In reply to Dan Horák from comment #1)
> AFAIK for F-23 it is on the way with docker BuildRequires already updated to
> be multi-platform.

The list of BZs you linked misses i686 (which is my highest priority).

eg. in http://pkgs.fedoraproject.org/cgit/golang-github-cpuguy83-go-md2man.git/commit/?id=ea4e03a6807331ef749bf8316ef41aabbbf6776b

(In reply to Stephen Gallagher from comment #2)
> (In reply to Dan Horák from comment #1)
> > AFAIK for F-23 it is on the way with docker BuildRequires already updated to
> > be multi-platform.
> 
> The list of BZs you linked misses i686 (which is my highest priority).

aha, I see :-)

> The list of BZs you linked misses i686 (which is my highest priority).

A bug in i686 was fixed over the weekend. It seems that docker actually bundles a bunch of golang libraries too which was partially the error there too.

(In reply to Peter Robinson from comment #5)
> > The list of BZs you linked misses i686 (which is my highest priority).
> 
> A bug in i686 was fixed over the weekend. It seems that docker actually
> bundles a bunch of golang libraries too which was partially the error there
> too.

Peter, sorry what bug and error are you talking about? link please?

(In reply to Lokesh Mandvekar from comment #6)
> (In reply to Peter Robinson from comment #5)
> > > The list of BZs you linked misses i686 (which is my highest priority).
> > 
> > A bug in i686 was fixed over the weekend. It seems that docker actually
> > bundles a bunch of golang libraries too which was partially the error there
> > too.
> 
> Peter, sorry what bug and error are you talking about? link please?

golang-github-vishvananda-netns

http://koji.fedoraproject.org/koji/buildinfo?buildID=643716

It turned out not to be a bug in the golang-github-vishvananda-netns package but that the version of golang-github-vishvananda-netns bundled within Docker is either old and broken or it's been altered from it's original upstream in a broken way. Either way it should be debundled.

On that topic, does Docker have a bundled library exception from FESCo?

If so this page needs updating, otherwise there's a whole pile of things that need fixing with this package.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Hi Adam,

using bundled/debundled dependencies is one of open question about golang packaging [1].

Docker is not the only 'golang' package in Fedora building from bundled dependencies. It is just impossible to carry out daily builds of a package (to keep up with upstream) and at the same time build from debundled dependencies. Every update of docker's dependencies can break API and make docker unbuildable. Or it takes so much time which you don't have. As recently I have been updating libcontainer which took me about about 3 days. Why? New dependencies of libcontainer appeared. What has to be done? Create a spec file => review request => find someone who will do the review => SCM request => import srpm to all branches => build on all branches => update on all branches => buildroot override on all branches. Some dependencies need to be updated as well. Again, update spec files on all branches => build on all branches => ...

In general, for each project you need different commits of the same dependency which does not have to be backward compatible with each other. So at least one tools (docker, kubernetes, etcd, flannel, mongo-tools, ...) will not build. So sooner or later there will be more packages building from bundled dependencies.

Golang packages are 'just' not yet ready to be fully build only from debundled depencies. What am I doing about that? Trying to keep all dependencies up-to-date with kubernetes, cadvisor, etcd and every other tool I update. So one day 'maybe' API of all golang projects stabilize and there will be no backward compatibility violetions. Checkout out [2] to see for changes in API. The web is still under development but can give a good picture of changes in API (red are changes breaking API, green are extensions of API). E. g. kubernetes has a lot of 'red' changes in API [3].

[1] https://fedorahosted.org/fpc/ticket/382#comment:37
[2] http://10.3.11.63/
[3] http://10.3.11.63/stats/kubernetes.html

Regards
Jan

Oh, OK. The golang SIG/ecosystem is just blatantly disregarding Fedora guidelines in the mean time, got it.

> will be no backward compatibility violetions. Checkout out [2] to see for
> changes in API. The web is still under development but can give a good
> picture of changes in API (red are changes breaking API, green are
> extensions of API). E. g. kubernetes has a lot of 'red' changes in API [3].
> 
> [1] https://fedorahosted.org/fpc/ticket/382#comment:37
> [2] http://10.3.11.63/
> [3] http://10.3.11.63/stats/kubernetes.html

10.x.x.x is a non routeable address space part of RFC-1918. This is a public BZ for Fedora, not some internal RHEL issue, please provide publicly accessible links for [2] and [3]

Hi Peter,

yes, you are right. At the moment the web is still a proof of concept. Once it is finished it will go public.

Jan