[00:16] <mohamadf> hello. where can i find ubuntu touch zip file for Galaxy S1?
[00:17] <nhaines> !devices
[00:18] <mohamadf> thanks. ok! this is page of Galaxy S1: https://wiki.ubuntu.com/Touch/Devices/galaxysmtd
[00:18] <mohamadf> but its empty! where i can find the ROM?
[00:22] <nhaines> mohamadf: if it's not there, we don't know.  You'll need to contact whomever is working on the port.
[00:22] <nhaines> But feel free to update that page with anything you find!
[00:22] <mohamadf> ok. thanks. :)
[00:22] <nhaines> mohamadf: do see the notes here: http://al.robotfuzz.com/~al/random/ubuntu-touch-galaxysmtd.txt
[00:23] <mohamadf> no i dont! i'll read it.
[00:24] <nhaines> It was on the S1 page, but a little inconspicuous.  :)
[00:29] <mohamadf> it seems, this: http://al.robotfuzz.com/~al/random/ubuntu-touch-galaxysmtd.txt is just a guide to install cyanogenmod!
[00:30] <mohamadf> thats right?
[00:36] <nhaines> mohamadf: no.  It's how to build your own image.
[03:05] <uhhimhere> can someone port ubuntu touch for the galaxy s7580
[03:07] <nhaines> With a few months, 5 developers, and $100,000 I'm sure it could be arranged.
[03:16] <uhhimhere> nice
[03:16] <uhhimhere> i think i have 100000 lying around somewhere up in the attic
[03:16] <uhhimhere> i have to clear out the bats first though
[03:17] <uhhimhere> howbout this, you go ahead and get the ball rolling and ill go get the 100k
[03:19] <uhhimhere> hey when compiling from menuconfig for a SoC should General-->Embedded system be enabled?
[04:21] <uhhimhere> what tool should i use to make a filesystem.gz ?
[07:31] <gam002> ?
[07:31] <nhaines> !questions
[07:32] <uhhimhere> !port
[07:32] <uhhimhere> !kernel
[07:32] <uhhimhere> nhaines: hey where can I find the dts file for my device?
[07:33] <gam002> how long will it take to finish the project for moto G ?
[07:33] <uhhimhere> samsung has their own kernel available for download on their website; would the dts be in /arm/boot/dts?
[07:34] <gam002> 1 year or more?
[07:34] <nhaines> uhhimhere: I'm sorry, I don't know.
[07:35] <nhaines> gam002: I don't understand your question.
[07:35] <nhaines> gam002: oh, wait it got caught up in a couple of lines scrolling by.
[07:36] <nhaines> gam002: the Moto G is not officially supported and is not being worked on by the Ubuntu developers.  You'll need to contact the community developers working on the Moto G port for more information.
[07:36] <nhaines> !devices > gam002
[07:36] <nhaines> !devices | gam002
[07:36] <nhaines> There may be contact information available there.
[07:37] <gam002> i got here through that link
[07:37] <gam002> how to check private message? i am new
[07:37] <uhhimhere> how do i find out what kind of "!" messages a channel has?
[07:38] <nhaines> gam002: I used the wrong command.  The ubot5 message here is the same information.
[07:38] <gam002> !help
[07:38] <nhaines> gam002: If you use that link, you will see that it points to the XDA forums for the Moto G port, not here.
[07:39] <gam002> nhaunes: its under work in progress
[07:39] <gam002> nhaines:its under work in progress
[07:40] <nhaines> gam002: we don't have any information that isn't on that wiki page.  For further information you'll need to talk to the ones doing the work.
[07:40] <uhhimhere> nhaines: does ubuntu touch use upstream or device kernel?
[07:41] <nhaines> Ubuntu uses the Ubuntu kernel.  The device kernel is loaded in an LXC container for driver support.
[07:41] <gam002> nhaines: actually  it is in the wiki page https://wiki.ubuntu.com/Touch/Devices its is on the botton on the work in progress section "Motorola Moto G"
[07:42] <nhaines> gam002: yes, and it links to the XDA forums as the place to determine more information.
[07:43] <gam002> ook
[07:43] <gam002> Thanks for the info
[07:44] <uhhimhere> nhaines: what kernel does ubuntu use currently
[07:45] <nhaines> uhhimhere: Ubuntu 14.10 uses 3.16.0.
[07:45] <uhhimhere> ok thats quite recent
[07:46] <uhhimhere> so what is relationship with CM?
[07:46] <nhaines> None.
[07:46] <uhhimhere> ok so the device doesnt have to have CM support to be able to run UT?
[07:47] <nhaines> CM scripts were used as a scaffolding for the first public images, but was transitioned to AOSP fairly quickly.
[07:47] <nhaines> Not that I'm aware.
[07:47] <uhhimhere> !AOSP
[07:47] <nhaines> I'm preparing to reboot at midnight for the new year, but I'll be back soon.
[07:48] <nhaines> AOSP is the Android Open Source Project.
[07:48] <nhaines> Just a note, I'll be rebooting my server in about 12 minutes for the new year, but will be back after a couple of minutes.
[07:49] <uhhimhere> ok, why isnt teamhacksung.org online?
[07:49] <uhhimhere> sprry
[07:49] <uhhimhere> wrong channel
[07:49] <nhaines> It's okay.  :)
[07:52] <uhhimhere> so does UT have an arm repository?
[07:52] <uhhimhere> for software
[10:37] <shiggitay> rsalveti,  :P
[13:37] <aquarius> Elleo, hey, I missed your pong :)
[14:11] <Makalak> hi guys, im trying to port ubuntu touch and i have everything setup, but i keep getting this error during compiling
[14:11] <Makalak> undefined reference to '__system_property_serial'
[14:13] <Makalak> checked android.mk and it has the right static lib and the file throwing that error also has the right include
[14:17] <Makalak> well, it seems i dont, for some reason whenever i try to google that error I get redirected to __system_property_get which is setup correctly
[14:41] <venezuela> feliz año
[14:46] <Makalak> if anyone would like the full error http://pastebin.com/QdvAPyBg
[15:28] <venezuela> buenos dias
[17:30] <sasha8787> Какие шансы установить сие чудо на htc one m7 привет
[19:25] <Elleo> aquarius: heya
[19:49] <aquarius> Elleo, hey, pal. You said you had a little C++ thing that worked around the datapath bug
[19:51] <aquarius> Elleo, that'd be a useful thinrd-party binary independent component for nik90_'s component store, I think
[19:51] <aquarius> as would one which runs an external command, which I'm fiddling with now :)
[19:55] <aquarius> I have a dream of doing "ucs install command-run" which downloads a tiny binary component and sets it up for you in the current project. No C++ involved :)
[19:58] <Elleo> aquarius: yeah, I could make a quick stand alone qml plugin that exposes all the QStandardPath stuff, could be handy for people using content hub's file moving stuff too I guess
[19:58] <aquarius> totally, yeah
[19:58] <aquarius> the key point here is, in my opinion, that it's in ucs and one-command-installable as a binary, I think
[19:59] <aquarius> saying "here is source" isn't *all* that helpful for most app devs, who are not doing a C++ project and won't know what to do with the source even if htey had it :(
[19:59] <aquarius> although having the source certainly is useful for people who *are* writing such a project, of course!
[19:59] <Elleo> yeah, I haven't played with ucs at all yet, will take more of a look at it
[19:59] <aquarius> it doesn't exist yet :)
[19:59] <Elleo> ah
[20:00] <aquarius> it started as an idea in my head and then nik90_ got interested, although he's going in a slightly different direction from me
[20:00] <Elleo> yeah, it'd be cool to have a sort of meta-community-SDK type thing for handy community stuff that isn't part of the core SDK
[20:00] <aquarius> that's what I think too :)
[20:01] <aquarius> the big issue in my head is: where does the index of components go?
[20:01] <aquarius> I wish launchpad were searchable.
[20:03] <nhaines> aquarius: you could alway reimplement the Ubuntu app store.
[20:03] <aquarius> nhaines, I have no problem building the service.
[20:03] <aquarius> I have a problem paying for its bandwidth and uptime :)
[20:04] <nhaines> Banner adds and crowdfunding will solve all problems.  ;)
[20:04] <Elleo> aquarius: well you could have an RSS file upload to launchpad that indexes everything
[20:04] <aquarius> Elleo, um?
[20:05] <Elleo> aquarius: e.g. for deepvision I didn't want to host image classifiers, so I did this: https://launchpad.net/deepvision/+download <-- the client reads manifest.xml to know what classifiers it can download from launchpad
[20:06] <Elleo> (there's only one at the moment, so it doesn't make much difference though)
[20:06] <aquarius> Elleo, certainly a component will need a manifest file which describes it. But something needs to index the contents of all the manifest files and make that index searchable.
[20:06] <aquarius> launchpad can't do that, as far as I'm aware; it does not have code search.
[20:07] <aquarius> github does, and would be fine for this, but I'm a bit loath to *require* github for it.
[20:07] <Elleo> aquarius: yeah, but you don't need launchpad to do it, you just need a tool that can generate an index for you which you can upload to launchpad
[20:07] <aquarius> I am ok with requiring the manifest to be uploaded to launchpad, because it's an Ubuntu thing.
[20:08] <aquarius> Elleo, that's the thing: I don't want to host such a tool. It'd need to be online always in order that new components and changes to components are noticed and the reindex occurs...
[20:09] <aquarius> I admit that it's less of a worry if the search index is a separate file which your client downloads
[20:09] <aquarius> rather than an online search engine
[20:09] <aquarius> on the other hand, that's not a very efficient way of doing it :)
[20:09] <Elleo> well if the components have their own manifest the global one only needs to point to that, and then the component's own manifest records changes; for new components presumably there'd need to be some sort of manual process anyway to ensure rubbish/malicious stuff isn't being added
[20:10] <Elleo> so you'd just have a tool that reviewers run like "add-to-manifest lp:mycoolcomponent" that updates the global manifest
[20:10] <aquarius> sorta
[20:12] <aquarius> I think the way I'd do it, if doing it your way, is that my component would have a manifest file in it containing its name, etc, etc, and then I'd upload my component to lp and do "ucs submit lp:mycomponent/manifest.json" which would send an http request to ucs-indexer.com and pass that URL -- ucs-indexer.com would then fetch that URL, update the BigListOfAllComponents.json, and upload that to lp:ucs-indexer/bigl
[20:12] <aquarius> ist.json. Then when a user does "ucs search whatever", the first thing the ucs tool does is download lp:ucs-indexer/biglist.json and then do all the searches etc locally
[20:13] <aquarius> sorta like how deb archives work.
[20:13] <aquarius> I was originally imagining that it'd be an online service.
[20:13] <aquarius> that did the searches and returned results
[20:13] <aquarius> but your idea is interesting!
[20:14] <Elleo> :)
[20:14] <aquarius> can you get a zip file of a branch HEAD from launchpad?
[20:15] <Elleo> not sure, it's not something I've tried before; can't see anything obvious in the UI
[20:15] <aquarius> aha!
[20:16] <aquarius> http://bazaar.launchpad.net/~michael-sheldon/deepvision/trunk/revision/16?start_revid=16 - download tarball
[20:16] <aquarius> so that'd be your download URL
[20:16] <Elleo> ah, cool
[20:17] <aquarius> http://bazaar.launchpad.net/~michael-sheldon/deepvision/trunk/tarball works, nicely, and gets HEAD
[20:17] <Elleo> cool
[20:18] <aquarius> although... can you store binaries without code in LP? I don't think so. Hm.
[20:18] <aquarius> (not without paying, anyway.)
[20:18] <aquarius> and I don't want the code. (it needs to be easily available, but I don't want it in my project.)
[20:18] <aquarius> so maybe not LP...
[20:19] <Elleo> didn't realise there were restrictions on uploading binaries
[20:19] <aquarius> there aren't
[20:20] <aquarius> but if you make a project which is *only* binaries, then it's not open source
[20:20] <Elleo> ah, right
[20:20] <aquarius> which means that you need a paid LP account :)
[20:20] <aquarius> is making a separate branch with only the binaries in too much hassle for component publishers, do you think?
[20:20] <Elleo> would it be so bad to have the project being the source but also containing a zip file with the binaries in?
[20:21] <Elleo> so ucs install grabs just mycoolcomponent.zip from lp:mycoolcomponent
[20:21] <aquarius> oh, so "ucs install elleo" fetches the download URL, gets binaries.zip out of it, and throws away the rest?
[20:21] <aquarius> that might work.
[20:22] <aquarius> or, even... you provide a download URL in the manifest which points directly at the binaries.zip
[20:22] <aquarius> sneaky.
[20:22] <Elleo> if binaries.zip is always the project name you might not even need to do that
[20:23] <aquarius> hrm
[20:23] <aquarius> project name according to the manifest file, you mean.... maybe, yeah
[20:23] <aquarius> (not according to LP. People should not *have* to publish on LP, and should be able to use +junk branches even if they do)
[20:24] <Elleo> ah, right
[20:25] <aquarius> my plan is to make component names be elleo/datapathfixer rather than just datapathfixer, so a component name doesn't have to be globally unique; php composer does that, and I think it's a better idea than just a name. I think. There is a problem of where the name comes from, though.
[20:26] <Elleo> what's the problem with where names come from?
[20:28] <aquarius> how do I stop you creating a package named sil/whatever?
[20:29] <Elleo> ah right
[20:29] <aquarius> :)
[20:30] <Elleo> if it was limited to one location like launchpad *or* github it could be done via their usernames
[20:30] <aquarius> even if usernames aren't in the package name, we still need them in order that you can't upload new versions of my packages.
[20:30] <Elleo> but with both (or more) I could just sneakily duplicate your launchpad username on github
[20:31] <aquarius> yeah
[20:31] <Elleo> if we reintroduced a webservice element we could use email addresses with an email verification stage
[20:31] <Elleo> so it become elleo@gnu.org/mycoolcomponent
[20:31] <aquarius> the issue there is: I am loath to *require* launchpad (because lots of people don't use it and don't want to), but I don't want to really make an Ubuntu-specific service depend on a code environment which *isn't* launchpad
[20:31] <Elleo> and then when uploading I get an email to elleo@gnu.org asking me to confirm the upload
[20:32] <aquarius> thought: if you are a component developer, then you must have an Ubuntu One login account so that you can install apps.
[20:32] <aquarius> which means that you have an LP account, doesn't it?
[20:32] <aquarius> I am honestly not sure whether they are still the same thing under the covers.
[20:33] <Elleo> yeah, I'm not certain
[20:33] <aquarius> who would know? Canonical ISD, as was. pindonga, perhaps
[20:33] <aquarius> ok. for the moment, stipulate that the system is launchpad-based.
[20:34] <aquarius> so the web service to which you submit package manifest URLs requires lp: URLs, but it does not actually have to maintain any state (so you don't log in to it or anything).
[20:34] <aquarius> That makes it much, much easier to run.
[20:34] <Elleo> if that were the case then the <user> part of <user>/<component> could be the repository owner
[20:34] <aquarius> totally, yep
[20:34] <Elleo> which then has the bonus of allowing groups
[20:35] <aquarius> then the security issue is that in order to submit a package lp:someapp/path/ubuntu_component_store.json you have to have the ability to write to lp:someapp
[20:36] <aquarius> I suppose technically I could cause trouble by submitting stuff that's in LP but not in the store yet, but that's pretty edge-casey so I don't care about that. :)
[20:37] <Elleo> yeah, I guess the web service would reject anything without an ubuntu_component_store.json
[20:37] <aquarius> ya
[20:37] <Elleo> so you could only submit something belonging to someone else that isn't in the store if they're got it into a state where it could be in the store already
[20:37] <aquarius> indeed
[20:37] <aquarius> that's why I'm not worried about that :)
[20:40] <aquarius> so, procedure is this: I write a component. I then compile it for arm and amd64 and create mycomponentname.zip containing bin/amd64/mycomponentname.so and bin/arm/mycomponentname.so, put that at the top level of the component, create ubutnu_component_store.json which looks like {"name": "sil/mycomponent", "description": "whatever"} and put *that* at the top level too, then bzr push the whole lot to lp:~sil/anypro
[20:40] <aquarius> ject/anybranch ... and then "ucs submit lp:~sil/anyproject/anybranch", which sends that LP URL to the service.
[20:41] <aquarius> the service fetches lp:~sil/anyproject/anybranch/ubuntu_component_store.json and (assuming it's correct), adds/updates its copy of AllTheComponents.json and then uploads that to LP.
[20:41] <aquarius> does that make sense?
[20:41] <Elleo> yep
[20:42] <aquarius> that works.
[20:42] <aquarius> the client then downloads AllTheComponents.json before it does anything, and then uses that to deal with things, such as what the download URL is for a component, etc.
[20:42] <Elleo> yep
[20:43] <aquarius> I can think of two problems with this model. The first is that it is really tied to LP: it's basically not possible to generalise it to non-LP hosting.
[20:43] <aquarius> and the second is that AllTheComponents.json could be really big if there are loads of components. But that's a ucs 2 problem ;-)
[20:44] <Elleo> also I still think it needs to have a review stage, I'm a bit concerned about everyone using "MyAwesomeLoginComponent" that secretly emails everyone's passwords to sil@kryogenix.org ;)
[20:45] <Elleo> the .zip should possible be built from source in the review stage
[20:45] <aquarius> that's a problem, right enough, but I think it should be out of scope. Because it is a problem entirely composed of stop energy.
[20:46] <aquarius> we do not have the resources to do manual review. The first version of the Ubuntu app store proved that.
[20:46] <Elleo> okay, but remember this conversation when I'm emptying your bank accounts ;)
[20:46] <aquarius> remember that the component will be running in an app which is sandboxed.
[20:46] <aquarius> I can't prove that cutespotify doesn't raid my bank account either -- but the sandbox stops it from doing so :)
[20:47] <aquarius> hence why I am not worried about review. :)
[20:47] <Elleo> aquarius: it doesn't stop it from stealing your spotify password and sending it to me though
[20:47] <Elleo> aquarius: and if there's a general component that ends up in a lot of network enabled apps it could be sending stuff to places even the app dev isn't aware of
[20:47] <aquarius> no, it does not. And we may want some sort of ratings-and-reviews style thing
[20:48] <aquarius> but this is ebay-style "don't use this component" reviewing, not pre-publication block-until-we're-happy code review
[20:48] <aquarius> essentially that doesn't work until you hit the limit case, where you can only upload source and the server builds it for you. Which is what Ubuntu does, and is correct and the right way to solve this problem... but impossible if you're not CAnonical-scale :)
[20:49] <Elleo> yeah, I guess
[20:49] <Elleo> so, step 1) we create a company and get it to canonical size, step 2) we implement ucs
[20:49] <Elleo> easy ;)
[20:49]  * aquarius laughs
[20:50] <quietschie> happy new year :)
[20:50] <aquarius> Mike's Underpant Gnomes Theory Of Project Success :)
[20:50] <Elleo> heh
[20:50] <aquarius> question for you, though; given said zip file of binaries, what needs to happen in a project to make them accessible?
[20:51] <quietschie> has anyone succeeded in getting ubuntu touch on a lenovo yoga tablet 2?
[20:51] <aquarius> that is: what does "ucs install elleo/somecomponent" do after it's downloaded the binary zip and unpacked it into the project?
[20:51] <aquarius> presumably they have to get added to some import path or something...
[20:51] <Elleo> aquarius: I had a feeling that something was being done to have automatic imports from certain directories
[20:52] <Elleo> aquarius: I'm not sure if that ever happened or not
[20:52] <Elleo> aquarius: might be worth looking at what multi-arch click packages do, I think they might do something like that to select an arm vs amd64 binary correctly
[20:53] <aquarius> Elleo, that's the fat binary stuff -- as I understand it, that's for your main binary, not for components. But I might be wrong there. And I do not know whether that has actually *happened* yet or whether it's still just being talked about. I was pushing for it to be done when I was there, which is 18 months ago :) I believe it's done now...
[20:53] <aquarius> good point though -- if you *have* components, then the fat package stuff needs to work for them too, doesn't it?
[20:53] <Elleo> yeah
[20:53] <aquarius> as in: it should already work
[20:54] <Elleo> I think nik90_ wrote something about creating fat packages a little while back
[20:54] <Elleo> so presumably that stuff is working
[20:54] <Elleo> I might be misremembering who wrote it though
[20:54] <aquarius> *nod*
[20:54] <aquarius> where does Ubuntu SDK put my compiled components when it compiles them?
[20:54] <Elleo> http://www.theorangenotebook.com/2014/12/creating-mutli-arch-click-packages.html
[20:54] <Elleo> ^ talks about having a lib/<arch>/ stuff
[20:55] <aquarius> aha, yep, that was the plan, indeed
[20:55] <aquarius> so it's been done
[20:55] <aquarius> rock
[20:56] <quietschie> lenovo yoga tablet? anyone?
[20:56] <aquarius> quietschie, I don't know, I'm afraid.
[20:57] <quietschie> thank you, aquarius. I tried different tutorials, but i'm afraid, fastboot oem unlock fails
[20:58] <quietschie> also i don't exactly know, what fastboot does
[20:58] <aquarius> quietschie, "fastboot" is for Android devices. That's not how you'd install Ubuntu Touch on a Lenovo tablet.
[20:59] <nhaines> aquarius: or *is* it?
[20:59] <aquarius> quietschie, the better approach for now would be to install desktop Ubuntu on that tablet (which you will find more help for) and then switch that desktop Ubuntu to use the touch interface (which is called "Unity 8")
[21:00] <aquarius> quietschie, http://www.roytanck.com/2014/09/16/lenovo-yoga-2-13-first-impressions/ seems to give some thoughts on running Ubuntu 14.04 on the Yoga 2.
[21:00] <quietschie> aquarius, thank you, i'll look into this.
[21:04] <quietschie> aquarius, i think this link has other preconditions...i'm trying to get rid of my android, he seems to be on a windows system
[21:04] <aquarius> quietschie, oh, it's an Android device? Sorry, I misunderstood then
[21:05] <aquarius> quietschie, then fastboot *is* the way to do it... but it may not work.
[21:05] <quietschie> aquarius, so i'm without hope?
[21:06] <aquarius> quietschie, you'll need someone to have done a "port" of Ubuntu touch for the device
[21:06] <aquarius> !ports | quietschie
[21:06] <aquarius> bah!
[21:06] <aquarius> not that one
[21:06] <aquarius> !devices | quietschie
[21:07] <quietschie> there is nothing listed
[21:07] <quietschie> for my device
[21:07] <aquarius> quietschie, the Yoga 2 tablet isn't listed on there. Ubuntu touch is only supported on certain devices by the Ubuntu team, and then there are "community ports" which are done by other people; it doesn't look like anybody's done one for the Yoga 2 tablet, I'm afraid.
[21:10] <quietschie> aquarius, a port is a hard thing to do? How deep do i have to dig into the hardware to do a port?
[21:10] <aquarius> quietschie, I don't know much about porting, I'm afraid. You'll need some pretty heavy skills, though; it is not a trivial thing, and it requires good knowledge of both the hardware and the Ubuntu kernel and startup process, I think.
[21:12] <quietschie> ok...i'll rather create a webapp and use the android :) Thanks for your support, aquarius!
[21:12] <aquarius> https://wiki.ubuntu.com/Touch/DeprecatedPorting has some thoughts on porting, but it says it's deprecated and out-of-date. It should give you some sense of the skills you'll need, though, even if what it describes to do isn't correct yet.
[21:13] <aquarius> quietschie, no problem. I like webapps myself, too :)
[21:30] <aquarius> Elleo, hrm, it has just occurred to me that if the submit server is stateless, then the "ucs submit" request has to hang until the server downloads the json file and checks it. Which might take a while...
[21:30] <aquarius> but I don't want a stateful server because they're hard to run :)
[21:35] <Elleo> aquarius: it shouldn't take a massive amount of time, no harm in having the user wait a few seconds for feedback on their submission
[21:35] <aquarius> you think? fair play
[21:36] <Elleo> aquarius: and the server could be providing status updates while it's doing it ("Downloading manifest", "Verifying manifest", "Applying changes to global index", "Uploading global index", etc.)
[21:36] <Elleo> as long as its clear that ucs is doing something and hasn't just hung I think it's fine
[21:37] <aquarius> that's reasonable, yeah
[21:37] <aquarius> ok, I need to work out how this fat package stuff works, and where ucs install should put things
[21:38] <nhaines> "Reticulating splines", "Squircling squares", "duotoning graphics to aubergine"...
[21:38] <aquarius> now not sure whether it should be called ucs or not; that was my original name for it, but nik90_ is taking that name in a different direction and that might get confusing
[21:38] <Elleo> hehe
[21:38] <aquarius> and I don't want some big pie-fight over a name because I'm not that much of an arse. :)
[21:39] <aquarius> usc, maybe, for ubuntu sdk components. although maybe that's even more confusing ;)
[21:39] <Elleo> aquarius: you could widen the scope to QML in general and call it qcs (QML Component Store)
[21:40] <aquarius> I could, but I think I'd be doing the QML world a disservice there, because I'm only interested in Ubuntu... which means that I will happily make decisions that benefit Ubuntu components and break non-Ubuntu ones, possibly without even knowing that I'm doing it.
[21:41] <Elleo> heh
[21:42] <Elleo> VaaS, Vulnerabilities as a Service ;)
[21:42]  * aquarius grins
[21:43] <aquarius> half the QML people in the world think that pure QML apps are a terrible sin and if you're not basically a C++ programmer then you should go away. I (and ucs) are very much not of that view ;)
[21:46] <nik90_> aquarius: ucs is yours...feel free to take the name :)
[21:47] <nik90_> In the limited time I made a demo concept
[21:47] <nik90_> You can go ahead with merging your implementation as you see fit
[21:48] <nik90_> I am not in the way ;p
[21:49] <aquarius> nik90_, heya, pal!
[21:49] <Elleo> nik90_: yeah, to avoid any possible confusion you should name yours "youcs" ;)
[21:49] <aquarius> nik90_, the approach I've outlined above is rather completely different to where you're going with it
[21:49] <Elleo> no way that could get confusing
[21:50] <aquarius> nik90_, so I'm inclined to suggest that the two should have different names? what do you think?
[21:50] <nik90_> aquarius: give me two minutes to type from my laptop
[21:53] <nik90_> aquarius, Elleo: hi
[21:53] <aquarius> or maybe we go with the approach I outlined in http://www.kryogenix.org/days/2014/11/16/ubuntu-component-store-redux/ ?
[21:53] <nik90_> aquarius: yeah that was my thought
[21:53] <aquarius> where community components are called sil/whatever
[21:54] <aquarius> but I limit it to them being on LP, as above
[21:54] <aquarius> I should write this stuff down, shouldn't I?
[21:54] <nik90_> aquarius: you mean the components submitted by users?
[21:54] <nik90_> should be hosted on lp/
[21:54] <aquarius> nik90_, yep. Obviously your curated store is on LP, because it's an LP branch.
[21:54] <Elleo> aquarius: IRC logs are basically documentation, right? ;)
[21:55] <aquarius> but I'm proposing that my community store is also LP, because it means that the server can be stateless and doesn't need to run accounts and so on.
[21:55] <aquarius> Elleo, that is precisely what I'm trying to avoid ;)
[21:55] <nik90_> aquarius: that is fine by me
[21:57] <nik90_> aquarius: what's your launchpad id?
[21:57] <aquarius> sil
[21:58] <nik90_> aquarius: you should now have full access to https://launchpad.net/component-store
[21:58] <aquarius> nik90_, cool
[21:59] <aquarius> gah, ucs is a shell script
[22:00] <nik90_> aquarius: yeah we had this discussion before :)
[22:00]  * aquarius laughs
[22:00] <nik90_> where I asked if I should convert it into a python script
[22:00] <nik90_> and you said I should wait for your revamp idea
[22:00] <aquarius> yeah
[22:00] <aquarius> which I now have :)
[22:01] <nhaines> Everything should always be converted into a python script.
[22:02] <nik90_> nhaines: yeah. The implementation I made at the time for the summit was just for demo purposes and works with limited set of users
[22:02] <nik90_> s/limited/small
[22:06] <aquarius> Elleo, maybe we don't need the binaries.zip -- just have a top-level folder in the branch called ubuntu_component_store, and then have ubuntu_component_store/bin/$arch/$whatever.so and ubutnu_component_store/qml/$whatever.qml ?
[22:07] <Elleo> aquarius: yeah, sounds reasonable; could make a template for component authors that builds stuff in those dirs too
[22:22] <aquarius> http://www.kryogenix.org/days/2015/01/01/ubuntu-component-store-redux-2/ written so I don't forget the plan :)
[22:27] <Elleo> aquarius: looks good; small thing but the binary components would be shared objects (.so) instead of .o
[22:28] <aquarius> oops
[22:28] <aquarius> will fix that shortly
[22:52] <dobey> ugh, compiled binaries in vcs