Re: [RFC] 12.04.5
On 02/07/2014 09:00 AM, Leann Ogasawara wrote: Hi All, With 12.04.4 having just released, I wanted to propose the idea of having a 12.04.5 point release for Precise. +1 -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing reiserfs support from the installer
On 09/12/2013 08:47 AM, Dmitrijs Ledkovs wrote: On 12 September 2013 16:37, Colin Watson cjwat...@ubuntu.com wrote: Debian has removed reiserfs support from its kernel packages and its installer (http://bugs.debian.org/717517). I don't really want to keep maintaining it without Debian; for instance it would mean adding support for http://bugs.debian.org/696123 as an Ubuntu-specific patch once we have the underpinnings done. Does anyone feel desperately that we have to keep this or shall I just go ahead and drop it? I've informally raised this with #ubuntu-kernel team on irc / one-to-one conversions as well. I think the rough consensus was that we should follow suite and also drop reiserfs support from both our kernel configuration and installer. Not sure if the kernel configuration should be kept in-tact because of hardware enablement stack backports, I would hope that it wouldn't be necessary. Ditto other kernel modules that were dropped from the debian kernel config at the same time as reiserfs. I agree that reiserfs support should simply be dropped, and ideally should have been done earlier in the cycle when the same change was done in debian. Regards, Dmitrijs. As was pointed out on IRC this is the original email from Ben Hutchings regarding his decision to remove reiserfs from kernel udebs: https://groups.google.com/forum/#!topic/linux.debian.maint.boot/QO187Szy2_o I'm not really in favor of entirely dropping reiserfs support from the kernel, e.g., CONFIG_REISERFS_FS=n. Doubtless, there are still folks out there using it that would be pretty annoyed on upgrading to find they can no longer access their file system. I am, however, OK with dropping resierfs from any udebs that we produce. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Release engineering sprint, July 2013
On 08/08/2013 08:45 AM, Colin Watson wrote: On Mon, Jul 29, 2013 at 12:43:11PM +0100, Colin Watson wrote: A noticeable amount of time here will be improved by pending hardware upgrades. Adam spent some sprint time working on the installation of new Calxeda systems; we don't know how much those will shave off the livefs build phase (currently 52m or so) but it wouldn't be a surprise if they removed 20m or so, and the current Panda boards occasionally corrupt data which causes extra delays while people debug them. The Calxeda builders are now deployed and in service, both for package building and live filesystem building. My test live filesystem build ran in 30 minutes. Thanks to Adam and a cast of several sysadmins for getting this sorted out. Saucy armhf kernel builds dropped from 18 hours to approx 5. I'm liking that trend. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Quantal: End of the line for i386 non-PAE
On 05/08/2012 08:13 AM, Phillip Susi wrote: On 5/2/2012 10:57 AM, Tim Gardner wrote: Any ideas on how we might allow PAE capable CPUs to upgrade? Is this the job of update-manager ? It seems likely that Debian must have encountered this issue before. With a Replaces: line in the control file of the new kernel? The suggestion offered yesterday in the kernel flavours session was to add a pre-install hook in the meta package to determine if the CPU was PAE capable, and to stop the upgrade if not. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Drop Non-smp PowerPC Kernel Flavor
On 03/15/2012 06:02 AM, Colin Watson wrote: On Thu, Mar 15, 2012 at 11:02:09AM +0800, Jeremy Kerr wrote: Hi all, We consulted Jeremy Kerr about this. He says that an SMP kernel will run on all 32 bit powerpc platforms, including non-SMP. To clarify: the hardware supported by the powerpc and powerpc-smp flavours is almost identical. The differences probably don't matter Ubuntu users, as it'll be obscure hardware. I've CC-ed benh in case he wants to correct me on this one. However, the SMP kernel supports (surprise!) bringing up1 CPU on machines that have1 CPU. With a UP kernel on these machines, the other CPUs are left doing nothing. The main class of 32-bit SMP powerpc machines are the Apple dual-G4s. So, since the hardware coverage is essentially the same, but we get SMP support on SMP machines, I'd say that we would prefer the powerpc-smp kernel over the powerpc flavour. OK, that all makes sense, and I agree based on that. I'd forgotten about the dual G4 class. I would switch the installer over to powerpc-smp today, then, except that the kernel doesn't ship powerpc-smp udebs yet, only powerpc and powerpc64-smp. Can somebody fix that so that I can do this transition? I'll take care of it. Leann plans to upload later in her day Friday, so the kernel ought to be available by Monday. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Smoke testing of Precise X server bits
On 01/19/2012 11:43 PM, Chase Douglas wrote: On 01/20/2012 03:01 AM, Chase Douglas wrote: Hi all, We have everything ready (almost) for the upload of the X server into Precise. It includes X server 1.11 plus the input stack from 1.12. It also includes a bunch of interdependent packages that would break if you were only to update your X server. Here's the known issues with the PPA: * No utouch-geis support, which means most of your gestures won't work - Will be fixed by feature freeze * Multitouch in Qt from indirect devices (e.g. trackpads) is broken - Will be fixed in next Qt upload *after* we push these packages * Qt is still building for armel, so don't test this on armel yet * A security hole will kill your screen saver if you type Ctrl+Alt+KP_Multiply - Will be fixed in xkeyboard-config upload in the next couple hours Notably, xserver-xorg-input-synaptics has a large patch added in today for multitouch support. The X synaptics module is used for all trackpads. Please test that your trackpad is behaving sanely. We are mostly looking for blocker bugs right now (random X server crashes, really obnoxious behavior, etc.). Please reply with any such bugs you find. Oops, I forgot to mention the packages are in ppa:canonical-x/x-staging. The following should get you set up for testing: $ sudo add-apt-repository ppa:canonical-x/x-staging $ sudo apt-get update $ sudo apt-get upgrade I don't think you need to dist-upgrade for this as there shouldn't be any new packages or packages needing to be removed, but I'm not entirely certain. -- Chase Will any of these updates address cut and paste on a Mac touchpad ? It appears to be impossible to select text without using an external mouse. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
On 11/09/2011 02:43 PM, Tim Gardner wrote: Per discussion at UDS the kernel team is proposing to drop the non-PAE i386 flavour. The upgrade path for non-PAE users will be the PAE kernel. Those CPUs that do not have i686 and PAE support will be orphaned. To the best of my knowledge, these include Intel CPUs prior to Pentium II, 400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no laptop or desktop class CPUs being produced that do not meet these minimum requirements. Before I do something that is difficult to revert, I would like to hear from the development community why we should continue to maintain a kernel flavour that is (in my opinion) getting increasingly low utilization. It is my feeling that an extremely high percentage of users of the non-PAE kernel have a CPU that is PAE capable. If there is sufficient community demand (and support), I would be willing to sponsor the first non-PAE kernel upload to Universe. https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReview We'll be conducting a similar survey for powerpc. rtg P.S. For those of you that are totally confused by this email, PAE (Physical Address Extension) was an addition to 32 bit x86 CPUs that allowed them to address more then 4GB physical memory. http://en.wikipedia.org/wiki/Physical_Address_Extension Thank you to everyone who responded to this thread. To summarize, no compelling hard evidence has been presented to change my original decision. I am opposed to supporting non-PAE CPUs for another 5 years. Colin King has developed power and performance profiling data that indicate the differences between PAE and non-PAE are negligible. I've also discussed this with OEM regarding possible future LTSP projects and have concluded it will have no detrimental impact. Every flavour maintained by the kernel team has an incremental impact, especially when it comes to test builds and the full packaging cycle. Every flavour must also be tracked by meta packages. Every flavour has its unique class of bugs; non-pae has a ginormous and ugly NX emulation patch that has consumed substantial maintenance resources in the past, not to mention all of the bugs complaining about memory holes and the 4Gb limit. The kernel team has limited resources. Obviously I want to apply what resources we have to the problems that affect the most important platforms. Furthermore, I anticipate new ARM flavours in the coming months which will take up any slack afforded by the loss of non-PAE. It is my recommendation that folks running PAE incapable CPUs stay on Lucid (10.04), a release for which they'll still receive more then 3 years of official support. If you feel passionately that I've made an incorrect decision, then I suggest contacting the Ubuntu technical board. https://wiki.ubuntu.com/TechnicalBoard rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
On 11/28/2011 11:44 AM, Kees Cook wrote: On Mon, Nov 28, 2011 at 09:40:53AM -0700, Tim Gardner wrote: non-pae has a ginormous and ugly NX emulation patch This is about dropping non-PAE support, not dropping non-NX support. The NX emulation patch must remain in the kernel since a large number of systems have PAE but not NX. You can see this in the table here: https://wiki.ubuntu.com/Security/Features#nx Dropping non-PAE just eliminates the top line in that table. NX-emu will still be needed. I guess you are correct. I naively assumed that execute-disable was introduced with PAE in the Pentium Pro series. However, it did not appear in Intel CPUs until Pentium 4 (approx Q1 2005). AMD had it from the beginning in the Athlon series. that has consumed substantial maintenance resources in the past, I'm also curious about this claim, as you've expressed to me in the past that carrying it has been surprisingly trivial. In fact, since I'm the one maintaining it these days, it's actually going to require 0 resources from Canonical. ;) http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/nx-emu I did say in the past. I remember encountering several issues with the early implementation, as well as maintenance hassles while 32 and 64 bit arch support was converging. I would characterize the NX emulation patch as deeply intrusive, arguably one of the more complex patches against the core of Linux that we carry. Its a moot point given the model gap between PAE and NX introduction. The kernel team has limited resources. Obviously I want to apply what resources we have to the problems that affect the most important platforms. Furthermore, I anticipate new ARM flavours in the coming months which will take up any slack afforded by the loss of non-PAE. I'm curious why pushing non-PAE to universe and leaving it in the main linux source package is a burden? Then people using non-PAE get automatic security updates without any hassle on anyone's part. This is what the Ubuntu Security Team manager wants: https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034457.html as well as the Ubuntu Platform Team manager wants: https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034463.html I'm not convinced there's enough evidence to say that dropping it from the main linux source package will actually save any time at all. Dropping this flavour saves 5 minutes per build on a 4-way 80 thread server, which for some of the team can add up to quite a bit of time over the course of a day. Its one less variant that needs to be tested in Q/A, and its one less flavour we have to mess with in our meta and LBM packages. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
On 11/10/2011 08:14 AM, Tim Gardner wrote: On 11/09/2011 03:14 PM, Colin Watson wrote: Does KVM work properly with PAE kernels at the moment? I've had trouble with it within the last six months, and when running server installations I've had to tweak them on the fly to install the generic kernel in order that I could boot the installed system. This just seems like a bug. If we don't address it early in this cycle, then what incentive would we have to address it during the 12.10 dev cycle? I tested this on Precise today using testdrive on a 32 bit PAE server kernel to host a 32 bit Precise PAE guest kernel. Similarly, I also tested using a 64 bit host and a 32 bit PAE guest kernel. Are those combinations sufficient ? rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ARM: Dropping debian-installer armel+versatile kernel and netboot kernel
On 06/28/2011 03:57 PM, Loïc Minier wrote: On Tue, Jun 28, 2011, Tim Gardner wrote: I talked to Oliver Grawert about this. We are quite happy to drop the distro versatile flavour in favor of the Linaro packaged versatile-express kernel. Cool! I was about to followup on this, but didn't have time to cook an ubuntu-oneiric.git patch yet The only thing to be careful about is to keep generating linux-libc-dev on armel; all the versatile related stuff in the linux source package can go away IMO (Other impacted packages: debian-installer, I can take care of it, and maybe rootstock?) Dunno about rootstock. I'll go ahead and rip out the versatile flavour. Note that we still have an omap armel flavour, and we'll continue to generate the other armel binaries (such as linux-libc-dev). rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu 11.04 Kernel Configurations
On 03/25/2011 05:49 PM, Scott Ritchie wrote: On 03/24/2011 11:09 AM, Leann Ogasawara wrote: Hi All, With the Ubuntu 11.04 Beta-1 release approaching, the Ubuntu Kernel Team felt this would also be an appropriate time to advertise what we intend to be the final kernel configurations for all the main distro and ports kernel flavors. The purpose is to expose the main configuration changes and provide pointers to the full configurations for those who are interested. To aid in the comparison of kernel config changes from Ubuntu 10.10 (Maverick) to Ubuntu 11.04 (Natty) we have generated a delta report [1]. We have also posted the full Ubuntu 10.10 and Ubuntu 11.04 configurations for each flavor [2]. Thanks, The Ubuntu Kernel Team [1] https://wiki.ubuntu.com/Kernel/Configs/MaverickToNatty [2] http://kernel.ubuntu.com/~kernel-ppa/configs Perhaps this is an appropriate time to ask, since I've been trying to ask for months now in mailing list/IRC but never apparently to the right person... Can the kernel team please raise the hard limit for file descriptors (but keep the soft limit)? https://bugs.launchpad.net/bugs/663090 I'm having real applications break from this, and the change shouldn't affect any app that doesn't request it manually. Thanks, Scott Ritchie The initial hard limit value is not a CONFIG option, so the only way it can be changed is by carrying a patch in the kernel, something I would prefer not to do. This is the macro that initializes the hard limit: include/linux/fs.h:#define INR_OPEN 1024/* Initial setting for nfile rlimits */ What is the issue with having upstart set this limit early in the boot cycle? Won't all new processes inherit the modified limit? rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
