| === chriadam|away is now known as chriadam | ||
| === chihchun_afk is now known as chihchun | ||
| === charles_ is now known as charles | ||
| reversiblean | I get the error "appmenu-qt: handleReparent 136 The given QWindow has no QMenuBar assigned" when running 'Qt Quick Application' project template in Ubuntu SDK. | 07:00 |
|---|---|---|
| reversiblean | This has been asked before:http://askubuntu.com/questions/605205/how-can-i-get-menu-items-in-a-qt-quick-application. But I can't find any solution. | 07:01 |
| === chriadam is now known as chriadam|away | ||
| donniezazen | Why isn't Qt Creator 3.4 shipped with Ubuntu via main repo or the sdk ppa? | 07:59 |
| mcphail | Am I right in thinking that apps targeting the desktop aren't subject to the same apparmor restrictions as those running on Touch? | 08:01 |
| mcphail | aquarius: bzoltan: I enjoyed the UCS session, but I have major concerns about the C++ side of things | 08:17 |
| mcphail | aquarius: bzoltan: My experiments suggest that apps with a desktop target are unconstrained. Many developers are using the desktop target during development phase. There is the potential for a malicious/faulty piece of C++ code to run "system("rm -rf /");" or worse | 08:19 |
| mcphail | aquarius: bzoltan: unless there can be a constrained desktop environment, no code from the UCS can be trusted | 08:20 |
| bzoltan | donniezazen: there are two reasons. 1) Ubuntu follows the Qt upstream releases and we push the newer bits after massive testing and validation. QtC and Qt are very much go hand in hand. So the day will come when QtC 3.4 will be released. | 08:21 |
| bzoltan | donniezazen: 2) we have a super solid comitment that the developer experience is the same on LTS (14.04) and on the latest stable release (15.04) But when on LTS the Qt is on 5.2 and on Vivid the Qt is on 5.4 we need to be careful. Our Ubuntu SDK is based on the qtcreator-plugin-ubuntu plugin of teh QtC and so we need a QtC+plugin what builds and works the same way on Qt5.2 and on Qt5.4 ... the problem with QtCreator 3.3 and newerreleases is that | 08:24 |
| bzoltan | they are not compatible with the Qt 5.2. | 08:24 |
| bzoltan | donniezazen: So our plan to solve this problem is to decouple the Ubuntu SDK from the distro Qt release and create a QtSDK like package what can be installed on any kind of ubuntu release without worrying about the Qt version installed from teh archive. | 08:25 |
| bzoltan | donniezazen: The schedule is to release the first tech preview of the new SDK in few weeks and to make it the default for 15.10 | 08:26 |
| bzoltan | mcphail: how different teh situation is without UCS and without the SDK on any Ubuntu or on anz other GNU/Linux desktop? | 08:27 |
| mcphail | bzoltan: the session last night concluded that UCS community components neither enforced nor benefitted from review. The assumption was they would allow people with no knowledge of C++ to install components which could enable backend functionality. This group of developers would, by definition, not be able to audit C++ code. This is safe enough within the apparmor constraints on touch, but not on the unconstrained desktop | 08:29 |
| mcphail | bzoltan: it adds trust back into the equation | 08:30 |
| bzoltan | mcphail: I repeat my question :) How different is this with any Linux desktop in this day? In my view as long the desktop apps are not confined the same way as on the phone (convergece!) this problem does exist and indeed represents a major issue for the Linux desktop world. | 08:32 |
| DanChapman | Morning all | 08:33 |
| bzoltan | mcphail: so, yes, you are right .. but UCS does not bring any new risks what is not present already .. true it does not solve the problem either. but I imagine that aquarius would say that UCS has not signed up for solving this application security issue | 08:33 |
| mcphail | bzoltan: The difference is surprise. The components are "perfectly" safe when deployed on Touch but not on desktop. That difference is not immediattely apparent to the developer. Running untrusted C-code is always a risk, but the SDK should work hard to remove that risk. It strikes me as very odd to have a different model for desktop to Touch (particularly with snappy on the way). I think we need a constrained or sandboxed desktop environme | 08:35 |
| bzoltan | mcphail: That is the whole convergence story is about. It is definetly the target for the upcoming releases. | 08:38 |
| mcphail | bzoltan: that is great. In the meantime, though, I'd implore you not to allow C++ containing UCS components into the SDK. The security risks are too high | 08:39 |
| bzoltan | mcphail: But keep in mind that there is no .click or .snapp support available on Desktop. The Ubuntu SDK is about creating .click package right now. The SDK can build for Desktop target, but it is up to the developer to package and distribute it. | 08:39 |
| mcphail | bzoltan: as i said above, most devs are using the desktop target for development for speed/convenience | 08:40 |
| bzoltan | mcphail: I repeate my question :) What risks UCS brings what is not present on any Linux desktop? | 08:40 |
| mcphail | bzoltan: I answered that one already - Surprise :) | 08:40 |
| bzoltan | mcphail: No, you have answered the diff between Touch and Desktop ... i am asking about diff between Desktop with UCS and Desktop without it. | 08:41 |
| bzoltan | mcphail: An avarage developer can bzr branch or git clone any code right now... build it and run it...on any linux desktop. Nothing guarantees that the code does not remove the ~/* | 08:42 |
| mcphail | bzoltan: The desktop target is an SDK target. All the other SDK targets behave differently. That is a surprise in itself and is not immediately apparent. If I was developing a non-SDK app, I know what my target is and how it behaves. The SDK development obfuscates that a little | 08:43 |
| mcphail | bzoltan: it is almost like a breach-of-contract by the SDK. The apparent security isn't provided. I know this is very apparent to you, but it has taken me a month or so of hacking with the SDK to begin to understand the complexities | 08:44 |
| bzoltan | mcphail: With all respect I disagree ... all other targets the SDK creates an installable, checked and uploadable _package_ ... with Desktop target the SDK creates stuff under the build directory ... just as any `make` would do for any other project. | 08:44 |
| mcphail | bzoltan: the packages are invisible to the developer. I never have towrangle with a .click package. I press the big green "play" button whether I am targetting the desktop or emulator | 08:45 |
| bzoltan | mcphail: and again I ask ... how different is the risk with SDK + UCS from QtC on 12.04? In my view it was the same always ... | 08:45 |
| bzoltan | mcphail: Pushing the green button means make + run ... just as if you would make in the terminal and blindly execute the binary it creates. | 08:46 |
| mcphail | bzoltan: The difference is the risk is abrogated by some targets but not others, and that abrogation is not easily apparent | 08:46 |
| bzoltan | mcphail: I disagree ... QtC is availabe in Ubuntu archive for very long time... Pushing the big green triangle with the Desktop target did always the same ... you build and run the project. That is what IDEs are for. | 08:47 |
| bzoltan | mcphail: building and running code in an IDE on a Desktop is nothing new ... this feature is available since IDEs are available on Linux desktops... on _ALL_ Linux Desktops. It is the same on Debian, Suse, Arch, Gentoo. You run the IDE, open the project and run it. If it ruins your ~ then it is a sad thing, but you can not blame the IDE for it. | 08:49 |
| mcphail | bzoltan: I'm not arguing with that at all. But this isn't vanilla QtC. This is the Ubuntu SDK. I disagree that developers view them as the same thing. I open the SDK with a view to developing Ubuntu apps. I have a model for the apps in mind, complete with the security constraints. | 08:50 |
| bzoltan | mcphail: and yet again, it is not an issue what UCS brought in .. UCS is just an interface to a repository ... like git repositories out there. There are many git repos out there. Nothing guarantees that when you clone an unknown git repo and build+run it then it will not do evil things. | 08:51 |
| bzoltan | mcphail: the Ubuntu SDK is based on QtC and we do not disable those QtC's features what have been available for ages | 08:52 |
| mcphail | bzoltan: whilst that's true, the argument to have it _as_part_of_the_SDK_ was that trust wasn't required due to the constraints. I'd be interested to here aquarius's perspective | 08:52 |
| mcphail | *hear | 08:52 |
| mcphail | bzoltan: nothing is going to ruin the reputation of the SDK faster than it becoming a conduit for malware | 08:54 |
| bzoltan | mcphail: UCS has little if anything to do with it. The Ubuntu SDK does offer desktop application development since the day zero. | 08:54 |
| mcphail | bzoltan: and "legacy desktop" is a legitimate target | 08:54 |
| bzoltan | mcphail: I think you put responsibilities on the SDK what does not belong there | 08:55 |
| bzoltan | mcphail: The SDK is a tool. It is not responsible for the damage the application is causing what you develop with the SDK | 08:55 |
| mcphail | bzoltan: ok, maybe. All I know is I won't be able to use UCS components with the current model and that is sad | 08:55 |
| bzoltan | mcphail: like it is not the knife to be blamed if somebody hurts somebody with it | 08:56 |
| mcphail | bzoltan: I don't think we're going to agree here :) | 08:56 |
| bzoltan | mcphail: it is fully your choice to use or not to use the UCS. | 08:56 |
| bzoltan | mcphail: UCS is just a repo ... look at it as to a git repo with zillions of project. | 08:57 |
| bzoltan | mcphail: it is a developer's responsibility to evaluate the component she/he is about to download and integrate to the application she/he is developing. We did cover that issue yesterday on the session. | 08:58 |
| mcphail | bzoltan: I'm aware of the infrastructure. The problem is that it will not be any "better" than github with the current model. That strikes me as a missed opportunity | 08:58 |
| mcphail | bzoltan: There was disagreement on that point in the session. aquarius was very clear his vision for UCS was for people who do not know/understand C++ code | 08:59 |
| bzoltan | mcphail: Neither legaly or moraly the Ubuntu SDK can not be held repsonsible for the damage the applications cause in the space they have rights to cause damage. It is a very fundamental thing. | 08:59 |
| mcphail | bzoltan: of course. I don't disagree with that | 09:00 |
| bzoltan | mcphail: So neither UCS or the SDK does not bring new risks .. and true, they do not solve an old risk. What solves this problem is the confinement what is coming to the Ubuntu desktop too | 09:01 |
| donniezazen | bzoltan: thanks for the explanation. QtC meaning the compiler? | 09:01 |
| mcphail | bzoltan: and when that happens, I'll become a happy UVS user :) | 09:02 |
| mcphail | *UCS | 09:02 |
| bzoltan | mcphail: on the session it was me who complained about the risks the binary blobs represent. We managed to reach a consensus and we will support the source code distribution. So the developer can check the code... and of course we have click-reviewers-tools what we can extend if needed | 09:02 |
| bzoltan | donniezazen: QtC is the QtCreator, the IDE itself | 09:02 |
| donniezazen | bzoltan: that's a very nice idea to decouple those things. I want to run latest stable developmental tool and a solid stable system which LTS tend to be. That fits in perfectly. | 09:03 |
| bzoltan | donniezazen: We had the same objective in our mind. | 09:03 |
| donniezazen | :) | 09:05 |
| bzoltan | mcphail: I would not dismiss the UCS. The UCS is just the infrastructure. I would recommend to you and to all developers to review the code they pull down with UCS instead of blindly running it. But that is a basic thing. I would never excute an unknown binary ... never! That is not safe. | 09:05 |
| mcphail | bzoltan: That is completely untrue. We were all running OpenSSL and bash without auditing the code | 09:06 |
| bzoltan | mcphail: I am sorry, what is untrue? | 09:07 |
| mcphail | bzoltan: you never execute an unknown binary. You have trusted the debian devs and upstream for openSSL. That didn't work out well | 09:08 |
| bzoltan | mcphail: bash or OpenSSL are not unknown binaries | 09:08 |
| bzoltan | mcphail: I never run unkown binaries and I do recommend any other fellow computer users the same attitude. | 09:09 |
| bzoltan | mcphail: regardless if the binary I downloaded as a ready blob or I built it myself without looking at the source code | 09:09 |
| bzoltan | mcphail: it is not safe to got clone unkown projects and blindly build+run them. | 09:10 |
| bzoltan | mcphail: But it is not because git or gittorius would be unsafe ... it is the developer/user who should be safe. | 09:11 |
| mcphail | bzoltan: neither is it safe to trust the repo maintainers or upstream to provide safe binaries. OpenSSL was a very big case-in-point. | 09:11 |
| nik90 | popey: Could you fill in the summary for the core apps sessions that took place. I had other sessions to host at the time and missed them. | 09:11 |
| bzoltan | mcphail: I am sorry, but with all respect I disagree. | 09:12 |
| mcphail | bzoltan: fair enough | 09:13 |
| mcphail | nik90: what's your perspective on the above? If UCS components can run C++ code, they will have unconstrained access to the filesystem when run under the desktop target. Many developers use the desktop target when making apps as it it faster and more convenient than the emulator. This may permit "system("rm -rf /");" or similar from the C++ code which would make all UCS components untrustworthy. Should C++ be allowed before there is a const | 09:17 |
| popey | nik90: will do | 09:17 |
| nik90 | mcphail: I logged into irc only recently and as such was able to follow the conversation only after "mcphail> bzoltan: I'm aware of the infrastructure. The problem is that it will not be any "better" than github with the current model. That strikes me as a missed opportunity" | 09:19 |
| nik90 | mcphail: I think we are progressing step by step and our initial idea entailed components for the ubuntu phone where we have app confinement in place to avoid such evil code. | 09:20 |
| nik90 | mcphail: When Unity8 and snappy arrives on the desktop, I presume that the security model which extends on the phone will to some extent apply to the desktop as well to avoid a rogue application removing user data and going wild and such. | 09:22 |
| mcphail | nik90: my worry is that we will be developing for the phone, but developing on the desktop target for speed and convenience. The guarantees the phone provides are not there on the desktop just now. As such, UCS cannot be trusted if C++ is allowed | 09:22 |
| nik90 | mcphail: true, which is why it is now even more important that the app developer who uses a c++ component to review its code before running it. | 09:23 |
| mcphail | nik90: aquarius's point was that the people using the UCS will not be capable of reviewing C++ code | 09:24 |
| nik90 | mcphail: aquarius's point was also to not have a manual code review since that will slow down things considerably. We cannot have c++ code without introducing manual code review | 09:25 |
| nik90 | while at the same time restricting c++ components would be suicide, we would be losing out on so much | 09:26 |
| aquarius | I see myself mentioned | 09:26 |
| aquarius | let me read the scrollback | 09:26 |
| nik90 | we need to arrive at a compromise | 09:26 |
| aquarius | then I can explain what my point was :-) | 09:26 |
| mcphail | Thanks aquarius - I may have been putting words in your mouth :) | 09:26 |
| nik90 | aquarius: short summary: c++ components should not be allowed since new developers developing apps for ubuntu phone do it on their development which currently runs unity7 and any untested c++ component could potentially run unsafe system commands. | 09:27 |
| nik90 | aquarius: and thereby if UCS allows c++ components to be uploaded, it makes its components untrustworthy. | 09:28 |
| aquarius | OK, I'll address the "risk to developers who are using components while developing on the desktop" point first. Yes, there is that risk. It is no more significant a risk than using modules from PyPI or npm or rubygems while developing, but it is a risk. There is, however, no way to "fix" this without basically making the component store useless (because manual review doesn't work, and the point of ucs is comp | 09:32 |
| aquarius | iled components because they're what's difficult to do). | 09:32 |
| aquarius | This is to some extent ameliorated by confinement, once apps are confined while they're in development, but that's some distance away. That is not the point I was making in the discussion, though; confinement isn't for protecting app developers from malicious components, it's for protecting *users* from malicious components, and that works fine and isn't affected by this conversation. | 09:34 |
| aquarius | (Or, where it doesn't work currently, for desktop app users, ucs does not change that situation at all.) | 09:35 |
| mcphail | aquarius: I think developers should be protected as much as users, particularly if UCS is going to be integrated into the SDK. At this point, the only way I can see that happening is if C++ is not allowed. Most people on this channel are devs. I'm a user who would like to produce a couple of hobby projects. UCS could be a great solution for me but it isn't worth the risk in the current model | 09:45 |
| mcphail | (I say current, but I suppose C++ hasn't been integrated yet anyway with cmake -> qmake transition etc) | 09:46 |
| aquarius | mcphail, there is that risk, yes. I would suggest that this isn't an Ubuntu SDK issue, per se -- it will also prevent you from developing hobby projects in any other language or environment. | 09:47 |
| mcphail | aquarius: yes, I agree. But that's why it is such a missed opportunity. When confinement is convenient for devs as well as users those risks diminish hugely | 09:47 |
| aquarius | Protecting developers from potentially malicious components in the apps they develop is a laudable goal, but I don't think it's a primary goal for the SDK, personally. You can happily still use UCS components and only run the resulting apps in the emulator, or run the whole of Ubuntu SDK in a VM, or wait until app confinement arrives on the desktop, or choose to only use pure QML components from UCS, and I'd | 09:48 |
| aquarius | respect your decision to do all of those. | 09:48 |
| mcphail | aquarius: OK, I'll remove my cat from amongst the pigeons :) | 09:49 |
| aquarius | mcphail, perhaps running a development VM would be most convenient among those; just install Ubuntu 15.04 in VirtualBox and do development there? That's pretty easy, and it isolates your actual desktop away from any development issues. (Or just don't use UCS compiled components yet. :)) | 09:51 |
| * mcphail wishes, at least, the "desktop" target could be renamed "unconstrained desktop" to make the dangers apaprent to amateurs like himself | 09:51 | |
| aquarius | I personally can't use the desktop target anyway, because I'm running the 14.04 LTS like all good people should, and so I can't test on the desktop :-( | 09:52 |
| mcphail | :) | 09:53 |
| mcphail | Anyway, better get this grass cut or I'll be in trouble from t'wife. Thanks for the debate | 09:54 |
| aquarius | no problem! Glad we could help. | 09:54 |
| nik90 | mcphail, aquarius: Perhaps we can add a warning when people download c++ components from the community store to make the "dangers" more apparent. That said considering there are so many workarounds like the emulator, vm etc..we should not restrict c++ components. | 09:54 |
| nik90 | mcphail: thnx for the feedback | 09:55 |
| mcphail | nik90: thanks for listening :) | 09:55 |
| nik90 | :) | 09:55 |
| DanChapman | aquarius: If you wanted to test on the desktop, you could always do something like this with docker. https://bitbucket.org/snippets/dekkoproject/j88X/ | 09:57 |
| DanChapman | it works pretty well on 14.04 | 09:57 |
| aquarius | AlanBell, http://pad.ubuntu.com/uos-1505-themes-on-devices looks OK to me! | 10:41 |
| aquarius | AlanBell, although I do think that an ubuntutheme:// rule is the way forward here; then just tell all html5 app developers who want the native theme to add <link rel="stylesheet" href="ubuntutheme://"> and they're done (and add that to the default templates) | 10:42 |
| max_h_ | hi. I am trying out building a QML-client (desktop) for my go project (only cli so far). I have the sdk running and am able to develop&run the app. My question now is if there is already something like a package/artifact which I can produce to install it on my own machines. | 10:44 |
| === MacSlow is now known as MacSlow|lunch | ||
| popey | renatu: bfiller either of you available for http://summit.ubuntu.com/uos-1505/meeting/22411/calendar-planning/ - specifically around calendar sync | 11:30 |
| === _salem is now known as salem_ | ||
| aquarius | Huh. If I previously said I was interested in attending a UOS session and now I'm not, how do I set that? I don't seem to be able to :) | 12:51 |
| aquarius | aha! the meeting page itself has a "skip this meeting" thing. Cool. | 12:51 |
| === MacSlow|lunch is now known as MacSlow | ||
| markaa | Is there anyone who reviewed applications in the Ubuntu Software Center? thxž | 13:44 |
| akiva-thinkpad | markaa, they may be a bit busy today, as its the last day of the online summit | 13:45 |
| markaa | Okay, thank you very much for the information. | 13:46 |
| AlanBell | aquarius: yeah, <link rel="stylesheet" href="ubuntutheme://"> | 13:57 |
| AlanBell | would be good, and then as a page writer you can decide where to include that in your sequence so it overrides the things you want, but keeps the stuff that is fine | 13:57 |
| aquarius | 'zactly | 14:00 |
| AlanBell | aquarius: is there a neat way to wrap that in some kind of feature detection, so you can just include it or let it fail? | 14:16 |
| AlanBell | fail gracefully in browsers that don't support the ubuntutheme:// protocol | 14:16 |
| aquarius | AlanBell, no. this is the problem with custom URL schemata | 14:16 |
| AlanBell | hmm, how about <link rel="stylesheet" media="ubuntu" href="ubuntutheme://"> ? | 14:18 |
| aquarius | same thing, I think; if the browser tries to fetch it and it doesn't know the thing, it'll blow up. I think | 14:19 |
| aquarius | however, it might just Not Fetch Random URLs | 14:19 |
| aquarius | I'm honestly not sure :) | 14:19 |
| aquarius | would need to be tested across many browsers. | 14:19 |
| aquarius | I didn't thnk of tis. | 14:19 |
| AlanBell | well I don't think it would fetch it, there are -moz-* media thingies | 14:20 |
| AlanBell | https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries#Mozilla-specific_media_features | 14:20 |
| AlanBell | so, in theory it isn't completely nuts to invent our own media attribute (or several) that can be used | 14:21 |
| AlanBell | -ubuntu-gu would be a nice one, so you can conditionally do stuff on big gu and little gu screens | 14:21 |
| aquarius | the style should handle that. | 14:22 |
| aquarius | that's what media queries are for :) | 14:22 |
| aquarius | media *types* are pretty much deprecated now, because they're too pigeonhole-y | 14:23 |
| AlanBell | possibly, just looking down the list of things media queries can be used for | 14:23 |
| AlanBell | aquarius: that doesn't quite work (it tries to load the stylesheet anyway) however it can be fixed with javascript it seems http://christianheilmann.com/2012/12/19/conditional-loading-of-resources-with-mediaqueries/ | 14:33 |
| AlanBell | aquarius: http://web-dev.libertus.co.uk/cluck/ubutest3.html that should do it | 14:36 |
| renatu | charles, any news from silo 8? :D | 14:43 |
| charles | renatu, I don't know what the holdup is there. I'll ask after my current meeting ends... | 14:47 |
| renatu | charles, thanks | 14:48 |
| akiva-thinkpad | there is an ubuntu sdk q&a happening in 5 minutes, join this channel hree if you are interested #ubuntu-uos-appdev-2 | 14:56 |
| aquarius | zbenjamin, hey! When I filed https://bugs.launchpad.net/ubuntu/+source/qtcreator-plugin-ubuntu/+bug/1388655 saying that the reboot and shutdown device pane buttons don't work for the emulator, I wasn't expecting it to be solved by the buttons being removed! | 14:59 |
| ubot5 | Ubuntu bug 1388655 in qtcreator-plugin-ubuntu (Ubuntu Vivid) ""Reboot" and "Shutdown" buttons do not work for emulator" [Undecided,New] | 14:59 |
| zbenjamin | aquarius: well they do not work anymore because it requires root permissions, which we do not have a way to get anymore | 15:00 |
| zbenjamin | aquarius: that all was locked down by the higher security standards on the phone these days | 15:01 |
| aquarius | zbenjamin, :-( fair enough, then | 15:01 |
| charles | renatu, looks like it's under testing now for landing, according to https://trello.com/c/K4mc32CU/1455-ubuntu-landing-008-indicator-datetime-qtorganizer5-eds-charles-renatu alesage was looking at this yesterday and had a question for me but I'd EODed | 15:06 |
| * charles waves at alesage, :) | 15:07 | |
| * alesage waves back at charles | 15:07 | |
| === chihchun is now known as chihchun_afk | ||
| === aaron__ is now known as ahoneybun | ||
| === aaron__ is now known as ahoneyun | ||
| === ahoneyun is now known as ahoneybun | ||
| === salem_ is now known as _salem | ||
| === aaron__ is now known as ahoneyun | ||
| === ahoneyun is now known as ahoneybun | ||
| === _salem is now known as salem_ | ||
| === athairus_oops is now known as athairus | ||
| === aaron__ is now known as ahoneybun | ||
| === salem_ is now known as _salem | ||
| === aaron__ is now known as ahoneybun | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!