| === chihchun_afk is now known as chihchun | ||
| === salem_ is now known as _salem | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| zzarr | I know I have asked this before, but is there a way to get my hands on Qt 5.7 for Ubuntu touch? | 10:36 |
|---|---|---|
| Mirv | zzarr: I know I've answered this before :) but you'd need to define which way. the short answer is "probably not" if you want to publish Qt 5.7 using application to current users, as your .click package (if you'd get it to work by bundling Qt 5.7 into it with your app) would be gigantic. when we move to xenial as a base and .snap as the application packaging format, it'd be more liikely. | 11:14 |
| Mirv | zzarr: if there is one specific feature you need that is not available in Qt 5.4 (or Qt 5.6), it could be possible to backport that | 11:14 |
| zzarr | okey | 11:54 |
| zzarr | Qt3D | 11:55 |
| zzarr | but it's not something I need right now | 11:55 |
| zzarr | Mirv, how do .snap packages compare to .click? | 11:56 |
| mcphail | zzarr: surely you'd do it the same way you bundle libs for any click package? | 11:56 |
| zzarr | mcphail, okey, it's that easy? | 11:57 |
| mcphail | zzarr: I haven't packaged a different version of Qt in a click yet, but generally you just run ldd or and equivalent and track down the needed libs | 11:57 |
| zzarr | Mirv, also how does the two compare to .deb? | 11:57 |
| mcphail | zzarr: "objdump -p whateverbinaryyouarepackaging | grep NEEDED" is a good starting point | 11:59 |
| zzarr | so in theory I could do that on a desktop binary, then bundle the armhf equvivalents | 11:59 |
| zzarr | nice | 11:59 |
| mcphail | zzarr: you sometimes need to chase the dependency chain a little further, but that works for most things | 12:00 |
| zzarr | that's good to know | 12:00 |
| zzarr | does the source code for Qt 5.7 help? | 12:01 |
| zzarr | (I have it on the harddrive) | 12:01 |
| mcphail | zzarr: try using any prebuilt Ubuntu packages first. Will save you lots of time | 12:01 |
| zzarr | okey, that's true | 12:02 |
| mcphail | zzarr: you can "apt-get download" the file then "dpkg -x filename extractionpath" to get to the juicy bits | 12:03 |
| zzarr | nice :) | 12:03 |
| mcphail | (or open it with archive manager and drag and drop) | 12:04 |
| zzarr | that's true, I have done that before | 12:05 |
| mcphail | I usually do the downloading from a click chroot, and specify "apt-get download packagename:armhf" to get the correct architecture | 12:06 |
| zzarr | I'm I wish to know, is there a compareson between .deb, .click and .snap packages? | 12:06 |
| mcphail | snaps are very similar to clicks. Really just an evolution of the concept | 12:07 |
| zzarr | that's smart :) | 12:07 |
| mcphail | debs are arcane black amgic | 12:07 |
| zzarr | aren't all package types that? | 12:08 |
| mcphail | snaps and clicks are safer than debs, because the packate does not get to run arbitrary scripts as root at install time | 12:08 |
| zzarr | that's nice | 12:09 |
| zzarr | can a click depend on another click or are they independent? | 12:09 |
| zzarr | and the same question for snap, are they independent? | 12:10 |
| mcphail | clicks are indpendent. Snaps are currently independent (I think) but I'm not sure if that is always going to be the case | 12:11 |
| zzarr | when you (I mean Canonical) take the step and bring our phones/tablets to xenial, will there be an upgrade for the sdk that creates .snap? | 12:13 |
| zzarr | and another fun question (very interesting question I think), would it be possible to make architecture independent packages? | 12:15 |
| mcphail | zzarr: don't know about your first question (I'm just a hobbyist here) but you can already make "fat" multi-arch packages | 12:15 |
| zzarr | nice | 12:15 |
| mcphail | (on click anyway) | 12:16 |
| ogra | zzarr, snappy works a little different in that regard you can have multiple arches under the same name ... so you cn either build a gigantic "all" snap package for all arches or you can have sperate snaps, one for each arch, with the same name | 12:16 |
| ogra | (i guess most people will just prefer the latter and keep their packages small ;) ) | 12:16 |
| zzarr | I was about to write that :) | 12:17 |
| mcphail | ogra: more fool them when the hordes of popwerpc users come complaining ;) | 12:17 |
| ogra | yeah, when their powerpc phones stop working ... | 12:17 |
| ogra | we'll just tell them to instead get s390x phones .. they also look better | 12:18 |
| zzarr | ppc phone, never heard of :D | 12:18 |
| popey | They're a bit bulky | 12:19 |
| popey | And you need a long power-cord | 12:19 |
| zzarr | what about sparc phones? (and ultrasparc) | 12:19 |
| ogra | sadly we dropped sparc ... | 12:19 |
| ogra | i wouldnt mind a sparc phone ... expecially in winter | 12:19 |
| mcphail | zzarr: best thing is to build a click and a snap package by hand, constructing the directory structure and json/yaml manifest | 12:19 |
| ogra | would surely make a good pocket oven | 12:19 |
| mcphail | zzarr: gives you an idea about the internals | 12:19 |
| ogra | well, snaps should bettter be built using snapcraft | 12:20 |
| mcphail | ogra: yes - but he wanted to know the difference between snaps and clicks, so seeing the concepts behind the structure is a good start | 12:20 |
| zzarr | I just hope (and think that) .snaps will be deployed to a phone as easy as a click | 12:21 |
| ogra | well | 12:21 |
| ogra | the concept of handling the package is completely different for both | 12:21 |
| ogra | in the installed system i mean | 12:21 |
| mcphail | indeed | 12:22 |
| ogra | since one is an archive that gets unpacked to disk, the other is a squashfs that gets bind-mounted | 12:22 |
| ogra | so you cant really compare them | 12:22 |
| zzarr | I have browsed through the folders of a installed click on my phone | 12:22 |
| ogra | different filesystem sttructure requirements, different management (snapd vs ... well, there is nothing comparable in click) ... | 12:23 |
| ogra | while they have yaml in common, there isnt much else where they are comparable | 12:24 |
| zzarr | so... a click is essentially a tar.gz (or something) and a snap is a squashfs :) | 12:24 |
| zzarr | can you bind-mount an image (containg a filesystem) directly without using a loop device? | 12:26 |
| ogra | iirc a click is an .ar | 12:26 |
| ogra | (it uses dpkg internals for packaging) | 12:27 |
| zzarr | okey | 12:27 |
| mcphail | ogra: the construction process is fairly similar (if you use the old way of building a snap instead of snapcraft) | 12:27 |
| ogra | well, there is more involved than just bind mounting | 12:27 |
| ogra | you need the right rw areas, you need the right launche that sets up the environment, snapd also manages interfaces that allow/deny your snap to interact with other bits | 12:28 |
| zzarr | ogra, this is a guess, it's mounted with loopback and then a folder is bind-mounted to another part of the fs | 12:28 |
| ogra | in click this is all spread out into other os bits | 12:28 |
| ogra | right | 12:29 |
| zzarr | I see, I actually tried to make my own package type some time ago that worked like that | 12:30 |
| ogra | but the bind mounting is the smallest bit here ... there is a ton fo things snapd manages | 12:30 |
| ogra | (and snap-confine and ubuntu-core-launcher) | 12:30 |
| zzarr | I guessed so, that package type I made was a proof of concept and just a way for me to understand | 12:31 |
| zzarr | I just read about OTA-13 on softpedia, it sounds nice | 12:42 |
| zzarr | I just wonder, will the Android 6.0 part affect the MX4? | 12:43 |
| zzarr | (I hope it will) | 12:43 |
| === _salem is now known as salem_ | ||
| === JanC is now known as Guest58470 | ||
| === JanC_ is now known as JanC | ||
| === chihchun is now known as chihchun_afk | ||
| PaulfraOSAA | Hello, does any body else have problems with compiling projects after updating to (K)ubuntu 16.04? | 17:01 |
| === chihchun_afk is now known as chihchun | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!