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 , 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 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 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 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 > 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
