Re: gccgo internal compiler errors
As it's something we need to be doing for a while yet is there value in
adding this as a task that gets run by the landing bot?
Thanks
Matty
On Thu, Aug 28, 2014 at 11:48 PM, Tim Penhey tim.pen...@canonical.com
wrote:
Hi folks,
I spent some time this morning looking at
https://bugs.launchpad.net/juju-core/+bug/1362636
A critical regression that was breaking CI on power.
There is a bug in gccgo where we hit an internal compiler error when
comparing an interface to a concrete type that implements the interface
(as opposed to a pointer to the concrete type implementing the interface).
This impacts some of the names.Tag rework that is going on.
If you try to compare:
var tag names.Tag = names.NewMachineTag(1)
if names.NewUnitTag(1) == tag {
// BOOM!!!
}
This is entirely valid Go, and works fine with gc, but gccgo barfs
horribly.
My fix is here: https://github.com/juju/juju/pull/633
This is just a warning.
Remember folks that we need to support gccgo still (for at least another
year until we have power and arm64 using gc).
You can test locally by doing this:
go test -compiler gccgo
If you install the gccgo packages, which I don't remember, but hopefully
someone will follow up with.
Cheers,
Tim
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: gccgo internal compiler errors
nah, we have a fix upstream, we just need to get that backported to
trusty then this becomes a non issue.
On Fri, Aug 29, 2014 at 7:44 PM, Matthew Williams
matthew.willi...@canonical.com wrote:
As it's something we need to be doing for a while yet is there value in
adding this as a task that gets run by the landing bot?
Thanks
Matty
On Thu, Aug 28, 2014 at 11:48 PM, Tim Penhey tim.pen...@canonical.com
wrote:
Hi folks,
I spent some time this morning looking at
https://bugs.launchpad.net/juju-core/+bug/1362636
A critical regression that was breaking CI on power.
There is a bug in gccgo where we hit an internal compiler error when
comparing an interface to a concrete type that implements the interface
(as opposed to a pointer to the concrete type implementing the interface).
This impacts some of the names.Tag rework that is going on.
If you try to compare:
var tag names.Tag = names.NewMachineTag(1)
if names.NewUnitTag(1) == tag {
// BOOM!!!
}
This is entirely valid Go, and works fine with gc, but gccgo barfs
horribly.
My fix is here: https://github.com/juju/juju/pull/633
This is just a warning.
Remember folks that we need to support gccgo still (for at least another
year until we have power and arm64 using gc).
You can test locally by doing this:
go test -compiler gccgo
If you install the gccgo packages, which I don't remember, but hopefully
someone will follow up with.
Cheers,
Tim
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: gccgo internal compiler errors
I think the bot could be taught to at least compile all the tests under
gccgo (with go test -compiler=gcc -c). That would at least let us detect
compile failures.
John
=:-
On Fri, Aug 29, 2014 at 2:45 PM, David Cheney david.che...@canonical.com
wrote:
nah, we have a fix upstream, we just need to get that backported to
trusty then this becomes a non issue.
On Fri, Aug 29, 2014 at 7:44 PM, Matthew Williams
matthew.willi...@canonical.com wrote:
As it's something we need to be doing for a while yet is there value in
adding this as a task that gets run by the landing bot?
Thanks
Matty
On Thu, Aug 28, 2014 at 11:48 PM, Tim Penhey tim.pen...@canonical.com
wrote:
Hi folks,
I spent some time this morning looking at
https://bugs.launchpad.net/juju-core/+bug/1362636
A critical regression that was breaking CI on power.
There is a bug in gccgo where we hit an internal compiler error when
comparing an interface to a concrete type that implements the interface
(as opposed to a pointer to the concrete type implementing the
interface).
This impacts some of the names.Tag rework that is going on.
If you try to compare:
var tag names.Tag = names.NewMachineTag(1)
if names.NewUnitTag(1) == tag {
// BOOM!!!
}
This is entirely valid Go, and works fine with gc, but gccgo barfs
horribly.
My fix is here: https://github.com/juju/juju/pull/633
This is just a warning.
Remember folks that we need to support gccgo still (for at least another
year until we have power and arm64 using gc).
You can test locally by doing this:
go test -compiler gccgo
If you install the gccgo packages, which I don't remember, but hopefully
someone will follow up with.
Cheers,
Tim
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Juju stable 1.20.6 is released.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 juju-core 1.20.6 A new stable release of Juju, juju-core 1.20.6, is now available. This release replaces 1.20.5. juju-core 1.20.6 is available for utopic and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/stable Noteworthy This releases addresses stability issues, particularly with LXC. Resolved issues * arguments no longer passed to plugins if you don't have an environment set Lp 1359170 * ERROR Nonce already used Lp 1190986 * Juju status returns private IP in 'public-ip' field. Lp 1348287 * juju status unit nil pointer reference. Lp 1357482 * lxc containers created, juju can't seen or communicate with them Lp 1357552 * cannot get tools from machine for lxc container Lp 1359800 * Tools download can fail and is not always retried Lp 1360994 * Containers not starting on machine Lp 1362360 * Update the add machine api to accept both environment name and UUID Lp 1360063 Finally We encourage everyone to subscribe the mailing list at juju-...@lists.canonical.com, or join us on #juju-dev on freenode. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUAMh2AAoJEK84cMOcf+9h1sEH/A8jCI1SX7ZIDOY0orw9QXc2 E9L9pvazW4AhMgLHXrSPsF9xGWJFfbOupwKxYK3ItDAQgjRQlxTTgAr1PdeRIzIG 4ZpjbsyXrzOZHN6M7FFlhBL3A2lz1MN2mL6a5PqwK4yQ0HeDgbNAghEn1fEd/OyM z8nWkfmrSbTFrKInk6B2EQSBAM5vBwS6JaS3A0lw8tgrnCLtUDChvq/x7LG2Hqls iAWhHztgXv3XvytMN4wCjLVSrcM4pvzGtfOZ9q5iPmf2s+2h9p7KhQIpdZriPHN7 fg/UYqHJV3ai+gfSmmeUF7Zlr/vOsRnIIDU/od59jtF79JAX5TmulMRUdF3m400= =nZdE -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Commented-out tests?
Hey all, I ran into some commented out tests while making a change: https://github.com/juju/juju/pull/630/files#r16874739 I deleted them since keeping things around that we might need later is the job of source control, not comments ;) Ian just wanted me to check just to make sure this was OK. If not, please chime in on the PR ASAP. Thanks all! - Katherine -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Commented-out tests?
Git blame says ask Roger ;) 100% agree... don't leave in commented out code. If you feel you must, because you expect it to get uncommented very soon, then leave a very clear comment about why it was commented out and when it should get uncommented. But mostly just don't. On Fri, Aug 29, 2014 at 3:28 PM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: Hey all, I ran into some commented out tests while making a change: https://github.com/juju/juju/pull/630/files#r16874739 I deleted them since keeping things around that we might need later is the job of source control, not comments ;) Ian just wanted me to check just to make sure this was OK. If not, please chime in on the PR ASAP. Thanks all! - Katherine -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Commented-out tests?
On 30/08/14 05:55, Nate Finch wrote: Git blame says ask Roger ;) 100% agree... don't leave in commented out code. If you feel you must, because you expect it to get uncommented very soon, then leave a very clear comment about why it was commented out and when it should get uncommented. But mostly just don't. Agree. I was curious as to why they were commented out - in the absence of comments, I didn't know if people were planning on adding them back Real Soon or if the code truly was obsolete. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Commented-out tests?
On Fri, Aug 29, 2014 at 4:28 PM, Katherine Cox-Buday katherine.cox-bu...@canonical.com wrote: Hey all, I ran into some commented out tests while making a change: https://github.com/juju/juju/pull/630/files#r16874739 I deleted them since keeping things around that we might need later is the job of source control, not comments ;) If it was a relevant test, removing them generally means they're never coming back. The best course of action might be to Skip it or to use ExpectFailure, providing an appropriate reason string. This makes it visible that there are tests not being run or failing, while still making sure they at least build. Of course, if they're indeed never coming back, then just removing them for good is more honest. gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
