[07:33] <dholbach> good morning
[08:01] <dholbach> davidcalle, once you're caught up, you can maybe help me a bit with lp:~dholbach/developer-ubuntu-com/index_page - it's a WIP branch that should go into lp:~developer-ubuntu-com-dev/developer-ubuntu-com/snappy-docs-import - unfortunately I end up with articles which have the wrong parents (call to create_page wrong?) but once that's done we can get it into a final review and then fully merged :)
[08:02] <dholbach> davidcalle, I changed a few things, for example not recreating articles every time and being able specify an index_doc (like intro.md in the docs directory of lp:snapcraft)
[08:02] <davidcalle> dholbach, I've been following your branches last week, haven't tried any of it yet, but it looks great :)
[08:04] <davidcalle> dholbach, btw, do you know why no deploy in the last two weeks, staging seems fine. Issues with the mojo spec?
[08:09] <dholbach> davidcalle, I think the webops team had lots of other stuff to get done as well :/
[08:53] <davidcalle> dholbach, I'm trying to wrap my head about how the logic has changed: when I try the branch in its current state, I end up with a standalone snappy page (the default index one), outside of the existing snappy tree, with no chidren
[09:05] <dholbach> davidcalle, yeah, that's the problem I'm still trying to fix
[09:05] <dholbach> apart from that it all works
[09:07] <davidcalle> dholbach, hmm, where do imported docs end up?
[09:07] <dholbach> in /tmp
[09:07] <dholbach> you can uncomment the removedirs line to keep them around
[09:07] <davidcalle> dholbach, sorry, not end up , but "get published" :)
[09:12] <dholbach> let me check - I tried the lp:snapcraft last - let me check lp:snappy too
[09:24] <dholbach> davidcalle, good question :-/
[09:25] <dholbach> I think there's a problem with the index_doc logic
[09:27] <dholbach> ok, I think I found the issue
[09:27] <dholbach> let me confirm
[09:31] <dholbach> ok, I pushed a change now which should help in the lp:snappy case (no index_doc)
[09:31] <dholbach> it's still not quite right
[09:34] <dholbach> davidcalle, if I print out the variables of the create_page call, I get a different cms.models.pagemodel.Page reference for the parent node every time - this seems wrong
[09:36] <davidcalle> dholbach, hmm. /me looks
[09:44] <dholbach> davidcalle, it's bizarre: in the page tree it looks like snappy/guides/devel went into the top level, but its url is still /snappy/guides/devel/
[09:50] <davidcalle> dholbach, yeah, urls are independent of the actual cms tree
[09:50] <dholbach> oh ok
[09:51] <dholbach> how can I get them to show up in the cms tree nicely?
[09:52] <davidcalle> dholbach, attach the right parent page to it (when creating the page, with the parent argument)
[09:52] <dholbach> right, I think that's what I did
[09:53] <davidcalle> dholbach, looks like it, yeah :/
[09:54] <dholbach> davidcalle, debug output is: http://pastebin.ubuntu.com/12046988/
[09:54] <dholbach>         print(title, "default.html", "en", slug, parent, parent.get_absolute_url(),
[09:54] <dholbach>               menu_title, in_navigation, "last-child", redirect)
[09:55] <davidcalle> dholbach, I need to be afk for a moment. Will try to find a solution after that.
[09:55] <dholbach> sure, no worries
[09:56] <dholbach> I'll move over to the office and have a look at it as well
[09:56] <dholbach> thanks for helping out!
[11:26]  * davidcalle back
[12:15] <dholbach> davidcalle, ok, so all the articles get added in the top level
[12:16] <dholbach> davidcalle, later on they get removed by remove_old_pages
[12:16] <dholbach> maybe something with our use of page_resolver.get_page_queryset_from_path is wrong
[12:20] <davidcalle> dholbach, yeah, I'm at the same step of debugging
[12:21] <dholbach> davidcalle, http://pastebin.ubuntu.com/12047609/
[12:23] <davidcalle> dholbach, ty. Unrelated, but I need to add an "if placeholder.get_plugins()" at line 239 to get the branch to run
[12:23] <dholbach> oh
[12:23] <dholbach> let me check
[12:23] <davidcalle> dholbach, or it errors on placeholder.get_plugins()[0] (index out of range)
[12:24] <dholbach> sure
[12:24] <dholbach> maybe a preexisting page with no placeholders
[12:24] <dholbach> safe to check in any case
[12:26] <dholbach> davidcalle, maybe we can't rely on page_resolver.get_page_queryset_from_path
[12:26] <davidcalle> dholbach, well
[12:26] <dholbach> DJANGO_SETTINGS_MODULE=developer_portal.settings ./env/bin/python -c 'from cms.utils import page_resolver; print(page_resolver.get_page_queryset_from_path("snappy/guides").__dict__); print(page_resolver.get_page_queryset_from_path("snappy/guides").__dict__)'
[12:26] <dholbach> {'_known_related_objects': {}, '_sticky_filter': False, '_db': None, '_for_write': False, '_prefetch_done': False, '_result_cache': None, 'query': <django.db.models.sql.query.Query object at 0x7f470d9dc450>, 'model': <class 'cms.models.pagemodel.Page'>, '_prefetch_related_lookups': []}
[12:26] <dholbach> {'_known_related_objects': {}, '_sticky_filter': False, '_db': None, '_for_write': False, '_prefetch_done': False, '_result_cache': None, 'query': <django.db.models.sql.query.Query object at 0x7f470d9dc410>, 'model': <class 'cms.models.pagemodel.Page'>, '_prefetch_related_lookups': []}
[12:26] <dholbach> two subsequent calls to the same thing give me two different objects
[12:26] <dholbach> maybe that's already saying something(?)
[12:26] <dholbach> or I'm using it wrong :)
[12:27] <dholbach> ah no, sorry - that's the query object
[12:28] <dholbach> the id I get for both page objects is the same
[12:28] <dholbach> so ignore me
[12:29] <davidcalle> dholbach, I've frequently seen pages having two instances, one for live, one for draft, that could be related to what's going wrong
[12:29] <dholbach> hum hum
[12:30] <dholbach> maybe it's make sense to try to find out the parent once per branch and pass that as an object
[12:30] <dholbach> it'd be bizarre if that made it work, but it'd be worth a try and it'd be less hits on the db :)
[12:30] <dholbach> I'll try it out
[12:33] <davidcalle> dholbach, where is the index page getting its parent?
[12:35] <dholbach> davidcalle, that might be the problem
[12:41] <dholbach> davidcalle, hum... it should use the same get_or_create call like the other pages
[12:50] <davidcalle> dholbach, a ton of cached changes suddenly just appeared in my pages tree ;'(
[12:56] <didrocks> zsombi: hey, it seems that QML tries to be too smart for my use case. If I add a list of string as a property in a model object (like model.append({"foo": ["bar", "baz"]})), when I retrieved it, "foo" is a ListModel
[12:57] <didrocks> zsombi: this is a little bit annoying especially when you want to save it like in u1db as the object doesn't cast to anything (and become null)
[12:57] <dholbach> davidcalle, maybe we're missing some .save() and .publish() calls somewhere?
[12:57] <didrocks> zsombi: so, I don't know, seems like I'll have to handle all those transitions and keep 2 properties in my objects to handle the casting manually, doesn't sounds like optimal…
[12:57] <zsombi> didrocks: it's not my fault ;)
[12:59] <dholbach> davidcalle, I found another small issue :)
[12:59] <didrocks> zsombi: ahah, for sure! Just wanted to know if you encountered that and have some tips for me
[12:59] <dholbach> thanks for your persistence :)
[12:59] <davidcalle> dholbach, and in my cached tree there IS a version of my tests that put everything in the right place!
[13:00] <davidcalle> dholbach, no idea when or what though
[13:00] <dholbach> davidcalle, I used a backup of the database for every run of the script
[13:00] <zsombi> didrocks: I think it's obvious, as long as your model is also a ListModel, dynamic list roles would be considered to be ListModels
[13:01] <davidcalle> dholbach, that's smart /me takes notes
[13:01] <dholbach> davidcalle, that's at least what I'm going to do until I have the feeling everything works just fine :)
[13:01] <davidcalle> dholbach, what's your other small issue?
[13:02] <didrocks> zsombi: sure, but then, that would mean that you would expect u1db to be able to store those models by ductyping?
[13:02] <dholbach> davidcalle, when instantiating MarkdownFile, I should take index_doc already into account, so full_url is correctly set
[13:02] <dholbach> that might simplify the code in other places too
[13:02] <dholbach> looking at it right now
[13:02] <davidcalle> ok
[13:03] <zsombi> didrocks: not sure what it does if you declare the role statically in ListModel...
[13:03] <zsombi> didrocks: like ListModel { foo: ["bar", "baz"]}
[13:04] <didrocks> zsombi: well, the list is dynamic though
[13:04] <didrocks> as read from u1db
[13:04] <zsombi> didrocks: just to know what ListModel will think of that role
[13:05] <zsombi> didrocks: I guess it'll be an array then
[13:07] <didrocks> zsombi: instead of ListModel, you meant having a static ListElement in that ListModel to declare the role, right?
[13:07] <zsombi> didrocks: yeah :)
[13:07] <karni> zsombi: thank you :) (the list item swipe thing, IRC message from couple days back probably)
[13:07] <zsombi> karni: :) it shoudl be in trunk now
[13:07] <karni> \o/
[13:07] <zsombi> perhaps not...
[13:08] <karni> :D
[13:08] <zsombi> I guess it slipped the last release
[13:08] <didrocks> zsombi: "ListElement: cannot use script for property value"
[13:08] <zsombi> next one
[13:08] <karni> that's okay :)
[13:08] <didrocks> it doesn't like it :p
[13:08] <zsombi> didrocks: so no wonder it creates ListModel out of it :)
[13:08] <zsombi> dynamically I mean
[13:09] <didrocks> zsombi: yep… :/
[13:12] <dholbach> davidcalle, pushed a change
[13:14] <davidcalle> dholbach, UnboundLocalError: local variable 'plugin' referenced before assignment
[13:15] <davidcalle> plugin.save() is only for plugin update. Creation of a new one doesn't need it iirc
[13:15] <dholbach> davidcalle, ah... it should be: add a plugin = add_plugin()
[13:16] <dholbach> ok
[13:16] <davidcalle> so your add_plugin is fine
[13:16] <dholbach> yes, you're right
[13:16] <dholbach> I checked the code
[13:20]  * didrocks adds ugly workarounds :/
[13:42]  * ogra_ wonders why kalikiana wants me to put frozen joghurt into my pita 
[13:43] <kalikiana> lol
[13:43] <ogra_> :)
[13:43] <ogra_> though given the weather thats probably actually not a bad idea :)
[13:46] <t1mp> I have no idea what you are talking about, but the more I think of it the worse it gets...
[13:48] <ogra_> t1mp, see G+ ;)
[13:48] <svij> for the lazy people: https://plus.google.com/109371351926239865612/posts/deARcXU7K2R
[13:49] <davidcalle> dholbach, I've fixed the old pages removal issue, but I think we should move away from queryset_from_path
[13:49] <dholbach> davidcalle, is there anything else you'd suggest?
[13:52] <davidcalle> dholbach, maybe something using select_related('page__id').filter(path__regex=regex)
[13:52] <davidcalle> dholbach, well, not that exactly, but filters and path regex
[13:53] <dholbach> ok
[13:53]  * davidcalle tries
[13:54] <dholbach> I'm looking into some unrelated changes right now
[13:54] <davidcalle> ok
[13:54] <t1mp> svij: ahh, thanks :)
[14:03] <davidcalle> dholbach, http://i.imgur.com/Fq1Tm8d.png \o/
[14:05] <dholbach> the magic davidcalle is back!
[14:05] <davidcalle> huhu
[14:05] <dholbach> :-D
[14:05] <dholbach> in a call with dpm right now
[14:05] <davidcalle> dholbach, np
[14:05] <dholbach> I'll take a look at it in a bit :)
[14:05]  * dholbach hugs davidcalle
[15:04] <davidcalle> dholbach, here is a diff of my current state (http://bazaar.launchpad.net/~davidc3/+junk/duc-snappy-doc-100815/revision/155)
[15:05] <dholbach> davidcalle, ah yes, the admin change reminds me... there's a few small changes I pushed to different MPs
[15:07] <dholbach> davidcalle, great work
[15:15] <davidcalle> dholbach, I've seen them, do you have any merges you would like a review on?
[15:17] <dholbach> nevermind...... I guess I thought I should split them up logically, but with so many parts moving around, I guess I can just merge two of them already :)
[15:24] <davidcalle> ok :)
[15:32] <JoeyChan> hello  mzanetti   need your help over here  ~
[15:35] <popey> JoeyChan: i think he's on vacation, maybe someone else can help?
[15:36] <JoeyChan> oh no ...  can someone help with the cmake ? I still can't figure it out   popey
[15:37] <popey> ah, sorry. Not sure who else is a cmake expert round here
[15:37] <popey> maybe zbenjamin ?
[15:38] <zbenjamin> i'm no expert but it might help to kno the problem
[15:38] <JoeyChan> better than nothing   :P
[15:38] <zbenjamin> pfft
[15:39] <JoeyChan> zbenjamin:   multi-arch support using cmake
[15:39] <JoeyChan> the reminders-app is using
[15:39] <zbenjamin> JoeyChan: multi arch as in fat packaging?
[15:40] <JoeyChan> zbenjamin:   yes,   armhf, i386, amd64 in one click pak
[15:40] <zbenjamin> JoeyChan: ok, so what is your plan.
[15:40] <dholbach> davidcalle, the case of lp:snapcraft is fixed now too :)
[15:40] <dholbach> woohoo
[15:40] <dholbach> thanks again davidcalle!
[15:41] <dholbach> davidcalle, https://code.launchpad.net/~dholbach/developer-ubuntu-com/index_page/+merge/267533 :)
[15:41] <zbenjamin> JoeyChan: the problem is, how our builders work to build a cmake project cmake is running inside the chroot. It is simply not possible to have one cmake file to rule them all. Except you write a cmake project that works "outside" the chroots
[15:41] <JoeyChan> zbenjamin:   current Shorts-app is pure qml,   & we plan to reboot it as a c++ project,  lp:~mrqtros/ubuntu-rssreader-app/reboot-add-cmake-two-fixes
[15:42] <zbenjamin> JoeyChan: well one solution would be to use qmake ;)
[15:42] <zbenjamin> JoeyChan: the ubuntu sdk supports fat packaging for qmake using the IDE
[15:43] <zbenjamin> JoeyChan: however if you want a automated solution this is what the sdk does:
[15:43] <JoeyChan> zbenjamin:   there's a bash script which can build fat click pack:   http://paste.ubuntu.com/11930209/
[15:44] <JoeyChan> but failed with current cmake
[15:44] <zbenjamin> JoeyChan: yeah thats what the SDK does as well with qmake
[15:44] <JoeyChan> zbenjamin:  the reboot version works will with the SDK, but failed with this script
[15:45] <zbenjamin> JoeyChan: whats the error
[15:46] <JoeyChan> zbenjamin: I didn't test this cos I have only armhf chroot,   popey said he built an big AMD64 pack
[15:46] <zbenjamin> popey: ^ whats the error?
[15:46] <popey> uh
[15:46] <popey> JoeyChan: got the branch link handy?
[15:47] <popey> zbenjamin: I think it just didn't put the binary bits in arch specific folders
[15:47] <JoeyChan> popey:  lp:~mrqtros/ubuntu-rssreader-app/reboot-add-cmake-two-fixes
[15:47] <zbenjamin> popey: ah, yeah thats a project issue then
[15:47] <popey> so you get an executable in the root of the build dir, which is no good
[15:47] <zbenjamin> no, thats a zonk :D
[15:47] <popey> which would need to go in lib/armfoothing/
[15:47] <zbenjamin> popey: well the builddir is not the problem, the installdir is
[15:47] <popey> thats it
[15:48] <popey> thats all I know :)
[15:48] <zbenjamin> popey: why do you make me read cmake files? :D
[15:49] <popey> \o/
[15:49] <davidcalle> dholbach, +1 :) Now there are a few tweaks needed, eg. the info box on non-current pages has disappeared
[15:49] <dholbach> oh
[15:49] <zbenjamin> JoeyChan: ok popey is right, you put the binary into the root folder
[15:49] <JoeyChan> zbenjamin:  seems I just need to know how to make the click generate a script to execute multi-arch~
[15:50] <davidcalle> dholbach, I'll open a pad to list final tweaks? (in any case, we are in a releasable state now)
[15:50] <zbenjamin> JoeyChan: no your project setup it wrong
[15:50] <JoeyChan> zbenjamin:  yes I can put them in dif-folder
[15:50] <zbenjamin> JoeyChan: there are std folders for that
[15:50] <zbenjamin> JoeyChan: let me see
[15:50] <mcphail> JoeyChan: binaries under lib/whatever_arch/bin
[15:51] <JoeyChan> zbenjamin:  could u show an example cmake file ?
[15:52] <zbenjamin> JoeyChan: you have the ubuntu sdk handy right now?
[15:52] <dholbach> thanks a bunch davidcalle
[15:52] <popey> JoeyChan: http://bazaar.launchpad.net/~notes-app-dev/reminders-app/trunk/view/head:/CMakeLists.txt
[15:52]  * nemo halfheartedly pokes mcphail again
[15:52] <popey>     set(BIN_DIR /lib/${ARCH_TRIPLET}/bin)
[15:53] <popey> (and the bit above that which defines ARCH_TRIPLET)
[15:53] <zbenjamin> JoeyChan: check line http://pastebin.ubuntu.com/12048876/ 17
[15:53] <zbenjamin> JoeyChan: line 17
[15:53] <zbenjamin> ah popey has an example too
[15:53] <mcphail> nemo: Hi!
[15:54] <mcphail> nemo: you still keen to work on HW for touch?
[15:54] <nemo> mcphail: well. keen to see if you can get past your link errors ☺
[15:55] <mcphail> nemo: ha! Haven't looked at it as have been on holiday, then swamped with work, but back to normal now so can have a look this evening
[15:55] <nemo> if I recall, koda's speculation was needing to change lib names in SDLh.pas
[15:55] <mcphail> nemo: you around a bit later?
[15:55] <nemo> koda is, unfortunately, on vacation
[15:56] <nemo> mcphail: well, on and off. evenings often dominated by kids
[15:56] <nemo> but, hey, can play IRC tag
[15:56] <mcphail> nemo: OK, I'll poke around and see if I can get any further
[15:57] <JoeyChan> popey:  I remember that u said there's a script to execute the right "arch" file
[15:57] <popey> JoeyChan: yeah, see the lines in the linked cmakelists.txt
[15:57] <popey> 33-41
[15:58] <davidcalle>  np, let's sync tomorrow on all the bright ideas we'll have tonight ;)
[16:00] <zbenjamin> JoeyChan: popey: you need no script to execute the right file on the device. PATH is always set to the right directory
[16:00] <JoeyChan> popey:  no...  I mean,  the desktop file can only point to one executable file, but there r at least 3 files ...
[16:00] <popey> ah, i dont know how that works
[16:00] <popey> ah, as zbenjamin says, PATH fixes that :)
[16:01] <JoeyChan> popey:   so,  I don't need to set anything to the desktop file ?
[16:01] <mcphail> JoeyChan: you .desktop file should point to "nameofbinarywithoutanypath" and it will all work magically
[16:01] <JoeyChan> mcphail:  lol
[16:02] <popey> \o/
[16:02] <popey> I like magic.
[16:02] <zbenjamin> JoeyChan: popey: so all binary parts of the application go into that directory:   lib/<arch_triplet>   executables go into the bin subdir, qml plugins into the "qml" subdir and normal libraries just into the lib dir itself
[16:02] <JoeyChan> mcphail:  I like your answer   :D
[16:02] <mcphail> ha!
[16:03]  * mcphail wonders whether we can get rid of architecture-dependent binaries altogether by employing qemu-static, but that is another matter
[16:03] <zbenjamin> mcphail: that sounds like slooooooooooooooow apps
[16:04] <mcphail> zbenjamin: maybe. Might bring amd64 down to arm speeds :)
[16:04] <JoeyChan> haha~
[16:05] <mcphail> JoeyChan: you haven't experienced magic until you have used qemu-static
[16:06] <JoeyChan> mcphail:  haha   :P
[16:11] <aaler> hi
[16:11] <aaler> how do i compile to executable the app i made in sdk?
[16:12] <aaler> i am new here
[16:27] <zbenjamin> mcphail: its not only about executing armhf apps on x86, how about 3d acceleration , afaik qemu does not support that
[16:34] <mcphail> zbenjamin: yes - might be a problem. I can't quite work out at what level "user" mode qemu interfaces with the graphics drivers
[16:34] <mcphail> I think it is different from standard "system" mode, isn't it?
[16:36] <mcphail> (these things make my brain hurt)
[16:38] <mcphail> In "user" mode, the kernel/modules are running natively rather than being emulated, at the expense of a few broken syscalls
[16:52] <ogra_> mcphail, every time an armhf binary is found, the kernel uses the binfmt module and wraps it in the syscall translator (qemu-arm-static) ...
[16:52] <ogra_> there is no way to fake armhf hardware in that setup (you would need a container to do that and actually translation layers for the GL calles and all)
[16:52] <mcphail> ogra_: where does that leave graphics acceleration? :)
[16:53] <ogra_> nowhere :)
[16:53] <mcphail> aah. Curses!
[16:53]  * ogra_ wrote the initial imple,mentation of qemu-user-static ... 
[16:53]  * mcphail is in awe
[16:54] <ogra_> only for building and test execution though
[16:54] <ogra_> well, that wasnt such a big task, i just combined work of others ;)
[16:54] <mcphail> ogra_: it is very useful for building
[16:55] <ogra_> in any case, if HW comes into play you have lost ... that already starts at a garmbage collector using /proc
[16:55] <ogra_> *garbage
[16:56] <ogra_> i think mono is still not installable in an armhf chroot today
[16:56] <ogra_> due to its GC needs
[16:57] <mcphail> ogra_: so you'd need a full system emulation environment for that?
[16:57] <ogra_> yes, and then you will have problems finding actually one that has 3d drivers :)
[16:58] <mcphail> ogra_: I had hoped qemu-arm-static had solved all my cross-compiling worries :(
[16:58] <ogra_> the android emu is special in that regard, it is a full system emu and has a translation layer for the graphics to actually hand the calls through to the host in an understandable fashion
[16:58] <ogra_> qemu-arm-static is fine for compiling :)
[16:59] <ogra_> just not for running if you actually require HW support
[16:59] <mcphail> ogra_: brilliant. Cheers :)
[17:02] <mcphail> ogra_: were ther ever any plans to use qemu-arm-static for SDK builds rather than the current click chroot setup?
[17:03] <ogra_> mcphail, i think the click chroot execution actually uses it as backend
[17:04] <ogra_> (bzoltan_ should be able to confirm or deny ;) )
[17:04] <mcphail> ogra_: not sure about that - you still need cross-compilers in the SDK click chroots
[17:04]  * bzoltan_ reads backlog
[17:04] <mcphail> ogra_: (which is why I found qemu-arm-static in the first place)
[17:05] <ogra_> mcphail, right, it is a mix ... you use a qemu-arm-static chroot and inject the compiler from the outside
[17:05] <ogra_> that way you compile at host speed using the cross compiler
[17:05] <mcphail> ogra_: aah - I didn't think there was any emulation going on in the click chroots
[17:05] <ogra_> (i know this was the initil design that was discussed, no idea thats still the case)
[17:05] <ogra_> *initial
[17:07] <mcphail> ogra_: reason I ran into problems is because there doesn;t seem to be a pascal cross-compiler: https://adoptingubuntu.wordpress.com/2015/07/10/creating-an-emulated-armhf-chroot-for-development/
[17:07] <ogra_> yes, i think fpc was never fixed on armhf
[17:07] <ogra_> thats one of the few packages we miss for that arch
[17:08] <ogra_> is pascal still a thing ?
[17:08] <mcphail> ogra_: there is a fpc build on armhf, just not a cross-compiler
[17:08]  * ogra_ would have put that in the same corner as cobol :) 
[17:09] <mcphail> ogra_: nemo is keen to port hedgewars, which is pascal
[17:09] <ogra_> i.e. dead and gone but you get immensely right if you still know it :)
[17:09] <ogra_> *rich
[17:11] <bzoltan_> ogra_: the armhf click chroot is an x86 chroot with :armhf dev packages and cross compiler
[17:12] <ogra_> bzoltan_, ah, so no qemu involved at all ?
[17:12] <ogra_> mcphail, why do you need to recompile btw ... cant you just use the binaries from eth archive ?
[17:12] <ogra_> *the
[17:12] <mcphail> ogra_: no - that uses SDL1.2
[17:13] <ogra_> (with some LD_PRELOAD and LD_LIBRARY_PATH hackery)
[17:13] <ogra_> ah, crap
[17:13] <bzoltan_> ogra_:  the click is not depending on qemu-user-static
[17:13] <mcphail> ogra_: the code _can_ use SDL2, but the deb build is on 1.2
[17:13] <ogra_> bzoltan_, yeah, got it
[17:14] <bzoltan_> ogra_:  scratchbox is doing that :)
[17:15] <ogra_> well, scratchbox was using qemu-system last time i looked (4-5 years ago though) and injecting commands via serial into the qemu VM
[17:15]  * ogra_ inspected scratchbox when he did the first qemu-arm thingie 
[17:17]  * mcphail would be keen to know what setup the Ubuntu PPA build machine use to build armhf, so he can copy it
[17:17] <bzoltan_> mcphail:  I am cross packaging with cowbuilder
[17:18] <mcphail> bzoltan_: ooh - that looks good
[17:18] <bzoltan_> ogra_:  I am not sure if I remember right (4-6y) but as I remember SB used both system and user mode ... system for emulating and user for simple commands like building
[17:20] <bzoltan_> mcphail: for me the pbuilder based builders were the most reliable and least troublesome tools with building the SDK stuff... it has silly issues too.. but simple interface and pretty good with building-packaging.
[17:21] <mcphail> bzoltan_: cheers. That is really helpful
[17:22] <ogra_> bzoltan_, well, when i researched it user didnt exist ;)
[17:23] <bzoltan_> mcphail:  I use `cowbuilder-dist wily armhf create` and then just send it the .dsc files. All logs and results go under the ~/pbuilder And you can tune it to the skies. But it was made for .deb packaging in mind .. so when it comes to clikc app packaging the click chroot are the way to go...
[17:23] <bzoltan_> ogra_:  not impossible that i am mixing the SB2 with it... what was a different beast.
[17:23] <ogra_> yeah
[17:24] <ogra_> SB definitely couldnt use it because i wrote the first prototype of it after i looked at it ;)
[17:24] <ogra_> that was later properly implemented by lool in debian then (and renamed to qemu-user-static)
[17:25] <ogra_> i think SB2 then adopted lool's work
[18:18] <ahayzen> popey, as per https://code.launchpad.net/~vthompson/ubuntu-weather-app/reboot-remove-cpp-flag/+merge/267437 this site https://developer.ubuntu.com/en/community/core-apps/weather/ should not read "QML and C++" anymore just QML :-)
[18:22] <cwayne-afk> hi, is there a way to get the index of the listmodel when calling a leadingaction from that listitem?
[18:23] <ahayzen> cwayne-afk, should just be "index" ?
[18:23] <cwayne-afk> ahayzen: i thought so, but that seemed to get me the index of the action itself
[18:24] <ahayzen> hah
[18:24] <cwayne-afk> maybe i was doing something wrong :)
[18:24] <cwayne-afk> oh wow, i havent been afk for awhile, should prolly change that nick now
[18:24]  * ahayzen looks at the music-app's code to port to the new listitems
[18:25] <ahayzen> cwayne, we use index here http://bazaar.launchpad.net/~ahayzen/music-app/refactor-use-sdk-listitems/view/head:/app/components/Queue.qml#L65
[18:26] <ahayzen> cwayne, oh are you putting it in the actions part of the delegate part of the ListItemActions ?
[18:27] <ahayzen> *or the
[18:27] <cwayne> ahayzen: ah, i think I know what I was doing wrong.. (basically the index of the item in my sqlite db doesnt necessarily match the index of the listmodel once one is removed)
[18:28] <cwayne> ahayzen: so i should be able to get any of the info from the listmodel from there though right
[18:28] <ahayzen> from where?
[18:28] <cwayne> the listitem action
[18:29] <ahayzen> as long as you haven't removed itself... and you should be able to get the relevant info
[18:29] <ahayzen> unless you've called the index field in the sqlite 'index' wonder if that would override the actual index property
[18:29] <cwayne> no i think i called it 'id' there
[18:32] <cwayne> will need to take a look.. thanks for the link to the relevant music-app code ahayzen, i think that'll help me quite a bit
[18:32] <ahayzen> no problem :-)
[18:53] <popey> ahayzen: yay
[18:54] <popey> ahayzen: fixed! thanks
[20:12] <mcphail> nemo: ping
[20:34] <mcphail> nemo: if you get a chance, can you have a look at http://paste.ubuntu.com/12051196/ and tell me what I need to change in SDLh.pas (or give me a patched file)? Cheers
[20:34] <nemo> 'k
[20:34] <nemo> heading home tho
[20:34] <nemo> so afk for a little while
[20:35] <mcphail> nemo: np
[20:36]  * mcphail never learned pascal
[21:50] <antony_> Anyone Wanna test a gameboy/gameboy color emulator?
[21:55] <mcphail> antony_: is it in the store?
[21:56] <antony_> Yep its called ubuntu boy. ill swich it to free for a minute so you can download it.
[21:57] <mcphail> antony_: \o/
[21:57]  * mcphail wonders where he left his roms...
[21:58] <antony_> Let me know when your ready
[21:58] <mcphail> antony_: fire away
[21:58] <antony_> Ok set it to free
[21:59] <mcphail> antony_: ok, d/ling
[22:00] <mcphail> antony_: let me dig out a rom and I'll test
[22:03]  * mcphail loves z80 machines
[22:09] <mcphail> antony_: the play area is quite squashed up and the controls are very small. Can I adjust that?
[22:09] <mcphail> antony_: it is slightly better in landscape than portrait but still fairly unplayable
[22:10] <antony_> Ill make the controls bigger.
[22:10] <mcphail> antony_: the aspect ratio of the playscreen is off. I'll grab some screenshots
[22:15] <mcphail> antony_: http://themcphails.uk/tet1.png http://themcphails.uk/tet2.png
[22:15] <mcphail> antony_: good work, though. Plays well!
[22:16] <antony_> What rom did you use?
[22:16] <mcphail> antony_: some old tetris rom I had lying around. Only one I can find on this machine
[22:17] <mcphail> antony_: it is one I used on an old hacked zxspectrum gb emulator
[22:17] <antony_> Thanks for the complement
[22:17] <mcphail> antony_: is it all done in Qt?
[22:17] <antony_> html5
[22:18] <mcphail> cool
[22:18] <mcphail> antony_: seems to play at normal speed and music works well.
[22:20] <antony_> Meizu or Bq?
[22:20] <mcphail> antony_: bq - krillin (the 4.5)
[22:50] <mcphail> can someone remind me how I kill all my unneeded click chroots?
[22:52] <mcphail> for some reason they seem to be multiplying at an alarming rate
[23:26] <antony_> The emulator should be much better now
[23:27] <antony_> Fixed the aspect ratio and made the controls bigger.
[23:32] <mcphail> antony_: looks very much better. However, I don't think the direction pad is working and there is an irritating bug where a double-tap on a button zooms the screen. Don't know if that can be fixed?
[23:35] <antony_> Would imagine disabling zoom with javascript would fix that
[23:35] <antony_> Ill try it
[23:35] <antony_> gtg
[23:35] <mcphail> antony_: great :). Might be worth forcing portrait orientation as well as the landscape mode doesn;t look so good