Re: Proposing a New App Developer Upload Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/03/2012 04:03 PM, Philipp Kern wrote: David, am Mon, Sep 03, 2012 at 07:59:15PM +0200 hast du folgendes geschrieben: * Review the spec at https://wiki.ubuntu.com/AppDevUploadProcess what happens in case of a namespace conflict with Debian? Given that apps are not only in dpkg's namespace of all installed applications, as they also refer to paths within /usr. Can a package in Ubuntu be updated through this process? Will a package that appears in Ubuntu proper supersede the application submitted through this process? Will the version for use by apt and dpkg be prefixed, so that it does not collide? (I see todo items referencing a version numbering scheme, but I don't see it spelled out at first glance.) Kind regards Philipp Kern Apps already in the archives won't be eligible for this process. We don't have any requirement on version prefixing, the work items are there to make sure quickly and the lintian profile are using the normal version numbering scheme. Michael Hall mhall...@ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBCAAGBQJQRUBSAAoJEInUYcGJgfVyTnEP/AsTbp5pNMHb2Hl4K3MVzuL6 ZuOxMDUI03xRjXxI2YzGj1fIM0ClYXfry0PZb78jy4/F952hoqDa0rbB33dRiKcL AQgADPQ1zVAVzP5U7celPQm0zAMO9BjkdN2DkNK0TdzlJfxjHnlxxnq4f+9YBQS8 k+ksnOU3W/UAkoFShGoZeB3GyAy0IjmmXqO/PDh/PALi+tev4u3ohr7IY1G5NHkg 2L+V8rNMvtJzrPPl5dyVO56Jzp2p14swrGFgrhcAa5cdxG7MrjnE+jfzyyckoIhu VJbXvIMg7SRGQkyuMPYyH/f9U2hqA0LKNdhKd4igz44vlV56+z5GfUOjyZDgaxg5 7mAeidfxmW2tjKmvhgAdge7atEXEXAF4lM3SejrQ5Cm3BUQWIJFHAJV7aHXlw4pu ZVjxHwPhqXZeKAukzxdRXMBCHZHqHnozlPr1PbYtzuHOnXM7d59y1XTQh1+kOh3B +AEFTgA7BjzBjN/bHi8pBjxk90v0OeA99xdTpaAh5kauXgJdP9glTV7MfYCRCZeu QkAC3iwkAPYPYL5MW6+5/gqbcePC5cFh22eEg9k58jmpWlBUm4b7zWT1kOYIx1W9 T1V4wPVCNit17E2ct9vkM9eF1oLTGBzYB9HYoVK1mAXsOEA7UejIInqvJKRbtSL2 i6L2sJP08BUOeUNP1zJZ =vPcq -END PGP SIGNATURE- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On Mon, Sep 03, 2012 at 07:42:14PM -0400, Michael Hall wrote: On 09/03/2012 04:03 PM, Philipp Kern wrote: am Mon, Sep 03, 2012 at 07:59:15PM +0200 hast du folgendes geschrieben: * Review the spec at https://wiki.ubuntu.com/AppDevUploadProcess what happens in case of a namespace conflict with Debian? Given that apps are not only in dpkg's namespace of all installed applications, as they also refer to paths within /usr. Can a package in Ubuntu be updated through this process? Will a package that appears in Ubuntu proper supersede the application submitted through this process? Will the version for use by apt and dpkg be prefixed, so that it does not collide? (I see todo items referencing a version numbering scheme, but I don't see it spelled out at first glance.) Apps already in the archives won't be eligible for this process. We don't have any requirement on version prefixing, the work items are there to make sure quickly and the lintian profile are using the normal version numbering scheme. Hm, you dodged the issue of an app getting added to Debian/Ubuntu proper. Will you forbid epochs so that people cannot do something silly? Kind regards Philipp Kern 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: Proposing a New App Developer Upload Process
On 04/09/2012 05:50, bvidinli wrote: previously I had prepared package for Ubuntu, for my software. However, software was being denied by ubuntu people with the cause program touches system files. This reason was really interesting. My software Does touches system files, its job is to do so... my program is not in Ubuntu repos since 4-5 years, but it is being used since 6 years in ubuntu community, server admins, through classic install.sh installation, not apt-get command, since its package was not approved by package maintainers + ubuntu package preparation steps was too complicated There probably is more to this picture, but it is really hard to look into what really happened if you do not even name the software in question. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Simple but worthwhile to fix bugs?
Hello everybody, we recently had a quick conversation in #ubuntu-devel about how to get new people involved in Ubuntu development. Ideally we'd offer something like this: - Contributor finds good instructions. - Also a few simple things to work on, giving them a nice experience fixing things and they feel they accomplished something. - Their fixes get accepted quickly. - They progress to new and more exciting things. So far the theory. What we set up is https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative and we have a few merge proposals in the sponsoring queue already. While we tried to make it clear that Ubuntu-only fixes should go into sponsoring and Debian package fixes should go to Debian, some ended up in the queue, which sparked the discussion. In an attempt to make things even clearer, I wrote an article for the packaging guide, which I'd love to get feedback on: https://code.launchpad.net/~dholbach/ubuntu-packaging-guide/1045396/+merge/122552 Another question is: what kind of fixes do we want new contributors to work on? How simple is too simple? Are we afraid of typo fixes piling up in the queue? My personal take on this is that we should be able to review them pretty quickly and that some additional work is an effort we should definitely put into this, to give new contributors a nice experience. Feedback and suggestions very much appreciated. Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging And follow @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On Tuesday, September 04, 2012 02:32:04 PM David Planella wrote: Al 04/09/12 13:06, En/na Scott Kitterman ha escrit: On Monday, September 03, 2012 07:59:15 PM David Planella wrote: Hi everyone, As many of you will know, in the last few cycles we've been laying out the foundations to make Ubuntu a target of choice for app developers. I am not referring to building the platform here (an area in which we also keep seeking growth), but rather to enabling app authors to create and distribute original software, to grow a rich ecosystem of independent apps for our users. The resounding success of our latest initiative, the Ubuntu App Showdown, has not only shown an explosion of high-quality applications (created in just 3 weeks!), but more importantly, the growing interest in developing applications for Ubuntu. As we continue building upon these foundations, we also keep on refining our processes to identify and improve areas in which we can provide a better experience for app developers. While doing this, we've been gathering metrics from different sources –the current queue of apps pending review and the Showdown results being the main ones. They all provide clear evidence: the current approach to submit third-party apps in the Extras repository has already reached the limit in terms of human review capability and application throughput. Despite our best intentions and the Ubuntu App Review Board's epic efforts, we're currently putting a strain on reviewers (who cannot keep up with the incoming stream of apps) and providing an unsatisfactory experience for app authors (who have to endure long delays to be able to upload their apps). During the course of the last few weeks, after having identified the key issues and assessed the different options available, Jono Bacon, Michael Hall and myself have been working to put forward a proposal for a new, improved app developer upload process. We've been not alone in this project: we've had the input and help from many others, including the App Review Board and members of many other Ubuntu and Canonical teams (Security, Foundations, Desktop, Consumer Apps, just to name a few). We are now at a point where we consider the spec to be ready for public review and comment, and we would like to ask for your own contribution to this process. Ultimately, the goal is to discuss and scope the new app developer upload process at UDS, but we would like to have a solid specification to be used in advance as the basis for any UDS sessions and blueprints. If you'd like to contribute, you can: * Review the spec at https://wiki.ubuntu.com/AppDevUploadProcess * Provide any feedback either on the Feedback section (preferred) or continue the discussion on this thread. As the people who create Ubuntu, your input is especially valuable, and we'd really appreciate it if you could spend some of your time to help app development in Ubuntu succeed. I understand the goal of this and why it's the direction those interested in making it easier to provide non-Ubuntu apps want things to go. It's not at all surprising that the volunteer reviewers were insufficient, since that's always been the case for new Ubuntu packages as well. I do think the proposal misses a few points though. The purpose of /opt was not only to limit the access that these apps to the rest of the file hierarchy, it was also to make sure that files provided by these apps could not be in the path of Ubuntu packages and to avoid namespace contamination, particularly in /usr/bin. This proposal addresses neither of those points, so I think it's inusufficient as it stands. Thanks Scott for the feedback. This is indeed a good point and something that we've discussed, but I agree that we should better flesh it out in the spec. However, I disagree in that we're not addressing neither of the points. For 1. (limiting access to the rest of the file hierarchy) the proposal covers a mechanism for whitelisting a well-known set of file system installation locations [1]. It is only additional security in terms of installation of system files in the same sense /opt did. Actual access to the filesystem is limited through sandboxing, which is the main improvement over the /opt approach. As per 2. (file system conflicts), we're mentioning: will [...] rely on [...] file path conflict checking on the archive side And I think you're right in that that part needs further development. In the past, we've discussed a couple of approaches to detect file system conflicts [2]. They were mainly concerned with scanning the file contents of packages from different archives, comparing them and detecting the conflicts. For the scanning part, we've already got an example on packages.ubuntu.com (reads the Contents.gz file from the archive and stores the info on a database). Any input on these
Re: Proposing a New App Developer Upload Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/04/2012 04:12 AM, Philipp Kern wrote: On Mon, Sep 03, 2012 at 07:42:14PM -0400, Michael Hall wrote: On 09/03/2012 04:03 PM, Philipp Kern wrote: am Mon, Sep 03, 2012 at 07:59:15PM +0200 hast du folgendes geschrieben: * Review the spec at https://wiki.ubuntu.com/AppDevUploadProcess what happens in case of a namespace conflict with Debian? Given that apps are not only in dpkg's namespace of all installed applications, as they also refer to paths within /usr. Can a package in Ubuntu be updated through this process? Will a package that appears in Ubuntu proper supersede the application submitted through this process? Will the version for use by apt and dpkg be prefixed, so that it does not collide? (I see todo items referencing a version numbering scheme, but I don't see it spelled out at first glance.) Apps already in the archives won't be eligible for this process. We don't have any requirement on version prefixing, the work items are there to make sure quickly and the lintian profile are using the normal version numbering scheme. Hm, you dodged the issue of an app getting added to Debian/Ubuntu proper. Will you forbid epochs so that people cannot do something silly? Kind regards Philipp Kern If the app is added to Ubuntu proper (directly or from Debian) for a development release after it is already in Extras for a stable release, the Extras package will not be forward-copied to the development release and the developer will not be able to uploaded it to the development release. Michael Hall mhall...@ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBCAAGBQJQRflbAAoJEInUYcGJgfVyBvcP+wUcJpr2mmP2UpWuaQj0edzG wRiLMZ3ezU+L/cY18FqAvbs+wPr4QSjtOszDEstuRipVu+4/1Nxh9lSil1zco0Tl wUuBHjfFUANEBNEdYovoxgi47VcvWbRMvc5iY8HDrneS9U6vf7puOqiQgv61I5Sq H91evexTH4C4wLZgyDM3wBFNjmDeYI4KPaleRXFNPpsQdstLaNDrYs8PhZO3dmMH x9eEhLjOACKoeVRp64jrjbz2JHgZbl6RS7kIVEDh/cbaLMtI25/JbgNlZt0v0cxM R921OnF5RFK8MkeyaGtitCpo/tr/EIRobX9801f0Ebm43OZDW9kgJjYimQ/0pXia cKjTX8DnT6Qf1BtjcANyhduI3xg43ZwNmXjflq303NMT15DZ5l4BFhglnh9mHBxa 1cj0swRE91I+XGCmCwEISXt6NcYRsuT8L1btjrJ6xjqkM6gggCQoT+LT851MSmDJ hkPnVzQfaIoskqzALyP4wpLANhZHWqagolq8NEfVaPPRq3OAc5r8Ehvug00eifkq 4XmwYBB0aKeU+jLxSXM13B2jX7rZ/roxiQgIuE8pk8xowwqvP8+btwifOxF20+/J 6/s62FVj2qH0F//r4MPp8/CzzC/vfr7iEmAUAe9TRGSuWN5viJgiqS4m/UUGMCxe cI1nHlEC2e8nHQ2s3pkM =hm5K -END PGP SIGNATURE- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On 04/09/12 08:51, Michael Hall wrote: If the app is added to Ubuntu proper (directly or from Debian) for a development release after it is already in Extras for a stable release, the Extras package will not be forward-copied to the development release and the developer will not be able to uploaded it to the development release. What about the following scenario? We add an Extras package foo in precise. Then in quantal, we sync in some new, unrelated package foo from Debian that happens to share the same name. Now users that installed foo in precise that upgrade to quantal will be replacing their foo package with a completely unrelated one. I imagine the easiest way to avoid this is to namespace the package names too. (Though with namespaced packages, the user can end up in a weird situation if the Extras package foo does find its way into Debian and Ubuntu quantal. Then, they really do want the foo package from Debian but are left with the non-maintained extras-foo from precise.) -mt -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Michael Terry wrote: I imagine the easiest way to avoid this is to namespace the package names too. (Though with namespaced packages, the user can end up in a weird situation if the Extras package foo does find its way into Debian and Ubuntu quantal. Then, they really do want the foo package from Debian but are left with the non-maintained extras-foo from precise.) One way to work around these cases would be to have a transitional extras-foo in quantal-extras, which Depends: on foo, so that upgrading users would migrate from extras-foo to foo during the upgrade process. At some point the extras-foo package ought be removed from the system, but this is true for all the historical transitional packages, and so better handled as part of a general solution for that class of problem. -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On 04/09/12 10:12, Emmet Hikory wrote: Michael Terry wrote: I imagine the easiest way to avoid this is to namespace the package names too. (Though with namespaced packages, the user can end up in a weird situation if the Extras package foo does find its way into Debian and Ubuntu quantal. Then, they really do want the foo package from Debian but are left with the non-maintained extras-foo from precise.) One way to work around these cases would be to have a transitional extras-foo in quantal-extras, which Depends: on foo, so that upgrading users would migrate from extras-foo to foo during the upgrade process. At some point the extras-foo package ought be removed from the system, but this is true for all the historical transitional packages, and so better handled as part of a general solution for that class of problem. Good point. That's a way around the (likely not overwhelming) number of Extras packages that make it into Debian if we namespace the packages. So I'm even more certain that we should namespace the package names themselves. Without doing so, we can't really guarantee that the package won't switch completely out from under the user. We'd both be removing an app they thought they had as well as installing a package they didn't request (which could have quite bad side effects). -mt -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Hello, On 04.09.2012 15:28, Emmet Hikory wrote: The difficulty here is that there is uncontrolled scope for future conflict. While the Contents.gz file is useful (and the conflictchecker system more so), if both extras and backports are enabled by default, there is no means by which the review board can determine that a given filename will not be provided by a backport of a new package imported from Debian. The fairest solution to this problem would be to turn on a conflict-check-before-publish for all parts of the archive. This would help us find these (and pre-existing) issues immediately and resolve them amongst the maintainers and upstreams. My current expectation is only a very tiny fraction of uploads would get blocked due to this and the general amount of work to resolve them would be small too. The /opt requirement on the other hand unfortunately imposes a huge amount of work on 1) app developers because our tools don't work this way very easily and 2) Ubuntu maintainers who have to enable path lookups in tools which don't know about /opt yet. Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging And follow @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On 09/04/2012 09:39 AM, Scott Kitterman wrote: The problem isn't just with file conflicts with current packages, it's that these packages will now start using up distro namespace. If some app developer package ships the file /usr/games/bird-game, even though there's no current conflict, there is a package sync'ed from Debian that also ships /usr/games/bird-game then there's a conflict we have to resolve. In /opt in a proper vendor namespace this can never happen. If bird-game already exists in Extras, and then a different package is allowed into backports that will install files into the same location, then yes there is a possibility for a conflict. But I assume part of the backports approval process already checks for conflicts, as they may exist with another package in the stable release already, so that process could easily be extended to include Extras packages as well. A fairly contrived example derived from the above is if the Debian/Ubuntu package that shipped /usr/games/bird-game was in the archive and an app developer package was uploaded that shipped /usr/bin/bird-game, it could be run instead since /usr/bin precedes /usr/games on the standard user path. This would only happen if two different apps were both called bird-game but otherwise different. This situation is also possible already, even between two packages in Universe. How is that currently handled? maybe a Python based app ships an embedded copy of a module since they've tested with that version and don't want to test with the distro version and they write their setup.py to install it in /usr/local/lib/python2.7/dist- packages. Suddenly every user of that module is now using the app developer package version and not the distro version. Installing python modules in the system directories is not allowed under this process. Check the whitelist defined in the App Preparation section of the spec. Michael Hall mhall...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On Tue, Sep 4, 2012 at 10:21 AM, Michael Hall mhall...@ubuntu.com wrote: On 09/04/2012 09:39 AM, Scott Kitterman wrote: The problem isn't just with file conflicts with current packages, it's that these packages will now start using up distro namespace. If some app developer package ships the file /usr/games/bird-game, even though there's no current conflict, there is a package sync'ed from Debian that also ships /usr/games/bird-game then there's a conflict we have to resolve. In /opt in a proper vendor namespace this can never happen. If bird-game already exists in Extras, and then a different package is allowed into backports that will install files into the same location, then yes there is a possibility for a conflict. But I assume part of the backports approval process already checks for conflicts, as they may exist with another package in the stable release already, so that process could easily be extended to include Extras packages as well. I think people are more concerned with auto-import from Debian than backports. Debian's approval process knows nothing about Extras, so there is no mechanism or approval process that checks for conflicts. A fairly contrived example derived from the above is if the Debian/Ubuntu package that shipped /usr/games/bird-game was in the archive and an app developer package was uploaded that shipped /usr/bin/bird-game, it could be run instead since /usr/bin precedes /usr/games on the standard user path. This would only happen if two different apps were both called bird-game but otherwise different. This situation is also possible already, even between two packages in Universe. How is that currently handled? New Universe packages are pretty much handled by Debian, and while it is generally avoided there is occasionally a collision (see the node.js example above in this thread). The problem is that the proposal is introducing a mechanism for adding packages and files which our current mechanism (Debian NEW queue) knows nothing about, greatly increasing the possibility of collision. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Hi! On 04/09/2012 10:21, Michael Hall wrote: On 09/04/2012 09:39 AM, Scott Kitterman wrote: The problem isn't just with file conflicts with current packages, it's that these packages will now start using up distro namespace. If some app developer package ships the file /usr/games/bird-game, even though there's no current conflict, there is a package sync'ed from Debian that also ships /usr/games/bird-game then there's a conflict we have to resolve. In /opt in a proper vendor namespace this can never happen. If bird-game already exists in Extras, and then a different package is allowed into backports that will install files into the same location, then yes there is a possibility for a conflict. But I assume part of the backports approval process already checks for conflicts, as they may exist with another package in the stable release already, so that process could easily be extended to include Extras packages as well. In extras, all the package files (with a few exceptions like the debian changelog, copyright files, etc) gets installed under /opt. There are some exceptions for things like unity lenses and .desktop entries, but those are prefixed with extras- so that they are somewhat namespaced. Packages in backports aren't allowed to install under /opt, so the chance of a collision is very rare. It's possible for someone to have collision if they happen to have the same unity lens or desktop entry that happens to start with extras-, but at least that's something fairly unlikely and easy to check, maybe something that should be considered suggesting to Debian policy and added to lintian. Having two packages with colliding file names doesn't seem like it will be a big problem. From what I can tell it seems like it's more likely that a package would be introduced in Debian or Ubuntu at some point that is also in extras. So far, many of the apps in extras have *extremely* generic names. While reviewing apps for the app showdown competition, I checked whether these packages existed in Debian/Ubuntu first before +1'ing them and was surprised to see that none of these names have been used before. IMHO it would be reasonable to prefix something to extras packages to avoid a conflict, perhaps also have some policy updates that prohibits a package name starting with extras- (or whatever the prefix would be) in the archives. -Jonathan -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On 09/04/2012 10:45 AM, Scott Howard wrote: On Tue, Sep 4, 2012 at 10:21 AM, Michael Hall mhall...@ubuntu.com wrote: On 09/04/2012 09:39 AM, Scott Kitterman wrote: The problem isn't just with file conflicts with current packages, it's that these packages will now start using up distro namespace. If some app developer package ships the file /usr/games/bird-game, even though there's no current conflict, there is a package sync'ed from Debian that also ships /usr/games/bird-game then there's a conflict we have to resolve. In /opt in a proper vendor namespace this can never happen. If bird-game already exists in Extras, and then a different package is allowed into backports that will install files into the same location, then yes there is a possibility for a conflict. But I assume part of the backports approval process already checks for conflicts, as they may exist with another package in the stable release already, so that process could easily be extended to include Extras packages as well. I think people are more concerned with auto-import from Debian than backports. Debian's approval process knows nothing about Extras, so there is no mechanism or approval process that checks for conflicts. Since Extras package won't be in the development release until FeatureFreeze, we can check them against the new packages imported from Debian before we forward-copy them from the previous stable release. Michael Hall mhall...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Daniel Holbach wrote: On 04.09.2012 15:28, Emmet Hikory wrote: The difficulty here is that there is uncontrolled scope for future conflict. While the Contents.gz file is useful (and the conflictchecker system more so), if both extras and backports are enabled by default, there is no means by which the review board can determine that a given filename will not be provided by a backport of a new package imported from Debian. The fairest solution to this problem would be to turn on a conflict-check-before-publish for all parts of the archive. This would help us find these (and pre-existing) issues immediately and resolve them amongst the maintainers and upstreams. Completely independently of this discussion, this is a good idea, although we probably ought have the system respect Breaks, Conflicts, and Replaces, or we'll end up with lots of false positives. Mind you, given the vast number of reports from conflictchecker, it may be that we would want to put up a review system for some time to clean up the existing issues prior to actually blocking publication. That said, while I agree that such issues can be sorted between the various developers involved (perhaps easily, perhaps less so (see node)), I am much more concerned about the effect on users. Assume I'm using Ubuntu Desktop, and I add an extras application to the Dock. Now assume there is a namespace conflict for that application, which is resolved by the extras application taking a new name. Depending on what I happened to install on upgrade (as a new dependency of another installed package), my Dock entry may behave entirely differently. More generally, this may happen for startup programs, so that I would upgrade, reboot, and end up running something completely unexpected automatically, and I may not even notice if the automatic execution doesn't load a window, and just believe my upgrade broke (and potentially end up finding my computer slower, or behaving oddly, depending on what the new program happened to do). The /opt requirement on the other hand unfortunately imposes a huge amount of work on 1) app developers because our tools don't work this way very easily and 2) Ubuntu maintainers who have to enable path lookups in tools which don't know about /opt yet. Much of this can be avoided by allowing a common location for extras files, for example /opt/extras/bin, /opt/extras/applications, /opt/extras/pixmaps, etc. If these locations are only permitted to contain namespace-protected symlinks, then it can be a matter of adding one or two lines to the 8-12 tools that perform these sorts of discoveries. No, this isn't an ideal solution, but it significantly limits the effort required to support a separate namespace. For application developers who prefer standard locations, I don't see any reason we oughtn't simply add their packages to the repository with immediate backport: in addition to allowing application developers to put their files in any policy-compliant location, it automatically provides a safe upgrade path for users. Even for software with release cycles that require significantly more frequent updates than typically provided by our release cycle, there are few barriers to keeping this updated in backports, and users who have installed from backports will remain with backports, so their most active and interested users may be expected to always have the latest version, while highly conservative users will be able to enjoy a consistent ABI during the life of a given release (although these users would need to wait for our next release before using the package). -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On 04/09/12 10:29, Michael Hall wrote: It's possible for me to upload a package to Universe in Precise's development phase, then for an unrelated package by the same name to be in Debian's archives when we do the Quantal sync. How is this currently handled? I believe badly. But it's not been a huge issue I suspect because (a) relatively low volume of packages which get put in Ubuntu first, and (b) due diligence by uploaders to universe that there aren't likely to be conflicts (i.e. there aren't other upstreams with the same name). (b) is hard to automate and neither scales. Since we are trying to scale better and automate more, this issue becomes more important. -mt -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Michael Hall wrote: We add an Extras package foo in precise. Then in quantal, we sync in some new, unrelated package foo from Debian that happens to share the same name. Now users that installed foo in precise that upgrade to quantal will be replacing their foo package with a completely unrelated one. It's possible for me to upload a package to Universe in Precise's development phase, then for an unrelated package by the same name to be in Debian's archives when we do the Quantal sync. How is this currently handled? The package would be listed as manual-merge, and the developer who looked at the merge would be expected to notice that these were not the same package at all, potentially raising the issue on ubuntu-motu@ for discussion, or potentially resolving the issue with interested parties in some other way. I don't remember this happening, although we've had a few cases where packages added to Ubuntu were later added to Debian with different names, in which cases we carried a transitional dummy binary package and associated patch until the next LTS. There have been a couple cases where we introduced filesystem conflicts as a result of new-in-Ubuntu packages: these were generally resolved by lengthy discussions with the relevant Debian maintainers and upstreams, with the end result that both previously conflicting packages were added to Debian, and the conflicts resolved there (I believe one of these transitions required two Debian releases, so such a process may not be fast, but it worked before). -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On 09/04/2012 11:11 AM, Emmet Hikory wrote: Daniel Holbach wrote: On 04.09.2012 15:28, Emmet Hikory wrote: The difficulty here is that there is uncontrolled scope for future conflict. While the Contents.gz file is useful (and the conflictchecker system more so), if both extras and backports are enabled by default, there is no means by which the review board can determine that a given filename will not be provided by a backport of a new package imported from Debian. The fairest solution to this problem would be to turn on a conflict-check-before-publish for all parts of the archive. This would help us find these (and pre-existing) issues immediately and resolve them amongst the maintainers and upstreams. Completely independently of this discussion, this is a good idea, although we probably ought have the system respect Breaks, Conflicts, and Replaces, or we'll end up with lots of false positives. Mind you, given the vast number of reports from conflictchecker, it may be that we would want to put up a review system for some time to clean up the existing issues prior to actually blocking publication. That said, while I agree that such issues can be sorted between the various developers involved (perhaps easily, perhaps less so (see node)), I am much more concerned about the effect on users. Assume I'm using Ubuntu Desktop, and I add an extras application to the Dock. Now assume there is a namespace conflict for that application, which is resolved by the extras application taking a new name. Depending on what I happened to install on upgrade (as a new dependency of another installed package), my Dock entry may behave entirely differently. More generally, this may happen for startup programs, so that I would upgrade, reboot, and end up running something completely unexpected automatically, and I may not even notice if the automatic execution doesn't load a window, and just believe my upgrade broke (and potentially end up finding my computer slower, or behaving oddly, depending on what the new program happened to do). We could alternately prevent the importation of packages that conflict with a package name already in Extras. That would prevent this from happening. We would also have to prevent the importation of packages that Depends or Recommends on the package we won't be importing. This would essentially make package names first come, first served between Extras and Debian. The /opt requirement on the other hand unfortunately imposes a huge amount of work on 1) app developers because our tools don't work this way very easily and 2) Ubuntu maintainers who have to enable path lookups in tools which don't know about /opt yet. Much of this can be avoided by allowing a common location for extras files, for example /opt/extras/bin, /opt/extras/applications, /opt/extras/pixmaps, etc. If these locations are only permitted to contain namespace-protected symlinks, then it can be a matter of adding one or two lines to the 8-12 tools that perform these sorts of discoveries. No, this isn't an ideal solution, but it significantly limits the effort required to support a separate namespace. Not only would it require the we carry these patches to system tools and libraries indefinitely, it would also mean that we encourage developers to produce apps and packages that are not compatible with our Upstream (Debian) or any other distro. For application developers who prefer standard locations, I don't see any reason we oughtn't simply add their packages to the repository with immediate backport: in addition to allowing application developers to put their files in any policy-compliant location, it automatically provides a safe upgrade path for users. Even for software with release cycles that require significantly more frequent updates than typically provided by our release cycle, there are few barriers to keeping this updated in backports, and users who have installed from backports will remain with backports, so their most active and interested users may be expected to always have the latest version, while highly conservative users will be able to enjoy a consistent ABI during the life of a given release (although these users would need to wait for our next release before using the package). Sending these packages to Backports instead of Extras doesn't change any of the potential problems with file and namespace conflicts. Michael Hall mhall...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Michael Hall wrote: We could alternately prevent the importation of packages that conflict with a package name already in Extras. That would prevent this from happening. We would also have to prevent the importation of packages that Depends or Recommends on the package we won't be importing. This would essentially make package names first come, first served between Extras and Debian. Package names are relatively easy: there aren't that many of them, and they can be namespaced without significant impact. My concern is about filenames. The /opt requirement on the other hand unfortunately imposes a huge amount of work on 1) app developers because our tools don't work this way very easily and 2) Ubuntu maintainers who have to enable path lookups in tools which don't know about /opt yet. Much of this can be avoided by allowing a common location for extras files, for example /opt/extras/bin, /opt/extras/applications, /opt/extras/pixmaps, etc. If these locations are only permitted to contain namespace-protected symlinks, then it can be a matter of adding one or two lines to the 8-12 tools that perform these sorts of discoveries. No, this isn't an ideal solution, but it significantly limits the effort required to support a separate namespace. Not only would it require the we carry these patches to system tools and libraries indefinitely, it would also mean that we encourage developers to produce apps and packages that are not compatible with our Upstream (Debian) or any other distro. We rather ought encourage developers to use build systems that allow one to specify an install location: then the difference between installing to /opt/ and system locations becomes entirely a matter of a preference in the packaging: other format distributions will not even notice. Distributions that use Debian-format packages are likely to be downstream from either Debian or Ubuntu: if we share the optional /opt/ packaging preference with Debian, then it is trivial for any distribution to adopt the package as either extra or part of the system with very little effort. As for patches in system tools, at least for icon cache, path, and desktop file discovery, this is one or two lines in a configuration file that already carries Ubuntu-specific patches. Is there a specific example of a discovery mechanism that is more complicated to change? For application developers who prefer standard locations, I don't see any reason we oughtn't simply add their packages to the repository with immediate backport: in addition to allowing application developers to put their files in any policy-compliant location, it automatically provides a safe upgrade path for users. Even for software with release cycles that require significantly more frequent updates than typically provided by our release cycle, there are few barriers to keeping this updated in backports, and users who have installed from backports will remain with backports, so their most active and interested users may be expected to always have the latest version, while highly conservative users will be able to enjoy a consistent ABI during the life of a given release (although these users would need to wait for our next release before using the package). Sending these packages to Backports instead of Extras doesn't change any of the potential problems with file and namespace conflicts. I don't care what the repository is called. My understanding of the backports process is that it requires the package *also* be present in the following release, as a regular system package. As such, it is automatically tracked by existing tools in Debian and likely to cause discussion in the event that someone wants to generate package name or filename conflicts. Conversely, my understanding of the extras process is that there is no expectation as to whether the package will be available for the following release or not, and that it uses a separate repository not currently tracked by any of the existing tools in Debian. As a result, there are significant chances that either 1) a conflict is introduced by some package in Debian, or 2) an extras maintainer may significantly delay adding a package to extras (perhaps until after release) as a result of conflict resolution discussions, which may adversely impact end users. The above notwithstanding, I'm all in favour of being able to safely add new or frequently changing packages with policy-compliant filenames to Ubuntu, both during the life of a release and as part of future releases. I'm just concerned that our attempts to work around some of the problems we have had with such systems in the past may lead to us creating new systems that closely parallel older systems without addressing the issues that caused the prior systems to no longer be considered ideal for future progress. Given my experience with cleanup after the pull of all the
Server Team 20120904 meeting minutes
Hi, Here are the minutes of the meeting. They can also be found online with the irc logs here: https://wiki.ubuntu.com/MeetingLogs/Server/20120904. -- 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, 2012-09-04
= Meeting Minutes = [[http://irclogs.ubuntu.com/2012/09/04/%23ubuntu-meeting.txt|IRC Log of the meeting.]] [[http://voices.canonical.com/kernelteam|Meeting minutes.]] == Agenda == [[https://wiki.ubuntu.com/KernelTeam/Meeting#Tues, 04 Sep, 2012|20120904 Meeting Agenda]] === ARM Status === No update this week. === 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 === Milestone Targeted Work Items === || apw || hardware-q-kernel-config-review || 3 work item || || || hardware-q-kernel-delta-review || 3 work items || || || hardware-q-kernel-misc || 1 work item || || || desktop-q-clean-old-kernels || 1 work item || || cking || hardware-q-kernel-misc || 1 work item || || ogasawara || hardware-q-kernel-misc || 4 work items || || tgardner|| hardware-q-kernel-misc || 1 work item || If your name is in the above table, please review your Beta-1 work items. === Status: Quantal Development Kernel === Last week we uploaded the 3.5.0-13.14 Quantal kernel. This upload contained some bug fixes which we felt we important for the Beta-1 milestone. This was also uploaded to the q-lts-backport [1] PPA to help facilitate testing of the 12.10 kernel in 12.04. We welcome anyone to please install, test, and let us know your feedback. [1] https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport Note that we are 2 days away from Beta-1. I do not foresee any further uploads before Thursday. At this point in time, any fixes will be re-targetted towards the Beta-2 milestone. Important upcoming dates: * Thurs Sept 6 - Beta 1 (~2 days) * Thurs Sept 20 - Beta 2 (~2 weeks) * Thurs Sept 27 - Beta 2 (~3 weeks) === Status: CVE's === == 2012-09-04 (weekly) == Currently we have 75 CVEs on our radar, with no added and two CVEs retired this week. See the CVE matrix for the current list: http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html Overall the backlog has decreased slightly this week: http://people.canonical.com/~kernel/status/cve-metrics.txt http://people.canonical.com/~kernel/cve/pkg/CVE-linux.txt === Status: Stable, Security, and Bugfix Kernel Updates - Precise/Oneiric/Natty/Lucid/Hardy === Here is the status for the main kernels, until today (September 04): * Hardy - Nothing in this cycle * Lucid - In Preparation; 2 CVEs; (7 commits) * Natty - In Preparation; 3 CVEs; (8 commits) * Oneiric - In Preparation; 2 CVEs; 2 upstream stable release(s); (67 commits) * Precise - In Preparation; 2 CVEs; 1 upstream stable release(s); (62 commits) Current opened tracking bugs details: * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html For SRUs, SRU report is a good source of information: * http://people.canonical.com/~kernel/reports/sru-report.html Future stable cadence cycles: * https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock NOTE: this is the *last* Natty kernel being built. === Open Discussion or Questions? Raise your hand to be recognized === No discussion. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Simple but worthwhile to fix bugs?
On Tue, Sep 04, 2012 at 11:47:32AM +0200, Daniel Holbach wrote: Another question is: what kind of fixes do we want new contributors to work on? How simple is too simple? Are we afraid of typo fixes piling up in the queue? Bad spelling and bad grammar are pet peeves of mine. I try to submit patches upstream when I spot errors myself. But admittedly these are typically minor issues. I think it's good to identify them, but it's more efficient for these to go directly upstream. The sponsorship process adds overhead and uses up time of reviewers that would be better to spend on more substantial issues. One area I think this audience could have a bigger impact on is backporting of existing fixes from upstream. This involves doing SRUs, which might be a bit much for newbies, but it usually requires little or no coding skill, just packaging/process know-how. Much of the trouble of backporting fixes is figuring out how to reproduce a problem and locating the upstream fix; but this is good many hands make light work type stuff that makes good use of the community. The remainder of the work is straightforward packaging and process type stuff; quite learnable via sponsorship and with plenty of ready pilots and mentors. We can't effectively mentor someone to learn C++ to fix a bug, but given an existing patch we can certainly mentor someone through the rest of the process of packaging/testing/sru'ing it. Bryce -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
UDS - I'll be there
Just heard today from Canonical. They approved my sponsorship to attend the developer summit. Woo hoo! Anyone else here going? ...Steve -- kubuntu-devel mailing list kubuntu-de...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Proposing a New App Developer Upload Process
Hi Michael, On Tue, Sep 04, 2012 at 10:50:21AM -0400, Michael Hall wrote: On 09/04/2012 09:39 AM, Scott Kitterman wrote: The problem isn't just with file conflicts with current packages, it's that these packages will now start using up distro namespace. If some app developer package ships the file /usr/games/bird-game, even though there's no current conflict, there is a package sync'ed from Debian that also ships /usr/games/bird-game then there's a conflict we have to resolve. In /opt in a proper vendor namespace this can never happen. If bird-game already exists in Extras, and then a different package is allowed into backports that will install files into the same location, then yes there is a possibility for a conflict. But I assume part of the backports approval process already checks for conflicts, as they may exist with another package in the stable release already, so that process could easily be extended to include Extras packages as well. I think people are more concerned with auto-import from Debian than backports. Debian's approval process knows nothing about Extras, so there is no mechanism or approval process that checks for conflicts. Since Extras package won't be in the development release until FeatureFreeze, we can check them against the new packages imported from Debian before we forward-copy them from the previous stable release. That's possible, but has some drawbacks: - If Ubuntu chooses to rename the package in universe to address this collision, that likely increases the burden on Ubuntu: Debian is unlikely to agree to rename a package, or binaries within a package, in response to namespace claims from third-party software that's not in the distro. - If the package in universe is given precedence, then users may have a frustrating experience when upgrading to the new release: either update-manager needs to do some complex mapping of extras packages to find the new name (if any) of the package, or all extras packages that don't exist in the new release need to be removed before upgrading. In either case, it seems a certain amount of coordination would be required to provide users a good experience in upgrades, and we quite reasonably want to avoid the need for that coordination. The latter option, which seems to require the least coordination, would also leave users who don't use update-manager for their updates out in the cold. And neither option really addresses the backports issue, where a package may become available in a devel release that there's user demand for post release, but there's already a package of the same name (but different origin) in extras. A namespace would be a good thing because it saves us from having to deal with these coordination issues. The /opt namespace hasn't shown itself to be viable, in part because we don't have tooling that will usefully generate the binary packages with the correct layout without a lot of fuss, and also in part because upstream sources seem not to be equipped to handle the split between /opt and /usr for the points where the package will need to integrate. It's possible that namespacing within /usr - for instance, requiring each subdirectory and binary name to be prefixed with 'extras.' - would give better results with regards to the upstream build systems, I'm not sure. But if we are going to try to do namespacing of extras packages to avoid the need for coordination, we definitely would need improved package helpers that support namespacing of packages (i.e., debhelper support). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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: Proposing a New App Developer Upload Process
On 09/04/2012 01:02 PM, Emmet Hikory wrote:
Michael Hall wrote:
Not only would it require the we carry these patches to system tools and
libraries indefinitely, it would also mean that we encourage developers
to produce apps and packages that are not compatible with our Upstream
(Debian) or any other distro.
We rather ought encourage developers to use build systems that allow
one to specify an install location: then the difference between installing
to /opt/ and system locations becomes entirely a matter of a preference in
the packaging: other format distributions will not even notice. Distributions
that use Debian-format packages are likely to be downstream from either Debian
or Ubuntu: if we share the optional /opt/ packaging preference with Debian,
then it is trivial for any distribution to adopt the package as either extra
or part of the system with very little effort.
If it can be reduced to a matter of build-time preferences, that would
be fine. The current /opt/ rules and support, however, require both a
significant amount of extra work in the packaging, and usually
additional changes to the code itself.
As for patches in system tools, at least for icon cache, path, and desktop
file discovery, this is one or two lines in a configuration file that already
carries Ubuntu-specific patches. Is there a specific example of a discovery
mechanism that is more complicated to change?
.desktop files, .service files (for dbus), .lens and .scope files (for
Unity) all needed to be changed to point to executables or images in
/opt/extra.ubuntu.com/${appname}/ when being packaged for Extras. Unity
APIs that require a .desktop or image file name had to use absolute
paths to the files in /opt/extras.ubuntu.com/{$appname}. These all
required changes to the app's source in order to support the
installation under /opt/.
Michael Hall
mhall...@ubuntu.com
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On Tuesday, September 04, 2012 10:21:15 AM Michael Hall wrote: On 09/04/2012 09:39 AM, Scott Kitterman wrote: The problem isn't just with file conflicts with current packages, it's that these packages will now start using up distro namespace. If some app developer package ships the file /usr/games/bird-game, even though there's no current conflict, there is a package sync'ed from Debian that also ships /usr/games/bird-game then there's a conflict we have to resolve. In /opt in a proper vendor namespace this can never happen. If bird-game already exists in Extras, and then a different package is allowed into backports that will install files into the same location, then yes there is a possibility for a conflict. But I assume part of the backports approval process already checks for conflicts, as they may exist with another package in the stable release already, so that process could easily be extended to include Extras packages as well. No. There isn't. There is a (reasonable) presumption that such issues have been resolved in the development release. I would not be in favor of increasing the testing requirements for backports to accommodate external repositories. A fairly contrived example derived from the above is if the Debian/Ubuntu package that shipped /usr/games/bird-game was in the archive and an app developer package was uploaded that shipped /usr/bin/bird-game, it could be run instead since /usr/bin precedes /usr/games on the standard user path. This would only happen if two different apps were both called bird-game but otherwise different. This situation is also possible already, even between two packages in Universe. How is that currently handled? Keep in mind there's no need for package name in the binary name to match, but if such a conflict happens, it's an RC bug in Debian terms and one has to be renamed. The Debian bug on /usr/bin/node is an example of how ugly this can get. It's not just enough to check for actual file conflicts though, you have to check the entire path to ensure that no files preempt files from other packages. Installing in /opt makes this a non-problem. maybe a Python based app ships an embedded copy of a module since they've tested with that version and don't want to test with the distro version and they write their setup.py to install it in /usr/local/lib/python2.7/dist- packages. Suddenly every user of that module is now using the app developer package version and not the distro version. Installing python modules in the system directories is not allowed under this process. Check the whitelist defined in the App Preparation section of the spec. OK. It seems odd not to allow install in /usr/games. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On Tuesday, September 04, 2012 04:25:56 PM Daniel Holbach wrote: Hello, On 04.09.2012 15:28, Emmet Hikory wrote: The difficulty here is that there is uncontrolled scope for future conflict. While the Contents.gz file is useful (and the conflictchecker system more so), if both extras and backports are enabled by default, there is no means by which the review board can determine that a given filename will not be provided by a backport of a new package imported from Debian. The fairest solution to this problem would be to turn on a conflict-check-before-publish for all parts of the archive. This would help us find these (and pre-existing) issues immediately and resolve them amongst the maintainers and upstreams. My current expectation is only a very tiny fraction of uploads would get blocked due to this and the general amount of work to resolve them would be small too. The /opt requirement on the other hand unfortunately imposes a huge amount of work on 1) app developers because our tools don't work this way very easily and 2) Ubuntu maintainers who have to enable path lookups in tools which don't know about /opt yet. It seems to me there's an assumption embedded in that response that if an extras packages gets a namespace first then it 'owns' it. I think that's inappropriate for that to be the case for any external repository. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On Wednesday, September 05, 2012 12:11:18 AM Emmet Hikory wrote: For application developers who prefer standard locations, I don't see any reason we oughtn't simply add their packages to the repository with immediate backport: in addition to allowing application developers to put their files in any policy-compliant location, it automatically provides a safe upgrade path for users. Even for software with release cycles that require significantly more frequent updates than typically provided by our release cycle, there are few barriers to keeping this updated in backports, and users who have installed from backports will remain with backports, so their most active and interested users may be expected to always have the latest version, while highly conservative users will be able to enjoy a consistent ABI during the life of a given release (although these users would need to wait for our next release before using the package). +1. I've never understood why there is resistance to this. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
On Tuesday, September 04, 2012 11:24:28 AM Michael Hall wrote: On 09/04/2012 11:11 AM, Emmet Hikory wrote: Daniel Holbach wrote: On 04.09.2012 15:28, Emmet Hikory wrote: The difficulty here is that there is uncontrolled scope for future conflict. While the Contents.gz file is useful (and the conflictchecker system more so), if both extras and backports are enabled by default, there is no means by which the review board can determine that a given filename will not be provided by a backport of a new package imported from Debian. The fairest solution to this problem would be to turn on a conflict-check-before-publish for all parts of the archive. This would help us find these (and pre-existing) issues immediately and resolve them amongst the maintainers and upstreams. Completely independently of this discussion, this is a good idea, although we probably ought have the system respect Breaks, Conflicts, and Replaces, or we'll end up with lots of false positives. Mind you, given the vast number of reports from conflictchecker, it may be that we would want to put up a review system for some time to clean up the existing issues prior to actually blocking publication. That said, while I agree that such issues can be sorted between the various developers involved (perhaps easily, perhaps less so (see node)), I am much more concerned about the effect on users. Assume I'm using Ubuntu Desktop, and I add an extras application to the Dock. Now assume there is a namespace conflict for that application, which is resolved by the extras application taking a new name. Depending on what I happened to install on upgrade (as a new dependency of another installed package), my Dock entry may behave entirely differently. More generally, this may happen for startup programs, so that I would upgrade, reboot, and end up running something completely unexpected automatically, and I may not even notice if the automatic execution doesn't load a window, and just believe my upgrade broke (and potentially end up finding my computer slower, or behaving oddly, depending on what the new program happened to do). We could alternately prevent the importation of packages that conflict with a package name already in Extras. That would prevent this from happening. We would also have to prevent the importation of packages that Depends or Recommends on the package we won't be importing. This would essentially make package names first come, first served between Extras and Debian. Blocking Ubuntu development based on what's in external repositories would be an atrocity. I for one would take the issue to the tech board and ask them no to allow such a thing. The /opt requirement on the other hand unfortunately imposes a huge amount of work on 1) app developers because our tools don't work this way very easily and 2) Ubuntu maintainers who have to enable path lookups in tools which don't know about /opt yet. Much of this can be avoided by allowing a common location for extras files, for example /opt/extras/bin, /opt/extras/applications, /opt/extras/pixmaps, etc. If these locations are only permitted to contain namespace-protected symlinks, then it can be a matter of adding one or two lines to the 8-12 tools that perform these sorts of discoveries. No, this isn't an ideal solution, but it significantly limits the effort required to support a separate namespace. Not only would it require the we carry these patches to system tools and libraries indefinitely, it would also mean that we encourage developers to produce apps and packages that are not compatible with our Upstream (Debian) or any other distro. There is a standard process that people can use to get packages into the distribution. It's not at all surprising that an alternative infrastructure would require alternative tools and processes. I don't understand what's so hard about /opt (for any gui application it's the .desktop file that's going to drive the applications being started and that can point anywhere). If the alternative to maintaining some extra processes and tools is to drive a namespace wedge between Debian and Ubuntu then I don't think you have a choice but to suck up the cost of providing the alternate process/tools if a Canonical standard method of delivering third party apps on Ubuntu is what Canonical wants to provide. For application developers who prefer standard locations, I don't see any reason we oughtn't simply add their packages to the repository with immediate backport: in addition to allowing application developers to put their files in any policy-compliant location, it automatically provides a safe upgrade path for users. Even for software with release cycles that require significantly more frequent updates than typically provided by our release cycle, there are few barriers to keeping
Re: Proposing a New App Developer Upload Process
On Tuesday, September 04, 2012 01:19:50 PM Michael Hall wrote:
On 09/04/2012 01:02 PM, Emmet Hikory wrote:
Michael Hall wrote:
Not only would it require the we carry these patches to system tools and
libraries indefinitely, it would also mean that we encourage developers
to produce apps and packages that are not compatible with our Upstream
(Debian) or any other distro.
We rather ought encourage developers to use build systems that allow
one to specify an install location: then the difference between installing
to /opt/ and system locations becomes entirely a matter of a preference in
the packaging: other format distributions will not even notice.
Distributions that use Debian-format packages are likely to be downstream
from either Debian or Ubuntu: if we share the optional /opt/ packaging
preference with Debian, then it is trivial for any distribution to adopt
the package as either extra or part of the system with very little
effort.
If it can be reduced to a matter of build-time preferences, that would
be fine. The current /opt/ rules and support, however, require both a
significant amount of extra work in the packaging, and usually
additional changes to the code itself.
As for patches in system tools, at least for icon cache, path, and
desktop
file discovery, this is one or two lines in a configuration file that
already carries Ubuntu-specific patches. Is there a specific example of
a discovery mechanism that is more complicated to change?
.desktop files, .service files (for dbus), .lens and .scope files (for
Unity) all needed to be changed to point to executables or images in
/opt/extra.ubuntu.com/${appname}/ when being packaged for Extras. Unity
APIs that require a .desktop or image file name had to use absolute
paths to the files in /opt/extras.ubuntu.com/{$appname}. These all
required changes to the app's source in order to support the
installation under /opt/.
These sorts of changes should be generalizable to be supported at build time.
It would take some work to set up the first time, but any build system I've
worked with would be able to do this.
Scott K
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/04/2012 04:41 PM, Steve Langasek wrote: Hi Michael, On Tue, Sep 04, 2012 at 10:50:21AM -0400, Michael Hall wrote: On 09/04/2012 09:39 AM, Scott Kitterman wrote: The problem isn't just with file conflicts with current packages, it's that these packages will now start using up distro namespace. If some app developer package ships the file /usr/games/bird-game, even though there's no current conflict, there is a package sync'ed from Debian that also ships /usr/games/bird-game then there's a conflict we have to resolve. In /opt in a proper vendor namespace this can never happen. If bird-game already exists in Extras, and then a different package is allowed into backports that will install files into the same location, then yes there is a possibility for a conflict. But I assume part of the backports approval process already checks for conflicts, as they may exist with another package in the stable release already, so that process could easily be extended to include Extras packages as well. I think people are more concerned with auto-import from Debian than backports. Debian's approval process knows nothing about Extras, so there is no mechanism or approval process that checks for conflicts. Since Extras package won't be in the development release until FeatureFreeze, we can check them against the new packages imported from Debian before we forward-copy them from the previous stable release. That's possible, but has some drawbacks: - If Ubuntu chooses to rename the package in universe to address this collision, that likely increases the burden on Ubuntu: Debian is unlikely to agree to rename a package, or binaries within a package, in response to namespace claims from third-party software that's not in the distro. - If the package in universe is given precedence, then users may have a frustrating experience when upgrading to the new release: either update-manager needs to do some complex mapping of extras packages to find the new name (if any) of the package, or all extras packages that don't exist in the new release need to be removed before upgrading. In either case, it seems a certain amount of coordination would be required to provide users a good experience in upgrades, and we quite reasonably want to avoid the need for that coordination. The latter option, which seems to require the least coordination, would also leave users who don't use update-manager for their updates out in the cold. And neither option really addresses the backports issue, where a package may become available in a devel release that there's user demand for post release, but there's already a package of the same name (but different origin) in extras. A namespace would be a good thing because it saves us from having to deal with these coordination issues. The /opt namespace hasn't shown itself to be viable, in part because we don't have tooling that will usefully generate the binary packages with the correct layout without a lot of fuss, and also in part because upstream sources seem not to be equipped to handle the split between /opt and /usr for the points where the package will need to integrate. It's possible that namespacing within /usr - for instance, requiring each subdirectory and binary name to be prefixed with 'extras.' - would give better results with regards to the upstream build systems, I'm not sure. But if we are going to try to do namespacing of extras packages to avoid the need for coordination, we definitely would need improved package helpers that support namespacing of packages (i.e., debhelper support). Would it be reasonable for MyApps to add a package name prefix to the submitted package, rather than requiring the developer to do so? MyApps will already be modifying the submitted package to include the generator AppArmor profile. So, for example, if I submit quickly-gtk as a source package to MyApps, it would convert it to extras-quickly-gtk, add the AppArmor profile, and re-build the source package before submitting it to the PPA/buildds. Michael Hall mhall...@ubuntu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBCAAGBQJQRnCvAAoJEInUYcGJgfVyWmoP/R5V3ASIAMwH0uZSyxr3A43s NT7YUFnGnCL45ax4klEUGezEO3iwHanAHlEhgPDyLjiFXLir7AIVpCtF0X8aNHMD we+14KgJEoq4lAnGzPyx13Enf7UikSSQqXnYVbTl19KG0bxtHhbU9/5r3NO/CtAq pJS6yTKRZQbmFlhAd5HcgpHD0V/WXJirYdewdShxqYx9A9srptMwtHneTFC3Rxbh Z+nU3Kj38GA63QQYMYSu0kPgF6vXXOaOuWDuTPxhR40p8Qk+jSpBfBMxw+rvVYFN /dWJtFKuTwjEDf1BXuzegmBjx2V2jyy1hY1bcFriXai6EwDsj/II3ivwPSFTSMF7 uUeFhYF9rv34GAIWN7NSv80UW6ULsnIYivuIUfRKDgAKkKkYKGAsDhrN+UGOS8a5 9T5Ifmphnpc3aMeRBL63eDFgICm2e+v/lwqep/J906Wy/Ew+49He9iAYGS1h6VkF C1RIwdcJNQ4v3nYHlFQG4n3w08lYt2508p9goJvYksv2tsD0psxhsR4CDNICkReK WbTuLsXhP6ssi5P/zrXt7z/HYsZUHv1bRONTeWORjc3wyVjc/w77jcEl/f0NdRos
Re: Proposing a New App Developer Upload Process
Michael Hall mhall...@ubuntu.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/04/2012 04:41 PM, Steve Langasek wrote: Hi Michael, On Tue, Sep 04, 2012 at 10:50:21AM -0400, Michael Hall wrote: On 09/04/2012 09:39 AM, Scott Kitterman wrote: The problem isn't just with file conflicts with current packages, it's that these packages will now start using up distro namespace. If some app developer package ships the file /usr/games/bird-game, even though there's no current conflict, there is a package sync'ed from Debian that also ships /usr/games/bird-game then there's a conflict we have to resolve. In /opt in a proper vendor namespace this can never happen. If bird-game already exists in Extras, and then a different package is allowed into backports that will install files into the same location, then yes there is a possibility for a conflict. But I assume part of the backports approval process already checks for conflicts, as they may exist with another package in the stable release already, so that process could easily be extended to include Extras packages as well. I think people are more concerned with auto-import from Debian than backports. Debian's approval process knows nothing about Extras, so there is no mechanism or approval process that checks for conflicts. Since Extras package won't be in the development release until FeatureFreeze, we can check them against the new packages imported from Debian before we forward-copy them from the previous stable release. That's possible, but has some drawbacks: - If Ubuntu chooses to rename the package in universe to address this collision, that likely increases the burden on Ubuntu: Debian is unlikely to agree to rename a package, or binaries within a package, in response to namespace claims from third-party software that's not in the distro. - If the package in universe is given precedence, then users may have a frustrating experience when upgrading to the new release: either update-manager needs to do some complex mapping of extras packages to find the new name (if any) of the package, or all extras packages that don't exist in the new release need to be removed before upgrading. In either case, it seems a certain amount of coordination would be required to provide users a good experience in upgrades, and we quite reasonably want to avoid the need for that coordination. The latter option, which seems to require the least coordination, would also leave users who don't use update-manager for their updates out in the cold. And neither option really addresses the backports issue, where a package may become available in a devel release that there's user demand for post release, but there's already a package of the same name (but different origin) in extras. A namespace would be a good thing because it saves us from having to deal with these coordination issues. The /opt namespace hasn't shown itself to be viable, in part because we don't have tooling that will usefully generate the binary packages with the correct layout without a lot of fuss, and also in part because upstream sources seem not to be equipped to handle the split between /opt and /usr for the points where the package will need to integrate. It's possible that namespacing within /usr - for instance, requiring each subdirectory and binary name to be prefixed with 'extras.' - would give better results with regards to the upstream build systems, I'm not sure. But if we are going to try to do namespacing of extras packages to avoid the need for coordination, we definitely would need improved package helpers that support namespacing of packages (i.e., debhelper support). Would it be reasonable for MyApps to add a package name prefix to the submitted package, rather than requiring the developer to do so? MyApps will already be modifying the submitted package to include the generator AppArmor profile. So, for example, if I submit quickly-gtk as a source package to MyApps, it would convert it to extras-quickly-gtk, add the AppArmor profile, and re-build the source package before submitting it to the PPA/buildds. I think that's the right direction to be looking in, both for package names and files in the system path. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Hi Scott, On Tue, Sep 04, 2012 at 05:50:12PM -0400, Scott Kitterman wrote: On Wednesday, September 05, 2012 12:11:18 AM Emmet Hikory wrote: For application developers who prefer standard locations, I don't see any reason we oughtn't simply add their packages to the repository with immediate backport: in addition to allowing application developers to put their files in any policy-compliant location, it automatically provides a safe upgrade path for users. Even for software with release cycles that require significantly more frequent updates than typically provided by our release cycle, there are few barriers to keeping this updated in backports, and users who have installed from backports will remain with backports, so their most active and interested users may be expected to always have the latest version, while highly conservative users will be able to enjoy a consistent ABI during the life of a given release (although these users would need to wait for our next release before using the package). +1. I've never understood why there is resistance to this. There's a general sense that the Ubuntu archive can't scale out to the degree it needs to in order to take on the next challenges for the platform. While Debian packaging isn't hard for you or me, and while it's definitely gotten much easier over the past 4 years or so, it's still not so easy that we blindly trust outside contributors to get the packaging right without review by an Ubuntu developer. We do not have an infinite supply of Ubuntu developers to do this review. Should the set of software available to Ubuntu users through apt be limited to only that software that Ubuntu developers (or Debian maintainers) have time and interest to take care of directly? Or should users have better (not perfect, but better) ways to install software that's not gotten the attention of the elite inner circle? The intent of Extras was always to make it easy for upstream developers who know nothing about packaging policy to get their software in the hands of users in as reliable and bug-free a manner as possible. To date, it has fallen far short of this goal. We see 130 apps written for the recent app contest that will never make it into Ubuntu or Debian, because no one will ever package them the traditional way; and I think this is the tip of the iceberg. Provided we can address the app isolation issues and streamline the packaging helpers, doesn't it make sense for us to make this software available to our users - all of it, not just the ones an Ubuntu dev looks at and decides are personally interesting to them? Sure, there's going to be some low-quality stuff in there that our users aren't going to want. But isn't it better to let users judge this quality for themselves instead of having it pre-judged by what Ubuntu developers choose to work on? I may know a lot about putting together a distribution, but I'm a terrible judge of what the next big thing will be that's important to users, and I'd rather our users didn't miss out on it because of my poor ability to pick the winners. Given this goal, then, backports is not a solution. Backports is a necessarily heavy-weight process, of getting the package prepared, sponsored (possibly after several rounds of feedback), through the NEW queue for the devel release, and only then backported. That works for some upstreams who can invest that time and energy, but it won't work for all of them, and if it did I think the backports team would quickly reconsider the workload. And it's a process that largely doesn't map to the goals of the upstream who is trying to get their software into the hands of the users running the current stable release, *not* to get their software integrated into Ubuntu itself. It's entirely possible that some of this software won't be relevant by the time the next Ubuntu release comes out! Why put an upstream through a process optimized for long-term integration of the distribution when all they care about is getting an app out to users that gives them information about this month's beer festival? Does this explain better why there's resistance to using the backports process for this class of package? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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: Proposing a New App Developer Upload Process
On Tue, Sep 04, 2012 at 01:19:50PM -0400, Michael Hall wrote:
As for patches in system tools, at least for icon cache, path, and
desktop
file discovery, this is one or two lines in a configuration file that
already
carries Ubuntu-specific patches. Is there a specific example of a discovery
mechanism that is more complicated to change?
.desktop files, .service files (for dbus), .lens and .scope files (for
Unity) all needed to be changed to point to executables or images in
/opt/extra.ubuntu.com/${appname}/ when being packaged for Extras. Unity
APIs that require a .desktop or image file name had to use absolute
paths to the files in /opt/extras.ubuntu.com/{$appname}. These all
required changes to the app's source in order to support the
installation under /opt/.
Note that, independent of any packaging issues for Ubuntu, upstream best
practice would have the absolute paths in these files generated at build
time, once it's known where they will be installed. Is there any chance
that we could help these app developers with implementing such best
practices? Perhaps an improvement to the quickly templates?
On Tue, Sep 04, 2012 at 05:20:47PM -0400, Michael Hall wrote:
It's possible that namespacing within /usr - for instance,
requiring each subdirectory and binary name to be prefixed with
'extras.' - would give better results with regards to the upstream
build systems, I'm not sure. But if we are going to try to do
namespacing of extras packages to avoid the need for coordination,
we definitely would need improved package helpers that support
namespacing of packages (i.e., debhelper support).
Would it be reasonable for MyApps to add a package name prefix to the
submitted package, rather than requiring the developer to do so?
MyApps will already be modifying the submitted package to include the
generator AppArmor profile.
So, for example, if I submit quickly-gtk as a source package to
MyApps, it would convert it to extras-quickly-gtk, add the AppArmor
profile, and re-build the source package before submitting it to the
PPA/buildds.
For package renaming that seems easy enough to do, but if we're worried
about file conflicts, dynamically prefixing filenames when building the
package is going to have an even worse impact on the upstream code than
changing directories does.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
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: Proposing a New App Developer Upload Process
Steve Langasek wrote:
On Tue, Sep 04, 2012 at 05:20:47PM -0400, Michael Hall wrote:
It's possible that namespacing within /usr - for instance,
requiring each subdirectory and binary name to be prefixed with
'extras.' - would give better results with regards to the upstream
build systems, I'm not sure. But if we are going to try to do
namespacing of extras packages to avoid the need for coordination,
we definitely would need improved package helpers that support
namespacing of packages (i.e., debhelper support).
Would it be reasonable for MyApps to add a package name prefix to the
submitted package, rather than requiring the developer to do so?
MyApps will already be modifying the submitted package to include the
generator AppArmor profile.
So, for example, if I submit quickly-gtk as a source package to
MyApps, it would convert it to extras-quickly-gtk, add the AppArmor
profile, and re-build the source package before submitting it to the
PPA/buildds.
For package renaming that seems easy enough to do, but if we're worried
about file conflicts, dynamically prefixing filenames when building the
package is going to have an even worse impact on the upstream code than
changing directories does.
Changing the base filename indeed generates more complicated issues,
not only in terms of collisions, but also in terms of coordination between
code and data (e.g. code expects to find ${CONFIG_DIR}/package and fails
to initialise properly with only ${CONFIG_DIR}/extras-package.
However, if we consider renaming to apply to the entire path, rather
than the bare filename, this becomes considerably less of an issue. If
MyApps were to call tooling that changed the default installation location
for files while preserving bare filenames, then there is less potential
for conflict. The standard mechanism for this is to place the non-system
files in per-package namespaced directories in /opt.
For the convenience of developers, this should likely be implemented
through debhelper support, so that if one specifies `dh --with-extras`
one gets the alternate installation prefix, as well as the apparmor
profile, etc.
--
Emmet HIKORY
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Michael Hall wrote:
.desktop files, .service files (for dbus), .lens and .scope files (for
Unity) all needed to be changed to point to executables or images in
/opt/extra.ubuntu.com/${appname}/ when being packaged for Extras. Unity
APIs that require a .desktop or image file name had to use absolute
paths to the files in /opt/extras.ubuntu.com/{$appname}. These all
required changes to the app's source in order to support the
installation under /opt/.
The XDG menu specification provides very wide flexibility in where
and how .desktop files are stored, and all the compliant implementations
of which I am aware use a configuration file to determine where to find
the files, and which to include where. Similarly, dbus service files
may be placed in any of ${XDG_DATA_DIRS}/share/dbus-1/services. Icons
(for use in .desktop files) may be stored in ${XDG_DATA_DIRS}/icons. I
know less about .lens and .scope files, but presume that there would be
advantages beyond this discussion to have them check a runtime-determined
set of locations.
Where this gets extra annoying is the expectation that things
are found in application-specific locations: while it is possible
to add /opt/${PACKAGE}/applications to the menu search path for
each package, this quickly becomes unwieldy. While it reduces the
separation between applications to some degree, use of a shared
namespace for this sort of file (e.g. /opt/extras.ubuntu.com/applications
or /opt/extras.ubuntu.com/share/dbus-1/services) reduces the issue to
a simple configuration change and a symlink from the shared location
to the package namespace.
The disadvantage of doing it this way is that it imposes a requirement
for all extras packages to share a single namespace for these resources
(desktop files, icon names, dbus services, etc.), although on a given system
we would likely wish to impose that anyway (two packages providing the same
apparent program name, or the same apparent dbus service may lead to many
more complicated issues in terms of user confusion than fienames).
--
Emmet HIKORY
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposing a New App Developer Upload Process
Steve Langasek wrote: On Wednesday, September 05, 2012 12:11:18 AM Emmet Hikory wrote: For application developers who prefer standard locations, I don't see any reason we oughtn't simply add their packages to the repository with immediate backport: in addition to allowing application developers to put their files in any policy-compliant location, it automatically provides a safe upgrade path for users. Even for software with release cycles that require significantly more frequent updates than typically provided by our release cycle, there are few barriers to keeping this updated in backports, and users who have installed from backports will remain with backports, so their most active and interested users may be expected to always have the latest version, while highly conservative users will be able to enjoy a consistent ABI during the life of a given release (although these users would need to wait for our next release before using the package). There's a general sense that the Ubuntu archive can't scale out to the degree it needs to in order to take on the next challenges for the platform. While Debian packaging isn't hard for you or me, and while it's definitely gotten much easier over the past 4 years or so, it's still not so easy that we blindly trust outside contributors to get the packaging right without review by an Ubuntu developer. We do not have an infinite supply of Ubuntu developers to do this review. Should the set of software available to Ubuntu users through apt be limited to only that software that Ubuntu developers (or Debian maintainers) have time and interest to take care of directly? Or should users have better (not perfect, but better) ways to install software that's not gotten the attention of the elite inner circle? This needn't be an XOR model. Taking as given that our application acceptance model has not only failed to scale, but has actually become less efficient over the past couple years (roughly lucid through precise), and that we *must* come up with a way to ensure that our users can easily get new software in a safe manner (as opposed to use of random PPAs, arbitrary third-party archives, random downloads and local compilation attempts, etc.), we need not decide that this cannot interoperate with the existing processes by which we add new applications, nor that the existing processes are now inflexible to the point of no utility. Historically, the limitation has often been insufficient reviewers, and automation is a wonderful way to remove this, especially in combination with sufficient insulation of the application from the rest of the system. That said, we oughtn't force *all* applications to be so limited: there are many tools that we would welcome as regular packages, assuming we had reviewed them. Of course, unless we take care to ensure that, from the perspective of the application developer, the process for having the package included is very similar (and most importantly has the same widely-publicised entry point), we only create division: random arguments about the best way to submit packages in places we fail to see, people deciding not to submit because they are unsure, or feeling rejected by one process and not wanting to start another. So, if we encourage the development of portable applications, and create automation that can accept these packages, perform (limited) review, and wrap them in sufficient insulation before presenting them to users, we should be able to almost completely remove the requirement for human review (although there are complexities that may require a lightweight gatekeeper check to avoid repititions of the hotbabe discussions or similar). That said, if an application fails the automated insulation testing or requires deeper integration with the system, we should make it immediately available to human reviewers who would be empowered to accept the submission as a regular system package. For those applications requiring insulation, the use of the extras repository is likely the simplest route, although I'd personally prefer that if we do this we either claim extras to be part of Ubuntu (and place it under similar trust metrics), or create a new repository that we then consider part of Ubuntu. For those applications requiring human review, I don't see any reason we shouldn't strive for them to be included as part of the regular repositories, and suspect backports is the appropriate way to do this (although this may require some streamlining of the backports process for *entirely new* packages, if we find that this is a blocking factor). Where this becomes complicated in when we think about trust: who do we trust to perform the human reviews? Do we trust application developers who received human review to update their packages responsibly? If we wish to scale, I believe that we need to answer the first with Ubuntu Developers: if we have people
Re: chromium no longer maintained
On Tue, Sep 4, 2012 at 12:58 AM, Benjamin Kerensa bkere...@ubuntu.com wrote: Daniel is talking about chromium-browser not Google Chrome which is closed source and he is correct chromium-browser is outdated since the maintainer of the package has moved on to other projects. Please don't spread lies. The bulk (most of) of Google Chrome is open source, it's called, wait for it...Chromiumn. The way you talk you seem to think that Chrome started as a fork of Chromium that was closed off when Chromium was a fork of Chrome that went open source, which means that the truth is, the bulk (most of) of Chrome is open source and you are spreading lies. -- 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 12.10 Quantal 12.10 beta 2
On 03/09/2012 20:34, Oliver Grawert wrote: hi, Am Montag, den 03.09.2012, 20:16 +0200 schrieb Johan Scheepers: Good day, Have trouble locating download link for above OS. i bet anyone would, you are a bit ahead of time, ubuntu 12.10 beta *1* will be released this thursday, beta 2 is still a bit away ;) ciao oli No wonder, I was looking for something in the future. Thanks. -- 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: chromium no longer maintained
Jordon, You have wrong. Chromium is and ever was the core of the web browser from Google. And it is open source (there was no before, no after, no fork - it is the core). Google Chrome is that core, plus a certain amout of code which is not open-source and so, you don't have access to the source code of Google Chrome itself (which is a packages chromium + other codes). Nevetheless it was not the point: Daniel said that the package chromium-browser is outdated. It has been verified. That's it. Regards, Nicolas 2012/9/4 Jordon Bedwell jor...@envygeeks.com On Tue, Sep 4, 2012 at 12:58 AM, Benjamin Kerensa bkere...@ubuntu.com wrote: Daniel is talking about chromium-browser not Google Chrome which is closed source and he is correct chromium-browser is outdated since the maintainer of the package has moved on to other projects. Please don't spread lies. The bulk (most of) of Google Chrome is open source, it's called, wait for it...Chromiumn. The way you talk you seem to think that Chrome started as a fork of Chromium that was closed off when Chromium was a fork of Chrome that went open source, which means that the truth is, the bulk (most of) of Chrome is open source and you are spreading lies. -- 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 -- Nicolas MICHEL -- 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: chromium no longer maintained
On Tue, Sep 4, 2012 at 2:35 AM, Nicolas Michel be.nicolas.mic...@gmail.com wrote: You have wrong. Chromium is and ever was the core of the web browser from Google. And it is open source (there was no before, no after, no fork - it is the core). Google Chrome is that core, plus a certain amout of code which is not open-source and so, you don't have access to the source code of Google Chrome itself (which is a packages chromium + other codes). While I don't completely understand what you are saying I will attempt to refute it. Please do research before stating somebody is wrong: In September 2008, Google released a large portion of Chrome's source code as an open source project called Chromium [2], which Chrome releases are still based on. [1] [1] http://en.wikipedia.org/wiki/Google_Chrome [2] http://arstechnica.com/information-technology/2008/09/google-unveils-chrome-source-code-and-linux-port/ While today Chrome may be be based off of Chromium, originally Chromium was based off of Chrome. Chrome is the original, Chromium is the fork. I am correct as I stated exactly that. So I repeat again, stop spreading lies and use fact and truth please. Thanks and have a great day sir. -- 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: chromium no longer maintained
Hi, Jordan, aacually what you describe is not a fork. In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software. The term often implies not merely a development branch, but a split in the developer community, a form of schism.[1] The base of Chrome is Chromium Chrome = Chromium + other proprietary extensions. Linux Mint is no fork of Ubuntu. It is based on it. Regards, Damian 2012/9/4 Jordon Bedwell jor...@envygeeks.com: On Tue, Sep 4, 2012 at 2:35 AM, Nicolas Michel be.nicolas.mic...@gmail.com wrote: You have wrong. Chromium is and ever was the core of the web browser from Google. And it is open source (there was no before, no after, no fork - it is the core). Google Chrome is that core, plus a certain amout of code which is not open-source and so, you don't have access to the source code of Google Chrome itself (which is a packages chromium + other codes). While I don't completely understand what you are saying I will attempt to refute it. Please do research before stating somebody is wrong: In September 2008, Google released a large portion of Chrome's source code as an open source project called Chromium [2], which Chrome releases are still based on. [1] [1] http://en.wikipedia.org/wiki/Google_Chrome [2] http://arstechnica.com/information-technology/2008/09/google-unveils-chrome-source-code-and-linux-port/ While today Chrome may be be based off of Chromium, originally Chromium was based off of Chrome. Chrome is the original, Chromium is the fork. I am correct as I stated exactly that. So I repeat again, stop spreading lies and use fact and truth please. Thanks and have a great day sir. -- 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 -- 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: chromium no longer maintained
On Tue, Sep 4, 2012 at 6:38 AM, Damian Ivanov damianator...@gmail.com wrote: Hi, Jordan, aacually what you describe is not a fork. In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software. The term often implies not merely a development branch, but a split in the developer community, a form of schism.[1] The base of Chrome is Chromium Chrome = Chromium + other proprietary extensions. As far as I'm concerned, this is the most correct view. And for the purpose of this discussion, they are practically the same. The issue here is that version 18 is considered outdated and insecure. The version of chromium that we should have right now is 21, whether it be in the form of chromium-browser or google-chrome. It would be nice if someone could step up and maintain the chromium-browser version of chromium, but for whatever reason, that isn't happening. Shouldn't the ppas at least be updated to state that the version held is out of date? Shouldn't version 18 be removed from the archive? Dan -- 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: chromium no longer maintained
On 09/04/2012 07:13 AM, Daniel Hollocher wrote: On Tue, Sep 4, 2012 at 6:38 AM, Damian Ivanov damianator...@gmail.com wrote: Hi, It would be nice if someone could step up and maintain the chromium-browser version of chromium, but for whatever reason, that isn't happening. Shouldn't the ppas at least be updated to state that the version held is out of date? Shouldn't version 18 be removed from the archive? There has long been talk of switching to Chromium by default in Ubuntu new installs. For a while wasn't it the default browser in Xubuntu? Look if it gets Google to give Canonical more money (i.e. from product placement, like with the Firefox package's search bar functionality embedding Canonical's adsense ID into Google searches) I say Chromium should be maintained so the portion of the userbase who uses it doesn't go using a downloaded/hand-compiled package and not generating any revenue. Dan -- 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: chromium no longer maintained
2012/9/4 John Moser john.r.mo...@gmail.com On 09/04/2012 03:44 AM, Jordon Bedwell wrote: On Tue, Sep 4, 2012 at 2:35 AM, Nicolas Michel be.nicolas.mic...@gmail.com wrote: You have wrong. Chromium is and ever was the core of the web browser from Google. And it is open source (there was no before, no after, no fork - it is the core). Google Chrome is that core, plus a certain amout of code which is not open-source and so, you don't have access to the source code of Google Chrome itself (which is a packages chromium + other codes). While I don't completely understand what you are saying I will attempt to refute it. Please do research before stating somebody is wrong: In September 2008, Google released a large portion of Chrome's source code as an open source project called Chromium [2], which Chrome releases are still based on. [1] [1] http://en.wikipedia.org/wiki/**Google_Chromehttp://en.wikipedia.org/wiki/Google_Chrome [2] http://arstechnica.com/**information-technology/2008/** 09/google-unveils-chrome-**source-code-and-linux-port/http://arstechnica.com/information-technology/2008/09/google-unveils-chrome-source-code-and-linux-port/ While today Chrome may be be based off of Chromium, originally Chromium was based off of Chrome. Chrome is the original, Chromium is the fork. I am correct as I stated exactly that. So I repeat again, stop spreading lies and use fact and truth please. Thanks and have a great day sir. No, it works like this: - Google releases Chrome (Closed source) - Google open sources Chrome... mostly: parts are proprietary, so they shuffle those into the closet and release most of it, shaped up into working order and ready to accept their proprietary code. This new open-source Chrome is called Chromium since Google Chrome is a particular brand (it's the name of Google's browser) - Chromium also runs on Linux, so Linux distributions package Chromium - Google continues to work on Chromium and on their Chrome patch set, releasing Chromium as source code and the Chrome browser as a compiled product. Chromium is just Google Chrome without some of Google's secrets. You're describing the process like these projects were different but they aren't. They are both part of the same projet. In fact Chromium project is behind 3 products of Google (http://www.chromium.org/): - Chromium (the browser) - Google Chrome - Chromium OS Chromium is the codebase of future versions of these related projects. They are testing new codes into chromium and then decides or not to keep that code and put it into Google Chrome. And yes google chrome also have part of proprietary codes as the decoder for the H264 codec and other things. In conclusion : Google Chrome is mostly Chromium but not entirely. And one is not the fork of the other because in a fork, the codebase tends to differienciate along the time which is not the case here. One is based on the other, plus some more features. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.**ubuntu.comUbuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/** mailman/listinfo/ubuntu-devel-**discusshttps://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Nicolas MICHEL -- 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: chromium no longer maintained
2012/9/4 John Moser john.r.mo...@gmail.com On 09/04/2012 03:44 AM, Jordon Bedwell wrote: On Tue, Sep 4, 2012 at 2:35 AM, Nicolas Michel be.nicolas.mic...@gmail.com wrote: You have wrong. Chromium is and ever was the core of the web browser from Google. And it is open source (there was no before, no after, no fork - it is the core). Google Chrome is that core, plus a certain amout of code which is not open-source and so, you don't have access to the source code of Google Chrome itself (which is a packages chromium + other codes). While I don't completely understand what you are saying I will attempt to refute it. Please do research before stating somebody is wrong: In September 2008, Google released a large portion of Chrome's source code as an open source project called Chromium [2], which Chrome releases are still based on. [1] [1] http://en.wikipedia.org/wiki/**Google_Chromehttp://en.wikipedia.org/wiki/Google_Chrome [2] http://arstechnica.com/**information-technology/2008/** 09/google-unveils-chrome-**source-code-and-linux-port/http://arstechnica.com/information-technology/2008/09/google-unveils-chrome-source-code-and-linux-port/ While today Chrome may be be based off of Chromium, originally Chromium was based off of Chrome. Chrome is the original, Chromium is the fork. I am correct as I stated exactly that. So I repeat again, stop spreading lies and use fact and truth please. Thanks and have a great day sir. No, it works like this: - Google releases Chrome (Closed source) - Google open sources Chrome... mostly: parts are proprietary, so they shuffle those into the closet and release most of it, shaped up into working order and ready to accept their proprietary code. This new open-source Chrome is called Chromium since Google Chrome is a particular brand (it's the name of Google's browser) - Chromium also runs on Linux, so Linux distributions package Chromium - Google continues to work on Chromium and on their Chrome patch set, releasing Chromium as source code and the Chrome browser as a compiled product. Chromium is just Google Chrome without some of Google's secrets. You're describing the process like these projects were different but they aren't. They are both part of the same projet. In fact Chromium project is behind 3 products of Google (http://www.chromium.org/): - Chromium (the browser) - Google Chrome - Chromium OS Chromium is the codebase of future versions of these related projects. They are testing new codes into chromium and then decides or not to keep that code and put it into Google Chrome. And yes google chrome also have part of proprietary codes as the decoder for the H264 codec and other things. In conclusion : Google Chrome is mostly Chromium but not entirely. And one is not the fork of the other because in a fork, the codebase tends to differienciate along the time which is not the case here. One is based on the other, plus some more features. One more things : Google Chrome AND Chromium are both working on Linux ... -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.**ubuntu.comUbuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/** mailman/listinfo/ubuntu-devel-**discusshttps://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Nicolas MICHEL -- 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: chromium no longer maintained
Hi David, Bad said, Ubuntu is a fork of Debian, it gets forked once in a while after a release to update packages, see wikipedia. Anyway I think chromium is still the most recent, from when 12.04 was released, so may somebody will just need to pick it up for 12.10 I guess 2012/9/4 David Klasinc bigwh...@lubica.net: On 09/04/2012 02:10 PM, Nicolas Michel wrote: In conclusion : Google Chrome is mostly Chromium but not entirely. And one is not the fork of the other because in a fork, the codebase tends to differienciate along the time which is not the case here. One is based on the other, plus some more features. Apart from the licenses, Chrome is to Chromium what Ubuntu is to Debian. But is this discussion really necessary here on this list? Unmaintained package is chromium-browser. That's all that matters. :) Regards, David -- 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 -- 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: chromium no longer maintained
-- Forwarded message -- From: Damian Ivanov damianator...@gmail.com Date: 2012/9/4 Subject: Re: chromium no longer maintained To: Gareth McCumskey gare...@nexustech.co.za From wikipedeia: scroll down to history and development, Ubuntu is a forkhttp://en.wikipedia.org/wiki/Fork_(software_development) of the Debian http://en.wikipedia.org/wiki/Debian project's codebasehttp://en.wikipedia.org/wiki/Codebase . 2012/9/4 Gareth McCumskey gare...@nexustech.co.za From Wikipedia: Ubuntu ([image: play] /http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English ʊ http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Keyˈhttp://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key b http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Keyʊhttp://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key n http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Keythttp://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key uː http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English#Key/http://en.wikipedia.org/wiki/Wikipedia:IPA_for_English *u-bun-too*http://en.wikipedia.org/wiki/Wikipedia:Pronunciation_respelling_key )[8] http://en.wikipedia.org/wiki/Ubuntu_(operating_system)#cite_note-7 [9]http://en.wikipedia.org/wiki/Ubuntu_(operating_system)#cite_note-about_ubuntu-8 is a computer operating systemhttp://en.wikipedia.org/wiki/Operating_system * based* on the Debian http://en.wikipedia.org/wiki/Debian Linux distribution http://en.wikipedia.org/wiki/Linux_distribution and distributed. Emphasis my own On Tue, Sep 4, 2012 at 2:26 PM, Damian Ivanov damianator...@gmail.comwrote: Hi David, Bad said, Ubuntu is a fork of Debian, it gets forked once in a while after a release to update packages, see wikipedia. Anyway I think chromium is still the most recent, from when 12.04 was released, so may somebody will just need to pick it up for 12.10 I guess 2012/9/4 David Klasinc bigwh...@lubica.net: On 09/04/2012 02:10 PM, Nicolas Michel wrote: In conclusion : Google Chrome is mostly Chromium but not entirely. And one is not the fork of the other because in a fork, the codebase tends to differienciate along the time which is not the case here. One is based on the other, plus some more features. Apart from the licenses, Chrome is to Chromium what Ubuntu is to Debian. But is this discussion really necessary here on this list? Unmaintained package is chromium-browser. That's all that matters. :) Regards, David -- 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 -- 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 -- Gareth McCumskey http://garethmccumskey.blogspot.com twitter: @garethmcc Mobile: 071 397 8758 -- 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: chromium no longer maintained
My message was a (too) subtle hint that this thread should die, because it is really not important what is the codebase for what and who's forking and who's not. :) Regards, David -- 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: chromium no longer maintained
On 4 September 2012 13:26, Damian Ivanov damianator...@gmail.com wrote: Hi David, Bad said, Ubuntu is a fork of Debian, it gets forked once in a while after a release to update packages, see wikipedia. Anyway I think chromium is still the most recent, from when 12.04 was released, so may somebody will just need to pick it up for 12.10 I guess 12.10 currently has chromium-browser 20.0.1132.47 Ubuntu 12.10 (144678) Colin 2012/9/4 David Klasinc bigwh...@lubica.net: On 09/04/2012 02:10 PM, Nicolas Michel wrote: In conclusion : Google Chrome is mostly Chromium but not entirely. And one is not the fork of the other because in a fork, the codebase tends to differienciate along the time which is not the case here. One is based on the other, plus some more features. Apart from the licenses, Chrome is to Chromium what Ubuntu is to Debian. But is this discussion really necessary here on this list? Unmaintained package is chromium-browser. That's all that matters. :) Regards, David -- 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 -- 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 -- 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 12.10 Quantal 12.10 beta 2
On 03/09/2012 20:23, Alan Jhonn Aguiar Schwyn wrote: In this page you can get all version (32 and 64 bits) http://cdimage.ubuntu.com/releases/quantal/alpha-2/ I have 12.10 and works really good! Regards! Alan Date: Mon, 3 Sep 2012 20:16:18 +0200 From: johans...@telkomsa.net To: ubuntu-devel-discuss@lists.ubuntu.com Subject: Ubuntu 12.10 Quantal 12.10 beta 2 Good day, Have trouble locating download link for above OS. Would love to have that. Having trouble with daily build for OS. No mouse. Thanks Johan S -- 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 Downloaded alpha 2. Install fine up to choose a picture then hangs. Still a lot of bugs JohanS -- 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: chromium no longer maintained
http://www.webupd8.org/2012/09/new-chromium-stable-and-development.html 2012/9/4 Colin Law clan...@googlemail.com: On 4 September 2012 13:26, Damian Ivanov damianator...@gmail.com wrote: Hi David, Bad said, Ubuntu is a fork of Debian, it gets forked once in a while after a release to update packages, see wikipedia. Anyway I think chromium is still the most recent, from when 12.04 was released, so may somebody will just need to pick it up for 12.10 I guess 12.10 currently has chromium-browser 20.0.1132.47 Ubuntu 12.10 (144678) Colin 2012/9/4 David Klasinc bigwh...@lubica.net: On 09/04/2012 02:10 PM, Nicolas Michel wrote: In conclusion : Google Chrome is mostly Chromium but not entirely. And one is not the fork of the other because in a fork, the codebase tends to differienciate along the time which is not the case here. One is based on the other, plus some more features. Apart from the licenses, Chrome is to Chromium what Ubuntu is to Debian. But is this discussion really necessary here on this list? Unmaintained package is chromium-browser. That's all that matters. :) Regards, David -- 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 -- 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 -- 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: chromium no longer maintained
On Tue, Sep 4, 2012 at 1:52 PM, Damian Ivanov damianator...@gmail.com wrote: http://www.webupd8.org/2012/09/new-chromium-stable-and-development.html Cool. So that will allow users who would like to use chromium-browser. It still looks like no one should be using chromium 18 since there have been a handful of security fixes since that release. Maybe I should file a bug? FWIW: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1045993 For quantal, it looks like version 20 came from debian. I suspect that by the time quantal is released, 20 will be just as bad security wise as 18 is now. Dan -- 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: chromium no longer maintained
On Tue, Sep 4, 2012 at 8:43 AM, David Klasinc bigwh...@lubica.net wrote: who's forking and who's not. :) Cheeky. -- 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
