Re: telepathy-qt5 0.9.5
bump :/ On Tue, Dec 9, 2014 at 11:49 AM, Harald Sitter apachelog...@ubuntu.com wrote: ahoy, since apparently there are a heap of excessively intrusive patches in telepathy-qt5 because of ubuntu touch, can someone please refresh the patches against 0.9.5 (and land that)? and can we please not have API patches that aren't upstreamed? cheers. HS -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Minutes from the Ubuntu Kernel Team meeting, 2014-12-16
= Meeting Minutes = [[http://irclogs.ubuntu.com/2014/12/16/%23ubuntu-meeting.txt|IRC Log of the meeting.]] [[http://voices.canonical.com/kernelteam|Meeting minutes.]] == Agenda == [[https://wiki.ubuntu.com/KernelTeam/Meeting#Tues, 16 Dec, 2014|20141216 Meeting Agenda]] === Release Metrics and Incoming Bugs === Release metrics and incoming bug data can be reviewed at the following link: * http://people.canonical.com/~kernel/reports/kt-meeting.txt === Status: Vivid Development Kernel === The master-next branch of our Vivid kernel remains rebased to the final v3.18 upstream kernel. We have pushed uploads to our team's PPA for preliminary testing. We are still debating on uploading to the archive after Alpha1 releases this week. However, we may opt to wait until everyone returns from holiday after the new year. - Important upcoming dates: Thurs Dec 18 - Vivid Alpha 1 (~2 days away) Fri Jan 9 - 14.04.2 Kernel Freeze (~3 weeks away) Thurs Jan 22 - Vivid Alpha 2 (~5 weeks away) Thurs Feb 5 - 14.04.2 Point Release (~7 weeks away) === Status: CVE's === The current CVE status can be reviewed at the following link: http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html === Status: Stable, Security, and Bugfix Kernel Updates - Utopic/Trusty/Precise/Lucid === Status for the main kernels, until today: * Lucid - Prep * Precise - Prep * Trusty - Prep * Utopic - Prep Current opened tracking bugs details: * http://kernel.ubuntu.com/sru/kernel-sru-workflow.html For SRUs, SRU report is a good source of information: * http://kernel.ubuntu.com/sru/sru-report.html Schedule: cycle: 12-Dec through 10-Jan 12-Dec Last day for kernel commits for this cycle 14-Dec - 20-Dec Kernel prep week. 21-Dec - 10-Jan Bug verification; Regression testing; Release === Open Discussion or Questions? Raise your hand to be recognized === No open discussion. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] CONFIG_ARM64_64K_PAGES=y for vivid?
On Mon, Dec 15, 2014 at 7:08 PM, Adam Conrad adcon...@ubuntu.com wrote: On Mon, Dec 15, 2014 at 05:36:25PM -0700, Dann Frazier wrote: There's the question of whether or not we would be penalizing the performance of other classes of workloads people want to run on arm64. If there are some representative tests we should be looking at, please let me know. So, this is the obvious concern, and it only makes logical sense that many workloads will perform better with a smaller page size, as if you don't actually need the giant loads, you'll be flushing fewer caches for nothing. But, I'll put my money where my mouth is and see if I can find benchmarks to back up that hand-waving. I'm not sure how much interest there is for ARMv7 compat in Ubuntu. There is the developer use case of using the same hardware for armhf and arm64 porting - which, theoretically, we could also achieve by rebuilding those ports w/ an updated binutils. But otherwise, I'm not aware of many legacy ARMv7 apps that users are likely to want to bring over to Ubuntu/arm64 that couldn't be rebuilt. So, retroactively rebuilding all our already released dists is clearly not an option, and I hadn't even thought about this armv7 compat issue. This does impact our previous master plan for scrapping our armv7 build infrastructure and building armhf on arm64 in chroots, like we do for all our other 64/32 port pairs. Now, if qemu-system-arm --enable-kvm happens to work on arm64 (with 64k pages), this might be a non-issue, as we can run fully accelerated v7 VMs on our v8 kit, and that would serve just as well as 32-on-64 with chroots. Is that possible? Does it work today? If not, is there any one working on making it work? There appears to be work to address 32-on-64 KVM upstream, but it does not work today. While testing this I discovered a (very likely platform-specific) issue on my test system that causes kvm to fail to init on 64K hosts. I'll investigate that in the background. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] CONFIG_ARM64_64K_PAGES=y for vivid?
On Mon, Dec 15, 2014 at 05:36:25PM -0700, Dann Frazier wrote: We've measured significant performance improvements for several benchmarks by using 64K pages (SPECint, sysbench mysql, and kernel compiling)[*]. I'd therefore like to discuss whether or not we should switch to 64K pages in vivid. There's the question of whether or not we would be penalizing the performance of other classes of workloads people want to run on arm64. If there are some representative tests we should be looking at, please let me know. There are arm64 cell phones; I suspect the workload on a cellphone is different enough from a server workload that it should be tested as well. The end results may indicate 64k pages are a win everywhere or they may indicate a need for two arm64 flavours when we eventually target higher-end phones. Sorry, I can't recommend any benchmarks that would simulate the cellphone workload. Thanks signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: openssl performance delta built-in vs custom compiled
On ven, 2014-12-12 at 23:53 +0100, Marcus Pollice wrote: I'd be grateful if someone could point out the reason for the difference and also how to compile binaries to achieve the same performance. I know nothing about openssl in particular, but you may see improvements simply due to the flags you have used to compile it. The binaries shipped in Ubuntu must meet the lowest common denominator, that is they can't use any processor specific optimisations, otherwise the binaries would not run on all computers. For example, on my Gentoo machine everything is compiled for my specific processor model, meaning it uses various SSE and other processor specific instructions. There are also optimisations that may not be enabled on the Ubuntu builds for various reasons. For example, I use -fomit-frame-pointer which provides optimisations, but is probably not used in Ubuntu as debugging an application compiled this way is extremely difficult. Another is setting the optimisation level to 3 (-O3), this again would make it faster, but will cause some programs to malfunction, and developers typically don't allow bug reports if you've used this level. You can read more about the most common options here: http://wiki.gentoo.org/wiki/GCC_optimization If you want to have everything optimised to your system, you may want to consider using Gentoo, you can set the flags you want to use when compiling, then whenever you install a program (akin to apt-get install) it will download the source and compile it to your specification. signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: openssl performance delta built-in vs custom compiled
On mar, 2014-12-16 at 15:31 +, Sam Bull wrote: On ven, 2014-12-12 at 23:53 +0100, Marcus Pollice wrote: I'd be grateful if someone could point out the reason for the difference and also how to compile binaries to achieve the same performance. Nevermind, I just realised the performance you're seeing is the other way round. I've no idea why Ubuntu's would be faster, that is strange. signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [Ubuntu-phone] Feedback and Bug App
Let me play devil's advocate here. This isn't because I think it's a bad idea (I think we need more feedback, in general), but because I think this proposal needs a bit of tightening to give us a worthwhile product. Firstly, I don't see anything here that requires an app. All of this could be done on a website. Once you have a website, you can make a webapp for Ubuntu very easily. If there's a reason this has to be an app, that should be clarified. On Tue, Dec 16, 2014 at 4:30 PM, Alexander Langanke alexlanga...@googlemail.com wrote: This would be a Blog updated (for example) once or twice a month announcing the most important changes that have landed so far in order to draw attention to them and encourage feedback on these topics. Of course this could also be used to just keep the community informed in general. I would love to see the different teams updating here regularly. For example I have read about an upcoming Blog for Unity that is to be created in the near future, would love to get updates on Unity Next, the Phone, Ubuntu TV etc. without checking different sites. I'm confused about what exactly would appear on this blog. If it's only updated once every two weeks, it's not going to be go-to reading for anyone. I'd wait for these posts to be syndicated on Planet Ubuntu. If it's supposed to be aggregating a bunch of blogs, isn't that what Planet Ubuntu is already doing? 2. Missions This is a place where Core Developers and perhaps any other developer (not sure on that yet) can post small things they specifically want users to check out, test and give feedback on. Here we are looking for Feedback in terms of quality and not quantity. See Mockup Image. 3. Polls A place where we can gather feedback in a quantifiable sense. How many people like the new iconsets? How many people think Unity Next should have Windows on the Desktop etc. You get the picture.. See Mockup Image. The Ubuntu App Developers community on Google+ is already used for this purpose. What does this offer that Google+ does not? I'm also skeptical of the usefulness of polls with self-selected respondents. They tend to tell you only what people who feel strongly about an issue think, which may not be the same as what most people think. 4. General Feedback Here a User can select different official Ubuntu Flavors, Topics and Packages/Projects to give feedback on or send in an Idea without the need of a Mission or Poll. Why would this work any better than the now-defunct Ubuntu Brainstorm site? Where would this information go? As a developer, I rather have bugs and feature requests on my issue tracker, rather than on some external site. Thanks, Robert -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
