Ubuntu QA Tracker: New build notification [20110426.1]
You are receiving this email because you have been subscribed to the following test case: Ubuntu Studio Alternate amd64 [20110426.1]: http://iso.qa.ubuntu.com/qatracker/info/5721 Install (auto-resize): http://iso.qa.ubuntu.com/qatracker/result/5721/226 Install (entire disk with encryption): http://iso.qa.ubuntu.com/qatracker/result/5721/225 Install (entire disk): http://iso.qa.ubuntu.com/qatracker/result/5721/227 Ubuntu Studio Alternate i386 [20110426.1]: http://iso.qa.ubuntu.com/qatracker/info/5722 Install (auto-resize): http://iso.qa.ubuntu.com/qatracker/result/5722/222 Install (entire disk with encryption): http://iso.qa.ubuntu.com/qatracker/result/5722/221 Install (entire disk): http://iso.qa.ubuntu.com/qatracker/result/5722/223 Please report any bugs you identify in Launchpad and report on the success or failure of the test in the tracker: https://launchpad.net/ubuntu/ Please see the testing team wiki pages for for further information: https://wiki.ubuntu.com/Testing For questions about the procedure or to coordinate testing, please join #ubuntu-testing on freenode. Thank you for helping us to test Ubuntu. -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
Re: [Oneiric-Foundations-Topic] Boost Defaults
On Tuesday, April 26, 2011 05:51:05 AM Matthias Klose wrote: On 04/26/2011 04:47 AM, Scott Kitterman wrote: On Saturday, April 23, 2011 06:26:27 AM Matthias Klose wrote: On 04/14/2011 06:28 PM, Scott Kitterman wrote: This should get done before UDS, during toolchain upload (i.e. before the first autosync), but I think it's worth mentioning. The current Boost that's default and in Main is 1.42. Debian's current default is 1.46. My proposal for Oneiric is that we switch our default/Main version to 1.46 at the start of Oneric development and then in Debian updates their default prior to feature freeze, we'll assess where we are and decide if we should stay with 1.46 or advance. whatever version you do choose, please make sure it does build with GCC 4.6. Please update the gcc-defaults in the toolchain PPA in Natty to be newer than the one in natty itself and I'll check it out. See https://lists.ubuntu.com/archives/ubuntu-devel/2011-April/033042.html Is there something missing? Thanks. I looked in the wrong PPA. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu Kernel Team Meeting Minutes - 2011-04-26
= Meeting Minutes = [[http://irclogs.ubuntu.com/2011/04/26/%23ubuntu-meeting.txt|IRC Log of the meeting.]] BR [[http://voices.canonical.com/kernelteam|Meeting minutes.]] == Agenda == [[https://wiki.ubuntu.com/KernelTeam/Meeting#Tues, 26 Apr, 2011|20110426 Meeting Agenda]] === Release Metrics === Release Meeting Bugs (15 bugs, 6 Blueprints) Release Milestoned Bugs (21 across all packages (down 31)) * 1 linux kernel bugs (down 1) * 0 linux-ti-omap4 bugs (no change) * 0 linux-meta-ti-omap4 bug (no change) Release Targeted Bugs (272 across all packages (up 36)) * 38 linux kernel bugs (up 4) * 16 linux-ti-omap4 bugs (up 14) * 0 linux-meta-ti-omap4 bug (no change) Milestoned Features * 6 blueprints (Including HWE Blueprints) Maverick Updates Bugs * 5 Linux Bugs (no change) Lucid Updates Bugs * 16 Linux Bugs (up 1) Bugs with Patches Attached:87 (down 5) * [[https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on | Bugs with Patches]] * [[http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/ | Breakdown by status]] === Blueprints: Natty Bug Handling === All items completed or postponed === Status: General Natty === The kernel remains frozen for the Natty release. We now have 2.6.38.4 pending for SRU. We do have some desirable fixes pending and we likely would like an early SRU if possible. === Status: Stable Kernel Team === We are not currently in a normal SRU kernel cycle due to allocation of testing resources to Natty. There are new kernels for Hardy, Lucid, and Maverick which need verification. BR BR The Dapper kernel which is in -proposed will not be released. Instead, the stable kernel team will prepare one final Dapper kernel by the end of this week. === Security bugfix kernels - Maverick/Lucid/Karmic/Hardy/Dapper === || Package|| Upd/Sec || Proposed || TiP || Verified || |||| || || || || || dapper linux-source-2.6.15 || 2.6.15-57.94 || 2.6.15-57.95 ||0 ||0 || |||| || || || || || hardylinux || 2.6.24-29.88 || 2.6.24-29.89 ||0 ||0 || |||| || || || || || karmic linux-ec2 || 2.6.31-308.28|| 2.6.31-308.29||1 ||1 || || --- linux || 2.6.31-23.74 || 2.6.31-23.75 ||1 ||1 || |||| || || || || || lucidlinux-ec2 || 2.6.32-314.27|| 2.6.32-316.30||8 ||6 || || --- linux-ports-meta || 2.6.32.31.23 || 2.6.32.32.24 ||0 ||0 || || --- linux-meta-lts-backport-maverick || 2.6.35.25.36 || 2.6.35.28.37 ||0 ||0 || || --- linux-lts-backport-maverick || 2.6.35-25.44~lucid1 || 2.6.35-28.50~lucid1 || 13 || 13 || || --- linux-backports-modules-2.6.32|| 2.6.32-31.31 || 2.6.32-32.32 ||0 ||0 || || --- linux || 2.6.32-31.61 || 2.6.32-32.62 ||4 ||2 || || --- linux-meta|| 2.6.32.31.37 || 2.6.32.32.38 ||1 ||0 || || --- linux-meta-ec2|| 2.6.32.314.15|| 2.6.32.316.17||0 ||0 || |||| || || || || || maverick linux-ports-meta || 2.6.35.28.21 || 2.6.35.29.22 ||0 ||0 || || --- linux-backports-modules-2.6.35|| 2.6.35-28.20 || 2.6.35-29.21 ||0 ||0 || || --- linux-meta|| 2.6.35.28.36 || 2.6.35.29.37 ||0 ||0 || || --- linux-firmware|| 1.38.6 || 1.38.7 ||1 ||0 || || --- linux || 2.6.35-28.50 || 2.6.35-29.51 || 11 ||5 || |||| || || || || === Incoming Bugs: Regressions === Incoming Bugs 934 Natty Bugs (up 17) 1129 Maverick Bugs (down 136) 1022 Lucid Bugs (down 53) Current regression stats (broken down by release): regression-update * 41 maverick bugs (down 6) * 74 lucid bugs (down 3) * 4
Re: [Oneiric-Foundations-Topic]Python Goals
On 04/26/2011 08:50 PM, Barry Warsaw wrote: Apologies for the long delayed response. On Apr 01, 2011, at 01:11 PM, Scott Kitterman wrote: On Friday, April 01, 2011 12:58:37 PM Barry Warsaw wrote: Agreed. Can you elaborate on what experimental support for Python3 as the Python that is shipped on the various Ubuntu ISOs means to you? Does that mean no Python 2.7 on the ISO? Also, by experimental do you mean having a process for creating alternative CDs that have only Python 3.2 but not on the standard daily CDs? There is a lot of Python code in the Ubuntu insfrastructure. I'm not sure exactly what I meant by that, but here's an example: Ubiquity is written in Python. It's a reasonably complex program that is non- trivial to maintain and improve. It's also mission critical for Ubuntu. I would be really suprised if it was fully ported with no regressions in one cycle. In this case, I think experimental support would be a python3 branch that ~works, but may not be fully tested/have issues/or not be at feature parity so we wouldn't want to switch to it in the oneiric cycle. The goal would be to have it be mature enough during oneiric that in the P cycle we could switch to it early and have it land ~smoothly for the LTS. I know there are others. My impression is that most upstreams for core desktop packages support Python3. Mostly what we lack is packaging changes to support it. My expectation is that most of the challenge around a Python3 desktop in P will be around more peripheral modules/extensions and custom Ubuntu code. That shouldn't preclude shipping some Python3 stuff in oneiric if it's ready and we've got room on the relevant image. Does that help? It does, thanks. I wonder, with work going on in Launchpad to support derivatives, can we pervert that to create a Python 3 Ubuntu derivative that could be used for this experiment? It may not be fully functional, but I think it would be a great test and status tracker for how well our Python 3 efforts are going. which packages are affected, and what work is needed to get these packages even built? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Request to upgrade the assaultcube package in Multiverse Repository
On 2011-04-24 23:54, Rafael Barreto wrote: Hello fellows, Sorry for my bad english. This is the second time we try to call your attention over this same old issue. The assaultcube version provided by your repository (1.0.4repack1-1) is *unplayable*, since our 1.0 masterserver was turned off almost one year ago. Please, we would like to know if we are responsible for packaging an upgrade for you. If so, please reply this mail providing us some instructions to create and send the proper package. We apologize our ignorance. Also we would like to request to you to remove the outdated package from your repository as soon as possible. Thank you in advance. Best regards Brahma Visit our main site: http://assault.cubers.net Interact with us: http://forum.cubers.net Follow the development: http://sourceforge.net/projects/actiongame Hi Brahma and thanks for raising the issue. You're not responsible for providing packaging, but since Debian - where this game is packaged originally - is made up of volunteers, they might not have had the time/priority to deal with this issue. If I were you, I'd write an email to the Debian Games Team pkg-games-de...@lists.alioth.debian.org, and ask them if they need assistance, and if there is anything that can be done to speed up the process of updating accaultcube to a new version in Debian. You can also point them to this bug which is probably the same as what you're talking about: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604109 That is, unless the collective mind of this mailinglist has a better idea :-) -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic -- 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: [Oneiric-Foundations-Topic] networked client app updates
On Thu, 2011-04-21 at 16:32 +0100, Alan Pope wrote: On 21 April 2011 16:14, Allison Randal alli...@canonical.com wrote: - Only ship a very small shim for the client on the CD (advantage of small footprint), and do the rest of the install the first time someone uses Ubuntu One. This is what dropbox does albeit a download and not on CD, and it seems to work nicely. You end up with a boatload of statically linked libraries in ~/.dropbox-dist as a result though. I don't know if you'd look to let the shim install a deb or do a similar think to dropbox, but whatever you do, make it Just Work. That's one significant advantage dropbox has over Ubuntu One. OK, so let's start off by not making comparisons of U1 and Dropbox, because they are completely different, even on the conceptual level. Ubuntu One does provide file synchronization, but it is not the only thing the product is about. The Dropbox download and install this one deb bit sort of works for what they do, because they ONLY provide file synchronization. They provide a single extension for a single file manager, and when you restart that file manager after installing, you get pretty much all the Dropbox UI you will ever see. The tray icon/indicator, preferences, file manager integration, and setup wizard, are all in this one plug-in for Nautilus. When you sign in, it then downloads this huge tarball of proprietary stuff, extracts it in a dot directory, and starts syncing your files. Ubuntu One on the other hand, is a suite of services, and a platform for extending applications with services, built into the Ubuntu experience. There is no single entry point into Ubuntu One in the Ubuntu workspace; and some of our software is used by other core parts of Ubuntu itself (like Software Center). We don't ship a single plug-in for a core GNOME component that is on every GNOME-based Linux distribution. We ship lots of software, with plug-ins for lots of different types of applications, in lots of different languages: - gnome-settings-daemon (C) - nautilus (C) - evolution-data-server/evolution (C) - rhythmbox (python) - banshee (in upstream, C#) - ubuntu-sso-client (used by Software Center, and anything using U1) - firefox (XUL/JS) There are also some applications which ship (or will be shipping) code that talks to U1, which are in Ubuntu themselves, as well: - deja-dup (Vala) - shutter (PERL) - shotwell (Vala) There has also been some work to get extensions written for Chrome and Thunderbird, to support synchronizing contacts and bookmarks on U1. And there is always constant talk of providing different types of services in U1, as well as what applications to extend or write to provide additional data synchronization features through U1, within Ubuntu. So you can see where Dropbox's seemingly simple solution, is nowhere near as feasible for Ubuntu One to implement. 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: Request to upgrade the assaultcube package in Multiverse Repository
Rafael Barreto schreef op zo 24-04-2011 om 18:54 [-0300]: This is the second time we try to call your attention over this same old issue. When was the previous time? (Do you have a reference?) The assaultcube version provided by your repository (1.0.4repack1-1) is *unplayable*, since our 1.0 masterserver was turned off almost one year ago. [...] Also we would like to request to you to remove the outdated package from your repository as soon as possible. Is it really unplayable, or can people still run their own server? Please, we would like to know if we are responsible for packaging an upgrade for you. If so, please reply this mail providing us some instructions to create and send the proper package. We apologize our ignorance. As David Henningsson explained, Ubuntu imports most packages directly from Debian, so fixing this in Debian will also fix it for the next Ubuntu version. I suppose this issue is (at least in part) the result of an unfortunate combination of incompatible release cycles though. Debian focussing on getting a release out every 2-3 years (and not having a focus on games during the last part of that cycle), Ubuntu focussing on 6-month release cycles (but being based on Debian) and you having your own release tempo. I wonder if it's possible to create a games repository for Ubuntu that has somewhat different rules from the existing repositories... (or maybe your game can be removed from the official repositories and moved into the extra repositories to make it easier to follow your release schedule). PS: I don't have anything to say about this, just trying to help you, your project *and* Ubuntu... :) -- Jan Claeys -- 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: [Oneiric-Foundations-Topic] networked client app updates
John Rowland Lenton schreef op do 21-04-2011 om 18:23 [+0100]: * recently we had to upgrade couchdb in lucid for replication to work, and the upgrade broke replication with the old version (which was the reason we needed to upgrade), as well as potentially breaking couch apps that only worked with the older version. What we ended up doing was putting the fix in backports as the less onerous of the non-world-breaking options we had. Wasn't it possible to make the new U1 client(s) depend on a new package 'couchdb-for-u1' (just an example name) which installs in a different location/namespace and doesn't interfere with the LTS version of it? -- Jan Claeys -- 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: [Oneiric-Foundations-Topic] networked client app updates
Jan Claeys li...@janc.be wrote: John Rowland Lenton schreef op do 21-04-2011 om 18:23 [+0100]: * recently we had to upgrade couchdb in lucid for replication to work, and the upgrade broke replication with the old version (which was the reason we needed to upgrade), as well as potentially breaking couch apps that only worked with the older version. What we ended up doing was putting the fix in backports as the less onerous of the non-world-breaking options we had. Wasn't it possible to make the new U1 client(s) depend on a new package 'couchdb-for-u1' (just an example name) which installs in a different location/namespace and doesn't interfere with the LTS version of it? Code copies complicate security support and post release maintenance. It's not forbidden, but definitely discouraged. Scott K -- 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: [Oneiric-Foundations-Topic] networked client app updates
On Tue, 2011-04-26 at 20:09 +0200, Jan Claeys wrote: John Rowland Lenton schreef op do 21-04-2011 om 18:23 [+0100]: * recently we had to upgrade couchdb in lucid for replication to work, and the upgrade broke replication with the old version (which was the reason we needed to upgrade), as well as potentially breaking couch apps that only worked with the older version. What we ended up doing was putting the fix in backports as the less onerous of the non-world-breaking options we had. Wasn't it possible to make the new U1 client(s) depend on a new package 'couchdb-for-u1' (just an example name) which installs in a different location/namespace and doesn't interfere with the LTS version of it? Possible? Probably. Easy? Certainly not. The difficulty in dealing with a custom couchdb package, for only one stable release that's already out there, was just not worth the trouble it would cause. 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: [Oneiric-Foundations-Topic] networked client app updates
On Thu, 21 Apr 2011 18:23:52 +0100, John Rowland Lenton john.len...@canonical.com wrote: * if our projects switch to, say, python 4, then we'd be looking at shipping python 4 to all supported ubuntus, including LTS'es. I can see why you would want to do this for ease of support, but it's common for projects to support several versions to avoid this requirement. In addition, making a change like this would likely have effects far beyond u1, in order to allow u1-on-lts to use a Python version that may not have been available when it was released. * it's easy to imagine scenarios where we'd want to ship updated versions of rhythmbox, banshee or nautilus (and/or any newer application that integrated with our apis). Much more commonly we'd want to update plugins to those apps. Why would you want to upgrade the apps themselves? This seems to be getting away from what I thought was the original question in the discussion, and in to the more general territory of wanting to push new stuff in to released versions, and perhaps it is worthwhile to separate those discussions if possible? the thing we need is to have as much feature parity as is possible across all the platforms we support, This seems to be a core point of contention. Perhaps you could explain why feature parity across versions of Ubuntu is important to your team. As I understood the original question it was how to update client code to keep it in sync with changes that the server makes. It would be possible to do that in order to keep old features working and not enable new features on the old releases. A desire to push new features in to old releases is valid, but seems to be a different question to me, and not one that has a lot to do with the code in question being a networked service client. Thanks, James -- 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: Request to upgrade the assaultcube package in Multiverse Repository
Hey! Ty for your replies! I did not sent a mail to Debian Games yet, but after considering a bit, maybe removing (or moving) the game from the current repository is the quickest (and dirty) solution to avoid new confuse players. And yes, the 1.0 is not playable in multiplayer (you can create your server, but there is no masterserver to register it). -- 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: [Oneiric-Foundations-Topic] networked client app updates
On 04/26/2011 11:53 AM, James Westby wrote: On Thu, 21 Apr 2011 18:23:52 +0100, John Rowland Lenton john.len...@canonical.com wrote: * if our projects switch to, say, python 4, then we'd be looking at shipping python 4 to all supported ubuntus, including LTS'es. I can see why you would want to do this for ease of support, but it's common for projects to support several versions to avoid this requirement. In addition, making a change like this would likely have effects far beyond u1, in order to allow u1-on-lts to use a Python version that may not have been available when it was released. This is where the /opt/.../UbuntuOne/... install location comes into play for dependencies. Simply using backports means the updated library/tool affects the entire system, which is likely to be a nightmare. Installing a version in /opt, which only one app can find, is safer. My gut reaction is that installs of dependencies in /opt should be very rare, and paved with warnings to the app developers of You understand that you are *personally* responsible for this version of the library you're installing with your app? And it darn well better not leak out into the rest of the system! But, it does fit with general Linux development practices in the wider world. * it's easy to imagine scenarios where we'd want to ship updated versions of rhythmbox, banshee or nautilus (and/or any newer application that integrated with our apis). Much more commonly we'd want to update plugins to those apps. Why would you want to upgrade the apps themselves? This seems to be getting away from what I thought was the original question in the discussion, and in to the more general territory of wanting to push new stuff in to released versions, and perhaps it is worthwhile to separate those discussions if possible? This is a cost/benefit question. Chances are it's very expensive to do the integration and maintenance work on non-standard versions of all those apps, and much less expensive to maintain multiple variants of the plugins. But, it's appropriate to consider the problem on both sides as we work our way toward the best solution. the thing we need is to have as much feature parity as is possible across all the platforms we support, This seems to be a core point of contention. Perhaps you could explain why feature parity across versions of Ubuntu is important to your team. As I understood the original question it was how to update client code to keep it in sync with changes that the server makes. It would be possible to do that in order to keep old features working and not enable new features on the old releases. A desire to push new features in to old releases is valid, but seems to be a different question to me, and not one that has a lot to do with the code in question being a networked service client. The key feature of a lightweight client app like this is the ability to connect to the remote service. It is possible to maintain 5 versions of U1 client that each implement the latest connective features, but depend on only the versions of various libraries/tools available in each supported distribution. That's one for (to take a snapshot today): - Natty, the upcoming release - Maverick, the current release - Karmic, the soon-to-be-removed non-LTS release - Lucid, the current LTS release - Hardy, the soon-to-be-removed LTS release And, it might even be reasonable to ask the U1 team to continue with this rather hefty maintenance burden perpetually, since they happen to be backed by a company that deeply believes in the Ubuntu release cycle. I'm not so sure it's reasonable to ask other developers of other networked client apps to carry similar maintenance burdens. Or at least, we can ask them to, but they're perfectly free to say No thanks, we just won't bother with an Ubuntu version. Or, they'll do what Dropbox does, and just maintain their own pirate radio repository just for their client app, completely avoiding the standards and quality control Ubuntu has in place for repositories. That's not necessarily a bad thing, there's always room for the chaos of evolution. But, the fact that we have multiple projects all stumbling around the same problem also means this is an opportunity to be opinionated, solve the problem once in a way that really fits with Ubuntu, and set an example in U1 for the best way to implement updates for a networked client app on Ubuntu. There are definite advantages to a clean set of thoughtfully developed standards. Allison -- 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
