[Bug 1028646] New: Error: json: cannot unmarshal number into Go value of type string
https://bugzilla.redhat.com/show_bug.cgi?id=1028646 Bug ID: 1028646 Summary: Error: json: cannot unmarshal number into Go value of type string Product: Fedora Version: 20 Component: docker-io Assignee: l...@redhat.com Reporter: nath.e.w...@gmail.com QA Contact: extras...@fedoraproject.org CC: golang@lists.fedoraproject.org, l...@redhat.com, mat...@redhat.com, mgold...@redhat.com, vba...@redhat.com Description of problem: [root@wyrd ~]# docker search centos 2013/11/08 18:38:41 Error: json: cannot unmarshal number into Go value of type string [root@wyrd ~]# docker search base 2013/11/08 18:43:24 Error: json: cannot unmarshal number into Go value of type string Version-Release number of selected component (if applicable): docker-io-0.7-0.13.dm.fc20.x86_64 How reproducible: every time Steps to Reproduce: 1. install docker-io-0.7-0.13.dm.fc20.x86_64 2. search for an image Actual results: Error: json: cannot unmarshal number into Go value of type string Expected results: list of available image Additional info: -- You are receiving this mail because: You are on the CC list for the bug. ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate
https://bugzilla.redhat.com/show_bug.cgi?id=1022983 --- Comment #16 from Matthew Miller --- Soo, this means that: 1. Unsetting CC at the top of the %check file should work 2. This is probably the right thing to do, because we're not using a wrapper at runtime EXCEPT unsetting CC didn't work. I had to set CC to /usr/bin/gcc to make it work. That's confusing (and why I jumped through the hoops above). Why's that? Uh oh: $ grep mygcc . -r Binary file ./bin/go matches ./src/cmd/go/zdefaultcc.go:const defaultCC = `/home/mattdm/rpmbuild/BUILD/go/zz/mygcc` ./src/cmd/cgo/zdefaultcc.go:const defaultCC = `/home/mattdm/rpmbuild/BUILD/go/zz/mygcc` Binary file ./pkg/tool/linux_amd64/cgo matches We've got the path to the gcc wrapper in the build tree built into the whole thing -- looks like golang 1.2 wants to keep using the wrapper it was built with. That seems logical, but raises some... interesting questions. a) Should all go programs built by the go compiler use our RPM flags? (That is, should we _ship_ the mygcc wrapper?) b) If so, might that introduce horrible bugs? c) If not, should we seek an exception for building golang itself? -- You are receiving this mail because: You are on the CC list for the bug. ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate
https://bugzilla.redhat.com/show_bug.cgi?id=1022983
--- Comment #15 from Matthew Miller ---
And in the generated code, here is our unused "a":
void
_cgo_92e4c70c8af1_Cfunc_foo(void *v)
{
struct {
char unused;
} __attribute__((__packed__, __gcc_struct__)) *a = v;
foo();
}
Now, without going deeply into what that's all about, I've got no idea if this
is a bug or intentional in this test.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
golang mailing list
golang@lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/golang
[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate
https://bugzilla.redhat.com/show_bug.cgi?id=1022983
--- Comment #14 from Matthew Miller ---
Okay, so, here is the test code that is failing:
main.go:
-
package main
/* void foo(void) {} */
import "C"
import (
"fmt"
"runtime"
)
func main() {
C.foo()
buf := make([]byte, 1)
runtime.Stack(buf, true)
fmt.Printf("OK\n")
}
$ go run main.go
# command-line-arguments
./main.go: In function ‘_cgo_92e4c70c8af1_Cfunc_foo’:
./main.go:30:49: warning: unused variable ‘a’ [-Wunused-variable]
OK
but only if CC points to the version which wraps the $RPM_OPT_FLAGS
--
You are receiving this mail because:
You are on the CC list for the bug.
___
golang mailing list
golang@lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/golang
[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate
https://bugzilla.redhat.com/show_bug.cgi?id=1022983 --- Comment #13 from Matthew Miller --- This is especially fun to debug because go cleans up the temporary directory it was using to build right after it exits, making it really hard to find where the error is. Neat. -- You are receiving this mail because: You are on the CC list for the bug. ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate
https://bugzilla.redhat.com/show_bug.cgi?id=1022983 --- Comment #12 from Matthew Miller --- Same error happens in rc3, btw. -- You are receiving this mail because: You are on the CC list for the bug. ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
[Bug 1022983] Consider updating Rawhide to Go 1.2 release candidate
https://bugzilla.redhat.com/show_bug.cgi?id=1022983 --- Comment #11 from Matthew Miller --- RC3 is out now, by the way https://groups.google.com/forum/#!msg/golang-nuts/7FXy8x7Oqyg/_mfUwUdnyXIJ -- You are receiving this mail because: You are on the CC list for the bug. ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
Re: Slides from my future talk at Moscow Golang User Group meetup
On 08/11/13 12:01 +0100, Dan Hor?k wrote: On Fri, 8 Nov 2013 14:43:48 +0400 Peter Lemenkov wrote: CC: Dan Horák, Jeffrey Scheel. Hello All! I'm going to speak at the next Moscow Golang User Group this November and will describe some of Fedora Golang SIG plans. Here are the slides (in Elglish and in Russian): * http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup%202013-11-20%20Fedora%20and%20Golang.en.pdf * http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup%202013-11-20%20Fedora%20and%20Golang.pdf I won't talk about Docker (my fellow golangers from Yandex will do), and won't tell anything about etcd (we still don't decide what to do with it). Instead I'll describe my effords to fix long-standing issue with systemd and multiple Erlang nodes running in parallel. I did few attempts to fix that issue with different success, and finally switched over to golang-powered solution which fixes it (and makes a room for further improvements). This will have an interesting consequence for the secondary arches, such as s390/s390x and PowerPC. In the future all Erlang services in Fedora, namely CouchDB, Ejabberd, RabbitMQ, Riak, will *want* service written in golang (I wouldn't use word "*require*" here). Since golang is available only for x86/x86_64 and ARM, this could be an annoyance. Technically it will still be possible to run Erlang daemons on the secondary arches, but it will require some painful manual intervention, and lead to inevitable race conditions. Beware! Also I hope we'll see some progress on porting Golang on these achitectures. Is there a strict dependency on golang or just on go? Because "GCC 4.8.2 provides a complete implementation of the Go 1.1.2 release." citing from gcc 4.8.2 release notes and we build gccgo on all our secondary arches. gccgo will compile on any arch it is available, while the golang compiler has a more limited scope. So far the golang libraries that are packaged are source only, so anyone wanting to build with gccgo, need only set up their compile flags to -I the directories of the libraries needed. This is left as somewhat of an exercise for those interested. Since some projects will have tuned their resulting executable/binary builds to using the golang compiler instead of the gccgo. Take care, vb pgp1uM25lwvkY.pgp Description: PGP signature ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
Re: docker-io
For anyone who'd prefer 'yum install docker-io' on f19 and f20, please follow Marek Goldmann's blog post here: http://goldmann.pl/blog/2013/11/08/recent-docker-changes-in-fedora/ He maintains a personal repo with the latest docker-io. Hope that helps. On Fri, Nov 08, 2013 at 08:50:20AM -0600, Lokesh Mandvekar wrote: > On Fri, Nov 08, 2013 at 11:13:27AM +0400, Павел wrote: > > Thank you again. > > You're welcome. Another thing to be aware of, currently the docker-io package > plays well only with fedora containers. I've noticed trouble with ubuntu, > centos and busybox containers. > > But this should be fixed soon though: > https://bugzilla.redhat.com/show_bug.cgi?id=1026545 > > > > > > > 2013/11/8 Lokesh Mandvekar > > > > > On Fri, Nov 08, 2013 at 10:39:50AM +0400, Павел wrote: > > > > Ok, thank you Lockesh. > > > > Do you know about when this release will be released? > > > > > > No idea about the release date. Looks like devicemapper integration needs > > > quite a bit > > > of work and testing before it can be officially released. > > > > > > As far as version numbers go, devicemapper integration is expected in 0.7 > > > while docker's master branch is currently on 0.6.6. > > > > > > > > > > > > > > > 2013/11/8 Lokesh Mandvekar > > > > > > > > > On Fri, Nov 08, 2013 at 12:10:30AM -0600, Lokesh Mandvekar wrote: > > > > > > Just so you know, we won't be fedpkg update-ing docker-io since the > > > > > > devicemapper code hasn't made it into the official docker release > > > yet. > > > > > > > > > > To put it better, fedpkg update would be done only after the official > > > > > docker > > > > > release containing devicemaper. > > > > > > > > > > > > > > > -- > > > > > Lokesh Mandvekar > > > > > OpenShift Team > > > > > https://openshift.com > > > > > ___ > > > > > golang mailing list > > > > > golang@lists.fedoraproject.org > > > > > https://lists.fedoraproject.org/mailman/listinfo/golang > > > > > > > > > > > > > > > > > > > > > -- > > > > С уважением, > > > > Павел Недригайлов > > > > > > > ___ > > > > golang mailing list > > > > golang@lists.fedoraproject.org > > > > https://lists.fedoraproject.org/mailman/listinfo/golang > > > > > > > > > -- > > > Lokesh Mandvekar > > > OpenShift Team > > > https://openshift.com > > > ___ > > > golang mailing list > > > golang@lists.fedoraproject.org > > > https://lists.fedoraproject.org/mailman/listinfo/golang > > > > > > > > > > > -- > > С уважением, > > Павел Недригайлов > > > ___ > > golang mailing list > > golang@lists.fedoraproject.org > > https://lists.fedoraproject.org/mailman/listinfo/golang > > > -- > Lokesh Mandvekar > OpenShift Team > https://openshift.com > ___ > golang mailing list > golang@lists.fedoraproject.org > https://lists.fedoraproject.org/mailman/listinfo/golang -- Lokesh Mandvekar OpenShift Team https://openshift.com ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
Re: docker-io
On Fri, Nov 08, 2013 at 11:13:27AM +0400, Павел wrote: > Thank you again. You're welcome. Another thing to be aware of, currently the docker-io package plays well only with fedora containers. I've noticed trouble with ubuntu, centos and busybox containers. But this should be fixed soon though: https://bugzilla.redhat.com/show_bug.cgi?id=1026545 > > > 2013/11/8 Lokesh Mandvekar > > > On Fri, Nov 08, 2013 at 10:39:50AM +0400, Павел wrote: > > > Ok, thank you Lockesh. > > > Do you know about when this release will be released? > > > > No idea about the release date. Looks like devicemapper integration needs > > quite a bit > > of work and testing before it can be officially released. > > > > As far as version numbers go, devicemapper integration is expected in 0.7 > > while docker's master branch is currently on 0.6.6. > > > > > > > > > > > 2013/11/8 Lokesh Mandvekar > > > > > > > On Fri, Nov 08, 2013 at 12:10:30AM -0600, Lokesh Mandvekar wrote: > > > > > Just so you know, we won't be fedpkg update-ing docker-io since the > > > > > devicemapper code hasn't made it into the official docker release > > yet. > > > > > > > > To put it better, fedpkg update would be done only after the official > > > > docker > > > > release containing devicemaper. > > > > > > > > > > > > -- > > > > Lokesh Mandvekar > > > > OpenShift Team > > > > https://openshift.com > > > > ___ > > > > golang mailing list > > > > golang@lists.fedoraproject.org > > > > https://lists.fedoraproject.org/mailman/listinfo/golang > > > > > > > > > > > > > > > > -- > > > С уважением, > > > Павел Недригайлов > > > > > ___ > > > golang mailing list > > > golang@lists.fedoraproject.org > > > https://lists.fedoraproject.org/mailman/listinfo/golang > > > > > > -- > > Lokesh Mandvekar > > OpenShift Team > > https://openshift.com > > ___ > > golang mailing list > > golang@lists.fedoraproject.org > > https://lists.fedoraproject.org/mailman/listinfo/golang > > > > > > -- > С уважением, > Павел Недригайлов > ___ > golang mailing list > golang@lists.fedoraproject.org > https://lists.fedoraproject.org/mailman/listinfo/golang -- Lokesh Mandvekar OpenShift Team https://openshift.com ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
Re: Slides from my future talk at Moscow Golang User Group meetup
2013/11/8 Dan Horák :
> On Fri, 8 Nov 2013 14:43:48 +0400
> Peter Lemenkov wrote:
>> This will have an interesting consequence for the secondary arches,
>> such as s390/s390x and PowerPC. In the future all Erlang services in
>> Fedora, namely CouchDB, Ejabberd, RabbitMQ, Riak, will *want* service
>> written in golang (I wouldn't use word "*require*" here). Since golang
>> is available only for x86/x86_64 and ARM, this could be an annoyance.
>> Technically it will still be possible to run Erlang daemons on the
>> secondary arches, but it will require some painful manual
>> intervention, and lead to inevitable race conditions. Beware! Also I
>> hope we'll see some progress on porting Golang on these achitectures.
> Is there a strict dependency on golang or just on go? Because "GCC
> 4.8.2 provides a complete implementation of the Go 1.1.2 release."
> citing from gcc 4.8.2 release notes and we build gccgo on all our
> secondary arches.
There won't be a *dependency*, just an additional highly desired
systemd-service. If no such service was found it will continue working
as it does right now. If this service is available then systemd starts
it, so Erlang-based application will benefit from it (this will
resolve some issues mysterious for the end users). Also I think of
adding something like this into Erlang spec-file:
%ifarch %{ix86} x86_64 %{arm}
Requires: eclus
%endif
As for eclus dependency on golang that's another interesting story.
Actually eclus doesn't require golang for building, and frankly
speaking I think we shouldn't require golang anywhere else for that -
instead we should come up with some kind of virtual provides for that.
I've built eclus with gcc-go and it works quite fine. In fact I'm
using exactly that build for a couple of weeks already w/o any issues.
However gcc-go doesn't improve situation with secondary arches:
http://thread.gmane.org/gmane.linux.redhat.fedora.golang/23
--
With best regards, Peter Lemenkov.
___
golang mailing list
golang@lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/golang
Re: Slides from my future talk at Moscow Golang User Group meetup
On Fri, 8 Nov 2013 14:43:48 +0400 Peter Lemenkov wrote: > CC: Dan Horák, Jeffrey Scheel. > > Hello All! > > I'm going to speak at the next Moscow Golang User Group this November > and will describe some of Fedora Golang SIG plans. Here are the slides > (in Elglish and in Russian): > > * > http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup%202013-11-20%20Fedora%20and%20Golang.en.pdf > * > http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup%202013-11-20%20Fedora%20and%20Golang.pdf > > I won't talk about Docker (my fellow golangers from Yandex will do), > and won't tell anything about etcd (we still don't decide what to do > with it). Instead I'll describe my effords to fix long-standing issue > with systemd and multiple Erlang nodes running in parallel. I did few > attempts to fix that issue with different success, and finally > switched over to golang-powered solution which fixes it (and makes a > room for further improvements). > > This will have an interesting consequence for the secondary arches, > such as s390/s390x and PowerPC. In the future all Erlang services in > Fedora, namely CouchDB, Ejabberd, RabbitMQ, Riak, will *want* service > written in golang (I wouldn't use word "*require*" here). Since golang > is available only for x86/x86_64 and ARM, this could be an annoyance. > Technically it will still be possible to run Erlang daemons on the > secondary arches, but it will require some painful manual > intervention, and lead to inevitable race conditions. Beware! Also I > hope we'll see some progress on porting Golang on these achitectures. Is there a strict dependency on golang or just on go? Because "GCC 4.8.2 provides a complete implementation of the Go 1.1.2 release." citing from gcc 4.8.2 release notes and we build gccgo on all our secondary arches. Dan ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
Slides from my future talk at Moscow Golang User Group meetup
CC: Dan Horák, Jeffrey Scheel. Hello All! I'm going to speak at the next Moscow Golang User Group this November and will describe some of Fedora Golang SIG plans. Here are the slides (in Elglish and in Russian): * http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup%202013-11-20%20Fedora%20and%20Golang.en.pdf * http://peter.fedorapeople.org/presentations/Moscow%20Golang%20Users%20Meetup%202013-11-20%20Fedora%20and%20Golang.pdf I won't talk about Docker (my fellow golangers from Yandex will do), and won't tell anything about etcd (we still don't decide what to do with it). Instead I'll describe my effords to fix long-standing issue with systemd and multiple Erlang nodes running in parallel. I did few attempts to fix that issue with different success, and finally switched over to golang-powered solution which fixes it (and makes a room for further improvements). This will have an interesting consequence for the secondary arches, such as s390/s390x and PowerPC. In the future all Erlang services in Fedora, namely CouchDB, Ejabberd, RabbitMQ, Riak, will *want* service written in golang (I wouldn't use word "*require*" here). Since golang is available only for x86/x86_64 and ARM, this could be an annoyance. Technically it will still be possible to run Erlang daemons on the secondary arches, but it will require some painful manual intervention, and lead to inevitable race conditions. Beware! Also I hope we'll see some progress on porting Golang on these achitectures. -- With best regards, Peter Lemenkov. ___ golang mailing list golang@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/golang
