Re: Re: Request for Adding Ubuntu Kylin Archive
Hi Jack, On Fri, Apr 04, 2014 at 12:33:05AM +0800, jac...@ubuntukylin.com wrote: The software here are all free. Commercial companies mean software companies such as Kingsoft and Sogou, who is providing the most popular Office suite, cloud file storage and Chinese input method in China. Ubuntu Kylin team has co-developed with them for their Linux clients. When you say they're free, you mean they're available free of charge, rather than that they're Free Software (Open Source), correct? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org At 2014-04-03 23:38:54,Soren Hansen so...@linux2go.dk wrote: It's not really clear to me whether the software intended for this archive is free or not? What exactly does commercial mean in this context? /Soren On Apr 1, 2014 7:38 PM, jac...@ubuntukylin.com wrote: Hi Technical Board, I'm writing to request to add an archive for Ubuntu Kylin flavor. This archive mainly includes Chinese commercial packages co-developed by Ubuntu Kylin team and commercial companies. We also developed a software center client that supports both Ubuntu archive and Ubuntu Kylin archive. This request have already been supported by Jason, Leonard, Anthony, etc. from Canonical team. We know that in the rules of Ubuntu, flavors are not allowed to add archives. However, Ubuntu Kylin is a little special since it mainly focuses on Chinese users. Our partners (Such as Sogou, King soft) want to locate their apps in China. Do you have any comments on this? Thanks in advance. -- Regards, Jack Yu UbuntuKylin Team -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: [MRE] Iscsitarget 1.4.20.3+svn490 into Precise
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Mark (and the TB) On 23/12/13 16:07, Mark Shuttleworth wrote: If this is a single-use MRE, and it's saucy-to-precise so that we can use a saucy kernel in precise, and it's been reviewed for new-code-ness, then it's already cross a fairly high bar. Is it reasonable to suggest a longer-than-usual gestation in -proposed? In the interests of not having to ask todo this again once the trusty 3.13 kernel is available in 12.04, I'd like to propose that we backport the version of iscsitarget in trusty to 12.04; this includes a three extra commits from upstream: [r499] Compatibility with 3.13 kernel (LP: #1291641). [r498] Fix backward compatibility patch rules for 3.x kernels. [r497] Fix SERVICE ACTION IN / READ CAPACITY (16) - regression from r488. And a single fix in the packaging to make the init script retry unloading of the kernel module a few times if it fails at first. Stefan's original analysis still stands. I've uploaded this backport to PPA and its been tested on 12.04 (see [0]). This will put us in a much better position once 3.13 lands in 12.04 as iscsitarget will support all kernel versions on 12.04. Regards James [0] https://bugs.launchpad.net/ubuntu/precise/+source/iscsitarget/+bug/1262712#19 - -- 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/ iQIcBAEBCAAGBQJTPpgTAAoJEL/srsug59jDF94P/3mdFbhaITS3RYiC6gErr+wP VwE/OCi1PsO7AuZHjP/XeFy4P2ZLMpGAkMcvkWpDsDW4WOVZ4YT0dfByDDEahipx 15avKKjKVKjWq3cTOjwyzcK7DSfm6IrDpBuY7SMngeLITxffaxAtJNNwGeueB7e8 DphQYze8tqtOq+484nen8pLe6aHgYV8DXw0C7TnXPlKuXlxm9JGBXY27+ZqPl3ye DySdej5kEz6pFXSM1/0p50otg6c8rTE8Gc9vmwjMAgPYNJz5T5eEfZeyqEliOLz3 Yam+Qo2uli5x2pd82B/TG1dJeinef1S3G1DY5PQx65Y+EjBRBANhy5rq5RJMBi1c /kjqHrA0pLHXgX2YpmeAEuTHdoNu5oyFIu93y45cZizBSQS8d9hDR3U1hp8OCH2H C+jlgi8i97+DsbutNLwzv+1sJrmYXUKAIuRxEOYznqyPRazNZ+vXPaDzwBXllbmn Ff30vy/rRK2NtTMEcdetnC6UXnRwKm+lqA8pno5usea44xCXuPHZI0oj/XnEKNoc nTO24DcEJXhAEnim3nIQw/ev3BRDGhHohR7xX9SR9ASXYyzloKF8I10kR0rhGd6U Kj9mqikGjs7MwK8Tf5oXklj+fT3SsbOiUdhDXjhpi1Z1KvU/lWCS5mNKOW1HZXGm 5nukkMQT+DsX15cksgZF =X9sG -END PGP SIGNATURE- -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re:Re: Request for Adding Ubuntu Kylin Archive
Hi Steve, Thanks a lot for all your help to make Ubuntu Kylin better and better. See bellow please. -- Regards, Jack Yu UbuntuKylin Team At 2014-04-04 09:39:36,Steve Langasek steve.langa...@ubuntu.com wrote: Hi Jack, On Tue, Apr 01, 2014 at 11:42:34PM +0800, jac...@ubuntukylin.com wrote: Hi Technical Board, I'm writing to request to add an archive for Ubuntu Kylin flavor. This archive mainly includes Chinese commercial packages co-developed by Ubuntu Kylin team and commercial companies. We also developed a software center client that supports both Ubuntu archive and Ubuntu Kylin archive. This request have already been supported by Jason, Leonard, Anthony, etc. from Canonical team. We know that in the rules of Ubuntu, flavors are not allowed to add archives. However, Ubuntu Kylin is a little special since it mainly focuses on Chinese users. Our partners (Such as Sogou, King soft) want to locate their apps in China. Do you have any comments on this? Thanks in advance. Thank you for raising this issue before the Technical Board. I understand that you've already gone through the process of discussing this with Canonical's business team, so having to discuss it all again with the TB is probably very frustrating. However, the TB has a mandate to provide independent oversight for the technical decisions made around Ubuntu and its flavors, to ensure transparency and accountability to Ubuntu's founding principles. So I ask that you bear with us as we get up to speed on Ubuntu Kylin's needs. Sorry that we have some misunderstanding on the process. As a Ubuntu flavor, we are very appreciating the Ubuntu rules. We are happy to apply your permission, which will also make our solution stronger:). We of course don't want to block any legitimate activities by any of the Ubuntu flavors - our purpose is to facilitate the Ubuntu community in doing great things, not to be a roadblock to progress! - but our default position will be one of natural conservatism: our goal is to make Ubuntu sustainable and coherent over the long term, so when something like a new archive is proposed, we will want to understand why it doesn't fit among the (already quite complex) set of existing archives. For the reference of everyone here, there is an existing, Tech Board-approved policy regarding the addition of extension repositories: https://wiki.ubuntu.com/ExtensionRepositoryPolicy I think the conversation here should be focused around how the proposed new archive does or doesn't fit this policy, and if there are ways in which the existing policy falls short. For instance, point 1.8 of this policy talks specifically about Canonical. It's worth understanding the reasons why this is, and how these reasons apply to the question of an archive with a separate root of trust (i.e., NUDT). As the original seed of the Ubuntu community, Canonical is in a unique position of absolute trust within that community. Canonical manages the infrastructure on which the Ubuntu archive runs, sets the security policies governing access to the signing keys in use, and protects the integrity of the overall system. The Ubuntu community, in turn, implicitly trusts Canonical to carry out this function; this is not just because several members of the TB are employed by Canonical, but because there must be *some* root of trust, which for Ubuntu is Canonical. However, it seems that the proposal being discussed here is to add a second root of trust for the Ubuntu community. One root of trust is necessary; two roots of trust, however trustworthy, are a weakness, and one we should try to avoid. My understanding is that - answering Martin's question - the software you're proposing to put in this archive is commercial software that Canonical does not have the rights to distribute. Only NUDT, Ubuntu Kylin's commercial backer in China, has these distribution rights. It makes sense that Chinese software companies may prefer to do business with other companies in China, rather than foreign companies like Canonical; and just as we have archive.canonical.com (the Canonical partner archive) to make sure that free redistribution from our mirrors is not an obstacle to our users having access to a piece of software, if there is software that's interesting to our users which *Canonical* cannot distribute, but one of our partners in the Ubuntu community can, we should consider how we can enable this software to be made available within the Ubuntu framework instead of outside of it. Some questions that I think will help clarify: - It's understood that the package archive server will be located in China and that only NUDT will have the rights to distribute the packages. But, is there a license reason that we could not do the package *builds* on the existing Launchpad infrastructure, in a private ppa or other private archive? This would make it possible to do the package builds using the existing trusted infrastructure,
MRE for juju-core/juju-mongodb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Technical Board Despite the fact that juju-core will not be able to enter main this cycle (see [0] for context), the Canonical Server Team still need to be able to maintain it in its universe home for the duration of 14.04. Since 1.16 upstream juju-core have maintained a stable branch with critical changes and bug fixes only; we’ve been pushing these point releases into Saucy with full testing of each fixed bug which has worked out OK so-far (note that 1.16.6 is still pending acceptance into -proposed for saucy as I've not had time to document test cases in full just yet). We’d like to apply for a MRE for juju-core and juju-mongodb to support this maintenance approach. We’d also like to ask for permission to introduce new stable releases of juju-core into 14.04 using versioned packages at a later date. 1) juju-core MRE Upstream maintain stable branches with critical bug fixes; All juju-core releases must pass the full set of CI tests upstream prior to release; this includes testing on most supported providers (ec2, openstack, azure, local, HP, manual, restrictive and closed network) for all supported Ubuntu releases up to and including 14.04. Stable to stable release upgrades of juju-core itself are also tested as part of this process. The tarball used in the tests is the tarball used in the release. One gap exists in juju-core upstream testing - MAAS provider testing. The Canonical Server Team will undertake testing of this as part of the SRU process in the short term. The juju-core CI team are working to plug this gap in upstream testing. 2) juju-mongodb MRE This package is a cut down version of mongodb which just provides binaries for juju-core to use; Currently its based on the 2.4.x series of MongoDB. MongoDB upstream maintain even point releases as stable releases which only receive bug fixes as part of minor point releases (see [1] for an example). That said, stable releases are only maintained for 18-24 months (obviously counter to the 5 year support period for 14.04). For this reason, we’d also like permission to introduce new stable versions of MongoDB via this package in the future. This process would be done in-conjunction with juju-core upstream to ensure compatibility and facilitate testing and would probably be done under an exceptional SRU with extended testing after the release of the new upstream version on MongoDB in juju-mongodb as part of an interim Ubuntu release. The package build runs the upstream unit test suite minus the script engine tests - the package builds with scripting disabled to avoid use of libv8 - this was requested by the Security Team during the start of the work to support the MIR for juju-core. 3) New juju-core packages In addition to maintaining the stable release version of juju-core in 14.04, we’d also like to include new stable releases using versioned packages. These would be aligned to each upstream stable release of juju-core. This will allow 14.04 users easier access to new stable releases than trying to figure out which PPA they should be using to get the latest stable release (and features): sudo apt-get install juju-core-4 This approach is similar to that taken for HWE kernels and Xorg during the 12.04 lifecycle. In terms of backwards compatibility, we would not introduce a stable release which was not backwards compatible from the client to the release version of juju-core in 14.04 (1.18) on running servers. Regards James [0] https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1267393 [1] http://docs.mongodb.org/manual/release-notes/2.4/ - -- 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/ iQIcBAEBCAAGBQJTPrJDAAoJEL/srsug59jD3psQAKPUVaHKrpbpnt1QHHat3pee Y53eKdRinpXXHfVZRJEddkhIG4KMXZULGkiq2oYnN0rYomBpJRGZsTvxMxsIV0A8 fYooJItbtocQBhX/Y+w1lWzJbJFpiULpzZ1w35YG6CX4wz43woyQEmINaJ6145xE Nzaxz/v/ANm3ZXJ7uHohF/a+UViwWgCRaHsR9IWAQsxiFGxgRaTJIoPEeMSJbOMB qlz2mEHw1QYtkR4V4sSgYo6rRMapd9uwfEPRqXg5D6DvFVbPBkOVIS5e9UfN9MJe 4OoDZ3k33uM0O7giZz8EVhG1pmPuIdmYlsg90rPpOjeATG1utNSEGlk/zStPralQ h1GMvfNctt8UF2LExlN+uORbBuXhscScxLEC0kJjpiXK/DhXF06l4oZbP2Klv7tJ deNWrTfBy3nnCWVkpvuLW/75OCuqt07vkWgvlLtCUCocqDZC/xgCOrOt+BgGWGHV rt+RWEsRt9gvObMbVM7c4SVIC5xvWd+oC86NZnaq3rkSdg+6eiE+AHqAF4TXu9KA KT33c00q8CzwP5GjhcehPd2lmHk0h1TZ17/F3tXWsFjlcdUWhdk8XImLiheMNfYC k3SOn1hIJjMi1yNbh1F0YyEvoWHGZVknmUK4Hx4ao0W5FsngmqZbqV9bDcbMo+k6 6VV76vUI/ir+ca6zmpPY =EIAI -END PGP SIGNATURE- -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request for Adding Ubuntu Kylin Archive
On 14-04-04 09:08 AM, jac...@ubuntukylin.com wrote: Hi Steve, Thanks a lot for all your help to make Ubuntu Kylin better and better. See bellow please. -- Regards, Jack Yu UbuntuKylin Team At 2014-04-04 09:39:36,Steve Langasek steve.langa...@ubuntu.com mailto:steve.langa...@ubuntu.com wrote: Hi Jack, On Tue, Apr 01, 2014 at 11:42:34PM +0800, jac...@ubuntukylin.com mailto:jac...@ubuntukylin.com wrote: Hi Technical Board, I'm writing to request to add an archive for Ubuntu Kylin flavor. This archive mainly includes Chinese commercial packages co-developed by Ubuntu Kylin team and commercial companies. We also developed a software center client that supports both Ubuntu archive and Ubuntu Kylin archive. This request have already been supported by Jason, Leonard, Anthony, etc. from Canonical team. We know that in the rules of Ubuntu, flavors are not allowed to add archives. However, Ubuntu Kylin is a little special since it mainly focuses on Chinese users. Our partners (Such as Sogou, King soft) want to locate their apps in China. Do you have any comments on this? Thanks in advance. Thank you for raising this issue before the Technical Board. I understand that you've already gone through the process of discussing this with Canonical's business team, so having to discuss it all again with the TB is probably very frustrating. However, the TB has a mandate to provide independent oversight for the technical decisions made around Ubuntu and its flavors, to ensure transparency and accountability to Ubuntu's founding principles. So I ask that you bear with us as we get up to speed on Ubuntu Kylin's needs. Sorry that we have some misunderstanding on the process. As a Ubuntu flavor, we are very appreciating the Ubuntu rules. We are happy to apply your permission, which will also make our solution stronger:). We of course don't want to block any legitimate activities by any of the Ubuntu flavors - our purpose is to facilitate the Ubuntu community in doing great things, not to be a roadblock to progress! - but our default position will be one of natural conservatism: our goal is to make Ubuntu sustainable and coherent over the long term, so when something like a new archive is proposed, we will want to understand why it doesn't fit among the (already quite complex) set of existing archives. For the reference of everyone here, there is an existing, Tech Board-approved policy regarding the addition of extension repositories: https://wiki.ubuntu.com/ExtensionRepositoryPolicy I think the conversation here should be focused around how the proposed new archive does or doesn't fit this policy, and if there are ways in which the existing policy falls short. For instance, point 1.8 of this policy talks specifically about Canonical. It's worth understanding the reasons why this is, and how these reasons apply to the question of an archive with a separate root of trust (i.e., NUDT). As the original seed of the Ubuntu community, Canonical is in a unique position of absolute trust within that community. Canonical manages the infrastructure on which the Ubuntu archive runs, sets the security policies governing access to the signing keys in use, and protects the integrity of the overall system. The Ubuntu community, in turn, implicitly trusts Canonical to carry out this function; this is not just because several members of the TB are employed by Canonical, but because there must be *some* root of trust, which for Ubuntu is Canonical. However, it seems that the proposal being discussed here is to add a second root of trust for the Ubuntu community. One root of trust is necessary; two roots of trust, however trustworthy, are a weakness, and one we should try to avoid. I fully agree with this. If we were to ultimately allow a Kylin-specific archive, having it be located under the same root of trust should be a requirement. My understanding is that - answering Martin's question - the software you're proposing to put in this archive is commercial software that Canonical does not have the rights to distribute. Only NUDT, Ubuntu Kylin's commercial backer in China, has these distribution rights. It makes sense that Chinese software companies may prefer to do business with other companies in China, rather than foreign companies like Canonical; and just as we have archive.canonical.com (the Canonical partner archive) to make sure that free redistribution from our mirrors is not an obstacle to our users having access to a piece of software, if there is software that's interesting to our users which *Canonical* cannot distribute, but one of our partners in the Ubuntu community can, we should consider how we can enable this software to be made available within the Ubuntu framework instead of outside of it. Some questions that I think will help clarify: - It's understood that the package archive server will be located in China and that only NUDT will have the rights to
Re: Request for Adding Ubuntu Kylin Archive
On 14-04-01 11:42 AM, jac...@ubuntukylin.com wrote: I'm writing to request to add an archive for Ubuntu Kylin flavor. This archive mainly includes Chinese commercial packages co-developed by Ubuntu Kylin team and commercial companies. We also developed a software center client that supports both Ubuntu archive and Ubuntu Kylin archive. Are you requesting that the software archive be enabled by default, or simply available to be enabled by an end-user using the software center? Marc. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MRE for juju-core/juju-mongodb
Hi James, On 14-04-04 09:23 AM, James Page wrote: snip 3) New juju-core packages In addition to maintaining the stable release version of juju-core in 14.04, we’d also like to include new stable releases using versioned packages. These would be aligned to each upstream stable release of juju-core. This will allow 14.04 users easier access to new stable releases than trying to figure out which PPA they should be using to get the latest stable release (and features): sudo apt-get install juju-core-4 This approach is similar to that taken for HWE kernels and Xorg during the 12.04 lifecycle. In terms of backwards compatibility, we would not introduce a stable release which was not backwards compatible from the client to the release version of juju-core in 14.04 (1.18) on running servers. Will all these new stable releases use the version of gccgo and/or golang gc that came with 12.04, or will they possibly require updates to newer versions also? Marc. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request for Adding Ubuntu Kylin Archive
Hi Marc, On Fri, Apr 04, 2014 at 02:14:05PM -0400, Marc Deslauriers wrote: On 14-04-01 11:42 AM, jac...@ubuntukylin.com wrote: I'm writing to request to add an archive for Ubuntu Kylin flavor. This archive mainly includes Chinese commercial packages co-developed by Ubuntu Kylin team and commercial companies. We also developed a software center client that supports both Ubuntu archive and Ubuntu Kylin archive. Are you requesting that the software archive be enabled by default, or simply available to be enabled by an end-user using the software center? So that I understand, do you think the answer to this impacts whether the TB should grant its approval here? For comparison, I believe that Canonical's commercial software repository is enabled by default in Software Center on the Ubuntu desktop (via server-side indices in the app store, rather than via an apt repository). The partner repository has never been enabled by default either in apt or in software-center, which frankly I think is a bug given that I routinely get private pings from people asking why they can't find skype packages despite them being in partner. We also have community flavors (Mythbuntu) that not only enable, but actually build from, multiverse. So I think there is ample precedent for this software source being enabled by default on Ubuntu Kylin, if that's what the Kylin team believes is the right thing to do. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request for Adding Ubuntu Kylin Archive
Hi Steve, On 14-04-04 03:56 PM, Steve Langasek wrote: On Fri, Apr 04, 2014 at 02:14:05PM -0400, Marc Deslauriers wrote: On 14-04-01 11:42 AM, jac...@ubuntukylin.com wrote: I'm writing to request to add an archive for Ubuntu Kylin flavor. This archive mainly includes Chinese commercial packages co-developed by Ubuntu Kylin team and commercial companies. We also developed a software center client that supports both Ubuntu archive and Ubuntu Kylin archive. Are you requesting that the software archive be enabled by default, or simply available to be enabled by an end-user using the software center? So that I understand, do you think the answer to this impacts whether the TB should grant its approval here? For comparison, I believe that Canonical's commercial software repository is enabled by default in Software Center on the Ubuntu desktop (via server-side indices in the app store, rather than via an apt repository). The partner repository has never been enabled by default either in apt or in software-center, which frankly I think is a bug given that I routinely get private pings from people asking why they can't find skype packages despite them being in partner. Yes, I did believe it could influence the decision, as I thought that both the partner and the commercial archives were disabled by default and opt-in for end-users. I have now checked and the commercial archive is in fact enabled by default. We also have community flavors (Mythbuntu) that not only enable, but actually build from, multiverse. Yes, but multiverse is enabled by default for everyone. So I think there is ample precedent for this software source being enabled by default on Ubuntu Kylin, if that's what the Kylin team believes is the right thing to do. Since the commercial archive is in fact enabled by default, I agree there is precedent, and my question is moot. Thanks, Marc. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request for Adding Ubuntu Kylin Archive
On Fri, Apr 04, 2014 at 04:18:06PM -0400, Marc Deslauriers wrote: On 14-04-04 03:56 PM, Steve Langasek wrote: On Fri, Apr 04, 2014 at 02:14:05PM -0400, Marc Deslauriers wrote: On 14-04-01 11:42 AM, jac...@ubuntukylin.com wrote: I'm writing to request to add an archive for Ubuntu Kylin flavor. This archive mainly includes Chinese commercial packages co-developed by Ubuntu Kylin team and commercial companies. We also developed a software center client that supports both Ubuntu archive and Ubuntu Kylin archive. Are you requesting that the software archive be enabled by default, or simply available to be enabled by an end-user using the software center? So that I understand, do you think the answer to this impacts whether the TB should grant its approval here? For comparison, I believe that Canonical's commercial software repository is enabled by default in Software Center on the Ubuntu desktop (via server-side indices in the app store, rather than via an apt repository). The partner repository has never been enabled by default either in apt or in software-center, which frankly I think is a bug given that I routinely get private pings from people asking why they can't find skype packages despite them being in partner. Yes, I did believe it could influence the decision, as I thought that both the partner and the commercial archives were disabled by default and opt-in for end-users. I have now checked and the commercial archive is in fact enabled by default. We also have community flavors (Mythbuntu) that not only enable, but actually build from, multiverse. Yes, but multiverse is enabled by default for everyone. So I think there is ample precedent for this software source being enabled by default on Ubuntu Kylin, if that's what the Kylin team believes is the right thing to do. Since the commercial archive is in fact enabled by default, I agree there is precedent, and my question is moot. FWIW, I'm fine with this configuration: - signed by Canonical (no 2nd root of trust) - on by default only in Ubuntu Kylin - hosted on non-Canonical servers -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request for Adding Ubuntu Kylin Archive
On Fri, Apr 04, 2014 at 02:26:54PM -0700, Steve Langasek wrote: On Fri, Apr 04, 2014 at 02:09:07PM -0400, Marc Deslauriers wrote: However, it seems that the proposal being discussed here is to add a second root of trust for the Ubuntu community. One root of trust is necessary; two roots of trust, however trustworthy, are a weakness, and one we should try to avoid. I fully agree with this. If we were to ultimately allow a Kylin-specific archive, having it be located under the same root of trust should be a requirement. Does your phrasing here (if we were to ultimately allow) imply that you see other blockers for approving such a thing? Or are we at the point that we should try to write up our understanding of the plan and vote on it? - It's understood that the package archive server will be located in China and that only NUDT will have the rights to distribute the packages. But, is there a license reason that we could not do the package *builds* on the existing Launchpad infrastructure, in a private ppa or other private archive? This would make it possible to do the package builds using the existing trusted infrastructure, and to do all package signing using the existing archive keys, while publishing the packages for distribution only under control of the Ubuntu Kylin team. Would this satisfy the requirements from the Kylin side? Yes, you have an accurate understanding of our situations, and I think we could build and sign these packages on LP. Actually, we have been building the Sogou input method on LP during our co-developed with Sogou Corp. We will build Kuaipan Storage Client and Kingsoft Office on LP soon. I think building the software in a private PPA, and then mirroring the signed PPA onto NUDT's infrastructure would be a reasonable way of achieving all the requirements. Would that be an acceptable solution? It sounds like it meets Ubuntu Kylin's needs, but I would be wary of us trying to dictate the technical details at this level. We might find that this is the best technical implementation, or we might find that something closer to partner, where packages are uploaded to a central archive queue and managed using the Ubuntu archive tooling, makes more sense. I think we can at least set the following high level requirements: - Uploaders must be Ubuntu members and have signed the CoC (I'd have been tempted to require ~ubuntu-dev but that'd mean pretty much nobody on the Kylin team would be able to upload...) - Packages must be built on the same infrastructure as Ubuntu, using the same builder pool and build chroots. - The result must be signed by a GPG key managed by Canonical (not provided to the Kylin team) within the Canonical infrastructure. - That GPG key must be separate from any other key currently in use and should be (not a hard requirement for 14.04) signed by the archive master key. - Distribution will be done through a server managed by the Kylin team which will get its content from a private server on Canonical's network. That should leave enough room for implementation details to be decided by the relevant teams (Launchpad, IS, Kylin) while enforcing the bits I actually care about. Thoughts? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
