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 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
Quantal: End of the line for i386 non-PAE
As decided by the Tech Board, 12.04 is the last release to have the i386 non-PAE kernel flavour. So, how do we upgrade folks ? IIRC a non-PAE kernel was installed because 1) there was less then 4GB RAM, or 2) their CPU did not have PAE support. The folks in case 2 are simply out of luck (and no longer supported). I have removed the non-PAE kernel meta package from Quantal that would allow a non-PAE upgrade. Its likely that folks attempting an upgrade to Quantal will be left with a Precise kernel. 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. 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: Distro-provided mechanism to clean up old kernels
Dustin, There is a blueprint started for cleaning old kernels. Perhaps you should add your thoughts to it. https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-clean-old-kernels 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 up>1 CPU on machines that have>1 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: [RFC] Drop Non-smp PowerPC Kernel Flavor
On 03/14/2012 11:00 AM, Colin Watson wrote: On Wed, Mar 14, 2012 at 09:52:01AM -0700, Leann Ogasawara wrote: The Ubuntu Kernel Team has been evaluating some of the current maintenance burdens for the upcoming Precise Pangolin 12.04 LTS release. One area which would reduce the maintenance costs would be to drop the non-smp PowerPC kernel flavor. There are currently three PowerPC flavors: Making the associated installer changes shouldn't be a big deal, but I suggest you ask the Xubuntu and Lubuntu communities about this since a good proportion of powerpc users are there. * non-smp (linux-image-powerpc) * smp (linux-image-powerpc-smp) * smp-64 (linux-image-powerpc64-smp) It's not clear to me whether it would make more sense to drop -powerpc or -powerpc-smp. My memory is that -powerpc-smp was significantly less used and would be a better candidate for removal. Do you have notes on which hardware is covered by -powerpc-smp that can't use -powerpc64-smp? We consulted Jeremy Kerr about this. He says that an SMP kernel will run on all 32 bit powerpc platforms, including non-SMP. I don't recall discussing if the 64 bit SMP kernel would run on all SMP capable hardware. That combination is not possible on all x86 platforms, so I was likely biased. 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] AUFS disabled for 12.04
On 03/01/2012 03:08 PM, Gary Poster wrote: Hi. aufs was reliable for us on Oneiric when creating ephemeral lxc instances based on an underlying template. The most recent overlayfs issue that we discovered is today's https://bugs.launchpad.net/ubuntu/+source/linux/+bug/944386 The summary is that, within an overlayfs, this fails: gary@garubtosh:~/tmp$ touch 3 gary@garubtosh:~/tmp$ chmod 0444 3 gary@garubtosh:~/tmp$ ln 3 4 ln: failed to create hard link `4' => `3': Operation not permitted That error makes xvfb unable to start, in this particular case. I'd feel a *lot* more comfortable if aufs were still around, in case we end up not finding the next overlayfs bug until it is too late for our project's delivery. Thank you, Gary In light of the concerns about overlayfs being sufficiently cooked in time for Precise, Andy Whitcroft and I have decided to re-enable aufs. We will continue to advocate for dropping aufs in favor of a sufficient upstream solution at each development cycle. This means that aufs _will_ disappear in future backported LTS kernels. In other words, don't bet your business on aufs. I am speaking directly to the lxc and server folks. aufs has _one_ maintainer, is enormously complex, is difficult to integrate with each new kernel version, and will _never_ be accepted upstream. 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: Call for testing: Upstart 1.4 in Ubuntu
On 12/22/2011 03:01 PM, James Hunt wrote: Hi All, We're looking to land Upstart 1.4 in Ubuntu Precise early January 2012. If you have an Ubuntu Precise test system [1] and you'd like to help with testing these new features, read on... = New Features = The two main new features are: - new 'setuid' and 'setgid' stanzas Allows you to specify the user and group a job runs as (this should help minimize the intricate su/sudo/start-stop-daemon command-lines) - Logging of job output for system jobs [2] Job logging is enabled by default in 1.4. Since this is the first version of Upstart that writes to *any* files, this is quite a big change. 3 new command-line options have been added to support this feature: '--no-log' (disable logging entirely) '--logdir=DIR' (specify alternate log directory) '--default-console=VALUE' (specify default value for 'console' stanza). = How to Obtain the Upstart 1.4 Package = please add the following 'upstart-job-logging' PPA [3] to your system and give it a spin: sudo add-apt-repository ppa:jamesodhunt/upstart-job-logging = Feedback = Please provide feedback via a bug report: https://bugs.launchpad.net/ubuntu/+source/upstart/+filebug = Further Details on Features = Full details on these features can be found in the usual places: - init(5) - init(8) - cookbook: http://upstart.ubuntu.com/cookbook/#console-log http://upstart.ubuntu.com/cookbook/#configuration http://upstart.ubuntu.com/cookbook/#setuid http://upstart.ubuntu.com/cookbook/#setgid Thanks for your help. Kind regards, James. [1] - Usual caveats apply: do *not* install this on any critical systems. [2] - Two limitations to be aware of: - logging *only* currently applies to system jobs, - any job that produces output and ends *before* the disk becomes writeable will not currently have output logged. Note: both limitations are currently being addressed. [3] - https://launchpad.net/~jamesodhunt/+archive/upstart-job-logging -- James Hunt http://upstart.ubuntu.com/cookbook http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf James - The kernel team has plenty of Precise systems that we can update. Given the fundamental nature of Upstart, is there any way to recover short of reinstalling if it completely breaks the boot ? Can we stash the original /sbin/init somewhere and hack the grub command ? 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/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/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: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
On 11/09/2011 03:14 PM, Colin Watson wrote: On Wed, Nov 09, 2011 at 02:43:28PM -0700, 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. 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? 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. I'd have thought we needed data here? As far as I can tell there hasn't been a mass produced non-PAE cpu in over 5 years that we (as a distro) care about. The consumer grade electronics lifecycle is _well_ below 5 years. Furthermore, the distro focus has been desktop with high performance 3D graphics and servers. Where do non-PAE CPUs fit in that world? There are better distro choices to fill that niche. I'm worried about dropping the kernel that's been the default during the installer for some time, in one step. If we want to switch the installer to generic-pae and then drop the non-PAE kernel in the next cycle if that works out well, I'd be happier with that approach; that gives us a much more graceful fallback plan in the event that our opinions are mistaken. I want to drop the non-PAE kernel _before_ the LTS. Otherwise we have to deal with the complexities of LTS backported kernels _not_ having the same flavour set as the released LTS kernel (something I'd prefer not to have to do). What do you think about dropping x86 32 bit kernels altogether for 14.04 ? By then we should have _really_ good multi-arch support, and the CPUs that we care about will all be 64 bit capable. 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
Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
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 -- 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: ARM: Dropping debian-installer armel+versatile kernel and netboot kernel
On 06/20/2011 03:17 PM, Loïc Minier wrote: Hey there On armel, we currently have a versatile flavor of the linux packages and a versatile netboot image of debian-installer. ARM Versatile was added in Debian a long time ago and then in Ubuntu because it could be run within QEMU. Nowadays in oneiric we have a linaro-vexpress kernel flavor and a corresponding d-i netboot image which supports ARM Versatile Express platforms. I'd like to kill the old versatile stuff: - ARM Versatile is an obsolete hardware platform (it got superseded by ARM RealView and then ARM Versatile Express, and even that is getting old) - versatile boards only supports up to ARMv6 CPUs but Ubuntu's userspace is ARMv7+, so we currently carry a patch to user an ARMv7 CPU in our linux versatile build, which is hackish. Vexpress supports SMP with ARMv7 CPUs, but can of course still run a v5 userspace like Debian's. Basically, Vexpress should be technically superior in all respects; notably, it can emulate 1024 MiB of RAM. - this would cut down the build time of "linux" on armel by one flavor out of two; perhaps from 28 hours to 14 hours - however, the kernel tree is slightly different: the linaro-vexpress flavor is based of linux-linaro which includes the Linaro kernel bits while versatile is built of the linux source package, with less patches over mainline Is there any objection to the removal of the versatile bits? NB: I'm seeing two annoying bugs with qemu/vexpress, which I think are present with versatile as well: qemu stalls regularly when accessing the emulated SD (LP #732223) but eventually proceeds; and some network I/O is corrupted or interrupted (LP #799757), but retrying allows to proceed. The latter prevents using things like debootstrap as it can't do any retries. Cheers, 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. 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
