Re: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement
On 01/04/2015 09:48 PM, Scott Kitterman wrote: No, of course not. I'm struggling to make sense of Stephen's original response and it seemed to make sense from that perspective. Qt (for example) is clearly now a free software project and it has a CLA. There are others as well. Qt's CLA is as imbalanced as the Canonical one, isn't it? In fact, I would claim that's even worse, because while in Canonical's case there's the *risk* that the software might be re-sold under a proprietory license, with Qt you have the *certainty* that it's been actively sold. Ciao, Alberto -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OAuth Client Ids in packages?
On 12/12/2013 05:55 PM, Rodney Dawes wrote: > Can it not integrate with Online Accounts in Uubntu, and obtain > authentication through that method, to talk to Google? Please do that, if possible. That would also allow you to support multiple Google accounts. :-) Anyway, we have the same issue in Ubuntu Online Accounts, indeed. But as Luke already wrote, there's no expectation that the secret key actually is treated as a secret (Facebook handles this differently, by not requiring a secret key at all). Ciao, Alberto -- 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 talk about arch-specific quilt patches.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2013 03:32 AM, Steve Langasek wrote: > In the case of signon, I see two possible cross-platform > solutions: > > - make signond support reading its configuration from multiple > files (e.g., /etc/signon.d/*.conf), and have the > signon-keyring-extension package provide the integration to enable > the storage backend, or - have signond autodetect the correct > backend at runtime. I think we can do something like the second solution: use the backend specified in /etc/signond.conf if it's found, otherwise just fallback to the default backend. https://bugs.launchpad.net/ubuntu/+source/signon/+bug/1237782 Ciao, Alberto -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJWP5IACgkQVLQegMXeCFL7GgCeMVXWOhTFCxZhFlKj7RbvWohi 8R0An3qqo1D8pSdMbgsCKEcwbcphOQx3 =SnWP -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: MeeGo applauncherd: faster application startup and more
On 06/17/2013 04:14 PM, Marc Deslauriers wrote: Hrm, since this forks instead of doing an exec, it probably doesn't handle kernel security mechanisms well, such as ASLR. I'm not sure how we would handle switching AppArmor policies either, or how well our DBus AppArmor integration would work. Our current plan is to use Upstart for application launching. I'm not sure about ASLR. But at least it should be possible to randomize the loading address the first time that the booster is started (at boot time, maybe?), or the booster can be killed and restarted from time to time. Also, the loading address of the application executable could be randomized. Are there any benchmarks somewhere that show what the performance gains are on application startup using mapplauncherd? I'couldn't find any, but the difference is so huge that you don't need any benchmarks :-) Just watch this: http://www.youtube.com/watch?v=47jP8V-z-ms The second time, the applauncherd hasn't had the time to initialize a new booster process, so a cold start-up happens instead. Ciao, Alberto -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [Ubuntu-phone] MeeGo applauncherd: faster application startup and more
On 06/17/2013 12:35 PM, Thomas Voß wrote: On Mon, Jun 17, 2013 at 10:02 AM, Michael Zanetti wrote: Basically instead of launching your app normally, you give it as an argument to a the so called invoker (/usr/bin/invoker) which has all the common stuff already loaded and forks to your application. To be precise: /usr/bin/invoker just takes the application name and parameters and sends them to applauncherd (via a socket). Applauncherd has *already* forked into a new "empty" process, which is just waiting for the invoker data to load the application. So, what is left to do is just the application loading -- the forking is already done. Ack, here is where the upstart-launcher would come into play. I don't know much about upstart, but my understanding is that the functionality of the /usr/bin/invoker (it's a very small process) could go into upstart-launcher. [...] to create a new QApplication. I don't exactly know the details what they do inside that MDeclarativeCache. I guess one thing is to monitor the state of the created QML view and make the splash screen go away when ready. This is something we would need to investigate further. Alberto, can you take a look at MDeclarativeCache and try to summarize the benefits it provides? I think I explained it in my other message (point 2), but I'll try to be more clear: the booster process, which is the "empty" process waiting for a connection from the invoker to load the real application binary, is linked (or has dlopen()ed) quite a few common libraries, and has already instantiated a QGuiApplication and a QQuickWindow. This means that all the initializations performed by QGuiApplication (don't ask me what it does, I have no idea :-) ) and QQuickWindow (this is quite heavy: it initializes the QQmlEngine, and consequently the javascript engine) are already done by the time that the user starts an application. What happens when the user starts an application, is that the invoker informs the booster process of what binary needs to be loaded. The booster process sets up the security context and loads the real application binary, then invokes its main() method (with proper argc and argv), and all works. Now, to take the pre-initialization into use, the application binary needs not to instantiate new QGuiApplication and QQuickWindow, but just obtain them from the booster (which provides a couple of static functions to retrieve the already instantiated objects). Note that the objects which we want to pre-load are completely up to us. Suppose that we found out that there's another class whose initialization time is quite consistent, we can have the booster pre-create it (if the object's constructor takes no arguments, or if we can provide them later). Likewise, an application is not forced to use our cached objects; indeed, there might be cases where they don't work (the QApplication doesn't work with more than 32 command line arguments, for instance), so corner cases are covered as well. Please read the two links from my initial post (especially the second one); I think they explain the feature much better than how I could do. :-) Ciao, Alberto -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
MeeGo applauncherd: faster application startup and more
Hi all! I'm sending this message both to ubuntu-devel and ubuntu-phone, in the hope of reaching the widest interested audience as possible. However, please reply to ubuntu-devel only. I want to bring to your attention the existence of a project which IMHO would be very beneficial to Ubuntu (especially on embedded devices, but not only): the application launcher originally developed for Maemo/MeeGo. In short, the main features that applauncherd bring to the system are: * faster application startup * support for single instance applications * splash screen while the application is starting up The recommended readings are these: http://apidocs.meego.com/1.0/mtf/launcher.html http://goo.gl/DjGCV In order to be used in Ubuntu, the software itself needs some porting, to remove the dependencies to Qt4, X11, and the AEGIS security framework used in MeeGo. Luckily though, these changes have already been made by the Mer people, who ported the software to Qt5, removed the AEGIS stuff and also simplified a bit the architecture (there isn't an applauncherd daemon any more, but the invoked directly talks to the booster processes). They also wrote a booster for speeding up the startup of applications using QML components, and we could easily modify that to use our Ubuntu SDK components instead. Their code is here: https://github.com/nemomobile/mapplauncherd https://github.com/nemomobile/mapplauncherd-qt https://github.com/nemomobile/mapplauncherd-booster-qtcomponents Please let me know what you think of this. IMHO it's a simple and brilliant idea, it could be integrated with apparmor and also be used to provide sane default callbacks for handling the application lifetime state changes. I've never been directly involved in this project, but given how much I dislike NIH, I'd be happy to collaborate with whoever wants to bring this to Ubuntu. Ciao, Alberto -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [Ubuntu-phone] MeeGo applauncherd: faster application startup and more
On 06/17/2013 09:43 AM, Thomas Voß wrote: Hey Alberto, thanks for bringing this up. Upstart user session will take care of single application instances and integrates with AppArmor to implement our confinement strategy (for >= saucy). The interesting feature from my pov is the accelerated application startup. Is that relying on preloading specific symbols? It relies on mainly two points: 1) preloading libraries 2) preinitializing objects 1) Works by linking the booster process with some libraries that are very likely to be used by the application, and dlopen()'ing commonly used modules. For example, the booster for Ubuntu Qt application could be an executable linking with Qt5Core, Qt5Gui, Qt5Declarative and having dlopen()'ed the Qt Jpeg, Svg, sqlite, plugins. Then, when the user wants to start a Qt5 application, the booster would dlopen() the application's executable and run its main() function; this would be faster than starting an application from scratch because: a) no forking is needed (forking happens as soon as an app has been launched, to be ready for the next one) b) most libraries/modules have already been loaded 2) All graphical Qt applications will use QGuiApplication, and most of them will also initialize a QQuickWindow; these apps could be easily modified to retrieve a pre-initialized instance of these objects, which the booster process has prepared before knowing which application is going to be started next. Note that 1) doesn't actually require any modification to an application's code (it only requires that the main() symbols is exported), while 2) requires some additional 1-line modifications, so that instead of doing: QGuiApplication *app = new QGuiApplication(argc, argv); one would do QGuiApplication *app = MComponentCache::qGuiApplication(argc, argv) Ciao, Alberto -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: smem report from the nexus-raring
On 04/25/2013 08:00 PM, Sebastien Bacher wrote: > Le 25/04/2013 18:06, Sebastien Bacher a écrit : >> I will follow up on the list when I have more informations > > Laney found an issue with glib-networking (relying on > DESKTOP_SESSION="gnome" for detecting the method to use, where we set it > to "ubuntu" which shouldn't use the fallback mode either) and is working > on a fix, details on > https://bugs.launchpad.net/glib-networking/+bug/1172792 > > That will fix the ubuntu-geoip case (which does access proxy through > glib), but the problem with libproxy is still there and affects > signond/signon-ui which are using libproxy directly, we will need to > deal with those as well I suggest looking into a fix in libproxy itself, because it's probably going to be used by all Qt apps starting from Qt 5.1: https://codereview.qt-project.org/46272 Ciao, Alberto -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Online Accounts, QtWebKit and Mir
On 03/20/2013 12:07 AM, Scott Kitterman wrote: > > According to that blueprint, Canonical seems to intend to create (yet again) > a > unique fork, so if you're on a fork that only Canonical is using, you ought > to > be able to do whatever you want. No, you misread it. The "fork" word that appears there is not what we commonly intend by forking: instead, it means branching off the development tree, stabilize it for a while, make a release, then synchronize again with upstream and when the time is mature branch again, and so on. This is what all WebKit ports do. Let's try not to panic whenever we read the "fork" word in a document from Canonical. ;-) Ciao, Alberto -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Online Accounts, QtWebKit and Mir
Hi all! I'm seeking for advice to solve an issue which will affect Ubuntu Online Accounts -- especially on the phone/tablet, but possibly on the desktop as well. I hope you have time and patience to read this long e-mail. :-) Feedback on any point is very appreciated. Current situation = Ubuntu Online Accounts can perform web-based authentications (such as OAuth) on behalf of applications, by opening the website's authentication pages into a QWebView. This is then embedded into the GNOME control center by using the XEMBED protocol. The service which provides this is signon-ui; it is using Qt4 (and consequently the web engine used is WebKit1). The signon-ui service has a very minimal UI, just the webkit view (or username/password/captcha dialogs for non web-based authentication methods) and its process exits after some time of inactivity. Enter Qt5 and Mir = The Ubuntu Online Accounts code can run with minor modifications under Qt5. Qt5 still provides the WebKit1 engine, but the only way to access that is via the QWidget-based bindings. I've been told that QWidget-base applications don't work under Mir -- I'm not to worried about that: I guess it's a temporary defect with the Mir QPA plugin which will get eventually fixed (maybe it's fixed already, I don't know), but I mention it here just for completeness, ready to stand corrected. :-) Qt 5.0.x does not support XEMBED. However, for Qt 5.1 there will be support from it, provided by the QPA backends (currently this is only implemented in the XCB backend). To use it, one doesn't need any platform-specific APIs [0]. So, as far as the desktop (using X11) is concerned, Ubuntu Online Accounts will continue to work just fine in the future. Enter QtQuick 2.0 and WebKit2 = Apps in the phone/tablet are mostly QtQuick 2.0 based, and so will be the (still under design) System Settings panel. Despite the fact that signon-ui's UI is minimal and just encompasses a WebView, there might be some reasons to move the implementation away from QWidgets and use QtQuick 2.0. However, currently QtQuick 2.0 offers only the WebKit2 API, which is probably optimal for a standalone browser, but which is still missing some features required by Online Accounts: the main one is the possibility of having a per-view cookie jar. This is essential to support multiple accounts per provider, and also greatly increases security because it completely isolates the cookies you get while logging into an online account with those from other online accounts of from the user's browser (if it's QtWebKit based as well). I've been discussing the issue with QtWebKit developers, but as of now I'm still unclear about their opinion: http://comments.gmane.org/gmane.os.opendarwin.webkit.qt/3484 As far as I can see it, these are the possibilities: 1) Implement the per-view cookie jar in WebKit2. This is the best end result, but the hardest to achieve -- at least for a non WekBit expert like me: it involves digging deep into WebKit code and, given all the big stakeholders involved, passing through the code reviews could take ages. 2) Same as above, but while the reviews are in progress, apply the patch to QtWebKit's Ubuntu packages. The longer the review process takes, the more painful this solution will be. 3) Implement QtQuick 2.0 bindings for WebKit*1*, and keep them as a separate module. I did this already, and it's more or less working [1]. This can link against an unmodified libQt5WebKit.so, but in order to build the module we need to use some private QtWebKit headers -- and since these headers are generated during the build, it practically means that we need to have the QtWebKit source tree available in order to build this. 4) Like #3, but move the module as an Ubuntu patch for QtWebKit. This is far less dangerous than #2, because we are not modifying the QtWebKit build, just adding a very small extra .so (which we might drop in the future). 5) Like #4, but submit the code upstream. As you can read from the links above, the QtWebKit developers are not very fond of receiving more WebKit1-based code. Still, it might be possible to move both the QtQuick 2.0 module and the QtWebKitWidgets modules out of the tree by working on a common interface, so maybe this approach might be well received. Some words about security = As discussed during the last virtual UDS, the Ubuntu Engineering security team will provide security updates for WebKit [2]. Both QtWebkit's QWebView and the QML WebView are built from the same source tree, so my understanding is that both would be supported by the security team (even if involuntarily). That's because WebKit2 essentially uses the same code as WebKit1, just spread over different processes. In fact the libQt5WebKit.so library contains most symbols used in WebKit1 as well; the libQtWebKitWidgets.so library, as its file shows, it's just a tiny wrapper around the Webkit1 API. si
