Re: Call for nominations for the Technical Board
On Wed, May 23, 2018 at 11:19:18AM -0700, Walter Lapchynski wrote: > Please send nominations (of yourself or someone else) to > Mark Shuttleworth and CC: the nominee. > You can optionally CC: the [Technical Board mailing list][3], but as > this is public, you *must* get the agreement of the nominated person > before you CC: the list. Hi! I would be happy to stand again for the Ubuntu Technical Board. Thanks! -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU policy: Allow new features in LTSes under certain conditions - v2
On Wed, Sep 16, 2015 at 06:59:36AM +0200, Martin Pitt wrote: > Hello again, > > Martin Pitt [2015-09-01 17:45 +0200]: > > occasionaly we get a request to introduce a new package into LTSes. > > This is usually unproblematic as there is a miniscule chance to break > > existing installations (unless the Package uses > > Conflicts:/Replaces:/Provides:), which should obviously not be > > allowed). In July however we got a more intrusive request for > > introducing Ubuntu FAN into trusty [1]. This was granted a special > > exception by the TB, but it would be good to generalize the principles > > upon we agreed to this. > > > > I therefore propose the following amendment to the policy, relative to > > the changes proposed in [2]. > > This updated proposal incorporates the suggested changes from Stéphane > and Steve. > > Martin > > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > --- StableReleaseUpdates.specialcases 2015-09-16 06:44:07.135737058 +0200 > +++ StableReleaseUpdates.newfeatures 2015-09-16 06:51:45.290663836 +0200 > @@ -49,6 +49,7 @@ > > * Bugs which do not fit under above categories, but (1) have an obviously > safe patch and (2) affect an application rather than critical infrastructure > packages (like X.org or the kernel). > * For Long Term Support releases we regularly want to enable new hardware. > Such changes are appropriate provided that we can ensure not to affect > upgrades on existing hardware. For example, modaliases of newly introduced > drivers must not overlap with previously shipped drivers. This also includes > updating hardware description data such as udev's keymaps, media-player-info, > mobile broadband vendors, or PCI vendor/product list updates. > + * For Long Term Support releases we sometimes want to introduce new > features. They must not change the behaviour on existing installations (e. g. > entirely new packages are usually fine). If existing software needs to be > modified to make use of the new feature, it must be demonstrated that these > changes are unintrusive, have a minimal regression potential, and have been > tested properly. To avoid regressions on upgrade, any such feature must then > also be added to any newer supported Ubuntu release. Once a new > feature/package has been introduced, subsequent changes to it are subject to > the usual requirements of SRUs to avoid regressions. > * New versions of commercial software in the Canonical partner archive. > * '''FTBFS'''(Fails To Build From Source) can also be considered. Please > note that in '''main''' the release process ensures that there are no > binaries which are not built from a current source. Usually those bugs should > only be SRUed in conjunction with another bug fix. > +1 from me. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: how to contribute code?
Hi, I recommend reading this for sending Linux kernel patches upstream: https://www.kernel.org/doc/Documentation/SubmittingPatches Pay close attention to the checkpatch.pl and get_maintainer.pl scripts. Feel free to include me on CC when you do, and I can help make sure you've sent it to the right people. I hope that helps, -Kees On Tue, Jun 30, 2015 at 02:24:33PM -, chenhaiq wrote: I have a fix in iptable_rawpost.c and ip6table_rawpost.c in order to support recent kernels. Can I contribute the code to up stream? -- This message was sent from Launchpad by chenhaiq (https://launchpad.net/~chenhaiq) using the Contact this team's admins link on the Ubuntu branches team page (https://launchpad.net/~ubuntu-branches). For more information see https://help.launchpad.net/YourAccount/ContactingPeople -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposal to help CC with potential conflicts of interest
Hi Mark, On Tue, Jun 09, 2015 at 01:40:56PM +0100, Mark Shuttleworth wrote: A suggestion to address this is that the TB, as a very well-respected team that is elected with support of a broad segment of the project (though not as broad as the CC), would be a useful source from which to draw independent perspectives in such a corner case. I think it makes perfect sense to have a back-up back-up tie-break. :) I think what the TB brings to this is lack of overlap with CC, really. So, in its current configuration, I think this is a fine idea. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Question: maximum RAM memory supported by Ubuntu 14.04 64bit
Hi, Operating systems that have RAM limits are trying to force you to pay more money. Windows 7's RAM limits are artificially imposed, and serves as a salient example of why freedomless software should be avoided. RAM limits under Linux are the same as the physical hardware limitations. These usually stem from the motherboard and chipset, not the operating system. Please check the documentation on the system you're going to purchase. An unhelpful answer to your question would be 256 terabytes, but you won't find hardware that actually supports that. See Larger virtual address space in http://en.wikipedia.org/wiki/X86-64 -Kees On Sun, Dec 07, 2014 at 07:08:03PM +, Shio Gai Quek wrote: Dear All: My name is S. G. Quek from Malaysia.I am a PhD candidate doing research in Pure Mathematics.Right now I am using a workstation with 32 Gb of RAM.I am looking forward to own a compute-server with RAM surpassing 192 Gb. As we all know, 192 Gb is the maximum RAM memory supported by Windows 7 ultimate 64bit. So I would like to confirm the following questions: 1. What is the maximum RAM memory supported by Ubuntu 14.04 Desktop 64bit ? 2. What is the maximum RAM memory supported by Ubuntu 14.04 Server 64bit ? If any of these two supports more than 256Gb, it will be the OS of my coming compute-server. Hope to hear from you soon. My Utmost Regards. S. G. Quek -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Policy For Sunsetting GPG Keys 2048 Bits
On Wed, Nov 26, 2014 at 06:09:41PM -0500, Scott Kitterman wrote: As many of you know, Debian is in the process of terminating use of 1024 bit keys due to near term security concerns [1]. In Ubuntu, we should probably do this too, but since any developer can replace an existing key via the Launchpad U/I and there's no requirement to get keys signed through web of trust, we ought to be able to do it much faster. Some data [2] Ubuntu has a total of 207 uploaders. Ubuntu has a total of 314 GPG keys with upload privileges tied to them. Here are rough status on the number of primary and sub-keys and their sizes: 119 pub dsa1024 2 pub dsa3072 1 pub dsa768 2 pub rsa1024 1 pub rsa10240 1 pub rsa2047 56 pub rsa2048 1 pub rsa3072 120 pub rsa4096 1 pub rsa8192 1 sub dsa3072 27 sub elg1024 2 sub elg1536 71 sub elg2048 16 sub elg4096 1 sub elg768 9 sub rsa1024 1 sub rsa10240 66 sub rsa2048 8 sub rsa3072 1 sub rsa4064 112 sub rsa4096 While this does affect a significant number of keys, it's easy for people to upgrade, so this transition doesn't have to take a long time. On IRC (#ubuntu-release) we discussed the idea of, once a policy is decided on, having a U-D-A announcement, followed by individual nag mails, and warnings after uploads with keys that are about to be disabled. There was some discussion about if PPAs should have the same restriction or now. Discuss... I think we should have the same policy for PPAs, and it should follow the same timeline. Additionally, we should have LP reject uploading weak keys, which could happens early in the transition timeline. (Seems like we should ditch DSA keys entirely, and all RSA less than 2048.) -Kees Scott K [1] https://lists.debian.org/debian-devel-announce/2014/11/msg4.html [2] Thanks to stgraber, xnox, and wgrant -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
Hi, Sorry, I won't be able to attend the TB meeting this week. See everyone in 2 weeks! -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Ubuntu MATE Remix is seeking official flavor status
On Tue, Jul 22, 2014 at 05:21:37PM +0100, Martin Wimpress wrote: Hi all, My name is Martin Wimpress and I am the project lead for Ubuntu MATE Remix and also a MATE desktop developer. Ubuntu MATE Remix is a community developed Ubuntu based operating system that beautifully integrates the MATE desktop. You can find out more on the official project website. * http://ubuntu-mate.org All development is conducted on Launchpad. * https://launchpad.net/ubuntu-mate * https://launchpad.net/~ubuntu-mate-dev The Ubuntu MATE Remix project is supported by the core MATE developers, the Debian MATE packaging team (which I also contribute to) and Alan Pope has provided some useful advice during these early days. We released, a very, Alpha 1 and are on schedule to hit the Ubuntu Utopic Alpha 2 schedule with a much improved release. However, I am facing some challenges building the .iso images so they are consistent with the official Ubuntu flavors. After chatting with Colin Watson in #ubuntu-devel he suggested we start the process of seeking official status so that we can merge our changes and ultimately build releases on the official infrastructure. So, long email short, what are the next steps for our project to gain official recognition? I've been happy with MATE's progress, so I'd support this. As a side note, what would it take for MATE to be available from a PPA for trusty? Currently the trusty MATE story isn't very good (unsigned external repo). -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Meeting time
On Thu, May 08, 2014 at 04:19:53PM -0400, Marc Deslauriers wrote: On 14-05-08 10:09 AM, Martin Pitt wrote: Hello again, Martin Pitt [2014-04-30 10:46 +0200]: http://doodle.com/zmi9m7gfwtyczg5s Now everyone added themselves. Unfortunately there's not a single time when everybody is available, just some which are all-but-one: * Monday 19 to 21: all but Martin * Tuesday and Thursday 18 to 20: all but Adam So perhaps we can alternate between Monday and Tuesday 19:00 (London time, i. e. UTC plus DST) and just live with either Adam or me not being there and catching up by mail? If it helps, I could reschedule the weekly meeting I have on Tuesdays at 17:00 and become available. Since Kees is If Need Be at that time, I'll let him decide. Okay, sure. I may be late from time to time, but that can work. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Provisional MicroReleaseExceptions review
On Wed, May 07, 2014 at 03:33:14PM -0700, Brian Murray wrote: Steve asked that I have a look at the existing provisional micro-release exceptions to determine how many times the MRE was used and whether or not there were any issues with those micro-releases. Kees Cook and I put some code together that checks the package to see how many times a version of the package has been released to -updates for supported releases (including those formerly supported), whether there were any new crashes reported about that version of the package in the Error Tracker, and finally searches Launchpad for any bug reports reported by apport that have that specific package version in them. For any package the results look like: Thank you so much for getting this finished! package, release updates: quantity of SRUs release version: 1.2.3 date SRU version new errors reported: count launchpad bugs: # I've posted the search results to https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions/ProvisionalStatus One thing to note is that automatic crash reporting is not enabled for servers and a lot of the packages with provisional MREs are server packages. Also, I deliberately excluded iscsitarget since its provisional MRE is less than a month old. Nova, Glance, Horizon, Keystone should be full MRE (looks like a solid history). Cinder and quantum/neutron look similar. As do ceilometer and heat. Mesa makes me slightly nervous (trajectory is toward more bugs per release), but should probably get further study (are the bugs actually from the updates?) I think we should revoke VLC's pMRE -- it has never been used. Ceph looks fine. Openvswitch feels like it stopped getting updates. While it does have an update in 2014, there's not much history here. Perhap extend its provisional status another year? Finally, if the quantity of errors or Launchpad bugs is important then libreoffice will require some additional research. Yeah, that one is interesting. I suspect it may be noise and general problems, but as you suggest, should get more research. Yay! Thank you again for this! :) -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 Sat, Apr 05, 2014 at 06:14:08PM -0600, Adam Conrad wrote: On Fri, Apr 04, 2014 at 01:43:03PM -0700, Kees Cook wrote: 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 Sorry to be late to this party, though I think Steve and Stephane both represented my views quite well. I'm good with the simple summary by kees above with the (obvious, I think) s/hosted/distributed/ change to the last line. Obviously, this infrastructure is hosted by Canonical, but should not be distributed by them, except for the single rsync-over-ssh point of sync to the user-facing distribution server(s) operated by the Kylin folks. Right, sorry. I meant built on Canonical infrastructure, distributed from non-Canonical infrastructure. -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 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: Enable hibernation
On Fri, Jan 03, 2014 at 01:50:32PM -0800, Steve Langasek wrote: I know it's a feature that power users value, but I think the technical rationale for removing the option was valid, and still applies today. I think a precondition for reintroducing the option to the menu should be to resolve the reliability problems that led to its removal in the first place (including the problem of systems having insufficient swap allocation), and to get the buy-in from the kernel team (cc:ed) that it will be supportable in the future. I still don't see the sense in hiding a feature because it's buggy. How else should we expect it to get fixed? How about supporting the failure condition better? Add a dialog with instructions/warnings? At the very least the option should be able to be added back with a setting an adventurous user can set. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
provisional MRE review
Hi, With some help from Brian Murray, I've got an initial report of the publications made since a pMRE was put in place for a given package. I don't have details on number of bugs, yet. -Kees 2012-06-25 nova 8 2012-07-03 2012.1+stable~20120612-3ee026e-0ubuntu1 2012-09-03 2012.1.3+stable-20120827-4d2a4afe-0ubuntu1 2013-01-29 2012.2.1+stable-20121212-a99a802e-0ubuntu1 2013-04-25 2012.2.3-0ubuntu2 2013-05-16 2012.1.3+stable-20130423-e52e6912-0ubuntu1 2013-06-06 1:2013.1.1-0ubuntu2 2013-06-06 2012.2.4-0ubuntu3 2013-07-01 1:2013.1.2-0ubuntu1 glance 7 2012-07-10 2012.1+stable~20120608-5462295-0ubuntu2.2 2012-09-03 2012.1.3+stable~20120821-120fcf-0ubuntu1 2013-01-29 2012.2.1-0ubuntu1 2013-04-25 2012.2.3-0ubuntu2 2013-05-16 2012.1.3+stable-20130423-74b067df-0ubuntu1 2013-06-06 2012.2.4-0ubuntu1 2013-07-01 1:2013.1.2-0ubuntu1 horizon 7 2012-09-03 2012.1.3+stable~20120815-691dd2-0ubuntu1 2013-01-29 2012.2.1-0ubuntu1 2013-04-25 2012.2.3-0ubuntu1 2013-05-16 2012.1.3+stable-20130423-5ce39422-0ubuntu1 2013-06-06 1:2013.1.1-0ubuntu1 2013-06-06 2012.2.4-0ubuntu1 2013-07-01 1:2013.1.2-0ubuntu1 keystone 8 2012-07-10 2012.1+stable~20120608-aff45d6-0ubuntu1 2012-09-03 2012.1+stable~20120824-a16a0ab9-0ubuntu2 2013-01-29 2012.2.1-0ubuntu1 2013-04-25 2012.2.3+stable-20130206-82c87e56-0ubuntu2 2013-05-16 2012.1.3+stable-20130423-f48dd0fc-0ubuntu1 2013-06-06 1:2013.1.1-0ubuntu2 2013-06-06 2012.2.4-0ubuntu3 2013-07-01 1:2013.1.2-0ubuntu2 libreoffice 3 2012-07-25 1:3.5.4-0ubuntu1 2012-11-19 1:3.6.2~rc2-0ubuntu4 2013-02-15 1:3.5.7-0ubuntu4 2012-07-23 mesa 8 2012-08-15 8.0.3+8.0.2-0ubuntu3.2 2012-10-17 8.0.4-0ubuntu0.1 2013-01-22 8.0.4-0ubuntu0.3 2013-02-27 9.0.2-0ubuntu0.1 2013-02-28 8.0.4-0ubuntu0.4 2013-04-10 9.0.3-0ubuntu0.1 2013-06-19 9.1.3-0ubuntu0.2 2013-07-04 9.0.3-0ubuntu0.4 vlc 0 2012-12-03 cinder 5 2013-01-29 2012.2.1-0ubuntu1 2013-04-25 2012.2.3-0ubuntu2 2013-06-06 1:2013.1.1-0ubuntu1 2013-06-06 2012.2.4-0ubuntu1 2013-07-01 1:2013.1.2-0ubuntu1 quantum 5 2013-01-29 2012.2.1-0ubuntu1 2013-04-25 2012.2.3-0ubuntu2 2013-06-06 1:2013.1.1-0ubuntu1 2013-06-06 2012.2.4-0ubuntu1 2013-07-01 1:2013.1.2-0ubuntu1 2013-02-25 ceph 2 2013-06-20 0.48.3-0ubuntu1 2013-07-08 0.56.6-0ubuntu1 -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: provisional MRE review
On Mon, Aug 19, 2013 at 12:49:07PM -0700, Kees Cook wrote: 2012-07-23 vlc 0 So, this one seems easy: in a year, there have be 0 MREs of VLC. I say we eliminate this from pMRE status, since there's been no history at all. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Giving upload rights to non-Ubuntu members
Hi, This seems like a good thing over all to me. I'm sure there will be tweaks along the way, of course. On Mon, Jul 22, 2013 at 09:07:01PM +0100, Iain Lane wrote: example, to give greater weight to upstream contributions or to participation in other distributions (essentially, to concentrate on technical skill). I'm curious, though, by what criteria PPU rights will be granted? Unless I missed it, it was sounding pretty nebulous. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Micro release exception for Xen
Hi! On Wed, Jun 19, 2013 at 12:04:34PM +0200, Stefan Bader wrote: Hi, I would like to apply for a micro release exception for Xen for supported releases: - Those are managed by the Xen community and like stable kernels are and limited to bug fixes. Those get reviewed upstream before release. - Like for the stable kernel releases this helps to get bugs fixed even before people may be reporting them to us. - Security patches are based on the current stable release (currently 4.1.x and 4.2.x) so applying security updates before the next stable version has less risk of missing dependencies. - The backports I did prepare were simply replacing the orig tarballs and dropping security patches or bug fixes which since then were applied into upstream stable. https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1180396 (4.1.5) https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1180397 (4.2.2) - Backports get locally test build and also manually regression tested on AMD and Intel Xen hosts. Has there been any history of doing SRUs with the stable update process you've described here? It sounds like there is reasonable testing being done, so I'd be in favor of at least a provisional MRE to help get some more SRUs under our belt, if there are no objections from the SRU team. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: openssl as a system library
stated fairly recently that it's a violation to distribute squid linked against OpenSSL, so I have an extremely hard time seeing how we could possibly start doing so without a similarly explicit statement of permission, regardless of any unilateral decision about how we interpret the system library exception: http://www.squid-cache.org/mail-archive/squid-dev/201206/0075.html How they choose to distribute compiled Squid binaries doesn't exactly determine how Ubuntu should, though. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Squid openssl
On Thu, May 02, 2013 at 04:02:52PM -0700, Clint Byrum wrote: All of that said, there is a much simpler choice, which is to just port your software to use gnutls. I'd rather that software minded people spend their time and expertise on that, than having to deal with legal arguments. How much time could we have saved everyone just having to read these messages if we had put the same effort into gnutls patches for MongoDB and/or Squid? On the one hand, there is a nice compatibility layer already in gnutls. On the other hand, is gnutls as actively developed as openssl? -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: owncloud updates
On Thu, Apr 18, 2013 at 04:11:49PM +0100, Jonathan Riddell wrote: Owncloud is a package which doesn't like to work on our 6 monthly timetable. It has many security vulnerabilities and 3rd party php and javascript libraries which are often not packaged in older versions of Ubuntu. It's been suggested that the tech board might allow it to be updated wholesale to new versions including adding the shipped 3rd party libraries to the package as needed, so I've prepared these https://bugs.launchpad.net/ubuntu/+source/owncloud/+bug/1079150 Does the tech board approve of updating these as a SRU? Is there any hope of having the security problems in the libraries fixed directly? That would be much nicer; it'd fix anyone using those libraries beyond just owncloud... -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Apologies: Monday's meeting
On Wed, Apr 10, 2013 at 03:00:16PM -0700, Matt Zimmerman wrote: I won't be able to make it to the meeting Monday due to a work conflict. I'll also be unavailable. Sorry for the late notice! -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Updated release management straw man for TB consideration
at the moment someone runs dist-upgrade, and not a release. Rolling Snapshot I think would be more in line with what it is. I totally agree with the goal of making it stable, though. And here is as good a place as any to voice my concern over this concept. While I love the idea of a Rolling Snapshot, I am worried its difficulty is being underestimated. From time to time in the past, there have been murmurs about moving to a rolling snapshot. I feel these have coincided with Debian being frozen, and the Ubuntu archive giving the impression that the incoming package changes were slow and easy to deal with. As soon as Debian unfroze, these murmurs went away. We cannot control what will come flooding into the Ubuntu archive from Debian, which is why stabilization (via regular releases) is so critical to the success of Ubuntu. Improving the quality of the Ubuntu archive via automated testing is a great way to get out ahead of this, and those things are already in progress. However, I don't think they're nearly to the level of detecting regressions in DHCP lease delays, UI rendering glitches, streaming codec performance, etc. There are so many subtle and complex things that are hard to realistically automate tests for. Now, this should not stop us from attempting those tests. Every test added is another thing that we can throw a flag for if it goes wrong, but I think we're not there yet. I think opening the flood gates from Debian unstable will cause pain. However, that pain is still less than not opening those flood gates. Having those changes pour in is what we need to keep the regular releases coming. I think our cadence with Debian has been very successful. I think when there are end-to-end usability, performance, and regression tests in place, and there are people responding to those alerts, then we'll be in a much better place to have an automated Rolling Snapshot. I want this. It will be fantastic. I think it's a much longer road. As a (possibly) separate matter, in the blog I mention that decoupling platform and apps might help us go faster, and encourage app developers to make the tough choices about which versions of their apps are supported on which releases of the platform. I've left this bit out of the core proposal but would think our community would be interested in your collective take on that. What seems to create an App ecosystem is a stable API. If that can be provided, I think decoupling is almost automatic. (And if those Apps are closed-source, then you need a stable ABI, which is even harder than a stable API.) Regardless, I would agree: this is a separate matter. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Minutes of the Technical Board meeting 2013-02-18
are necessary before we begin doing so? No objections to this either. +1 -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
Hi, I won't be able to make the Mon Feb 18th meeting; it's a US holiday and I've got conflicting plans. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Reg Call for new ARB members
On Tue, Jan 15, 2013 at 10:58:40AM +0530, Bhavani Shankar R wrote: Dear Stephane/Techboard. After considering the number of people interested at the end of the call for new ARB members yesterday, we found only one suitable nominee who meets the application criteria of the App Review Board. No objections from me. +1 -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: launchpad-buildd-admins
Hi, On Mon, Jan 14, 2013 at 06:35:58PM +, Laura Czajkowski wrote: I am requesting I be added to the launchpad-buildd-admins team please. I fee it is necessary so I am able to deal with ppa build priorities when we get the requests from users ( canonical employees mostly). Launchpad has been reduced to two members of maintenance and are in the AU time zone. It would be be beneficial to my role to be able to deal with requests when they come in rather than waiting till they come online or poking webops so I can deal with requests in a timely fashion. This seems fine to me. Can other buildd-admins speak up in support too? -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request to add cinder and quantum packages to existing OpenStack MRE
On Thu, Nov 29, 2012 at 12:07:02PM -0800, Adam Gandelman wrote: Last cycle, the TB granted a provisional Micro Release Exception [1] for the OpenStack Essex core components (Nova, Glance, Horizon, Keystone) to help speed up the process of getting upstream stable release into Ubuntu. Since then, two new core components were added to the OpenStack core during the Folsom cycle: cinder and quantum. These made their way into the main Ubuntu archive for Quantal. I would like to request the cinder and quantum packages be added to the current MRE to facilitate quick and coordinated stable updates to OpenStack users across all core components. The same quality assurances made for Nova, Glance, Horizon and Keystone are true for Quantum and Cinder: - Low-volume, bug fix only upstream branches. - Upstream commits are required to pass per-review and numerous gating tests before they are eligible for merging. - The Ubuntu Server team continues its QA efforts around stable branches, providing per-commit build and integration testing for all changes merged into any of the core stable branches upstream. - As members of the OpenStack Stable Branch Maintainer team, Dave Walker and Chuck Short continue to help keep and eye on what stable fixes land upstream. To date, the existing MRE has proven to be extremely helpful in ensuring upstream stable updates are pushed out to Ubuntu users in a timely manner. Both the Ubuntu Server Team and the OpenStack project have spent a great deal of time refining the process and tooling around stable updates. Last cycle, were able to push out a thoroughly tested batch update to precise-updates [2] that closed 74 bugs across 4 projects with no reports of regressions. At the OpenStack Developer Summit in October, the project defined a release schedule [3] for stable Folsom updates allowing downstreams and users to better plan, test and prepare accordingly. We are currently in the process of preparing and testing the first of these stable Folsom updates for Quantal SRU and hope to have Cinder and Quantum fixes pushed out alongside the others. Best, Adam Gandelman [1] http://comments.gmane.org/gmane.linux.ubuntu.devel.technical-board/807 [2] https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1041120 [3] https://etherpad.openstack.org/process-stable-branch I'd be in support of a provisional MRE for these two as well. Thanks, -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Meeting time
Hi, On Tue, Nov 13, 2012 at 09:19:52AM +0100, Martin Pitt wrote: As this keeps causing confusion, and there is very little rationale for binding our meeting time to UTC (given that we are all on the Northern hemisphere), can we agree to always have the meeting at 21:00 London time? We tied this to UTC because UK/Europe/USA DTS wasn't always at the same time. That said, I'm fine with 2100 UK time. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
[Bug 174375] Re: Distribution drivers permissions may need redesign
** Changed in: ubuntu-community Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Ubuntu Technical Board, which is a bug assignee. https://bugs.launchpad.net/bugs/174375 Title: Distribution drivers permissions may need redesign To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad/+bug/174375/+subscriptions -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Extension of term lengths
On Fri, Sep 07, 2012 at 03:10:36PM +0200, Daniel Holbach wrote: Hello everybody, would it be possible for the TB to extend the term lengths of - Allison Randal - Andrew Mitchell - Shane Fagan - Stéphane Graber by 3-4 weeks? The restaffing process is a bit slow right now and the additional time would help with the transition. Yup, +1 from me too. -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
[Bug 252368] Re: Automatically associate DD and DM accounts with GPG keys in keyring packages to allow DDs to use the Launchpad Email interface
After talking to the Ubuntu LP Stakeholder, it sounds like LP development has stopped, and there are no plans for additional features. This means this bug either needs to go to Won't Fix, fixed by another team, or get escalated through some higher path. -- You received this bug notification because you are a member of Ubuntu Technical Board, which is a bug assignee. https://bugs.launchpad.net/bugs/252368 Title: Automatically associate DD and DM accounts with GPG keys in keyring packages to allow DDs to use the Launchpad Email interface To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad/+bug/252368/+subscriptions -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU for pango-graphite in Lucid
Hi Martin, On Thu, Jun 28, 2012 at 10:24:10PM +0200, Martin Erik Werner wrote: Alternatively it would work to only grab the code changes as a patch, and skip the rest, possibly this would better fit SRU policy... Debian stable carries the exact code this change would result in (whereas later versions of Ubuntu Debian carries additional patches on top), so presumably it is reasonably tested. The full upstream diff and the reduced version containing only the code changes are attached to the bug report: https://bugs.launchpad.net/ubuntu/+source/pango-graphite/+bug/540035/+attachment/3201822/+files/pango-graphite-0.9.2-to-0.9.3.diff https://bugs.launchpad.net/ubuntu/+source/pango-graphite/+bug/540035/+attachment/1424192/+files/u01_crasher-fix.patch It seems like just fixing the bug would be easier to get the SRU team to agree to. Please use that and follow the regular SRU process. There doesn't seem to be a pressing reason to do a version bump. Thanks, -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Micro release exception for Nova, Glance, Horizon, Keystone
Hi Chuck, On Tue, Jun 19, 2012 at 05:34:27PM -0400, Chuck Short wrote: Hi, I would like to apply for a micro release exception for Nova, Glance, Horizon, and Keystone. These micro releases: - Happen from a low volume stable branch reserved for bug fixes. - unit tests for each component are run during the package builds and the packages FTBFS if the test suite fail. - Dave Walker and Chuck Short are members of the stable release team for the openstack project. - Upstream commits are reviewed by the members of the stable release team for the openstack project. - Upstream commits are tested before they are added to the upstream stable/essex branch - Continous openstack integration is done by the Ubuntu Server team on the stable/essex branch. - Each commit is tested automatically by the openstack-ci lab that is hosted by canonical. Can someone from the SRU team vouch for this package? -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Micro release exception for Nova, Glance, Horizon, Keystone
On Wed, Jun 20, 2012 at 04:09:41PM -0400, Chuck Short wrote: On Wed, 20 Jun 2012 12:57:29 -0700 Kees Cook k...@ubuntu.com wrote: Hi Chuck, On Tue, Jun 19, 2012 at 05:34:27PM -0400, Chuck Short wrote: Hi, I would like to apply for a micro release exception for Nova, Glance, Horizon, and Keystone. These micro releases: - Happen from a low volume stable branch reserved for bug fixes. - unit tests for each component are run during the package builds and the packages FTBFS if the test suite fail. - Dave Walker and Chuck Short are members of the stable release team for the openstack project. - Upstream commits are reviewed by the members of the stable release team for the openstack project. - Upstream commits are tested before they are added to the upstream stable/essex branch - Continous openstack integration is done by the Ubuntu Server team on the stable/essex branch. - Each commit is tested automatically by the openstack-ci lab that is hosted by canonical. Can someone from the SRU team vouch for this package? Clint Byrum is on the SRU team and he can vouch for these packages. Based on the upstream commitments, test suites, and comfort level of the SRU and Security teams, this seems reasonable to me. I'd like to hear from other TB members first, though. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: micro release exception for LibreOffice
Hi Sebastien, On Mon, Jun 11, 2012 at 12:09:24PM +0200, Sebastien Bacher wrote: Le 05/06/2012 19:29, Bjoern Michaelsen a écrit : We released Precise with the regression in 3.5.3 and people are now waiting for a 3.5.4 SRU/MRE to get the upstream fix. There is some irony hidden in there. Hey TB, Is there any way we could get moving on that issue? The SRU team is not wanting to approve that update without a TB resolution and it has been 10 days the email got sent with one reply from Martin so far, meanwhile the LTS is stucked with a version which has regressions and data lost bugs when we have an update ready which fix those, is there anything else we can do to unblock the situation? The request is for an MRE, and I don't feel that there has been a sufficient history of successful SRUs to allow a blanket MRE for LibreOffice. The upstream requirements and test suite requirements are very nicely met, but without a demonstrable history of successful Ubuntu SRUs, I think it's premature to grant an MRE. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Extension of postfix microversion exception
On Tue, May 01, 2012 at 12:48:52PM -0400, Scott Kitterman wrote: Roughly half a year ago, I asked for a microversion exception for postfix and the tech board agreed to give it a trial: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011- October/000902.html As requested, we did a trial run of this in Natty and it went well (and then I got busy with some other things): https://launchpad.net/ubuntu/natty/+source/postfix/2.8.5-2~build0.11.04 Given the successful trial, I would like to get general approval for this going forward. Yeah, sounds good to me too. +1 -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Micro release Exception for Nova, Swift, Glance, and Keystone
Hi Chuck, On Mon, Nov 28, 2011 at 09:52:13AM -0500, Chuck Short wrote: I humbly ask for a on-going micro release exception for the openstack packages (nova, swift, glance, dashboard, quantum, and keystone) for oneiric and for future releases. Have SRUs happened for these already? Traditionally, it's better to have a few successful SRUs go by first before attempting an SRU MRE. * regression tests are enabled in the package's build Running the test suite has always been ran when the packages are built, an example is the following: https://launchpad.net/ubuntu/+source/nova/2011.3-0ubuntu6/+build/2826798he This is good; that gives me warm fuzzies. :) That's a lot of tests. Have you confirmed that failing a test will FTBFS the package? Thanks! -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Measuring success/failure in the installation
On Thu, May 26, 2011 at 03:52:45PM +0100, Matt Zimmerman wrote: On Wed, May 25, 2011 at 08:20:30AM -0700, Scott James Remnant wrote: On Wed, May 18, 2011 at 2:33 AM, Evan Dandrea e...@ubuntu.com wrote: To be clear, since it wasn't addressed in my original email, I intend to only present percentages of successful and unsuccessful installs. 3) Collaboration. This, to my mind, is the most important. This is a good reason to share raw data. It's useful for people to be able to run their own analyses. That said, the question of whether we share the raw data isn't a deciding factor for me. I think we should do this measurement because it's useful in itself. Can you describe how it is useful? I still don't see why the numbers would actually tell us anything actionable. Having a raw count of number of installs might be interesting, but I'm not sure I see the step to useful. -Kees -- Kees Cook Ubuntu Security Team -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Measuring success/failure in the installation
Hi Evan, Thanks for bringing this up. I've been trying to come up with a sensible response to the original thread, but I figure since I wear a few hats, I'd wait to reply with my TB hat on, and try to merge all my thoughts now. I have no general objection to collecting this kind of information, so long as it provides actual value. For example[1], connman connects back to http://www.connman.net/online/status.html and reports its version every time it establishes a network connection. This provides direct value to the user because their software is able to better detect if it has actually found a real Internet connection or not, and do something about it. What value does the installer connect-back actually provide the user? Why are raw counts of any value? It would seem that reporting a full set of hardware details in the connect-back would actually give you better before/after logs (people with FooBar wifi are never seen again), but it still doesn't provide the user with immediate direct useful improvement to their Ubuntu experience, so I'm not sure it's worth doing. Thanks, -Kees [1] http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=plugins/portal.c Thanks to Marc Deslauriers for pointing this out to me. -- Kees Cook Ubuntu Security Team -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Time of meeting
Hi Scott, On Mon, Apr 04, 2011 at 09:09:36PM -0700, Scott James Remnant wrote: I have it listed as 1900 UTC (11am America/London) What is the world is America/London? :P It's set for 1800 UTC, which is 11am on the US west coast. I love this site for validating insane tz issues: http://www.timeanddate.com/ -Kees -- Kees Cook Ubuntu Security Team -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
