gccgo-go is removed in vivid, superseded by gccgo-5
** Changed in: gccgo-go (Ubuntu)
Status: Confirmed = Invalid
** Summary changed:
- [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
+ [MIR] juju-core, juju-mongodb, gccgo, golang
** Also affects: gcc-defaults (Ubuntu)
Quoting myself: I'm pretty new to Go, but it feels like there's a nice
opportunity to use the type system to create a ShellScript type that can
only be constructed from static strings and properly quoted arguments.
I don't know why it took me until just today to think it through, but what
bash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/04/14 06:38, John A Meinel wrote:
I *really* feel like there is a clearcut win to separating what is
juju the client CLI application that you would install on your
desktop from jujud the server tools that get installed on the
machines
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/04/14 15:18, Matthias Klose wrote:
- Stop bundling every source in juju-core.
I think the dh-golang helper, albeit with golang gc as the default, is
now sufficiently developed to support this for juju-core; however this
ties heavily into how
** Changed in: juju-core (Ubuntu)
Assignee: Seth Arnold (seth-arnold) = (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to golang in Ubuntu.
https://bugs.launchpad.net/bugs/1267393
Title:
[MIR] juju-core,
...
On Mon, Mar 31, 2014 at 01:30:45PM -, Mark Ramm wrote:
I think a key point here is that the juju package does not generally
install or pull down binaries from anywhere to your machine. It does
instruct the cloud installation of a server to use a specific ubuntu
image from
Not addressing the component / archive / PPA questions, but other things
which I think are required.
- Upstream gc only works on adding shared library support to their C compiler,
afaics
there is currently no work done building shared go libs.
Adding this seems to be orthogonal, and even
I partially reviewed juju-core version 1.17.6-0ubuntu1 as checked into
trusty. This shouldn't be considered a full security audit; this review is
even more cursory than usual, since the MIR has been retracted for trusty.
So, here's the notes I've collected thus far in the hopes that they are
@Mark: Thanks for these clarifications. So as far as I understand,
simplestreams is conceptually way above the juju packaging, as it just
selects which built Ubuntu cloud image to fetch and install. So this
doesn't seem related to the question of how to build and package juju
itself.
These Ubuntu
Since we are dropping this MIR for this cycle, can we setup time to go
through this issue across the teams, and get alignment after the
release, but before the Juju cloud sprint at the end of April?
+1. Feel free to bring myself or Adam (or both) into this conversation.
--
You received this
On Sat, Mar 29, 2014 at 04:24:22AM -, Gustavo Niemeyer wrote:
[Steve]
My biggest concern here is that making golang-go genuinely supportable
in the distro context means supporting dynamic linking, and the Go
upstream community appears to be quite hostile to the principle of
dynamic
Actually, because juju-local only supports one architecture (your local
machine), it does *not* download the jujud tools from a remote site, but
uses the one on your local machine. (It should be put into the juju-
local package, rather than being in the 'juju-core' package, but that is
just
@jamie
However, I don't feel the download size is itself a blocker. We can
perform uploads for everything at first, figure out how to be
smarter/more selective later and along the way work with upstream on
dynamic linking if that makes sense.
I think that is particularly true in *this* case
@gustavo
I think it is right that there are many people in the go community who
would welcome dynamic linking in golang-go, but I also think that if we
want to have it, we need to do the work to add it there. Now that we
have to have Arm64 and Power, if we are going to be investing in
improving
@martin
Traditionally the Tech board has nacked everything in main which pulls
code from third-party sources, i. e. installer packages. Packages in
main must not enable any third-party PPA, pull code or binaries from an
upstream site and run it, and so on.
I think a key point here is that the
@all
Given the timeline and the various other bits on our roadmap, I think
main inclusion for juju core is *not* critical this cycle. We would
rather get agreement, and get this done the right way than create last
minute chaos for the release. But, it is critical that we sort this
and the MRE
From Gustavo:
Just a couple of points that might be useful to add:
[Jamie]
If we do this with golang-gc (gccgo would follow established update
procedures),
then right away if there is a security update or SRU in golang-foo-dev, we can
do 'reverse-depends -b golang-foo-dev' to see what needs
No-change uploads in response to a security update in a depended-on go
library package addresses the problem of making sure the security
updates happen, but it's still a suboptimal delivery method for those
security updates because of the download size. Instead of pushing an
update for just the
I think we can all agree that a Trusty desktop and Precise database server is
a pretty common situation, and the combination
of all the things that won't work is definitely common enough to make it a real
issue.
Of course. How come that mixing different Ubuntu releases worked in the
previous
I'm still pretty confused here on the Ubuntu usecase (let's ignore other
OSes, I realise that's a curiously different issue).
1) I run juju locally and want jujud installed on a bunch of cloud VMs.
2) Some magic happens (which, frankly, I don't care about) that gets jujud from
some random place
Since others have been very capably discussing the issues surrounding
installer packages, I won't add much to that conversation except to
make the observation that Go follows an established model for building
projects with other's code (eg, ruby gems, python pip, etc). There is
nothing wrong with
I wrote this before:
The foundations and security team's stance is clear: if we ship something in
Ubuntu in main, we need to be responsible for it and make sure people can get
their updates. Moving forward, I see several options in my personal order of
preference:
1. put resources behind the
* We figure out how to have a reasonable support story using golang-go. One
idea is that we could consider automatically performing no-change uploads to
-proposed with some bug automation if we update the runtime in an SRU/security
update. All packages in main are supposed to have a team
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: juju-core (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to golang in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: gccgo-go (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to golang in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: juju-mongodb (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to golang in Ubuntu.
Sorry, it's late here..
neither the Go community nor the Go core development team (most
important in this case) is not hostile to dynamic linking.
This should read:
note that neither the Go community nor the Go core development team
(most important in this case) are hostile to dynamic
We've had extensive conversations on this topic elsewhere, and these
were pretty much entirely covered in Jamie's comment #27, which does an
excellent job describing the various perspectives for the same problems.
Thanks for that Jamie.
Just a couple of points that might be useful to add:
@adam
I think you'd agree that the obvious and simple usecase isn't I
installed juju-core on my Ubuntu desktop so I can rollout charms on OSX
and Solaris.
Don't forget it will not support: old Ubuntu versions, Arm64, or power,
other versions of Linux, Windows, or anything but the series that
Jamie
Reading you comments in #16, it sounds like option 3) (statically
linking with golang but just for juju-core) is a no-go; I don't believe
that options 1) or 2) can be implemented for 14.04 so I think that means
that juju-core is effectively blocked from main entry for this release?
It
Upstream released jujud binaries are/will be distributed officially via
simplestreams using a documented build process (details TBC).
I've said it before, and I'll reiterate, this is fundamentally broken.
A package in the archive shouldn't have have of its binaries not in the
archive. This
@Adam
The jujud binary that is distributed via simplestreams can be built in
the archive - its currently done in PPA for older Ubuntu releases as it
requires a newer version of golang than we have in 12.04 - but for 14.04
I think the binary is actually picked from the packages in the archive.
@adam
We *can* build and include tools binaries in the package. And in fact
for many tools, we extract them from the builds, and upload them to a
central distribution point (which uses the same toolchain as the ubuntu
cloud images catalog -- simplestreams.
But, we don't distribute the tools
I know a lot of people are looking at this bug and just wanted to follow
up briefly to say that I'm working through some investigations and will
have a response soon.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to golang in Ubuntu.
@Mark
So, if we can build them with the packages, what's stopping us from
having a package that includes the bits, and even depends on the right
things to set up a simplestreams provider that people can use on their
closed networks? Sure, that won't have ALL the binaries for all
supported
Basically, the decision had been taken in Oakland last November that
gccgo is the toolchain Ubuntu Engineering would support on the client
and the foundations and security teams don't consider gc supportable
from a distro standpoint due to the static linking issue.
Ubuntu Server also took the
Does the MIR/security teams seriously consider pulling all of
golang/those static builds into main? The latter is quite a bad design
as I pointed out in comment 12, and by Gustavo's own words the golang
compiler grows old very quickly as there are constantly new upstream
releases with new or
Does the MIR/security teams seriously consider pulling all of
golang/those static builds into main?
This issue is quite complicated and slippery. Basically, the decision
had been taken in Oakland last November that gccgo is the toolchain
Ubuntu Engineering would support on the client and the
What's the time frame for this MIR review to complete?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to golang in Ubuntu.
https://bugs.launchpad.net/bugs/1267393
Title:
[MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
To
Patricia, it is currently blocked by (at least) the security team
review; this review is currently blocked by preparing a new apparmor
package upload for trusty. I sincerely hope this upload is completed
this week.
--
You received this bug notification because you are a member of Ubuntu
Server
I find it rather concerning that golang-go has no runtime library, but
everything gets linked in statically. This leads to enormous binaries
(e. g. each of the juju program are 30 MB) and hence lots of wasted
download/hard disk/archive space, as well as being quite an interesting
challenge wrt.
Jamie
gccgo lacks a feature that golang gc has called escape analysis which is
one of the causes for the increases memory usage with the gccgo built
binaries.
This feature is not planned in the 14.04 timescale for gccgo.
--
You received this bug notification because you are a member of Ubuntu
Regarding adding golang toolchain to MIR, shouldn't we consider fixing
the bug that causes the issue?
** Changed in: juju-core (Ubuntu)
Assignee: Jamie Strandboge (jdstrand) = Seth Arnold (seth-arnold)
--
You received this bug notification because you are a member of Ubuntu
Server Team,
** Changed in: juju-core (Ubuntu)
Assignee: (unassigned) = Jamie Strandboge (jdstrand)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to golang in Ubuntu.
https://bugs.launchpad.net/bugs/1267393
Title:
[MIR] juju-core,
@ubuntu-mir
juju-core will need a security team review; this was discussed at UDS
last.
Cheers
James
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to golang in Ubuntu.
https://bugs.launchpad.net/bugs/1267393
Title:
[MIR]
doko - subscribed ubuntu-server to the packages details in #5-#7
** Changed in: gccgo-go (Ubuntu)
Status: Incomplete = New
** Changed in: golang (Ubuntu)
Status: Incomplete = New
** Changed in: juju-mongodb (Ubuntu)
Status: Incomplete = New
--
You received this bug
juju-mongodb needs a team bug subscriber
** Changed in: juju-mongodb (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1267393
Title:
[MIR]
golang needs a team bug subscriber
** Changed in: golang (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1267393
Title:
[MIR] juju-core,
gccgo-go needs a team bug subscriber
** Changed in: gccgo-go (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1267393
Title:
[MIR]
** Summary changed:
- [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-*
+ [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
** Description changed:
+ golang
+
+ Availability
+
+
+ In universe, limited to amd64, i386 and armhf archs.
+
+ Rationale
+ -
+
+
Adding golang toolchain to MIR; scale testing to 1000 clients had some
rather nasty side-effects on the juju bootstrap node, which pushed a
virtual memory footprint of 50G/resident at 1G. Compared to the
binaries built using golang gc, this is an significant increase (over
twice the footprint
** Summary changed:
- [MIR] juju-core, juju-mongodb, gccgo-go
+ [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-*
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to juju-core in Ubuntu.
https://bugs.launchpad.net/bugs/1267393
Title:
52 matches
Mail list logo
