[01:15] how do you switch to the alpha channel? or maybe install a gui? [01:15] also why is man not included and why is the root fs image ext4 instead of squashfs? === c74d is now known as Guest7878 === c74d3 is now known as c74d [07:00] good morning [07:21] Good morning all [07:22] hey dholbach and davidcalle, good morning [07:22] mvo, hello, I don't seem to be able to catch rcj on IRC, any idea at what time he is around? [07:25] hi mvo [07:30] davidcalle: a good question, he is US timezone AFAIK [07:33] mvo, thanks, I've noticed, but still no luck in my european evenings. Nothing urgent though, I'll drop him an email. [07:36] * mvo nods [08:21] Morning folks, I've been asked a question on G+ which I'd like to check with you [08:22] willcooke: what is the question? [08:22] Will it be possible to install Snaps on the U7/.deb based at some point in the future? [08:22] Either for developers to test their packages [08:23] or as an alternative to .deb based application installation [08:28] willcooke: I think so, yes. not sure when, but conceptually I see no reason why that would not work. you can have snap/deb in parallel just fine [08:28] cool, thx mvo [08:35] Good morning all; happy Senior Health & Fitness Day! 😃 === erkules_ is now known as erkules === sabdfl_ is now known as sabdfl [11:41] asac, https://code.launchpad.net/~rick-rickspencer3/+junk/go-template [11:41] Chipaca, ^ since you were there last week ;) [11:50] mvo, where do I file a bug against snappy build? [11:52] rickspencer3, see topic ;) [11:52] oops, it was beneath the fold in xchat-gnome and I didn't see it :) [11:56] thanks ogra_ [11:56] np :) [11:59] pitti, do you happen to know what handles /etc/mtab in the boot process (pre and post systemd) ? [12:00] for pre-systemd i see /etc/init.d/checkroot.sh but i'm not sure that is used at all [12:15] ogra_: how do you mean "handle"? [12:15] /etc/mtab is not the thing you are looking for :) [12:16] ogra_: post-systemd> entirely ignored; the Debian package turns it into a symlink to /proc/mounts for legacy stuff that parses it, but systemd, util-linux, our boot scripts etc. all don't care [12:16] ogra_: I'm not entirely sure about mountall, though [12:17] ogra_: we never ran /etc/init.d/checkroot.sh, both upstart and systemd override it [12:19] hmm, k [12:20] pitti, we have some code on the system-image server that unpacks/repacks the rootfs tarball to enforce it being a symlink ... i'm not really sure why it is there [12:20] ogra_: it's only there because some stone old software might look at it [12:21] ogra_: which is hopefully not the case on touch, and most certainly not on snappy, so if we just want to remove it there, please let's [12:21] yes, and we dont use any such software on the phone and snappy images [12:21] yet stgraber once added code for it [12:21] this is sorta like the x86 A20 gate -- everyone hates it, it's broken, but it's sticky as glue :) [12:22] ogra_: I think we shoudl start dropping it from snappy; we can test the core, snapps should not ever care [12:22] and drop it from touch as well if we ever aren't in a "deep freeze/product release round the corner" situation [12:22] well, we use systemd, so i guess on snappy it is already gone [12:22] touch not so much ... and i cant reqally find out why [12:23] ogra_: as I said, our systemd package creates an /etc/mtab -> /proc/mounts symlink for legacy stuff compat [12:23] initrds /init makes it a symlink on start [12:23] but i dont find any code that turns it back into a file after run-init [12:23] yet, on my desktop installs it is a file [12:24] ogra_: oh - we had a bug about that the other day [12:24] ogra_: I don't remember which package any more, it was something like lxcfs or so [12:24] somethinng removes the link and makes it a "proper" mtab again [12:24] which accidentally turned an mtab symlink into a file [12:25] but I added a postinst to fix that, so maybe that got broken again [12:25] ogra@styx:~/Devel/tmp/meizu$ ls -l /etc/mtab [12:25] -rw-r--r-- 1 root root 1096 Mai 22 12:59 /etc/mtab [12:25] thats my utopic laptop [12:25] rickspencer3: what problems did you bump into? (bug#?) [12:25] ogra_: ah, utopic [12:25] ogra_: yeah, we didn't have any transition code under upstart [12:25] Chipaca: https://bugs.launchpad.net/snappy/+bug/1459212 [12:25] Ubuntu bug 1459212 in Snappy "snappy build does odd things with poorly formed /meta/package.yaml" [Medium,Confirmed] [12:25] pitti, well, i doubt it is any different in upstarted vivid installs [12:25] which touch is [12:25] * genii sips and ponders "odd things" [12:26] mvo: maybe we should state “snappy build is a SISO pipe” [12:26] ogra_: right [12:26] ogra_: sorry, you said "desktop", and I implied "vivid/wily" [12:26] but grepping recursively for mtab in /etc/init* doesnt really reveal anything ... [12:26] Chipaca, Chipaca https://bugs.launchpad.net/snappy/+bug/1459212 [12:26] rickspencer3: yep, mvo pointed me at it [12:26] probably mountall :/ [12:26] * ogra_ goes to get the code [12:26] ogra_: right, transition happens by /lib/systemd/system/debian-fixup.service calling /lib/systemd/debian-fixup [12:27] rickspencer3: at least, an easy fix :) [12:27] ogra_: so what are you looking for now? [12:27] pitti, a way to make mtab not being created in the vivid touch images [12:27] and just keep the symlink around that we get from the initrd [12:27] ogra_: ah, right; TBH I have no idea what creates it in the first place [12:28] i want to drop the link creation from the system-iage server so we dont need to re-pack the rootfs anymore [12:28] this thing is like "slap, go away", and it comes back [12:28] yeah [12:28] i remember discussion turning it into a symlink around dapper time :) [12:29] *discussing [12:29] * pitti grep -w mtab * in /var/lib/dpkg/info [12:29] * pitti sees bug 906293 and closes it [12:29] bug 906293 in util-linux (Ubuntu) "Get rid of /etc/mtab and store userspace options in /run" [Low,Triaged] https://launchpad.net/bugs/906293 [12:30] ogra_: hm, neither package maintscripts nor debootstrap [12:31] live-build? livecd-rootfs? [12:31] pitti, yeah, it must be something in the boot process ... else the symlink the initrd created would just stay around [12:31] Übereinstimmungen in Binärdatei /sbin/mountall. [12:31] * pitti RTFC [12:31] sigh, i knew it [12:31] yeah [12:32] so i will do then ... [12:32] ./src/mountall.c:written_mtab = TRUE; [12:32] ./src/mountall.c:if (written_mtab) [12:32] fairly sure we have a "winner" [12:32] yep [13:12] mterry: hey, so made my snaps, but then when i ran clocks, it gave me [13:12] https://pastebin.canonical.com/132060/ [13:12] did you ever hit that? [13:12] weird RAOF hit it last night as well when he tried... [13:12] kgunn, oh right! [13:13] kgunn, export LC_ALL=C.UTF-8 [13:13] kgunn, sorry, should have been part of my instructions [13:13] np! [13:13] kgunn, any specific reason to use a secret pastebin in the public channels ? [13:13] :) [13:13] nope sorry [13:19] mterry: success!....now matters of curiosity, why does it herald "bad system call" on running clocks [13:19] probably seccomp blocking it ? [13:20] kgunn, interesting, not sure. I'd have to look at a strace -- didn't remember seeing that [13:20] kgunn: dmesg should tell you what syscall was blocked [13:20] kgunn: then you can use "scmp_sys_resolver $nr" to figure out what the number means [13:27] thanks mvo [13:28] dirty dog....seems it no longer appears when i launch clocks, like a one time failure ? [13:28] rcj, ping [13:29] davidcalle, hi, what's up? [13:30] rcj, hey, do you mind having a look at this Amazon ec2 doc bug? https://bugs.launchpad.net/developer-ubuntu-com/+bug/1456390? [13:30] Ubuntu bug 1456390 in Ubuntu Developer Portal "Snappy ec2 getting started - various issues" [Undecided,New] [13:31] davidcalle, I can in a few minutes. My mouse pointer has disappeared so I need to restart before I can do precision tasks like clicking on links. I'll be back on in 5m. [13:31] rcj, :) [13:39] davidcalle, I've added our team to the bug and I'll get us started on this [13:41] rcj, many thanks! I'll take care of updating the doc, just ping me or add changes in a comment on the report. [13:53] davidcalle, I provided answers and assigned it back to you. [13:54] rcj, great, thanks :) [14:03] good morning. [14:55] bug 529993 [14:56] bug 529993 in mountall (Ubuntu) "mountall produces unharmful error messages when /etc/mtab is symlink to /proc/mounts" [Low,Fix released] https://launchpad.net/bugs/529993 [15:37] sergiusens: what's the plan with the cmd directory? [15:39] elopio: we need to rewrite what is inside the code; the external interface (cli) should behave the same [15:40] elopio: but basically moving to client/server; so the client could be easily mocked when this happens too ;-) [15:42] sergiusens: good. I was thinking that the cli conformance tests should be unit tests, leaving just a few functional tests. But I started digging how to fake the replies and that was not easy. [15:48] @reviewlist [15:48] https://code.launchpad.net/~stephen-stewart/webdm/remote-and-local-collections-with-sorting-and-filtering/+merge/260305 | No reviews (less than a day old) [15:48] https://code.launchpad.net/~sergiusens/webdm/godepsForBuilding/+merge/260156 | No reviews (less than a day old) [15:48] https://code.launchpad.net/~stephen-stewart/webdm/repent-harlequin-said-the-ticktockman/+merge/260120 | No reviews (less than a day old) [15:48] https://code.launchpad.net/~stephen-stewart/webdm/the-sun-is-the-same-in-a-relative-way/+merge/259933 | No reviews (4 days old) [15:48] https://code.launchpad.net/~stephen-stewart/webdm/icons-icons-icons/+merge/259800 | No reviews (5 days old) [15:48] elopio: no, not at all; well you can set functions to var in as in var snappyInstall = snappy.Install and then in the tests set snappyInstall to your mock [15:49] elopio: if you aspire to 100% coverage, this is the only way I think, unless Chipaca has a more clever idea [15:50] elopio: the go stdlib is full of exported functions calling the internal function and testing just the internal functions [15:50] beowulf: feeling better? [15:50] sergiusens: much [15:50] sergiusens: migraine [15:51] mvo: if you want some reviews ^^ i can start you by saying i haven't enough tests [15:52] sergiusens: hum, Let me try that. I'm not looking for 100% coverage (yet), I just want to improve tests like 01_test_info, which just check that the reply conforms to the spec. [15:52] sergiusens: i added a card to trello to expose what would be the results of a GET of installed snaps to the GO templates, i want to bootstrap the app so it doesn't have to make an api call first time [15:52] beowulf: heh :) dinner time here, probably needs to wait until tomorrow (unless someone lese beats me to it) [15:52] elopio: the what I propose will get you going [15:52] mvo: no problem , dinner here too [15:53] sergiusens: I'll play with that. But better wait and do it with the refactor of cmd, I think. [15:53] beowulf: oh nice, if we do this, can we just do updates with websockets for all else? [15:53] elopio: that will happen next month the soonest I guess [15:55] beowulf: I'll do your reviews, and let me set something up for tomorrow to discuss websockets, that template you speak of and all else [15:55] sergiusens: in the mean time we can work on tests for the functional part. Install a snap -> check the list, and things like that. Which are better without fakes and will survive the refactor. [15:55] sergiusens: yeah, but in the first instance i'm going to rely on a local (to the browser) list initially populated from the Go template, then sync the list in the background when the user won't notice [15:56] elopio: agreed [15:56] sergiusens: also, sad face that we don't have https, is that correct? [15:56] beowulf: works for me; initially we were going to go with a go template for most things so I'm not against it [15:56] beowulf: no https as no cert, but there is a plan [15:57] no https would rule out a couple of browser apis that webdm could use [15:57] sergiusens: elopio: I have zero clever ideas. [16:02] Chipaca: oh you [16:03] beowulf: well, it's coming === rickspencer3_ is now known as rickspencer3 [16:48] bzoltan, tedg: want to join a quick hangout to talk about IDEs & snapcraft? [16:48] mterry: tedg: I can do a quick chat [16:48] isnt that just a plugin thing ? [16:49] ogra_, well that's what I'm trying to determine, but it may influence how buildenvs are stored etc. fact finding [16:50] ah, well, i thought we would have pluggable build envs too :) [16:50] mterry: ogra_: I am fine with wjatever plugin :) as long the rootfs and the tollchain of the target is directly accessible from the IDE :) [16:50] so it would just be a matter of picking the ones the IDE wants [16:51] bzoltan, right, but other parts might have different reqs ... so i would envision we have pluggable backends as well as pluggable frontends ... and the frontend just defines what it wants as backend env [16:51] ogra_: mterry: so any sort of wrapping and confining of the toolchain+rootfs is a showstopper for the IDE [16:51] there might be parts that require a clean bootstrap ... others might want to use a VM ... you want to use a chroot etc [16:52] ogra_: I am fine with it... as long after plugging I can access the toolchain and the rootfs :) [16:52] sure, your backend plugin would have to do that then :) [16:52] ogra_, why would there be so many options? you just want a .snap sitting there, why require a VM? [16:52] ogra_: Noooooouuuuu :) I do not want chroot... I want sysroot + native toolchain_S_ [16:52] mterry, no idea, i was just making up examples :) [16:53] * bzoltan things that G+ hangouts are overrated :D [16:53] mterry, i think snapcraft should be flexible here [16:53] s/things/thinks/ [16:53] bzoltan, +1 .... excludes the community from the discussion :) [16:53] ogra_, the more flexible we are, the less magic we can be. We wanted to be very magic, ideally user never has to think about buildenvs [16:53] mterry: I second that [16:53] mterry, not a user ... a provider for a certain setup [16:54] bzoltan, talk me through the different options. So VM doesn't make sense, sure. chroot is bad because your plugin would need to be root to get in? let me look at what sysroot is, /me is dumb about it [16:54] pypi will have different reqs than node-snapper ... [16:54] C++ will have another set of different reqs [16:54] or java ... [16:55] ogra_, provider for a certain setup? oh, the pypi plugin just gets pointed at the buildenv and uses it. Why does it care what sort of chroot thing it is? [16:55] mterry: Ok... I explain... [16:55] bzoltan, ok, so sysroot is a gcc option? [16:55] I thought a VM was fine as long as the build directory is in the local FS. [16:56] i.e. we just need to be able to pull the directory through some magic into the VM. [16:56] That way the IDE can get full source introspection. [16:56] tedg, you also want direct interaction from your Ui etc ... [16:56] mterry: In our present app dev SDK we use the chroot model.. it means that whatever Ubuntu you are on... even on LTS ... and you develop for 15.04 phone ...teh chroot will be an x86 15.04 chroot with the armhf libs and headers. And we use the x86 toolchain (make-compiler-linker) to build the armhf binaries [16:57] Ah, so it needs some routing of STDIN/STDOUT [16:57] yeah, i guess so [16:57] mterry: that is a major hackaround ... but a huge saving because we do not need target specific toolchain... we simple use the target system's native one [16:57] but bzoltan experimented with VMs and can surely give you more details about the probs [16:58] bzoltan, hold up [16:58] bzoltan, you say "target specific toolchain" and "target system's native one" [16:58] mterry: yes [16:58] bzoltan, can you please dumb that down a tad? "target specific" is x86 toolchain that knows how to build armhf? [16:59] And "target system's native one" is actual armhf binary toolchain? [16:59] mterry: so when you compile a phone app you do not use the LTS edition of the toolchain, but the one from the chroot [16:59] I think he's also saying that it's the version of the target as well. [16:59] tedg: precisely! [16:59] So the wily would default to gcc 5.2 but trusty would be a gcc 4.x [17:00] Ok... So "target specific" is same-arch-diff-version, and "target native" is same-arch-same-version? [17:00] bzoltan, So then do you run the test suite using a QEMU hack? It seems like you still need to be able to exec armhf binaries in that chroot somehow. [17:00] tedg: mterry: some bed time reading -> https://developer.ubuntu.com/en/blog/2015/03/18/everything-you-always-wanted-know-about-kits-were-afraid-ask/ Kits here are the chroots [17:00] mterry: a sysroot is nothing else than a rootfs, plain simple. The catch here is that you have a specially built toolchain that can use that rootfs as the source to get the headers and libraries. So instead of /usr/include, it usues /path/to/sysroot/usr/include. Same for libs [17:00] And then the toolchain can also cross compile? [17:01] well, irt kind of does a native build [17:01] mterry: the toolchain itself is a cross toolchain running directly on the host. Its the standard way for most cross build SDKS, including android and Qt [17:01] but using the host toolchain inside the chroot for speed [17:01] mterry: thats why all lots of tools support it by default [17:01] in a cross way [17:02] tedg: for running cross build tests you need a emulator of course [17:02] it is the same ugly thing that scratchbox and the SuSE OBS use ... [17:02] zbenjamin, yup. Just trying to think of non-c++ stories too [17:02] So then do we need kits to be more generic than QtCreator? We need "snapcraft Kits" ? [17:02] mterry: does a nodejs for example need to be installed systemwide? can't you use a nodejs installation from everywere to build your app? [17:03] mterry, as long as it is gcc you can use that model for all langs gcc compiles [17:03] mterry: ogra_: We as the SDK team are lobbying for target specific toolchain + sysroot modell for years... the chroot solution is an acceptable ugly solution we can live with.. but hat is not troublefree either. VM is pointless. [17:03] zbenjamin, I'm sure. And Python can set PYTHONHOME and all that [17:03] zbenjamin, but I'm not sure about other compiled language cross compile stories. I'm sure they have something, but I've never done it in Go for example. I know it can, just don't know what it needs [17:03] mterry: go as well can be used from everywhere afaik [17:03] zbenjamin, take a look at node-snapper ... [17:04] bzoltan, zbenjamin: (A) you're IRC nicks are driving me crazy [17:04] i envision we'll use something similar for node in the end ... the prob with node is that you need to compile the modules on the fly ... [17:04] mterry: lols :D [17:05] bzoltan, zbenjamin: (B) it sounds like you guys just want a directory sitting on disk. Nothing special to it. It will just contain its own headers and build env setup. Right? [17:05] ogra_: mterry: also i was wondering how to handle snaps that combine languages? For example C++ and go and nodejs .... [17:05] mterry, I think they want the default paths changed. So, really, it's kinda snap-ifying the toolchain. [17:05] zbenjamin, good question ... on a snap level you just throw the binaries into the right places [17:05] zbenjamin, I suspect each language plugin would know how to set up its own parts [17:05] zbenjamin, for building that gets interesting :) [17:05] mterry: almost yes, the qt tools need to be built for cross building but when we have the base sysroot + toolchain thats easy [17:06] there we will need the magic that mterry mentioned earlier ;) [17:06] tedg, default paths? I think they just want to set sysroot at build time to point at the buildenv, not by default [17:06] mterry: ogra_: so if we think about sysroots and chroots. We totally could use a chroot as sysroot, all we need is the toolchain and the cross build tools (in our case Qt) in a extra location [17:07] or copied in place ... or linked/bind-mounted/overlayfs-mounted [17:07] ogra_: don't say the bad word "overlayfs mounted" :D [17:07] might be our future :) [17:07] zbenjamin, but you want to ideally be handed a directory that has usr/include usr/lib etc inside it, as well as usr/bin/gcc and friends. [17:08] mterry, quite a bit more ... [17:08] we're talking about gigs of build deps [17:08] mterry: zbenjamin: yes, the sysroot is really not much else then the directory structure of the target system + dev files ... PLUS we need the toolchain what knows the whereabout of that diretcory [17:08] ogra_, yeah, the whole shebang. everything needed to build [17:08] (the whole phone framework) [17:09] ogra_: as i said we could use the libraries from the chroots. We just need a external toolchain [17:09] bzoltan, the toolchain which sits outside that directory? why wouldn't it be the toolchain inside that dir? for speed reasons in case we are cross compiling? [17:09] ogra_: are you sure it is gigs? [17:09] mterry, yeah [17:09] mterry: thats a gcc requirement [17:09] mterry: afaik a relocatable toolchain can not be inside the sysroot [17:09] mterry: the location of the toolchain is not relevan, as long it is not emulated but native [17:09] mterry, using the native armhf compiler in a qemu-user-static chroot works but is slower and less reliable ... [17:10] OK, well that's fine [17:10] so you use the host one in cross setup [17:10] Host toolchain is fine [17:10] and copy/link/mount it into the chroot [17:10] But libs and everything inside the sysroot directory [17:10] ogra_, wait, I thought it didn't need to be inside? [17:10] ogra_: mterry: catch is we can not move the toolchain around. Gcc does not like this. Except we compile it as relocatable. [17:10] yeah, they need to match the target [17:10] zbenjamin, why is that a catch? [17:11] zbenjamin, gcc outside, all libs inside, right? [17:11] yeah [17:11] mterry: i mean we can not use the default toolchain from the archive [17:11] * tedg needs to run, but will catch up on the backlog when back (much better than hangouts) :-) [17:11] mterry: at least not how its compiled atm afaik [17:11] * mterry *likes* hangouts [17:11] zbenjamin, oh wait weird. I didn't know we were using non-archive gcc [17:11] mterry, especially the transcripts that you can read from logs next week ? [17:11] :P [17:12] zbenjamin, so there's some SDK-specific gcc we need to use? [17:12] ogra_, I get it! I just like your pretty faces is all [17:12] haha, we like yours too :) [17:12] mterry: either that, or we need to make sure the archive toolchain supports what we need [17:12] mterry: we probably need to ask a toolchain dev what is required here [17:12] zbenjamin, (why hasn't that happened? was it rejected?) [17:12] zbenjamin, what exactly is it that we need that archive doens't do? [17:13] mterry: it needs to support the --sysroot switch. [17:13] mterry: and i think you need to compile that in [17:13] zbenjamin, oh weird, that's not standard? curious [17:13] mterry: yes, it was rejected with the explanation that they have no time and hands to maintain more than one toolchain [17:13] mterry: basically we need a toolchain that can select the sysroot its compiling against [17:13] So this is not a solution we could build today [17:13] Or on 14.04 [17:13] bzoltan: mterry: yeah but back then we didn't come up with the idea that the default toolchain could do that maybe [17:14] zbenjamin: mterry: we did not know [17:14] yeah I get that. I'm just trying to figure out how to move forward [17:14] Sounds like this won't be sufficient for now [17:14] mterry: correct.. on LTS we are busted either way ... because we can not replace the toolchain there [17:14] mterry: yes so that would be only possible when we SRU that toolchain back [17:14] that's not happening :) [17:14] mterry, get doko really really drunk :) [17:14] :D [17:15] ogra_: add a "really" there :D [17:15] (step 1) [17:15] ogra_: you can not get doko _THAT_ drunk [17:15] zbenjamin, bzoltan: OK... so this sysroot solution is a future idea. For next LTS [17:15] yeah, it is also very hard to get him drunk :) [17:15] zbenjamin, bzoltan: what do you need on 14.04? You need a chroot? [17:15] mterry: sysroot + fixed toolchain on new releases and chroot on old releases [17:15] If I give you a sysroot directory on 14.04, you can't compile using it? [17:16] bzoltan: mterry: since we switching to distribute the SDK from an installer rather the archive we could ship a new toolchain with it (maybe) [17:16] mterry: on LTS we already have the chroot based solution... kind of okey [17:16] bzoltan, ok... so on 14.04 give you a sysroot directory with toolchain *inside* [17:16] zbenjamin: +1 [17:16] hmm, ok... [17:16] mterry: yes, and we chroot to that sysroot [17:17] mterry: our problem is we are hitting a wall with backporting the SDK because of the new Qt that is incompatible [17:17] you dont really want to diverge from the archive toolchain [17:17] bzoltan, zbenjamin: OK, so only difference is if toolchain is inside or outside sysroot [17:17] ogra_: true :/ [17:17] we need to find a way to utilize it from the archive [17:17] ogra_, yeah... but I'm ok having a copy of it inside a directory [17:17] mterry: yes.. and that with the present solution we chroot [17:17] ogra_: how about using exactly the same sources but enabling the sysroot caps? [17:17] ogra_: would that break ABI? [17:18] mterry, sure, but that looks more like "we need to recompile it first" [17:18] zbenjamin, bzoltan: is there a bug for this yet? [17:18] (to enable --sysroot) [17:18] zbenjamin, it could even get you different binary behavior ... [17:18] mterry: no i kind of just came up with it :D [17:18] ogra_: crap [17:18] zbenjamin, file one then from the SDK point of view, I'll subscribe and watch :) [17:18] ogra_: yeah thats the problem , we probably need to ask someone who knows the toolchains by heart [17:18] right [17:19] either doko or infinity [17:20] zbenjamin, bzoltan: so even if I gave you a chroot, that would still work in the --sysroot future, right? You just wouldn't use the toolchain sitting inside of it [17:20] mterry: yes, it would work [17:20] mterry: you can even setup the very same chroot to do, lets say nodejs builds in it [17:20] mterry, how do you handle the "cross" part in that ? [17:20] ogra_: same as we do with the click chroots? [17:21] how do we handle it there ? qemu-user-static ? [17:21] which is just build once per chroot, right? [17:21] ogra_: cross toolchains [17:21] ogra_: native cross toolchains [17:21] oh do you still have one chroot that builds more than one arch output? [17:21] thats enough for QT ? [17:21] mterry: ogra_: the present chroot solution in single run builds are pretty functional... the problem with it is that 1) takes time to set up 2) unstable for long run 3) needs root to set up [17:22] mterry: ogra_: 4) slows down the IDE horribly 5) leaks mounts [17:22] bzoltan, zbenjamin: I'm not saying I love chroots. By all means, get rid of them [17:22] 6) restores the leaked mounts after boot [17:22] bzoltan, zbenjamin: but for now, they're the only game in town :) [17:22] mterry, that might work for just Qt ... as soon as anything in the build tries to exec something inside the chroot you will need something like qemu-user-static again though [17:22] mterry: getting rid of chroot is good... but not by migrating to th even more messy VM [17:23] bzoltan, I'm not advocating that. I like the sysroot thing just fine, I think. But it's just not available today is what I'm saying [17:23] bzoltan, go get it added to our toolchain and then we can talk [17:23] and it is limited to the toolchain ... [17:23] ogra_, yeah we may need one-chroot-per-arch [17:24] mterry: the funny things is that pretty much all otherplatform's sdk is using that sysroot + toolchain modell ... nobody is using chroot or builder VM [17:24] mterry, and something clever that notices if some build script tries to exec something inside the foreign chroot [17:24] this needs to be wrapped in qemu-user-static calls [17:25] ogra_, or just run the build under qemu in the first place [17:25] and be slow [17:25] no [17:25] +1 ogra_ [17:25] bzoltan, that's fine! I can't control other platforms' sdks :) [17:25] then your RPi will be faster :) [17:25] mterry: that is called scratchbox :) NOOOOOO [17:25] bzoltan, but nor can I flip a switch and fix our toolchain. File a bug! [17:26] ogra_, bzoltan, zbenjamin: OK, OK :) No qemu-by-default... [17:26] mterry: +1 will be done [17:26] mterry, so your first focus shoilld be to develop such a switch then :) [17:26] *should [17:26] ogra_, oh that's just for the toolchain-in-or-out-of-sysroot problem. That doesn't solve the qemu problem, does it? [17:26] ogra_: atm all projects that are compiled for the phone need to be cross build capable. And so all tools since we have no qemu there. But thats just the phone story of course [17:27] ogra_, yeah maybe if a snapcraft language plugin needs qemu, it will know that and do what's necessary. but most won't need qemu, one hopes... [17:28] mterry, qemu-user-static (just syscall translation) is reasonably fast ... but also slightly unstable (not all syscalls can be translated) ... what i would do is to run such a syscall translated chroot and then replace the armhf toolchain with a cross x86 one that skips any syscall translation [17:28] mterry: ogra_: bzoltan: sorry guys i need to run, GF is already looking angry at me :D [17:28] zbenjamin, thanks! [17:29] i will read teh backlog... man always the interesting conversations when i need to go D [17:29] zbenjamin: do you have GF? Duuude, where is your comitment? :D [17:29] bzoltan: lol , what was it with wife and kids you just mentioned? [17:29] mterry, that way your compiler runs at host speed ... and in cases where tools inside the chroot needs to exec some native binaries they can use the syscall translation and run natively [17:29] zbenjamin: that is after life [17:30] ogra_, you're saying the x86 one inside the chroot would be able to skip the qemu translation being done on it? qemu is fancy enough to not translate native code? [17:30] mterry, right [17:30] neat [17:31] qemu-user-static uses the binfmt kernel module ... that checks the binary header of a file you try to exec [17:31] if it is foreign it wraps it [17:31] if not, it doesnt :) [17:31] OK. So sounds like the way forward is provide chroot directories to the SDK. They'll have toolchains inside. Which we may swap in and out for native toolchain as speed demands dictate. We'll have one chroot per arch [17:32] sounds good [17:32] That's not very controversial [17:32] mterry: ogra_: sounds smart enough to me [17:32] And in future, maybe we can skip stuffing the toolchain inside, if we get future --sysroot smarts [17:32] and at some point in the future we'll have --sysroot support [17:32] *snap* [17:32] :) [17:33] (...py) [17:33] * bzoltan lays back and opens the can [17:33] you havent yet ? tsk :) [17:33] bzoltan, and that's basically the same as current SDK uses, right? [17:33] This solution needs root though, which is a bummer. I'd like that --sysroot option too [17:33] https://www.youtube.com/watch?v=3YmMNpbFjp0 [17:33] mterry, fakechroot :) [17:34] * ogra_ hides in a hole [17:34] :D :D [17:34] mterry: we already get used to the chroot what requires root access... it is not great but keeping it is not a regression :) [17:35] ogra_, what is wrong with fakechroot? I know I rarely use it for anything. Does it just have holes in it's wall? [17:35] it is pretty similar to deb2snap :) [17:35]