[07:41] <dholbach> good morning
[07:53] <zzarr> good morgning
[07:54] <zzarr> morning*
[09:38] <zzarr> hello! I get this error trying to start an application on a armhf arm device, what's wrong? "Cannot mix incompatible Qt library (version 0x50401) with this library (version 0x50501)"
[09:39] <zzarr> or rather, how can I know what lib?
[10:14] <popey> zzarr, http://askubuntu.com/questions/534415/cannot-mix-incompatible-qt-library
[10:14] <zzarr> thanks popey :-)
[10:16] <zzarr> popey, what is Genymotion?
[10:16] <popey> android emulator i think
[10:16] <popey> used by people who make android apps/games for testing on the desktop
[10:17] <zzarr> never mind, "target.path = /usr/lib" was missing in the .pro file
[10:17] <popey> yay
[10:17] <zzarr> okey, thanks
[10:34] <kivi> popey, http://podcast.ubuntu-uk.org/ error 500
[10:34] <popey> thanks
[10:49] <mcphail> popey: found this - http://stackoverflow.com/questions/3662856/how-to-reimplement-or-wrap-a-syscall-function-in-linux - which might help us intercept open() calls
[10:51] <popey> mcphail, interesting
[10:52] <mcphail> the wrapper could just prepend the confined path
[10:56] <zzarr> hello again!
[10:56] <zzarr> I get this error "Cannot find a running Bluez. Please check the Bluez installation." but there's a bluetoothd up and running
[10:56] <zzarr> bluez version 5.36
[10:57] <zzarr> Qt version 5.5.1
[11:48] <bartbes> mcphail, popey: why do you want to intercept open calls?
[11:48] <popey> Imagine you have a linux program / game which writes files in places that (on Ubuntu phone) it can't shouldn't
[11:49] <popey> Rather than heavily patch the upstream app, just intercept those calls and point them in a different place
[11:49] <popey> e.g. calls to open ~/.config/foo-dir should go to ~/.config/foo.developer/foo-dir
[11:50] <bartbes> right, and you want to wrap them at compile-time?
[11:51] <popey> i was thinking more LD_PRELOAD=wrapper foo-app
[11:51] <popey> so you don't touch foo-app, just wrap it
[11:51] <bartbes> that should be fairly easy
[11:55] <popey> bartbes, for you maybe :)
[12:10] <bartbes> popey: have an example: http://hastebin.com/upewegilan.c
[12:10] <bartbes> it's not the neatest, but it works
[12:11] <popey> oooh
[12:11] <popey> did you write that?
[12:12] <popey> <3
[12:15] <bartbes> I think, as long as you conditionally read the mode flag, you could unconditionally pass it, but that probably depends on your abi
[12:16] <bartbes> though iirc the arm and amd64 calling conventions don't differ there
[12:25] <mcphail> Only problem with this is it is not going to catch any file access from anything which isn't compiled. If python or lua is embedded with hardcoded paths, it isn't going to be translated
[12:27] <bartbes> why not?
[12:27] <bartbes> lua calls open, too
[12:27] <bartbes> and I imagine so does python
[12:28] <mcphail> bartbes: but the wrapper won't wrap those calls, will it?
[12:28] <bartbes> oh, because they're from a shared library?
[12:28] <mcphail> yes
[12:28] <mcphail> unless the lib is recompiled...
[12:29] <bartbes> there is another way
[12:29] <bartbes> let's see..
[12:44] <bartbes> actually, it seems it doesn't catch lua because it uses fopen instead of open
[12:44] <bartbes> and fopen and open are both in libc
[12:46] <bartbes> indeed, adding a simple wrapper for fopen makes it work for lua's io.open, too
[12:48] <mcphail> bartbes: nice. I think your dynamic linking and running with LD_PRELOAD is better than the static linking I'd posted above, and can see why this would work whereas my approach wouldn't
[12:48] <bartbes> as for python, it looks like it may be executing the syscall directly, instead of using libc
[12:48] <mcphail> another reason to hate python more
[12:48] <bartbes> ptrace is an option
[12:50] <mcphail> This is good stuff. We might be able to implement a "poor man's container" here
[12:54] <mcphail> So we need to wrap open() and fopen() - anything else you can think of? fdopen() won't need wrapped. Can't think of other libc functions to wrap off the top of my head
[12:55] <mcphail> freopen(), i suppose
[13:10] <bartbes> stuff like stat could be interesting
[13:20] <mcphail> yes - running zgrep "const char *" *.gz in /usr/share/man/man2 suggests my optimism might be misplaced
[13:40] <bartbes> hmm, I've got an LD_PRELOAD running with ptrace
[13:45] <bartbes> it's a bit too effective, I'm currently redirecting opens to /dev :P
[13:59] <bartbes> mcphail: if you LD_PRELOAD this it also works with python: http://hastebin.com/gufoyupafu.c
[14:00] <bartbes> and if you set sharedMemSize to PATH_MAX it should probably work everywhere
[14:04] <mcphail> bartbes: that looks extremely clever. It is going to take a while for me to pick through that to fully understand it, but that is as cunning as a fox who's just been appointed Professor of Cunning at Oxford University
[14:05] <bartbes> the worst bit is extracting the original filename
[14:10] <mcphail> presumably stat() and friends make the SYS_open syscall as well, so this will catch everything?
[14:13] <mcphail> or maybe not...
[14:13] <bartbes> no, stat is a different syscall
[14:13] <mcphail> yes, just spotted that
[14:13] <bartbes> but fopen does trigger the SYS_open syscall
[14:13] <mcphail> yep. Should be enough for most things. Might need sys_create as well?
[14:14] <bartbes> creat might actually be open with O_CREAT
[14:14] <bartbes> nvm, there's also a SYS_creat
[14:15] <bartbes> see /usr/include/bits/syscall.h
[14:16] <mcphail> yep. browsing that just now. Looks as if this could work, doesn't it? It would greatly simplify repackaging .debs as .clicks
[14:48] <bartbes> from the looks of it all those syscalls have a filename as their first argument, so it's just a matter of adding a few ors
[14:58] <mcphail> Yes, prob several of the syscalls with "const char *" parameters will have to be looked at, and some of them with (non-const) "char *"
[14:59] <mcphail> Does this have a big impact on performance, do you think?
[15:00] <bartbes> I'm not sure, it will have a negative impact, how much, I don't know
[15:03] <bartbes> it could definitely help with the initial port, but it's definitely more efficient to patch the application
[15:04] <bartbes> the normal LD_PRELOAD method is probably faster, if only because it relies less on the scheduler and is more targeted
[15:05] <mcphail> bartbes: yes. Most apps will have very few open()s though, so it might not hurt too much to catch the syscalls your second way
[15:06] <mcphail> the magic is going to be working out which paths to rewrite and which paths to pss unchanged
[15:11] <mcphail> bartbes: if it is OK with you, I'll experiment with your LD_PRELOAD approach to reimplement open(), fopen(), stat() etc and see if it turns out to be useful. Would you be kind enough to post a version with a free licence?
[15:24] <farad> Hi there! Can anybody give me a tipp on how to prevent rotation of the screen with QML?
[15:24] <farad> I tried MainView.automaticOrientation but it did not change anything for me
[15:25] <farad> it did not change the behaviour if I set it to true or false, to be more specific
[15:26] <mcphail> farad: you set this in the manifest.json
[15:27] <farad> ah, thank you!
[15:27]  * mcphail can't remember the syntax just now
[15:29] <bartbes> mcphail: here you go: https://bitbucket.org/snippets/bartbes/K8EKk (2-clause BSD licensed)
[15:30] <mcphail> bartbes: you are a gentleman and a scholar
[15:36] <farad> Sorry, but I cannot find any information about Manifest files in the online api-documentation. Could you please point me to something?
[15:36] <popey> you can set it in the desktop file
[15:37] <mcphail> oops. sorry for the misinformation
[15:37] <popey> X-Ubuntu-Supported-Orientations=portrait  (or landscape)
[17:49] <mhall119> popey: when trying to run ubuntu-docviewer-app on qtcreator I get: This application failed to start because it could not find or load the Qt platform plugin "xcb".
[17:49] <mhall119> bzoltan_: zbenjamin ^^ any help you can give?
[17:55] <mhall119> I'm on wily, fwiw
[18:12] <bartbes> mhall119: I have had that too, and I partially followed a discussion about this earlier, make sure you've selected your hosts toolkit, not the new desktop one, and perhaps run cmake again?
[18:12] <bartbes> in any case, it did work for me launching from the terminal rather than the ide, but that's not much of a solution
[18:32] <mhall119> bartbes: by "hosts toolkit" do you mean a chroot?
[18:33] <bartbes> no, just the normal host qt
[18:38] <mhall119> how is that different from the desktop one?
[18:39] <mhall119> QTDIR=/usr/lib/i386-linux-gnu/qt5 for me
[19:00] <bartbes> for me an extra entry appeared
[19:00] <bartbes> with like a fancy name
[23:11] <faenil> ahayzen: yo, any news about the issue you had?
[23:12] <ahayzen> faenil, ah yes, sorry haven't tried it yet. Been busy with landings :-)
[23:13] <faenil> I see, np :=
[23:13] <faenil> :)
[23:13] <faenil> I'm just curious to know ;)
[23:13] <ahayzen> i'll try todo it tomorrow :-)
[23:13] <faenil> cool :)
[23:13] <faenil> gnight o/
[23:14] <ahayzen> night o/
[23:49] <mcphail> popey: might have hit a fatal flaw in our plans
[23:50] <mcphail> popey: don't know how to deal with open()s to /proc/....
[23:50] <mcphail> presumably they are limited by confinement?
[23:51] <mcphail> http://paste.ubuntu.com/14491850/