[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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) Importance: Undecided Status: New -- 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, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 (and Juju) are missing is an equivalent to SQL's prepared statements with placeholders. That is the class that Juju is missing, and if properly implemented, would doubtless be useful for the larger Go community beyond just Juju, though Juju would likely be the largest consumer. Thanks -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
-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 that are launched. I think jujud the binary should be in the juju-local package, and it would make lots of sense to keep juju-local in Universe (as it also allows juju-mongodb to stay in Universe, rsyslog- gnutls, cpu-checker, kvm and LXC support can all be brought in by the juju-local package, and *not* by the relatively small juju package.) I'm not sure this is clear-cut at-all - juju-mongodb + other deps are used in Juju deployed services outside of the local provider and we want to be able to provide support and security updates in these environments as well - not just for the local provider. - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPodVAAoJEL/srsug59jDhYcP/RGY9JhW6lRVkfh3OLQAa4HV ygCTDD6hi0S7xBYiRb5XEQ4n8pMPIjabtifBFesZdMo1QieYC4qeqs/s7yiJPro6 mACr6EE/kCNsCtbW+1mO+EXgz/vzXslHjVyIE/OKfPt96O1jwTnAdH1pT0ZAnd0N Du8jMZ8bZ8b8fCdSmhtX4MlBT1axQxcmd0NLnuiosh7xagPK8ZVT+LBqoAC4+HQq qazM6Cxn2yx+dOlWE2cauMQTpJzzp1uwC5qIFil8tgkJ5VmhqDthk+g7oIKIBqHD i5zsIXxpeLz5iouYFYxh22rTY1unf+T1VYudA+TQfoRJIr9iEsBtNlm/RNX1hmzY 1olLVD5y7R6G5QrzDd9XtkObUXRf1PJW/zZ5Klu6V52yUricCp4tCoK3NEaXCD4P 8Ws1NXElpQSzKWS1EAjF18b5EQ1FWzBLE8znc1NG81uNzj0kKJjw/Rffq5lcNsVN WmlAVNbGtzFvHZnnJ56B7MC+H5y7OsOCCqW1p5Bnn/3BuMwr4qGgjUyWTtSvh14s iHGDLmSvlV+8jiN7wEjuZWRFQjBv1oUwIQ3+IDBb0KUROxp6AigCwJ7E2m38PxAe SMYPRUOL2JeLcDeAL9CO23B8VKflygt7DqA+TBxHtBjp0gDAjfm7xyMaz4OiQwcb xeUI/U+N3QP/0m6JurqA =fvnt -END PGP SIGNATURE- -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
-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 jujud tools are distributed as we could end up with a situation where the jujud built in the Ubuntu archive != jujud built for distribution in simplestreams. I've been thinking about this over the last few days and I can't see a route to main for juju-core unless the jujud bits are always built in-archive - these could still potentially be distributed via simplestreams to support the versioned tools approach that juju takes - - probably worth covering how this works for the benefit of others. When a user bootstraps and environment, a tool version selection is made based on the best compatible tools for the client version - so a juju client at 1.17.7 would always pick from 1.17.x; the environment sticks to this version for all new units even if there is a new 1.17.x release - the administrator of the environment initiates an upgrade to this new version using juju: juju upgrade-juju myenv at which point the jujud daemons on the service units pickup the new version, perform any upgrade steps and restart with the new version of the binary. This allows the juju-core development team to have direct control over what happens during an upgrade and how its orchestrated across a running environment. I think this is a unique feature which is extremely hard to address in the packaging space and is very useful for end-users. However this does complicate updates of any kind; thinking in the context of a security update in a world where all juju-core dependencies are in separate packages and juju-core is still statically linked, the security update in the dependency requires a rebuild of juju-core - however this must bump the version of juju-core otherwise its not possible to effectively distribute new tools via simplestreams. Right now addressing an update/bug/security fix has to be done in-conjunction with juju-core upstream (as all dependencies are currently bundled in the source tree) so that tools and distro binaries stay in sync (hence the need for a MRE for juju-core which I will be submitting soon). Patching the distro package fixes issues for those using the local provider or using --upload-tools, but not 'normal' users consuming tool binaries from simplestreams. I guess if juju understood how to interrogate package versions from the archive, it might be possible to always build a version namespaced binary package, e.g. juju-core-1.17.8, so that the archive would retain a history of juju-core versions, allowing juju to pick a) the current version it needs and b) upgrade to a new version if available. - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPoyTAAoJEL/srsug59jDC1kQAM70KG8V8FHRcnhekOyjCtH6 MUBJIMLi6JIcUn6g8rQ6XSqaVehlfa4bEAZV2sj2RcVr0vhC3TPWAEnfkmdfZAew LPvnPX3GaHuw217MFtYCB3e+bwGH3CFQ7YWizy3kut2JhhLvcEC7X1SbKyQ4Wtr4 EjwDE1BD/tuN3V/COy+sg0FOnmoUYS3JBuvS2s24wCy8oSPnZDcB+tmTuerwPLlH ZYE6R4PJlYtbtq20n1SRK6u61ceyfip8OScBu4D7Nkajmz5sgT0qxPEDL4C8rvr6 HV/rtTCmnyJILxsy1Ic8ylFRdvUFwgSfv9rOHlKt3kJd5e7lxOx4r0/8lYq/mge1 NOVz4u/WMWktrqS4EVA1uXhVvYUXEigvSEJE1J3w/wZP7DpvOZMshcIwAsqF//r0 Un3t7NZQ/AzsV+Lrts0iiqpcK1HhJ+6C7GFbJAg20/T29eSV+5m90pZ5tUSaBvOP zN6q5gCNR6agMNY6mbM4FJFjKxXVeX8nDCXGTl1V5f243OpmnpPufUSXMFsaiWMV 6+RlXj+8mCkQSabxTKBjtzyvSi3Q9CFMkxXc3sDBKSITlKSVEIhO39NK0xLz14y1 ye+pttaEf78DzE9BFo2a2Ot31J6tvOf2HF5jqA0K/yYwUCIks3/mPeJYc0g1WwID q2XnBokObDb7OvpliHte =t2vu -END PGP SIGNATURE- -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
** 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, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
... 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 simplestreams and a specific jujud binary (also from simplestreams) on the remote host. I agree with Martin; the fact that these binaries do not originate in the Ubuntu archive, and are not subjected to the normal standards and procedures for the Ubuntu archive, is very concerning. Using simplestreams as the distribution method or not makes no difference to me - but the actual software that's being distributed should be built using Ubuntu best practices. We've been turning a blind eye to this so long as the package has been in universe. I don't think we want juju-core to go into main until jujud is also brought in house in Ubuntu. I'm pretty sure the jujud binaries are being built by the archive. At least, ISTR that we had to wait for some things to get built into Trusty before we could publish them. It may be that we switched to a PPA to increase turn around time, but that isn't as relevant for what we would publish as a stable release. John =:- -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 if you can't yet do this with gc, then you can start developing this with gcc. Questions to address are what to put into a shared library. Just a single Go package, or a bunch of packages? E.g. libgo.so as built from gccgo uses this approach. My feeling is that with a shared library for each go package we end up with hundreds of new libraries. - Start thinking how to package and build third libraries built by gc and gccgo. Sure Debian already does this, but completely ignores gccgo. - Merge our go tool gcc port upstream. Maybe we need a branch for Go 1.2 based compilers? - Stop bundling every source in juju-core. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 useful for the next MIR review: - release-public-tools.sh doesn't validate downloaded packages The jujud that is served up through simplestreams or cloud service provider tools buckets is entirely unchecked against accidental or malicious replacement. Please use apt-get download to retrieve packages, it performs all the necessary package hash comparisons and signed package list comparisons that are currently missing in the shell script. - utils/trivial.go ShQuote() is broken The quoting method used is broken -- some clever arrangement of , `, and $() will be able to execute unexpected commands. Part of why the quoting method is broken is because the design of the tool is trying to accomplish too many things at once. ShQuote() is being used both for quoting a single argument and for parsing entire scripts. It cannot be used for both tasks, and in fact trying to quote an entire script is a mistake. It needs to be re-done to focus on a single argument and use the method of quoting outlined by Florian Weimer at http://www.openwall.com/lists/oss-security/2014/02/04/3 The proper way (at least if your shell runs in a UTF-8 or ISO-8859 locale) to escape shell arguments is to wrap them in '', after replacing embedded ' characters with the four character sequence '\''. 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 -- and then the various Run commands could be typed to only accept arguments of the ShellScript type, to statically discover when a shell injection site may have been missed. - juju-backup shell script uses incorrect quoting method needlessly Another case of trying to quote an entire shell script; the base64 trick used elsewhere may be a better fit for what is attempted here. - The local environment hardcodes use of 'sudo' to raise privileges Some of the functions will execute 'sudo' if they weren't called with sufficient privileges. I'd rather have operations clearly fail if permissions are insufficient instead of trying to raise privileges behind the scenes. If some installations have configured sudo, these may be unwelcome or raise awkward questions or provide a very unfriendly user experience. Using 'sudo' in the units is fine, juju owns those. But sudo on the local host may be different. Thanks -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
@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 cloud images still need to be built somehow. We usually build all our images (desktop, server, cloud, phone) right our of our Ubuntu archive, so it seems for these this isn't the case as the juju bits of these images are pulled down separately from simplestreams. That's what I (and Adam, Jamie, etc.) object to. It should just use the binary packages instead. However, I realize that this is a much smaller impact than having to download the juju client from simplestreams locally (which is still the case for juju-local though). I have no official saying in that matter as I left the Mir/release teams some time ago, but if we can get away with not having to officially support these golang-go builds and golang-go itself with its current limitations, I'm all for that :-) -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 linking. That sounds like an overstatement. It is true that the Go community appreciates static linkage, and some members have public sayings about how dynamic linkage has its own issues, neither the Go community nor the Go core development team (most important in this case) is not hostile to dynamic linking. Ok, thanks for setting me straight on this. 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 simplestreams and a specific jujud binary (also from simplestreams) on the remote host. I agree with Martin; the fact that these binaries do not originate in the Ubuntu archive, and are not subjected to the normal standards and procedures for the Ubuntu archive, is very concerning. Using simplestreams as the distribution method or not makes no difference to me - but the actual software that's being distributed should be built using Ubuntu best practices. We've been turning a blind eye to this so long as the package has been in universe. I don't think we want juju-core to go into main until jujud is also brought in house in Ubuntu. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 shuffling the executables around.) So I think even the local case is already matching what was expected. The main reason the remote case doesn't just 'apt-get install jujud' on the machines we are starting up, is because that would lead to really out-of-date and fairly incompatible versions of jujud running on a heterogenous system. Having Trusty Precise machines, would lead to a case where you would only have the jujud that was available on Precise (I'm not even sure if juju-1.0 was available there), mixed with the latest jujud (hopefully 2.0 in Trusty). It would have been possible to follow the cloud-archive model, where we look up the base Ubuntu image in simplestreams, start an instance with that base image, have that image's first step install a custom archive where we keep compatible versions of the jujud binaries in an archive. However, that doesn't solve the multiple-architectures-that- aren't-Ubuntu case, and we already depend on image lookup. 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 that are launched. I think jujud the binary should be in the juju-local package, and it would make lots of sense to keep juju-local in Universe (as it also allows juju-mongodb to stay in Universe, rsyslog- gnutls, cpu-checker, kvm and LXC support can all be brought in by the juju-local package, and *not* by the relatively small juju package.) I personally think the most productive path forward for Go-in-Ubuntu would be to put effort into the gccgo toolchain, since it is the only one that is going to support PPC/Arm64 anyway. I do think it is a shame to not be using the tool that gets the most focus upstream, but it would fit better into the Ubuntu ecosystem. (We would likely still want to statically compile our jujud binaries, but as they can't really be distributed from the Ubuntu primary archive, I don't think that is particularly problematic.) -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
@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 where we are talking just about Juju Core. Of course as a standard policy, for a future where there may be many go applications in the distro, I think we really do want either golang-go or gcc-go with dynamic linking to be moved into a supportable state. And I also agree that we should not confuse the current case (1 app) with the future. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
@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 a toolchain for Go, I'm not exactly sure where that dev effort should go -- improving, fixing, and making GCC a viable option for us, or doing the dynamic linking in upstream go, as well as figuring out an alternative solution for architectures not supported by golango-go. What are your thoughts on the matter? -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
@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 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 simplestreams and a specific jujud binary (also from simplestreams) on the remote host. (Caveat: I have no idea what simplestreams is and how it works; the description on https://launchpad.net/simplestreams isn't very enlightening, but it sounds like you want to use it as a kind of package distribution system not unlike pip?) Simplestreams is a tool the server team created to help us catalog, sign, and distribute cloud images which are Ubuntu OS images, which can be generic, or customized to run on a specific cloud. The server that gets launched in the cloud when you use juju bootstrap picks a cloud image from simplestreams, verifies it's cryptographic signature, and starts a machine using it, we then grab the appropriate juju binary from simplestreams and install it (again on the remote server). So, juju isn't creating a need to trust simplestreams for the juju binary -- it already must be trusted for cloud images. And we're not creating our own system of packaging for jujud binaries, we're just piggiybacking on the way we distribute Ubuntu images in a cloud context. There is a small caveat: juju does have a local provider feature that sets up lxc containers and runs the jujud binary there. The local provider is designed to simulate a full cloud environment in containers on your local system, and when you do that we do the same thing as I mentioned in doing on the remote side above, we use simplestreams to select the right cloud image, and juju tools binary. That is the only case in which the juju client would download a binary from simplestreams and run it locally, and in that case it is downloading both the cloud image, and the juju binary. So, fixing the juju binary doesn't fix that -- we're still grabbing a binary blob from simplestreams and executing it locally -- the cloud image itself. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
@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 out as cleanly and quickly as possible. Juju is a key to our strategy of growing Ubuntu's presence in the server and cloud worlds, and we can't afford not to be united in our approach. My understanding of the current state of the conversation is that we need to solve two major issues: 1) Package security update rules/processes for Go. 2) SimpleStreams/Tools not in the package issues I think that we are making good progress on the first issue. It seems like there are both short and long term activities that need to happen, and which we can include in our various team plans for next cycle. We can get embedded libraries out, rebuild when needed, and simultaneously try to push forward the state of the art on either GCC go, or the state of dynamic linking on golang-go. I am less sure about us being on a path towards consensus on the second item though... My belief is that the juju team is doing something completely sane given that they have a mandate to support multiple OS's, and a mandate to support cloud image distribution through simplestreams already. And I think that it is not at all fair to call juju a installer package since the external distribution of tools is mostly a remote side issue, where this juju client package is not installed at all. 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? Also, if I'm missing any critical issues on which we have to have alignment, but don't, please raise them NOW rather than wait until the end of the next cycle -- so we can make sure we put aside time to deal with them properly this time. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 rebuilds. As an obvious point yet perhaps worth raising, a bug in a library doesn't necessarily mean everything has to be rebuilt. Right, I tried to mention this when I said but long term, perhaps we could figure out how to declare what changed in the update and have the no change auto builds mechanism detect what needs to be built based on that. I was trying to convey that even in the very nearest of short term, we can just rebuild everything, and we can figure out how to be smarter as we go. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 library with the security fix, you're pushing the update for that package plus all its reverse-dependencies, which is made all the worse by the fact that each of those revdeps is statically linked (==larger). We might be able to make this work for juju in the short term, but it doesn't scale particularly well. I agree and mentioned this in my comment, which is why I feel gccgo is the most correct solution (or golang-go with dynamic linking support). 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. In the meantime, developers wanting to target the phone or environments with potentially aggressive data restrictions, etc should carefully consider the choice of Go for their projects since there is a download cost. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 python version? You said you are testing backwards compatibility, so why would that break in a package based approach? 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. The notable (and blessed) exception is flashplugin-installer, which is in multiverse for that reason. We do that for a good reason: There is an established trust level in Ubuntu packages. They have stability promise and defined procedures for post- release maintenance (security and bug fix updates with corresponding verification mechanisms), have a cryptographically secure trust path, they have a defined and well-working mirroring system around the world, there's well-known tools for local caching/mirroring, we can build installer images with them, and so on. All of this would break down if we don't actually ship a binary package for juju clients which gets installed into ubuntu guest images. (Of course the repeatedly discussed immaturity of golang wrt dynamic linking and language changes also play a big role here). If you want to go down that route, I think you should go the full way and not pretend that we have and support Ubuntu binaries at all, and just always download the juju bits from simplestreams. With that you can support the same version on all Ubuntu releases and other OSes, but of course you have to introduce your own QA mechanisms, trust path to the binararies you download, options for local mirroring, and so on. So that comes with a big price attached, but it seems that's the direction you want to go to? (Caveat: I have no idea what simplestreams is and how it works; the description on https://launchpad.net/simplestreams isn't very enlightening, but it sounds like you want to use it as a kind of package distribution system not unlike pip?) -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 into the filesystem on my VM. Why is (2) not apt-get install jujud in the VM? -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 this and I have no problem with developers leveraging these tools for their own projects since it is something that they actively opt in to. The problem comes when an installer package that comes from the archive wraps all this up for the user and pulls down code that is isn't verified or maintained by the distribution. If that installer package is in main, who is responsible for the authenticity of the downloaded software or for its maintenance? So, putting the installer package issue aside, juju-core is the first Go software to pursue main inclusion and those responsible for maintenance of the Ubuntu archive realize that we need to be careful with how we proceed to make sure that we set the proper precedents and go down a sustainable path that works for everyone. I'd like to give my perspective on Go in Ubuntu to try to avoid an impasse. Go is marketed as an open source programming language that makes it easy to build simple, reliable, and efficient software. People are excited about it and its clear that we want to support Go in Ubuntu. Interesting software is being written in Go, whether that is juju, scopes, click apps and more. The Go community wants to use golang-gc over golang-gccgo and I recognize that viewpoint. Conversations surrounding Go have been challenging because Go was not designed with traditional OS distribution methods in mind (it statically links its runtime[1], uses remote code imports and encourages embedding code copies), yet we are trying to leverage Go using traditional distibution methods (ie, including Go software in the Ubuntu archive with Canonical support). If we take a step back, I think we have a disconnect where the Go developers may not be fully considering the problems of the Go model with regard to Canonical support while at the same time the traditional OS developers (ie, the ones responsible for the archive and its support) may not fully appreciate the needs of the Go community. Go's model of statically compiling software works fine for developers and administrators who are responsible for supporting their software and I have no objections with providing the tools to make Go development great on Ubuntu. I believe the developer model works mostly ok with click packages because click is about empowering developers to deliver their software in a manner that is much less dependent on the OS. Go developers can develop using standard Go techniques then package as click and things are mostly fine. That said, I challenge the proponents of Go in Ubuntu to consider how we can have a better developer story for people developing on Ubuntu-- namely, if Ubuntu provides the Go runtime and compiler that developers then use to statically compile their apps, what can we do to alert developers that they (or someone) should recompile when we update our runtime for a security update. While we could probably get away with just saying that developers are solely responsible for tracking Ubuntu's security updates, I can't help but feel we are doing the Go developers on Ubuntu a disservice if we take this stance. Go's model of statically compiling software doesn't work well for packages we deliver using the Ubuntu archive for a number of reasons: 1. static linking means recompiling all applications that use the standard library when there is an update to it 2. Debian has developed a methodology[2] for delivering Go software in its archive and this is available in Ubuntu. Essentially you use modern dh techniques with dh_golang and Build-Depends on whatever golang-*-dev packages you need. The golang-*-dev packages are unpacked into /usr/share/gocode and GOPATH is set to /usr/share/gocode. The compile proceeds as normal, statically linking into a monolithic binary (that inclues the developer's compiled code, the Go runtime and whatever was needed from /usr/share/gocode). At the time of this writing, there are 36 'golang-*-dev' packages in the archive, 18 of which are specified as a Build-Depends in 9 unique source packages. 3. remote imports are possible with Go, but impossible on our buildds, which promotes the use of embedded code copies 4. embedded code copies are extremely problematic for tracking security vulnerabilities since it is impossible to programmatically ascertain all packages that embed a particular source or to know what version was embedded 5. assuming we were able to enumerate all the software that embedded a given Go library along with its version, embedding code copies means we have to patch everything that embedded the software where each may have to be individually patched for the different version Developers and administrators responsible for their own
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 golang dynamic linking upstream bug and fix it 2. fix gccgo for the juju use case and/or update gccgo to a new version if one exists 3. allow golang into main with very strong wording that it is only for juju and that 3rd party developers are on their own '1' is by far my preferred solution because it would end this once and for all. I don't like '3' and I think it will tarnish Ubuntu's reputation. If we go for '3', a condition of the MIR would be reviewing where we declare the lack of support (an idea I had would be outputting a string at the beginning or end of the compile). Other options may exist, but I know the foundations team looked into them and my understanding is that '1' and '2' are really the only choices. In light of my comment #27, I still consider '2' most correct and '1' is interesting but I don't think either is a requirement anymore so long as we define sane embedding policies (ie, don't allow it) and agree that we can provide updates in a manner resembling what I described in comment #27. I'll let Seth comment on the security review for juju-core. Others have commented on the installer package issue. Assuming those issues are addressed, I have this to say: * juju: conditional ACK provided we pull out the embedded copies and push them into golang-*-dev packages. If this is not feasible for 14.04, we may be able to defer this to 14.10 (after all, juju will be the only Go package in main so it doesn't really matter where the libraries are for one package) * golang: conditional ACK provided packaging policy, support procedures and MIR standards conversations are started (I don't expect these to be resolved by 14.04) -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
* 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 subscribed to them, so that team would be responsible for verifying the package in -proposed. This seems to be in the spirit of Go development-- teams choosing to use Go are responsible for recompiling and retesting and a team's choice of Go will have to consider this cost. 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 library with the security fix, you're pushing the update for that package plus all its reverse-dependencies, which is made all the worse by the fact that each of those revdeps is statically linked (==larger). We might be able to make this work for juju in the short term, but it doesn't scale particularly well. 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 rebuilds. If we were to implement this at all, we should leverage the Build-Using field as defined in Debian policy. Developers may of course choose to use gccgo, but my current thinking is that based on various conversations with Go developers, efforts to improve gccgo might be better spent making golang-go supportable and this necessarily means stretching our existing policies and processes. 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 linking. So I'm not sure this is actually the path of least resistance - unless you are suggesting that we compromise our standards for main over the long term by doing the reverse-build-dep rebuilds you described. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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. https://bugs.launchpad.net/bugs/1267393 Title: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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. https://bugs.launchpad.net/bugs/1267393 Title: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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. https://bugs.launchpad.net/bugs/1267393 Title: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 linking. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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: [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 rebuilds. As an obvious point yet perhaps worth raising, a bug in a library doesn't necessarily mean everything has to be rebuilt. [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 linking. That sounds like an overstatement. It is true that the Go community appreciates static linkage, and some members have public sayings about how dynamic linkage has its own issues, neither the Go community nor the Go core development team (most important in this case) is not hostile to dynamic linking. Here is evidence showing progress rather than hostility: https://code.google.com/p/go/issues/detail?id=256 http://code.google.com/p/go/source/detail?r=885321ad387328c16c6f69fb04b12ac69b69b691 http://code.google.com/p/go/source/detail?r=c9e8491bbfcee7a9c05934f8be0718bccbf29aec http://code.google.com/p/go/source/detail?r=98034d036d03213807879975629172945169c7c8 http://code.google.com/p/go/source/detail?r=1eadf11dd1b7b19d4857681363553c2cfd2ad47d -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
@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 the package belongs to. 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. 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? We certainly *can* do that. I have no objection to it in principle. But, before we go down the path of what's stopping us, Let's take a look at the situation now: The obvious and simple use case is that I'm using Amazon, or Azure, Joyent, or HP Cloud. In those cases the tools are pre-published to a cloud local bucket and it would slow things down and create pain for the user if binaries had to be copied over from the local disk into the cloud. To top it off, the jujud binary isn't used locally (except of course when you are deploying charms locally) so having it on local disk is just waste in those cases. Furthermore, we need tools to be published to all the major clouds *before* the matching client lands in Ubuntu, because a new clients can require matching tools to bootstrap a new environment. (We do however maintain and stringently test backwards compatibility with already bootstrapped environments). We *have to* publish tools in simplestreams. We *can* put them in the package too -- as a limited and broken fallback mechanism that doesn't support multiple archs, doesn't support multiple series, doesn't support multiple OS's. My question is, if I take folks away from current projects, and have them update the packaging so that the tools you mention are there, what exactly does that buy us? I'm happy to do it, but I would like to know why exactly you want it, and what benifit it provides to our users. Another idea we had was to build tools for all supported series, OS's and arch's and put them in a single package, with the bits you need to push things up in a simplestreams location for your closed network. But our belief was that such a package would never be supported, particularly since the binaries in question won't be run on the local machine anyway, and are likely to just be a waste of disk space. We've done a lot of thinking on this, and we have *tried* to figure out how to use ubuntu packages to distribute tools -- and fundamentally simplestreams is a better fit for the needs of a multi-os, multi-arch, multi-series orchestration tool. And we already force users to trust simplestreams to get Ubuntu images, so we're not adding *another* mechanism, just re-using one that already exists and is quite widely used. --Mark On Wed, Mar 26, 2014 at 5:54 PM, Adam Conrad adcon...@0c3.net wrote: @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 platforms available, without a source to grab those from, but it would keep it self-contained for the simple use-case. 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. -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/1267393 Title: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 would be good to get a clear statement from both the foundations and security team in the context of 14.04. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 *must* be a solvable problem. If the problem is that the package can't be BUILT in the archive, then this isn't remotely suitable for main. Otherwise, I don't see what the blocker is at all. Just package up those binaries, and done. What fundamental flaw in the process is being hidden by shipping binaries outside the archive? Does the build system pull random deps from the internet, does it pull prebuilt objects from the internet, sans source code (again, absolutely unacceptable for main). -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
@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. I'll let one of the juju-core team respond on why the binary is distributed this way. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
@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 binaries via ubuntu packages because they aren't installed on the a juju client user's machine. So we aren't pulling down binaries to extend what we package on the local machine -- we are pulling down binaries on the server side that the local juju client talks too. We MUST distribute them through another mechanism because they will need to be chosen at workload deployment time based on whatever architecture, series, juju client version, and OS combination that is being targeted when that server is deployed. The key here is multi-OS support, we need to be able to support other unix and non-unix OS's, and we want one, standard code path for everything. The local juju client package is not the right place for tools. This has nothing to do with hiding anything, and our prefered mechanism is to create the binaries in the archive -- where we don't we create them in PPA's now, and we will document a secure process for building them for non Ubuntu OS's as we start officially supporting those OS's next cycle. We use simplestreams because we already have code that uses simplestreams to select the right architecture, series, and version for cloud images -- so we are re-using that same functionality to allow us to fulfill our multi-platform mandate in a sane way. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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. https://bugs.launchpad.net/bugs/1267393 Title: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
@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 platforms available, without a source to grab those from, but it would keep it self-contained for the simple use-case. 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. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 same decision; we wanted a single toolchain to work across all target architectures and gccgo was the only option that could provide this; however after alot of work to a) get everything functional on gccgo and b) alot of testing including at scale, the performance of gccgo was just not at the same level as gc; The decision to prefer gc for architectures where it was supported was made based on this process. We have to use gccgo on ppc64el and arm64 right now as this is still the only option. I appreciate that the static linking feature of gc does not fit with the distribution model generally; I'd encourage people to read the MIR in detail - specifically the way that juju server binaries are distributed which is also different as I want all interested parties/stakeholders to understand the full facts of what we are proposing for main inclusion. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 changed language features, API breaks, and so on. So this doesn't appear to be a toolchain that we can support for 5 years in its current version? -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 foundations and security teams don't consider gc supportable from a distro standpoint due to the static linking issue. For the client, promoting golang would mean Ubuntu is not being responsible because we are making all these developers responsible for tracking *our* security and high impact bug fixes. On the client, I don't care if app developers embed some library that we don't provide-- that's on them to keep up to date, but I very much care if we ship a runtime as a standard part of Ubuntu/the SDK that developers are expected to use and we can't provide the fixes for them automatically. That said, this MIR is about golang in support of juju for server/cloud, but the issue still remains-- we need to make sure we have something supportable. If golang is promoted to main, it is clear to me the Go community would rejoice and use it immediately, but then 3rd party developers will have to track Ubuntu's security fixes and recompile their applications on their own. Sure, we could add a note to the USN that people need to recompile their applications if they use golang, but USNs are not widely read and this practice is far outside the norm for updating stable releases and people will miss the fixes. To paraphrase Steve Langasek from foundations, if there are blockers for the use of gccgo as the compiler, we should know what those are and we should be fixing those. Personally, my thinking is that if golang is truly the future and what the Go community and Canonical devs want, perhaps we should put resources behind fixing the upstream bug: http://code.google.com/p/go/issues/detail?id=256 (which incidentally, doesn't seem to have progressed in a long time). 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 golang dynamic linking upstream bug and fix it 2. fix gccgo for the juju use case and/or update gccgo to a new version if one exists 3. allow golang into main with very strong wording that it is only for juju and that 3rd party developers are on their own '1' is by far my preferred solution because it would end this once and for all. I don't like '3' and I think it will tarnish Ubuntu's reputation. If we go for '3', a condition of the MIR would be reviewing where we declare the lack of support (an idea I had would be outputting a string at the beginning or end of the compile). Other options may exist, but I know the foundations team looked into them and my understanding is that '1' and '2' are really the only choices. ** Bug watch added: Go Issue Tracker #256 http://code.google.com/p/go/issues/detail?id=256 -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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. security/bug fix updates, as pretty much every golang-go program had to be rebuilt. This also completely escapes symbol tracking, thus makes it hard to detect ABI changes, and thus leads to surprising FTBFS of packages once the underlying toolchain changed. -- 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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, 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
** 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, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
@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] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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 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 manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
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] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gccgo-go/+bug/1267393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1267393] Re: [MIR] juju-core, juju-mongodb, gccgo-go, gccgo-4.9, golang
** 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 + - + + golang is the primary focus of Go toolchain development; scale testing + of juju with gccgo and golang gc built binaries revealed that the gccgo + built binaries consume a significant amount of memory compared to golang + gc built versions. + + As juju is focussed on building scale out service deployments, choosing + the toolchain that produces the most scalable binaries on the + architectures that most users are going to be using would make sense. + + Security + + + QA + -- + + Dependencies + + + All build-deps are in main; some non-core packages depend on package in + universe (kate, vim addons) - recommend that these are left in universe. + + golang-go.tools can be demoted to a suggested to limit scope of main + inclusion. + + Standards compliance + + + OK + + Maintenance + --- + + gccgo-go Availability In universe, available on all required architectures (x86, armhf, arm64, ppc64el). Rationale - 'go' build tool built using gccgo, avoiding the need to promote two golang toolchains to Ubuntu main. Security Searching for golang CVE's turned up nothing (this package is a rename of the golang 1.2 source package). Quality assurance - Package installs cleanly, go tool installed using alternatives at higher priority that golang-go version in universe. Dependencies gccgo is in universe, all other dependencies in main. Standards compliance OK Maintenance --- Some bugs expected upfront but should stabilize before release. Probably picked up by ubuntu-server if foundations team don't want to. Background information -- This package is a re-cut of the golang upstream codebase with selected cherry-picks from upstream VCS for gccgo support, along with a patch to support building using gccgo + Make. The only code actually used is in src/cmd/go. juju-mongodb Availability In universe, available on all required architectures (x86, armhf, arm64, ppc64el). Rationale - MongoDB is a dependency for operating a Juju deployed Ubuntu environment. Security MongoDB has had some CVE's in the past, related to the use of the V8 and Spidermonkey Javascript engine in the Mongo Shell; however juju-mongodb builds without support for Javascript scripting, avoiding the historic CVE's (which where fixed upstream anyway). Quality assurance - Package installs cleanly, package build process runs upstream smoke tests (minus jstests due to disabling javascript support). Tests pass on all architectures. Dependencies All in main already Standards compliance OK (well is scons but we won't hold that against it) Maintenance --- Upstream MongoDB run stable releases with point updates; its intended that a MRE is applied for this package so point releases can be pushed as SRU's. Its also possible that we might need to bump a major version (2.4.x - 2.6.x); as this package is specific to Juju, we can constrain the impact and regression testing to Juju only. Background information -- Why a separate package? it was agreed at the last vUDS that having a separate package allows us to limit a) use of v8 (disabled) which was a security concern and b) allows us to potentially update at a later date if need be only impacting juju itself. juju-core Availability In universe. Rationale - Juju is the recommended service orchestration tool for Ubuntu; as such it really needs to be a core part of Ubuntu. Security No security history, but it was agreed that a security review would be undertaken as part of the MIR process. Quality assurance - No tests are run as part of the package build process; however upstream do run these tests for all target series (12.04 - 14.04) prior to release so the overall quality of the codebase it pretty good. The package has some basic DEP-8 tests that bootstrap a local Juju environment to ensure everything hangs together OK. Dependencies juju-mongodb (see above) gccgo + gccgo-go Currently all required go dependencies are snapshotted at specific upstream commits and bundled with Juju. Standards compliance OK Maintenance ---
