Re: Old Firefox versions discourage real-world testing of Ubuntu development versions
On 04/09/2017 20:18, Simon Quigley wrote: > Hello Sebastian, > > On 09/04/2017 08:20 AM, Sebastien Bacher wrote: >> The desktop team has been suggesting to remove firefox from those >> architectures because we don't have the resources to work on those build >> issues and we believe there are little benefit to have firefox available >> on e.g ppc64el but that request has been rejected by the foundation team >> who said they would help to resolve the build issue so we are still >> waiting on that. >> >> In summary, there is no point moving the topic to another list. If you >> want to help either work on a fix for the build issue or try to convince >> foundations than most of our firefox users are on i386/amd64 and that if >> we don't have the resources to deal with build issues in timelined >> fashion (which experience from the previous cycles suggest) then we are >> better off having firefox uptodate on those architectures only than >> staying outdated for most of the cycle for the benefit of architectures >> who don't have actual desktop users. > So then what happens with stable releases? I would much rather have an > out-of-date firefox on devel if it means it's working for release for > most arches. I say this because Lubuntu 16.04 users on PowerPC or > Lubuntu users on the Raspberry Pi 3* will not have an up-to-date Firefox > (see: security issues). From the point of view of Lubuntu Release > Manager, I don't like that option. > > I don't personally know enough about Firefox (otherwise we'd have ALSA > support) to help with this, but I would if I could (maybe I can look > more as to what's involved). But I think I can speak for the many users > of Lubuntu on PowerPC (16.04) and the Pi 3 when I say that this really > should not be an option. Even if it's not me, I really really hope > someone will step up to help with this. > > If anyone wants statistics, I can gather some. > > *Ubuntu MATE ships PowerPC 16.04 images and Raspberry Pi 3 images as well. > There hasn't been a Firefox update on PowerPC on any release since June 2016 (it's stuck on 47.0), and there isn't going to be any more Firefox updates on PowerPC because we don't have the rust compiler building there. Regards, - Chris 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
Re: qreal change in Qt 5.2
On 05/12/13 05:26, Timo Jyrinki wrote: 2013/12/4 Dmitry Shachnev : Also, IIRC, nothing was decided about the SONAME stuff (and I would really want if we got synchronized with Debian on (not)doing the bump). I'd go for not bumping SONAME and doing all rebuilds at once. Debian should lead the way, and since they seem to do either this or not switch from float on arm, this seems a lot better option for the future. According to the bug report Fedora already switched without a bump. -Timo Hi, I second this. Please don't bump the soname independently of upstream as this will leave Ubuntu's Qt5 stack permanently ABI incompatible with everybody else, making it impossible for people to use pre-built binaries on Ubuntu that depend on Qt and aren't shipped in our archive. Regards - Chris -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Let's Discuss Interim Releases (and a Rolling Release)
On 28/02/13 15:31, Rick Spencer wrote: = tl;dr = Ubuntu has an amazing opportunity in the next 7-8 months to deliver a Phone OS that will be widely adopted by users and industry while also putting into place the foundation for a truly converged OS. To succeed at this we will need both velocity and agility. Therefore, I am starting a discussion about dropping non-LTS releases and move to a rolling release plus LTS releases right now. = Role of the LTS Releases = Many users prefer their OS does not change very often. We have a great system in place for these users. Every 2 years Ubuntu release an LTS and users can ride that LTS for the whole support period. Since the LTS comes out every 2 years, they can set a 2 year cadence of updates if they want to stay "up to date" with LTS releases. I think this 2 year cadence works out very well for these users. So, this proposal maintains those LTS releases as anchors for those users. = Role of the Interim Releases = But what about the 3 releases we do every six months in between (what I call the "interim releases")? Who are they for? Why do we invest so much in supporting multiple interim releases at a time? I think the value of the interim releases has run its course: * Customers (people who pay Canonical and others to support Ubuntu) like OEMs and Enterprises have all adopted an LTS to LTS cadence. * Many community members recommend only LTS releases to new users because of its longevity and stability, but the interim releases cause confusion about what is the “right” version for someone to install. * As Scott James Remnant pointed out some time ago, the six month cadence causes features to be either rushed, or to have to wait for six months to be released (along with other problems). (http://netsplit.com/2011/09/08/new-ubuntu-release-process/) * Due to Daily Quality efforts, the development release is now usable every day, so enthusiasts and community members don’t have to wait for a stable release to get the latest software and can participate more fully in the development of Ubuntu * Supporting interim releases is a costly distraction from future development, a cost in both time and attention. = Ubuntu NG = In the meantime, with Ubuntu Touch, the Phone, the Tablet, and convergence of these device experiences with the Desktop, we are in the process of inventing what is essentially a next generation Ubuntu. There will be lots of new code written and code integrated from new sources to accomplish this. The 13.04 Desktop would not have any of this new code, and therefore will be "old" before it is even released. Therefore, I think we should keep LTS releases, but starting now, stop doing interim releases and start a rolling release. More clearly, I think we should: * Stop making interim releases. * Keep doing daily quality and keep improving our daily quality. * Take a monthly snapshot of the development release, which we support only until the next snapshot That means users could choose: * The LTS release * The rolling release updated daily or as frequently as desired * The rolling release updated at least monthly = Benefits of Moving to a Rolling Release = A rolling release instead of interim releases will benefit users, community members, and developers. == For Users == Users who prefer the LTS releases will be unaffected by this change, at least directly. For users who prefer more up to date software, the rolling release will truly provide the latest and greatest software that they are looking for, but without the 6 month wait for a new release. Developers won’t be under pressure to rush a feature in before the release deadline, so users will be receiving more complete software when they do get updates. == For Community == The community will benefit from the simplified model. They will be able to recommend either the LTS or the rolling release, and the users of each will be clear. People who need to provide support may find their lives dramatically simplified, because on any one day, there will essentially be 2 releases with clearly differentiated user bases instead of their user base being distributed across a minimum of 3 supported releases. For example, on any one day, an ISV typically would only have to worry about the LTS releases and the current rolling release, instead of 11.10, 12.04, 12.10 and the current development releases, Raring. == For Core/MOTU Developers == For the people who are actually making Ubuntu (the people on this thread I hope) there are some clear wins as well. 1. Only 2 releases to support, the LTS and the rolling releases. That means fewer SRUs to worry about, and only for LTS releases. More time and attention to focus on what we are building instead of what we had built. 2. Features land when they are ready, not earlier or later. 3. No one will get stuck supporting "old" software that is not part of an LTS release. = Why Now? = There are two answers for
Re: GCC 4.7, STL and binary compatibility of objects built with different language standards
On 11/06/12 16:05, Chase Douglas wrote: I would have assumed that language standard choices should be intermixable across libraries. Is it possible this is merely a bug in GCC? -- Chase Hi Chase, Matthias just pointed me to http://gcc.gnu.org/wiki/Cxx11AbiCompatibility on IRC, so it seems that this behaviour is expected. So, either we need to build some libraries more than once or we need to enforce the language standard for all modules in the archive that expose STL in public API's (or consume these public API's). Regards Chris -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
GCC 4.7, STL and binary compatibility of objects built with different language standards
Hi, I've just finished debugging a Unity crash which occurs when we try a test rebuild of Unity and Nux with GCC4.7 in quantal. Although the original issue was caused by mixing 2 C++ ABI's (because libsigc hasn't been rebuilt yet in quantal), it was no better even after rebuilding libsigc with the quantal toolchain. What is happening is, in GCC4.7, std::_List_base::_List_impl has a data member which only exists for compilation units that are built with -std=c++0x (_M_size). This means that the STL ABI is dependent on the language standard. This obviously causes issues when a process loads libraries that are built with different language standards and which pass std::list's across public API's In the Unity case, both Unity and Nux are built with -std=c++0x, but they use libsigc which is not built with it and which exposes STL objects in its public API. Rebuilding libsigc locally with -std=c++0x is sufficient to make Unity work properly. However, uploading this will probably break anything else in the archive using libsigc which isn't built with -std=c++0x, so I'm not sure of the best way to proceed. In addition to welcoming other people's opinions, I also want to make sure that other people are careful here don't fall in to the same trap :) Regards Chris -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [ubuntu/precise] thunderbird-couchdb 0.0.1-0ubuntu2 (Accepted)
On 12/01/12 21:45, Angel Abad wrote: thunderbird-couchdb (0.0.1-0ubuntu2) precise; urgency=low * Rebuild against libedataserver-1.2-15. Date: Thu, 12 Jan 2012 22:39:46 +0100 Changed-By: Angel Abad Maintainer: Chris Coulson https://launchpad.net/ubuntu/precise/+source/thunderbird-couchdb/0.0.1-0ubuntu2 Hi, Rebuilding doesn't fix this, and it still depends on the old ABI. This extension uses ctypes to load libedataserver, and as such has a hard-coded dependency on a specific ABI. Fixing it really requires me rolling another release to support loading the new ABI. Regards Chris -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: The need for apport hooks
On 06/08/11 23:46, Bryce Harrington wrote: > In any case, these types of reports post-release are most useful in > aggregate rather than as individual bug reports. If they were filed in > some ultra simple crash database (with no signup required of the user) > we could get most of the value without incurring a lot of extra bug > labor. Bryce Something like https://crash-stats.mozilla.com/ ? - It doesn't require users to sign up - It collects duplicates together - Reports can be filtered by product / version / date - Provides some interesting statistics (eg, "Top Changers" is pretty useful for spotting issues early, and rate of crashes per user) - Can associate bug reports with crash signatures - The user can check back on reports they submitted (about:crashes in Firefox will show you this) Also, Breakpad (which is the client software) makes it easy to submit crashes from Firefox and Thunderbird - the crash dialog has a checkbox to enable this, a text area to enter relevant information (which is sometimes used to enter various profanities) and a way to provide an e-mail address (kept private on the server). We actually use Breakpad for Firefox and Thunderbird in Ubuntu already, rather than Apport - primarily so upstream have some visibility of crashes from Ubuntu users. Regards Chris -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing XULRunner from oneiric - call for help
Hi, I've already spent way too much on time on this and I really need to be doing other things, so unless someone steps up now for a particular application that they care about, the remaining pacakges depending on xulrunner will be dropped from the archive by alpha 2. This includes: - xiphos - needs either porting to Webkit (probably a lot of work, but not sure yet) or switched to using is gtkhtml backend (easy, but gtkhtml sucks). - dehydra - already using Spidermonkey, but needs switching to use the proper lib. Probably just minor build-system changes. - mongodb - same as dehydra. - edbrowse - needs porting to Spidermonkey 1.8.5. Based on experience of doing this already for couchdb, gxine and mongodb, this is probably going to be a lot of work for the unfortunate victim who ends up doing this. The list of remaining work can be found at https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-mozilla-rapid-release-maintenance There are still other outstanding items not mentioned here, either because people really shouldn't bother with them, they have someone assigned or I still plan to look at them (eg, vlc, fennec and eclipse). If I've not heard anything by the end of the week, I will assume that nobody cares about the remaining packages and will start filing removal requests for them. Regards Chris On Fri, 2011-05-20 at 15:53 +0100, Chris Coulson wrote: > Hi, > > At UDS we decided that we are no longer going to maintain XULRunner in > the Ubuntu archive from Oneiric onwards (although, this process already > started at the end of Natty when we did some last minute work to demote > it to universe). The reason for this is that the new rapid release > cadence for Firefox [1] makes XULRunner difficult to support for the > entire life of an Ubuntu release (up to 3 years for a LTS). The new > process doesn't really affect us that much for Firefox - we will still > get security updates at a similar frequency as before, and the changes > between these updates will be mostly incremental. The main differences > are that regular security updates (e.g., the upcoming 4.0.1 => 5.0 > update) will bring incremental changes to strings and API, whereas these > previously only happened during major version upgrades (such as the > recent 3.6 => 4.0 upgrade). There will also only be one supported stable > branch in the future, as opposed to the multiple supported stable > branches that we've been used to in the past. > > The development cycle is fairly similar to that of Chrome/Chromium. > > The reason this makes XULRunner difficult to support is that regular > security updates will be exposed to API changes. Although these will be > incremental, it means that the security team would have to spend a lot > of time every 6 weeks or so transitioning and testing applications to > make sure that they continue working. I know this is the case as I > maintain a binary extension for Firefox which I've already had to make > changes in, to ensure that it continues working on the latest nightly > builds of Firefox from mozilla-central. The alternative to this is to > just backport major security fixes to the version of XULRunner we ship > at release time, but we already know from past experience that this is a > lot of work too, and I don't think anybody is going to volunteer to do > that. I really don't think we have enough bandwidth to pursue either of > these options with an acceptable level of quality. > > In addition to this, Mozilla have removed the GtkMozEmbed embedding API > [2], which is still being used by some applications in the archive > (chmsee + anything depending on python-gtkmozembed). > > The work to remove XULRunner is being tracked in the > desktop-o-mozilla-rapid-release-maintenance blueprint [3]. When I > started creating work items I realized that we still have quite a lot of > applications in the archive that are using it. Over the next few days > I'm going to be reviewing these dependencies to work out what we should > do with each package. Where applications do have a hard dependency on > XULRunner, I will try to spend time removing that dependency, e.g., by > porting those to an alternative API (such as Webkit). > > This is where I would appreciate help from anyone who has a particular > interest in any of the affected applications listed on the blueprint. > > Obviously, it would be a shame to lose applications such as chmsee (I > use that, and this is one application which I think is definitely worth > keeping), but I'm not going to spend significant amounts of time working > on applications which aren't that popular or are not very well > maintained. > > So, the current plan of action is: > - Browser plugins that are currently depending on xulrunner-dev just to
Removing XULRunner from oneiric - call for help
Hi, At UDS we decided that we are no longer going to maintain XULRunner in the Ubuntu archive from Oneiric onwards (although, this process already started at the end of Natty when we did some last minute work to demote it to universe). The reason for this is that the new rapid release cadence for Firefox [1] makes XULRunner difficult to support for the entire life of an Ubuntu release (up to 3 years for a LTS). The new process doesn't really affect us that much for Firefox - we will still get security updates at a similar frequency as before, and the changes between these updates will be mostly incremental. The main differences are that regular security updates (e.g., the upcoming 4.0.1 => 5.0 update) will bring incremental changes to strings and API, whereas these previously only happened during major version upgrades (such as the recent 3.6 => 4.0 upgrade). There will also only be one supported stable branch in the future, as opposed to the multiple supported stable branches that we've been used to in the past. The development cycle is fairly similar to that of Chrome/Chromium. The reason this makes XULRunner difficult to support is that regular security updates will be exposed to API changes. Although these will be incremental, it means that the security team would have to spend a lot of time every 6 weeks or so transitioning and testing applications to make sure that they continue working. I know this is the case as I maintain a binary extension for Firefox which I've already had to make changes in, to ensure that it continues working on the latest nightly builds of Firefox from mozilla-central. The alternative to this is to just backport major security fixes to the version of XULRunner we ship at release time, but we already know from past experience that this is a lot of work too, and I don't think anybody is going to volunteer to do that. I really don't think we have enough bandwidth to pursue either of these options with an acceptable level of quality. In addition to this, Mozilla have removed the GtkMozEmbed embedding API [2], which is still being used by some applications in the archive (chmsee + anything depending on python-gtkmozembed). The work to remove XULRunner is being tracked in the desktop-o-mozilla-rapid-release-maintenance blueprint [3]. When I started creating work items I realized that we still have quite a lot of applications in the archive that are using it. Over the next few days I'm going to be reviewing these dependencies to work out what we should do with each package. Where applications do have a hard dependency on XULRunner, I will try to spend time removing that dependency, e.g., by porting those to an alternative API (such as Webkit). This is where I would appreciate help from anyone who has a particular interest in any of the affected applications listed on the blueprint. Obviously, it would be a shame to lose applications such as chmsee (I use that, and this is one application which I think is definitely worth keeping), but I'm not going to spend significant amounts of time working on applications which aren't that popular or are not very well maintained. So, the current plan of action is: - Browser plugins that are currently depending on xulrunner-dev just to include the NPAPI headers can depend on firefox-dev for those instead (eg, packagekit). The alternative is to include a local copy of the headers instead (eg, Totem does that). - Browser plugins that are actually using Mozilla interfaces will need to be modified to not do that (or they will be removed from the archive). An example is gecko-mediaplayer which uses nsIPrefService to modify preferences which change the UA string at run-time. This is an easy fix, as this doesn't even work in Firefox 4 any more (the preferences it touches were removed). - Anything using GtkMozEmbed is doomed anyway - they need porting to another embedding API regardless of what our plans are in Ubuntu. This includes chmsee, screenlets and lernid. - Anything just using Spidermonkey can use libmozjs now, as we have a proper library for this. These should be fairly trivial to fix if they are already using xulrunner-2.0, as they will probably just require some build system tweaks. If they are still using xulrunner-1.9.2, then there may be a significant amount of pain involved, as jsapi changed quite a bit between the 2 versions. - Anything that is using XULRunner as a general purpose toolkit (as opposed to just embedding) is going to be difficult to support, and we are probably just going to remove those from the archive without spending any time on them. This includes instantbird. If anyone has any questions or wants to help out, then please feel free to grab me on IRC. Regards Chris [1] - http://mozilla.github.com/process-releases/draft/development_specifics/ [2] - https://groups.google.com/forum/#! topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion [3] - https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-mozilla-rapid-rele
