| slangasek | ogra_: system-image doesn't include shim-signed because you can't have both grub-pc and grub-efi-amd64-signed; we want the latter but it's been an incremental process, requiring changes to udf first. Has udf efi support landed in all the right ppas? | 00:44 |
|---|---|---|
| slangasek | only once it has should we change the grub seeding | 00:45 |
| === chihchun_afk is now known as chihchun | ||
| === devil is now known as Guest34774 | ||
| fgimenez | good morning | 06:59 |
| === Guest34774 is now known as devil_ | ||
| dholbach | good morning | 07:29 |
| mvo | lool: I love your snappy shell idea (as you know) and couldn't help stating a simple branch that gives it some life: lp:~mvo/snappy/snappy-console | 07:34 |
| ogra_ | mvo, i love it too, but please not on port 22 :) | 07:59 |
| mvo | ogra_: :) I love the idea of snappy console / repl / cli /shell and being able to interact with it this way. I also like the possiblities it opens up. the points raised in the mail thread are indeed good ones, so by default maybe not | 08:02 |
| lool | mvo: awesome :-) | 08:05 |
| ogra_ | well... | 08:05 |
| ogra_ | you could have a "shell" command though :) | 08:05 |
| ogra_ | that gives you a shell session | 08:05 |
| lool | ogra_: this is already in the proposal | 08:14 |
| lool | "snappy cli" as a (hidden?) way to start the snappy shell, and "shell" from the cli as a way to start a real shell | 08:15 |
| ogra_ | lool, yeah, though pitti's argument still stands, ssh remote scripts would fail | 08:16 |
| lool | I'm not sure about this | 08:18 |
| lool | first, it would work with snappy commands, second, we could implement what people feel is important to get from a running snappy system there, third, there might be ways to reach a shell to run real commands | 08:20 |
| ogra_ | longsleep, image 0.3 ? not 3.0 ? :) | 08:23 |
| JamesTait | Good morning all; happy Fresh Veggies Day! 😃 | 08:55 |
| === vrruiz_ is now known as rvr | ||
| Chipaca | mvo: is it possible you forgot a prereq on the console branch? | 09:36 |
| mvo | Chipaca: maybe, let me double check | 09:41 |
| mvo | Chipaca: indeed I did, sorry for that | 09:43 |
| Chipaca | mvo: apology accepted | 09:43 |
| Chipaca | mvo_: the comment i made in your decorator2 is for addressing in a later branch if at all :) | 09:54 |
| Chipaca | mvo_: you know what i'd like? 'snappy verify' to run verify hooks for the apps | 10:01 |
| rsalveti | morning | 10:04 |
| rsalveti | Chipaca: welcome back | 10:04 |
| Chipaca | rsalveti: hey :) | 10:04 |
| rsalveti | slangasek: the udf efi branch landed everywhere already | 10:05 |
| Chipaca | mvo__: ETOOMANYMVO | 10:10 |
| Chipaca | mvo__: commit messages | 10:19 |
| === mvo__ is now known as mvo | ||
| mvo | Chipaca: thanks, yeah, adding those now, thanks a bunch for your reviews | 10:23 |
| Chipaca | mvo: wrt verify, i'm +1 on most of it, but uncomfortable with growing the already-too-large Part interface | 10:24 |
| Chipaca | oh dear | 10:24 |
| Chipaca | mvo: wrt verify, i'm +1 on most of it, but uncomfortable with growing the already-too-large Part interface | 10:25 |
| mvo_ | Chipaca: makes sense, let me try to think about alternatives then | 10:26 |
| Chipaca | mvo_: installed from a local meta already returns only SnapParts | 10:26 |
| Chipaca | mvo_: so a jfdi approach would be to do .(*SnapPart) on the parts returned by instlled | 10:26 |
| Chipaca | mvo_: a less jfdi approach would split Part into two interfaces, embed the local in the bigger one, and change Installed to return those | 10:27 |
| Chipaca | mvo_: another jfdi approach would be to tell me i'm wrong (or pyrrhically right) and go with the branch as writ | 10:30 |
| mvo_ | Chipaca: I dislike option (3) because you are right and ignoring that is bad(tm). the two-interfaces approach sounds like the cleanest, wdyt? | 10:31 |
| Chipaca | mvo_: i think you'll find it's a lot more code :) | 10:32 |
| mvo_ | Chipaca: heh :) probably I will hate myself for not taking the easy option | 10:32 |
| * mvo_ will try to fix his dsl before diving into the branch | 10:33 | |
| Chipaca | mvo_: may i suggest you set a time limit, take a prod on the interfaces, and bail to the jfdi if it snowballs out of time? | 10:33 |
| mvo_ | Chipaca: ok, that sounds sensible | 10:33 |
| Chipaca | mvo_: and next time i embark on a refactor, remind me to do the same :) | 10:37 |
| mvo_ | heh :-D | 10:37 |
| mvo_ | promised! | 10:37 |
| sergiusens | Chipaca: \o/ thanks for bringing up the Part interface again :-) | 10:38 |
| Chipaca | sergiusens: the price of readable code is eternal vigilantism, or something like that | 10:39 |
| sergiusens | Chipaca: yup | 10:39 |
| sergiusens | mvo_: so, if you do this, can you add the Ports interface to the local interface? | 10:40 |
| sergiusens | it's not part of Parts today and doing the .(*SnapPart) check | 10:40 |
| mvo_ | sergiusens: yes | 10:41 |
| Chipaca | sergiusens: Frameworks might also be moved over, although i do envision a future in which remote parts have Frameworks() and thus the installer can be more helpful wrt that | 10:43 |
| sergiusens | Chipaca: i say we request the store to add support for it | 10:46 |
| sergiusens | and do nicer things | 10:46 |
| Chipaca | sergiusens: yeah, but you know the store guys | 10:46 |
| rsalveti | mvo_: any reason for https://trello.com/c/6n9Q3tVh/109-core ? | 10:46 |
| Chipaca | they're all like "oh no we can't break things because people will get upset" | 10:46 |
| Chipaca | :) | 10:46 |
| rsalveti | :-) | 10:47 |
| mvo_ | rsalveti: that looks like trello was playing tricks on me | 11:00 |
| rsalveti | mvo_: :-) | 11:01 |
| mvo_ | rsalveti: I removed it | 11:01 |
| rsalveti | mvo_: thanks | 11:01 |
| sergiusens | Chipaca: adding stuff doesn't break anything :-P | 11:02 |
| sergiusens | Chipaca: unless you add too much and make it unbearable :-) | 11:03 |
| === chihchun is now known as chihchun_afk | ||
| lord4163 | How do I list all available snappy packages to install? | 11:14 |
| sergiusens | lord4163: snappy search | 11:15 |
| lord4163 | sergiusens: and then after I installed a package? | 11:18 |
| sergiusens | lord4163: snappy list | 11:19 |
| lord4163 | sergiusens: what can't I use the package now? | 11:20 |
| lord4163 | holy f*, I typed reboot in my kvm instance and it rebooted the host machine!?!?!?!?!?!? | 11:20 |
| lord4163 | So this snappy thing is for people missing Windows 95 I guess? | 11:38 |
| sergiusens | lord4163: it cetainly isn't for end users (core at least) | 11:42 |
| lord4163 | for who is it then? | 11:43 |
| rsalveti | lord4163: atm it's mainly for builders, which is why sergiusens said core | 12:20 |
| rsalveti | once we have more applications and so on, end users can simply consume that from the store | 12:20 |
| Chipaca | lord4163: typing reboot in your kvm instance can't reboot the host machine, fwiw | 12:21 |
| Chipaca | lord4163: if it can, i hear there's good money in selling the exploit | 12:21 |
| lord4163 | Chipaca: It did :P | 12:22 |
| Chipaca | lord4163: i believe you think it did, but i don't believe it did :) | 12:22 |
| lord4163 | Chipaca: Let's try it again then. | 12:23 |
| Chipaca | lord4163: how'd it go? | 13:05 |
| lord4163 | Chipaca: didn't work this time | 13:06 |
| lord4163 | Chipaca: but happened the first time? :P | 13:06 |
| Chipaca | sure it did | 13:07 |
| lord4163 | Now whole GNOME Boxes died | 13:07 |
| lord4163 | Chipaca: According to journalctl Fabian-PC login[1456]: FAILED LOGIN 1 FROM tty1 FOR kvm guest reboots host | 13:17 |
| mterry | mvo_, you mentioned duplicating a i18n.go file in each package. Does go tolerate sources that are symbolic links? Cause then you could avoid actual copies of the code at least | 13:17 |
| Chipaca | lord4163: i'm not sure what that means | 13:29 |
| Chipaca | sergiusens: why isn't setupCloudInit part of first boot? | 13:33 |
| mvo_ | mterry: nice idea, I don't know, I guess the package statement in the header is the problem | 13:33 |
| mterry | mvo_, ugh right | 13:34 |
| mterry | mvo_, i18n.G() is better than gettext.Gettext() though | 13:35 |
| mterry | but not as good as G() | 13:35 |
| sergiusens | Chipaca: because when I proposed to do that I was told not to | 13:35 |
| Chipaca | sergiusens: by whom, and why? | 13:35 |
| sergiusens | Chipaca: I wanted an oem snap entry to say cloud: on/off | 13:36 |
| sergiusens | Chipaca: and just disable the cloud-init job | 13:36 |
| Chipaca | cloud: very yes | 13:36 |
| Chipaca | cloud: extra strawberry | 13:36 |
| Chipaca | sergiusens: that seems sensible to me | 13:36 |
| Chipaca | sergiusens: what was the problem with it? | 13:36 |
| mterry | mvo_, you could add a i18n package, include a "InjectGettext()" function, then have every package's init() entry point set up a package-wide var for G? | 13:36 |
| mterry | mvo_, still copied code, but just a one-line init() maybe | 13:37 |
| Chipaca | mvo_: mterry: why not “. "yadda/yadda/i18n"”? | 13:38 |
| Chipaca | as long as i18n only exposed a single well-known function, that would seem ok to me | 13:38 |
| mterry | Chipaca, oh right! I forgot you could inline a package. Maybe that's good enough | 13:38 |
| * Chipaca would suggest using some non-ascii char for i18n's function, to avoid clashes and because it's extra twisted | 13:39 | |
| Chipaca | mterry: mvo_: a function called Ꝇ would be nice (it's a capital broken l, because localization! :-p) | 13:43 |
| mterry | Chipaca, that'll catch on! | 13:44 |
| Chipaca | inorite | 13:45 |
| Chipaca | mterry: and then we can move tzdata to Ꜩ! | 13:45 |
| ogra_ | there are explicit broken letters in utf-8 ? | 13:46 |
| ogra_ | wow | 13:46 |
| Chipaca | ogra_: 💔 | 13:46 |
| ogra_ | hah | 13:47 |
| Chipaca | as letters just the L, though | 13:47 |
| mterry | Chipaca, there's potential here for a whole programming language, akin to brainfuck | 13:47 |
| Chipaca | mterry: dude. APL. | 13:48 |
| mterry | Chipaca, hah, yikes | 13:48 |
| Chipaca | mterry: on the other hand, finding all primes in APL is: (~R∊R∘.×R)/R←1↓ιR | 13:50 |
| Chipaca | mterry: so we might be on to something | 13:50 |
| * Chipaca adds APL to the list of things to never, never learn | 13:52 | |
| Chipaca | sergiusens: ...? | 13:52 |
| mvo_ | lol@Chipaca and mterry | 13:53 |
| sergiusens | Chipaca: the ... means? | 13:54 |
| Chipaca | <Chipaca> sergiusens: what was the problem with it? | 13:54 |
| seb128 | sergiusens, hey, I tried again u-d-f, using DEBUG_DISK=1, I get a "(parted) mkpart system-a ext4 147456s 147455s" which errors out because the start is after the end (first number bigger) | 13:57 |
| seb128 | sergiusens, that's on i386 if that makes a difference | 13:57 |
| sergiusens | seb128: --size 10? | 13:58 |
| seb128 | sergiusens, no, why is that needed? isn't that for the writable partition? | 13:59 |
| sergiusens | seb128: well each of your a/b parts is now 4GiB instead of 1 | 14:00 |
| seb128 | sergiusens, I don't have 10G free space on that machine, trying again on my other box which has more disk but that's on vivid and trying to build goget-u-t fails on undefined logger.Panicf | 14:01 |
| sergiusens | seb128: build as a deb? you need to build on wily | 14:01 |
| seb128 | sergiusens, shrug, that box is vivid ... do you know what I need from wily? | 14:02 |
| seb128 | I tried to update golang* and ubuntu-snappy-cli but that's not enough | 14:02 |
| sergiusens | seb128: golang-snappy-dev | 14:03 |
| seb128 | sergiusens, I've the wily version of that | 14:03 |
| elopio | fgimenez: I'll be with you in a couple of minutes. | 14:03 |
| seb128 | sergiusens, I'm trying a clean build | 14:04 |
| rickspencer3 | hi all | 14:05 |
| rickspencer3 | I'm writing a snap in Go | 14:05 |
| rickspencer3 | I am trying to open a yaml file that is at /apps/go-uploader.sideload/0.3/cnf | 14:06 |
| rickspencer3 | os.Getenv("SNAP_APP_DATA_PATH") send me to | 14:06 |
| fgimenez | elopio, ack | 14:06 |
| rickspencer3 | /var/lib/apps/go-uploader.sideload/0.3/cnf/ | 14:06 |
| rickspencer3 | any idea what I what I am doing wrong? | 14:06 |
| sergiusens | rickspencer3: you want another envvar | 14:07 |
| rickspencer3 | sergiusens, are the envvars documented somewhere? | 14:07 |
| === chihchun_afk is now known as chihchun | ||
| Chipaca | rickspencer3: https://developer.ubuntu.com/en/snappy/guides/security-policy/ | 14:09 |
| sergiusens | Chipaca: thanks, was searching every doc | 14:10 |
| Chipaca | rickspencer3: listed, not documented, though | 14:10 |
| * sergiusens finds developer.ubuntu.com hard to navigate | 14:10 | |
| rickspencer3 | nice | 14:10 |
| rickspencer3 | lol | 14:10 |
| rickspencer3 | Chipaca, do I want SNAP_APP_PATH ? | 14:10 |
| sergiusens | rickspencer3: yes | 14:10 |
| sergiusens | that one | 14:10 |
| rickspencer3 | ok | 14:10 |
| rickspencer3 | tbhanks | 14:10 |
| rickspencer3 | maybe someone could, you know, list out what each is for ;) | 14:10 |
| sergiusens | rickspencer3: or 'snappy install hello-world' and run hello-world.env | 14:10 |
| sergiusens | that was in one of the guides I can't seem to find | 14:11 |
| rickspencer3 | that sounds quite indirect | 14:11 |
| Chipaca | rickspencer3: i'll add that to the doc i'm writing :) | 14:11 |
| sergiusens | Chipaca: wrt yur question, we need this anyways for backwards compat (setupcloud) | 14:11 |
| elopio | ogra_: are you coming to the meeting? | 14:32 |
| ogra_ | elopio, yes :) | 14:33 |
| === davidcalle_ is now known as davidcalle | ||
| slangasek | rsalveti: ok, if the udf efi has landed, then we should also make the seed changes to add shim - probably retroactively to 15.04 as well? | 14:42 |
| * tedg watches carefully | 14:43 | |
| tedg | Which seed exactly? | 14:43 |
| tedg | :-) | 14:43 |
| sergiusens | slangasek: didn't we add all that to 15.04 already a while back? | 14:56 |
| slangasek | sergiusens: 'seed changes to add shim'? no | 14:56 |
| sergiusens | seb128: personal doesn't have cloud-init seeded, right? | 14:58 |
| plars | rsalveti: do you think https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 will be merged at some point soon? It sounds like it causes no harm if you are running the typical debian install on your emmc with bbb, but helps enormously if you do not run the default image on emmc | 15:00 |
| fgimenez | elopio, i've pushed the latest changes https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748, ready for review? | 15:02 |
| elopio | fgimenez: I see output :) | 15:03 |
| fgimenez | elopio, at last! :) | 15:04 |
| elopio | fgimenez: yes, ready for review, thanks. | 15:05 |
| elopio | fgimenez: maybe you can add the newline here: | 15:05 |
| elopio | 256\ No newline at end of file | 15:05 |
| fgimenez | elopio, ok done | 15:07 |
| seb128 | sergiusens, it has, why? | 15:30 |
| dholbach | balloons, elopio, fgimenez, ogra_: mail sent | 15:32 |
| elopio | thanks dholbach | 15:32 |
| sergiusens | seb128: hmm, I am now missing context | 15:33 |
| seb128 | sergiusens, <sergiusens> seb128: personal doesn't have cloud-init seeded, right? | 15:33 |
| seb128 | sergiusens, https://launchpadlibrarian.net/209185916/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz | 15:33 |
| seb128 | it's installed | 15:33 |
| sergiusens | seb128: is it inherited, planned or $reason? | 15:35 |
| seb128 | sergiusens, http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop#L68 | 15:37 |
| seb128 | sergiusens, I guess we copied that from the ubuntu-core seed, we started from there | 15:37 |
| tedg | mvo_, Why does apt-cache show have seemingly two sections of data? | 16:08 |
| mvo_ | tedg: local and remote maybe? | 16:09 |
| * mvo_ needs to leave for dinner | 16:09 | |
| tedg | Hmm, okay. Enjoy! | 16:09 |
| stgraber | ok, so I'm working on making a snap for LXD, which for those who haven't heard about it is a container manager based on LXC. That means it's not going to be the simplest snap package in the universe :) | 16:33 |
| Chipaca | stgraber: :) | 16:33 |
| ogra_ | stgraber, dont look at the docker snap ... i heard people say thats a very bad example :) | 16:34 |
| Chipaca | perhaps the different kvm-launching snaps would be better | 16:34 |
| stgraber | currently my main problem is that LXC contains hardcoded paths. I can obviously get it rebuilt to change those, but I just want to make sure I can rely on stuff being at a fixed filesystem location, say /apps/<snap entry>/current/ and use that in my buil process | 16:35 |
| Chipaca | stgraber: note you can't write to /apps/<snap entry>/current though | 16:35 |
| ogra_ | we have lvm snaps ? | 16:35 |
| ogra_ | *kvm | 16:35 |
| stgraber | and if so, it looks like I'll need two builds, one for local dev (sideloaded) and one for the real thing, as one will have the .sideload suffix | 16:35 |
| stgraber | Chipaca: yeah, that's fine | 16:35 |
| Chipaca | stgraber: it would be a lot better if you used the environ for those | 16:35 |
| Chipaca | how hardcoded are the paths? | 16:36 |
| stgraber | configure args which wind up hardcoded in a .so | 16:36 |
| Chipaca | ugh | 16:36 |
| ogra_ | yeah, just de-hardcode them and allow them too be overridden by the $SNAP_* vars | 16:36 |
| stgraber | yeah, not quite looking forward to have to carry patches against upstream for that though (and having upstream be aware of SNAP_ isn't acceptable) | 16:37 |
| Chipaca | that would be ideal :) or some LXD_* vars, and set those from these | 16:37 |
| Chipaca | stgraber: wrt upstream, LXD_ env vars should be ok with them? | 16:37 |
| ogra_ | right, just translate them :) | 16:37 |
| ogra_ | you need a shell wrapper anyway | 16:37 |
| Chipaca | stgraber: i hear they're a friendly bunch :) | 16:37 |
| stgraber | Chipaca: "maybe" | 16:37 |
| kgunn | jdstrand: hey i'm trying to modify my seccomp file for mir in place on the vm, but seems to fail on the same syscall...is there a way to update? | 16:37 |
| stgraber | Chipaca: the problem is that part of usptream is setuid so we usually wipe our env clean | 16:38 |
| kgunn | or do i have to rebuild/reinstall the snap? | 16:38 |
| kgunn | tyhicks: ^ | 16:38 |
| Chipaca | stgraber: that makes sense | 16:38 |
| tomconte | ogra_: what's bad about the docker snap? | 16:38 |
| ogra_ | tomconte, it is just a bad example i heard ... | 16:38 |
| stgraber | anyway, will poke around some more, might end up just writting a quick LD_PRELOAD hack for those | 16:38 |
| ogra_ | since it has a bunch of exceptions a normal snap wouldnt be allowed to use | 16:38 |
| Chipaca | stgraber: do keep us updated if you can | 16:39 |
| Chipaca | and holler if you get stuck | 16:39 |
| tomconte | ogra_: ah, I see, but is there a way to package docker in a "clean" way then? | 16:39 |
| ogra_ | tomconte, not sure ... i assume the existing docker snap will be updated at some point ... it comes from a time where not much was working in snappy ... nowadays you can get most features you need for a proper docker snap i suspect | 16:40 |
| Chipaca | ogra_: it'd still need custom security bits though | 16:41 |
| ogra_ | well, but a lot less hacks already i guess :) | 16:41 |
| * kgunn wonders, isn't it b/c docker is a framework.... | 16:42 | |
| tyhicks | kgunn: you can temporarily update the seccomp whitelist for your snap | 16:42 |
| ogra_ | kgunn, that too ... but it actually comes from very early snappy days ... we didnt have any story for hardware access and the like back then | 16:42 |
| tyhicks | kgunn: what is the failing syscall? | 16:43 |
| Chipaca | kgunn: sc-logresolve might help | 16:43 |
| Chipaca | jdstrand: when does sc-logresolve print usage()? | 16:51 |
| ogra_ | Chipaca, when your patch landed that enables it ? | 16:52 |
| Chipaca | noted | 16:52 |
| * Chipaca branches it | 16:52 | |
| Chipaca | but if i suddenly disappear it's because somebody found my runaway dog, not because security gremlins took me down | 16:53 |
| stgraber | so if I set security-override, does that also turn off any cgroup config that's going on with snappy or is there some other thing I need to set to turn that off? | 16:54 |
| stgraber | (LXC has code which will escape the cgroup, so even if I can't turn that off, the cgroup stuff won't apply to me, but that may confuse some things when my process moves out of the cgroup ;)) | 16:55 |
| tomconte | ogra: thanks, asking b/c we were thinking of a snappy+docker image in azure instead of current full_ubuntu+docker | 17:01 |
| Chipaca | stgraber: i'd ask jdstrand that one | 17:01 |
| stgraber | jdstrand: heya | 17:02 |
| stgraber | jdstrand: so I'm doing an initial LXD packaging. That's obviously a framework and that's coming with more craziness that docker :) | 17:02 |
| stgraber | jdstrand: so as a first pass, I'm trying to have everything run without any of the security stuff applied to it. So apparmor unconfined, no seccomp policy and no moving stuff into cgroups. | 17:02 |
| stgraber | jdstrand: how do I do that? | 17:02 |
| stgraber | jdstrand: (the client itself just needs networking, so that bit will be confined using default policies + networking) | 17:03 |
| stgraber | jdstrand: eventually the daemon should be running under an apparmor policy, allowing to transition out to any profile we want (same as lxc-start) but still without any seccomp policy. | 17:04 |
| ogra_ | tomconte, well, i think you can just go ahead with that ... if docker gets updated it should be transparent to you | 17:05 |
| tyhicks | stgraber: the 'unconfined' security template is what you want for running without apparmor or seccomp confinement | 17:07 |
| tyhicks | stgraber: I don't recall a way to prevent the launcher from setting up the cgroup - let me look at that code | 17:07 |
| ogra_ | note that you need to bribe the store people to let your snap into the store then :) | 17:07 |
| tyhicks | I think stgraber is just wanting to get something running locally | 17:08 |
| tyhicks | and then we can decide on what to do for the confinement | 17:08 |
| tyhicks | (prior to uploading to the store) | 17:08 |
| stgraber | yeah and that thing will be a framework anyway, so manual review was kinda always the plan :) | 17:08 |
| tyhicks | stgraber: it looks like the launcher is unconditionally applying the devices cgroup | 17:11 |
| tyhicks | I don't have a good workaround for you there | 17:12 |
| stgraber | tyhicks: ok, well, as long as it doesn't get terribly confused when its cgroup ends up being empty, that should be fine | 17:13 |
| stgraber | tyhicks: LXC has code that will trigger an absolute cgroup move for all controlers, so it'll escape whatever cgroup the launcher creates for it | 17:13 |
| tyhicks | ok | 17:14 |
| jdstrand | stgraber: sorry, was in a meeting | 17:15 |
| jdstrand | stgraber: so the launcher decides when it is going to do the cgroup thing | 17:15 |
| Chipaca | ogra_: https://code.launchpad.net/~chipaca/ubuntu-core-security/usaaage/+merge/262115 just for you :) | 17:15 |
| jdstrand | tyhicks: are you looking at the code now for that ^ | 17:16 |
| jdstrand | tyhicks: my comment, not Chipaca's :) | 17:16 |
| jdstrand | Chipaca: oh gosh, sc-logresolve patch. that thing is barely more than back-of-a-napkin as it is :P | 17:17 |
| Chipaca | jdstrand: :) | 17:18 |
| tyhicks | jdstrand: I already looked at the code - it sets up the devices cgroup unconditionally | 17:18 |
| tyhicks | jdstrand: st graber says that shouldn't be a problem for him at the moment | 17:18 |
| jdstrand | tyhicks: hmmm, what was I thinking of then... seccomp? | 17:18 |
| jdstrand | I know it is making a choice about something, cause docker was grumpy about said something | 17:19 |
| jdstrand | or at least, it was making a choice | 17:19 |
| tyhicks | I'm not sure about that | 17:19 |
| tyhicks | let me look again | 17:19 |
| ogra_ | Chipaca, LOL ! | 17:22 |
| tyhicks | stgraber, jdstrand: I guess if ("/var/lib/apparmor/clicks/%s.json.additional", appname) is empty it won't set up the devices cgroup | 17:22 |
| jdstrand | that's ringing a bell | 17:22 |
| tyhicks | it doesn't have to be empty - it just can't match a hardcoded string in the launcher | 17:23 |
| jdstrand | actually I think I documented that | 17:23 |
| tyhicks | but creating an empty file is the easiest | 17:23 |
| jdstrand | https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Cgroups | 17:23 |
| jdstrand | "Note: because device names are not always static and due to limitations in AppArmor (1350598, 1444679), the device cgroup mechanism is only used when hardware is assigned to a snap, at which point a general write rule for... Conversely, when no hardware is assigned to the app, then the strict AppArmor rules are in effect and an app-specific cgroup is not used. " | 17:24 |
| tyhicks | ah | 17:25 |
| tyhicks | right | 17:25 |
| tyhicks | so just make sure that ("/var/lib/apparmor/clicks/%s.json.additional", appname) doesn't exist | 17:25 |
| jdstrand | I knew there was a reason I wanted to write that down :) | 17:25 |
| jdstrand | tyhicks: right, and it won't by default | 17:25 |
| jdstrand | an oem snap or hw-assign needs to be used | 17:26 |
| tyhicks | got it | 17:26 |
| jdstrand | I <3 documentation :) | 17:26 |
| * lborda asks: any idea how do I get python-smbus in snappy ? i didn't find the package in the ports repo. | 18:03 | |
| Chipaca | lborda: there isn't a python-smbus in ubuntu, even | 18:16 |
| Chipaca | lborda: but you could probably use the one from debian as a starting place | 18:16 |
| ogra_ | huh ? how can it be in debian but not ubuntu | 18:16 |
| lborda | Chipaca, yes there's only in debian https://packages.debian.org/wheezy/python-smbus | 18:17 |
| lborda | Chipaca, i am trying to get the pyglow working on the snappy image... have any of you tried with the pyglow ? | 18:18 |
| ogra_ | http://ports.ubuntu.com/pool/universe/i/i2c-tools/ | 18:18 |
| Chipaca | ogra_: | 18:18 |
| Chipaca | ｍａｇｉｃ | 18:18 |
| ogra_ | there is definitely a python-smbus | 18:18 |
| Chipaca | ogra_: but then why isn't there a python-smbus? | 18:19 |
| ogra_ | even my phone sees it | 18:20 |
| Chipaca | john@fogey:~$ apt-cache search python smbus | 18:21 |
| Chipaca | john@fogey:~$ | 18:21 |
| * Chipaca wonders | 18:21 | |
| ogra_ | no universe ? | 18:21 |
| lborda | i would thought the the python-smbus package would have to be found inside the universe/p/ folder and not inside pool/universe/i/i2c-tools/ | 18:22 |
| ogra_ | the folders are sorted by source package name ;) | 18:22 |
| Chipaca | deb http://archive.ubuntu.com/ubuntu vivid universe | 18:22 |
| ogra_ | python-smbus is a binary | 18:23 |
| ogra_ | http://paste.ubuntu.com/11726399/ | 18:24 |
| ogra_ | Chipaca, oh, you have an archive.u.c entry on an armhf machine ? | 18:24 |
| Chipaca | no, this was on my desktop | 18:25 |
| Chipaca | amd64 | 18:25 |
| ogra_ | ah | 18:25 |
| * Chipaca just noticed there is still a debian ia64 port | 18:25 | |
| ogra_ | well, my amd64 laptop finds it too | 18:26 |
| ogra_ | ogra@styx:~$ apt-cache policy python-smbus|grep archive | 18:26 |
| ogra_ | 500 http://archive.ubuntu.com/ubuntu/ vivid/universe amd64 Packages | 18:26 |
| Chipaca | ok, i'm going to close my computer and go have dinner and pretend weird things are not going on | 18:27 |
| Chipaca | because the gammon smells very good and i'm not going to let some silly smbus weirdness ruin it :) | 18:27 |
| kickinz1 | Just to add to this, I used rmadison against python-smbus: | 18:27 |
| kickinz1 | http://pastebin.ubuntu.com/11726413/ | 18:27 |
| ogra_ | (which is actually the right tool ... yay us ... ) | 18:28 |
| kgunn | tyhicks: sorry, was out to lunch...yep, so this is what i'm seeing https://www.youtube.com/watch?v=dbl81P2Vae4 | 18:40 |
| kgunn | and its munmap | 18:40 |
| kgunn | that's the syscall | 18:40 |
| mterry | mvo__, so I guess with these gettext branches, we need to push a deb package for the gettext module to wily? | 18:47 |
| * mterry was just looking into adding a debian/ dir for snapcraft | 18:47 | |
| tyhicks | kgunn: something's not right there - munmap is allowed in the default seccomp template (many things would break if we didn't allow munmap) | 18:49 |
| tyhicks | kgunn: the resolution isn't great but it looks like you're modifying a seccomp filter file in /apps/mir/snap1/meta/mir.seccomp - is that right? | 18:50 |
| kgunn | tyhicks: correct | 18:53 |
| kgunn | and i see it showing up in that copy as well as the one at | 18:54 |
| kgunn | /writable/system-data/apps/mir/snap1/meta/mir.seccomp | 18:54 |
| tyhicks | kgunn: odd - the launcher looks for seccomp filter files in /var/lib/snappy/seccomp/profiles/ | 18:59 |
| kgunn | tyhicks: ahha, i see that now...and it's missing, but it's filename is just mir_system-compositor-snap1 | 19:01 |
| kgunn | i was expecting it to be mir.seccomp | 19:01 |
| kgunn | tyhicks: so i'm guessing this is the file to modify... | 19:02 |
| tyhicks | kgunn: yeah, give that one a shot and let me know if it works | 19:02 |
| kgunn | tyhicks: awesome thank you!....got a new syscall failure....perfect | 19:03 |
| kgunn | tyhicks: at your earlier statement at it being strange, is it b/c i'm a framwork and having to create my own policy ? | 19:03 |
| kgunn | e.g. i lose all the defaults out of the box when i create my own | 19:04 |
| kgunn | tyhicks: and should i just start by copying some particular default file (template) of syscalls permitted ? | 19:04 |
| tyhicks | kgunn: ah, yes - now it makes sense | 19:05 |
| tyhicks | kgunn: this is the default template: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-core-security/trunk/view/head:/data/seccomp/templates/ubuntu-core/15.04/default | 19:06 |
| jdstrand | kgunn: ah, I meant to follow up with you | 19:06 |
| tyhicks | jdstrand: is there any way for a framework to reuse the default template? | 19:06 |
| tyhicks | (for seccomp) | 19:06 |
| jdstrand | what I have been recommending is installing hello-world.canonical from the store, then scp'ing /var/lib/snappy/seccomp/profiles/hello-world*env into meta/foo.seccomp then referencing foo.seccomp in "security-policy" | 19:08 |
| jdstrand | kgunn: so, in your case, on the device, do "sudo snappy install hello-world.canonical" | 19:08 |
| jdstrand | kgunn: then do: cd /var/lib/snappy/seccomp/profiles/ | 19:09 |
| jdstrand | kgunn: then, sudo cp hello-world.canonical_env_1.0.17 ./<your mir seccomp profile> | 19:09 |
| kgunn | perfect guys...thanks, but struggling has helped it make sense | 19:09 |
| jdstrand | kgunn: then see if it works. if it doesn't, just add syscalls to the end of ./<your mir seccomp profile> until it does | 19:10 |
| jdstrand | one could also do: sed 's/^deny/# EXPLICITLY DENY/' /usr/share/seccomp/templates/ubuntu-core/15.04/default > your.seccomp | 19:13 |
| jdstrand | that is harder to remember | 19:13 |
| jdstrand | kgunn: iirc, that was all you needed from me yesterday (sorry I didn't see until you were eod) | 19:15 |
| ogra_ | jdstrand, regading rickspencer3's bug i actually wonder what image he runs there ... (might be one of the broken RPi ones for example) | 19:46 |
| rickspencer3 | ogra_, if you are talking about my net_admin denial ... it's an update amd64 image | 19:47 |
| jdstrand | ogra_: I confirmed it on amd64 snappy, vivid desktop and precise desktop | 19:47 |
| jdstrand | it is something else | 19:47 |
| ogra_ | (including system-image-cli -i should be mandatory for bug reporting on snappy ;) ) | 19:47 |
| ogra_ | jdstrand, ah, k | 19:47 |
| ogra_ | rickspencer3, thanks | 19:47 |
| jdstrand | ogra_: note, I advised rickspencer3 on what to put in the bug. This seems to be a golang thing but until we know what is tickling that denial, I didn't know where to put it, so we put it in the snappy project for now | 19:48 |
| ogra_ | ah | 19:48 |
| Chipaca | ogra_: kickinz1: fwiw, an apt-get update fixed it, whatever it had been | 20:00 |
| rickspencer3 | Chipaca, you seem like you would know | 20:09 |
| rickspencer3 | when do I use SNAP_APP_USER_DATA_PATH, | 20:10 |
| rickspencer3 | vs. SNAP_APP_DATA_PATH | 20:10 |
| rickspencer3 | ? | 20:10 |
| Chipaca | rickspencer3: i'm not particularly clear on the difference myself, *however* | 20:10 |
| rickspencer3 | nice | 20:10 |
| rickspencer3 | lol | 20:10 |
| Chipaca | rickspencer3: i do know that SNAP_APP_USER_DATA_PATH is owned by the user | 20:10 |
| Chipaca | rickspencer3: and SNAP_APP_DATA_PATH is owned by not-the-user | 20:10 |
| rickspencer3 | Chipaca, ok, if I wrote a program that saved files from sensor data, which envvar would I use for saving the file in? | 20:11 |
| rickspencer3 | (and consequently for uploading the file to the cloud service) | 20:11 |
| Chipaca | rickspencer3: is that a daemon, or a one-off? | 20:11 |
| Chipaca | rickspencer3: daemons will run as root | 20:11 |
| rickspencer3 | daemon | 20:11 |
| rickspencer3 | Chipaca, oh | 20:12 |
| rickspencer3 | well, it is a service | 20:12 |
| rickspencer3 | don't know if it is daemon per se | 20:12 |
| Chipaca | rickspencer3: so SNAP_APP_DATA_PATH should work | 20:12 |
| Chipaca | i meant service, yes | 20:12 |
| rickspencer3 | I declare it as a service, and then use for{time.sleep()} | 20:12 |
| rickspencer3 | ok | 20:12 |
| rickspencer3 | thanks Chipaca | 20:12 |
| Chipaca | use a time.Ticker, but yes | 20:13 |
| rickspencer3 | ? | 20:13 |
| Chipaca | rickspencer3: go? | 20:13 |
| rickspencer3 | Chipaca, yes, but the samples I saw said for{time.sleep()} ... time.Ticker sounds somewhat more sensible, though | 20:13 |
| Chipaca | rickspencer3: for long-lived processes, inside a loop, a time.Ticker is better | 20:14 |
| rickspencer3 | ok, I'll do some Googling and fix that up | 20:14 |
| Chipaca | time.Sleep is straightforward, but will incurr a higher gc overhead over time | 20:14 |
| rickspencer3 | we should really have an app template | 20:14 |
| rickspencer3 | create a stubbed out service for you (or binary if that's what you need) | 20:14 |
| Chipaca | rickspencer3: ideally, we'd be exposing systemd timers | 20:15 |
| rickspencer3 | oh goodness | 20:15 |
| Chipaca | rickspencer3: so you wouldn't need the for loop | 20:15 |
| rickspencer3 | that sounds groovy, yeah | 20:15 |
| Chipaca | just tell us how often you want calling, and if you want to wake up the device when the time comes | 20:15 |
| rickspencer3 | but hard | 20:15 |
| Chipaca | not at all | 20:16 |
| * Chipaca is tempted to show *how* not-hard it is by jfdi'ing it, but needs to keep to a sane schedule | 20:16 | |
| olli | how do I unpack a .snap locally? | 20:18 |
| Chipaca | olli: dpkg-deb ? | 20:18 |
| Chipaca | olli: or ar if you're hardcore | 20:18 |
| Chipaca | olli: or renamed it to .deb and use mc to browse it | 20:18 |
| ogra_ | olli, dpkg-deb -x foobar_0.1_all.snap extracted | 20:18 |
| ogra_ | olli, cd extracted | 20:19 |
| ogra_ | ... fiddle ... fiddle ... fiddle ... | 20:19 |
| ogra_ | cd .. | 20:19 |
| olli | hm | 20:19 |
| ogra_ | snappy build extracted | 20:19 |
| olli | thx guys | 20:19 |
| awojo | Can you convert to snappy after the fact? I'm installing 15.04 VM right now, but I'd like to use snappy | 20:21 |
| ogra_ | awojo, no, ther are completely different (snappy is assembled from debs, but then all deb functionality is removed) | 20:22 |
| ogra_ | s/ther/they/ | 20:22 |
| tedg | So the code using apt-cache and such is getting brittle. Thinking about switching to the python module. | 20:22 |
| awojo | So I'd have to download the snappy iso, and rebuild my VM? | 20:22 |
| tedg | Haven't used it before, anyone giving warnings? :-) | 20:22 |
| ogra_ | rickspencer3, SNAP_APP_DATA_PATH is /var /lib/apps/<app>/<version> ... SNAP_APP_USER_DATA_PATH is ~/apps/<app>/<version>/ | 20:23 |
| rickspencer3 | ogra_, so, if I am capturing sensor data into files, where would I store it? | 20:24 |
| rickspencer3 | i.e. into which dir should I save the file? | 20:24 |
| ogra_ | rickspencer3, if it is a service SNAP_APP_DATA_PATH ... if it is an app the enduser runs perhaps in the USER_DATA_PATH | 20:24 |
| rickspencer3 | it is a service | 20:25 |
| rickspencer3 | interesting distinction | 20:25 |
| * ogra_ never had the need to use the latter yet | 20:25 | |
| rickspencer3 | oh, i guess if it is a multi-user system | 20:25 |
| ogra_ | well, you need to have $USER for the latter | 20:25 |
| Chipaca | awojo: no | 20:26 |
| Chipaca | awojo: what're you wanting to do? | 20:26 |
| ogra_ | awojo, the img is a ready made VM already ... nothing to do ... just download, uncompress and start it with kvm | 20:27 |
| tedg | We probably named those DATA_PATH variables wrong. We should have made it easier to store in the USER directory than the system one. | 20:28 |
| ogra_ | tedg, well, you need a user for that ... | 20:29 |
| ogra_ | tedg, most bits we have/had in the store are actually services | 20:29 |
| ogra_ | (only pastebinit is an enduser app i think) | 20:30 |
| tedg | ogra_, Sure, so for services they should be the same value, no? | 20:30 |
| ogra_ | for services you cant user them | 20:30 |
| ogra_ | s/them/SNAP_APP_USER_DATA_PATH/ | 20:30 |
| ogra_ | there is no user ... where would it point to ? | 20:30 |
| plars | rsalveti: Not sure if you saw this earlier: do you think https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 will be merged at some point soon? It sounds like it causes no harm if you are running the typical debian install on your emmc with bbb, but helps enormously if you do not run the default image on emmc | 20:30 |
| tedg | So perhaps we shouldn't have USER_DATA_PATH at all. If there is a user point to the user's home, otherwise the system dir. | 20:31 |
| plars | or anyone else that might know? ogra_ I think you were looking at that MP also? | 20:31 |
| tedg | Nobody needs both. | 20:31 |
| Chipaca | tedg: +1 i think | 20:31 |
| * sergiusens is back | 20:31 | |
| ogra_ | well, not sure, someone surely had a usecase in mind when adding it | 20:31 |
| ogra_ | (i havent found one where i could make any use of it yet though) | 20:32 |
| * tedg goes on record: Nobody will ever use more than one directory | 20:32 | |
| rsalveti | plars: sure, I can take a look | 20:32 |
| ogra_ | if you have an app that stores config data per user SNAP_APP_USER_DATA_PATH is your place | 20:32 |
| plars | rsalveti: not a super big rush, just wondering, and it's a one-liner | 20:32 |
| ogra_ | plars, i would feel comfortable if elopio could give it a quick shot | 20:32 |
| rsalveti | yeah, just need further testing | 20:32 |
| ogra_ | (after all its a one line change ... quickly done and tested) | 20:32 |
| rsalveti | elopio: care to stamp https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 ? | 20:33 |
| ogra_ | boot, rollback, auto-rollback | 20:33 |
| rsalveti | otherwise I can take a look earlier tomorrow | 20:33 |
| sergiusens | tedg: USER_DATA_PATH is user accessible while SNAP_APP_DATA_PATH root accessible (initially one was for binaries and the other for services) | 20:34 |
| sergiusens | I didn't come up with it and I didn't read the backlog either :-) | 20:34 |
| tedg | sergiusens, The question is whether there'd ever be an app snap that would do both. It seems services need one while user apps need a different one. Seems like there could be one variable depending on how it is executed. | 20:36 |
| ogra_ | but that could be confusing | 20:38 |
| ogra_ | for the packager | 20:38 |
| sergiusens | tedg: my camlistore snap (which is currently unpublished) used both | 20:38 |
| tedg | sergiusens, How did it use both? | 20:38 |
| ogra_ | sergiusens, yeah, where is it ... fix that ! | 20:38 |
| ogra_ | :) | 20:38 |
| tedg | It seems like the service couldn't ever expect to use USER, but I could see an app share with the service through the SYSTEM one. | 20:39 |
| ogra_ | the webdm store on armhf makes me cry currently ... | 20:39 |
| ogra_ | it used to be so niecely filled already | 20:39 |
| tedg | Not sure if that isn't just bad design though :-) | 20:39 |
| ogra_ | tedg, what about a service that serves an app shipped in the same snap | 20:40 |
| ogra_ | you'd want one path for the root owned files and the other for user settings | 20:40 |
| tedg | ogra_, There's also be multiple users, so it couldn't really use the USER directory. | 20:40 |
| ogra_ | why ? | 20:40 |
| ogra_ | teh app knows who executed it | 20:40 |
| ogra_ | (the service doesnt indeed) | 20:40 |
| tedg | Yes, I don't think the service ever needs to know the USER one. | 20:41 |
| ogra_ | i.e. i have a service and a management app ... | 20:41 |
| tedg | Though I could see a app accessing the system one. For instance if there was a service that updated a cache. | 20:41 |
| ogra_ | no, the service doesnt need to know the user one | 20:41 |
| ogra_ | but the app does | 20:41 |
| ogra_ | to store per user settings | 20:41 |
| ogra_ | so your snap needs to use both | 20:41 |
| ogra_ | but that setup comes from a time wheer we didnt have a launcher :) | 20:42 |
| ogra_ | might indeed be obbsolete if the launcher can handle it based on $knowledge (whatever $knowledge is) | 20:42 |
| tedg | Not sure exactly what that should be. But yes, it is interesting. Seems that we'd want DATA_PATH to be "where we want you to write your files" where that is contextual. | 20:47 |
| jdstrand | kgunn: hey, ok, based on what you've been experiencing and the questions you've had, I wrote up: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy | 20:48 |
| === chihchun is now known as chihchun_afk | ||
| kgunn | cool jdstrand | 20:56 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| sergiusens | tedg: right camlistore's binaries were executed by the user | 20:58 |
| jdstrand | kgunn: there may be info in there that you might still find helpful | 20:59 |
| kgunn | will read | 20:59 |
| tedg | sergiusens, So then what did you use the system directory for? The user wouldn't have access, no? | 21:01 |
| kgunn | jdstrand: perfect the development tips is effectively the workflow i'm in at the moment | 21:01 |
| jdstrand | great :) | 21:03 |
| sergiusens | tedg: the client and server communicated over http | 21:04 |
| sergiusens | tedg: server config in /var and user config into /home (the client could talk to other servers and the server could be talked to with other clients, but that is obvious I guess :-P) | 21:05 |
| tedg | sergiusens, I see. So some binaries were executed under the user and then the service was executed under systemd. | 21:06 |
| sergiusens | tedg: yup | 21:06 |
| * ogra_ can imagine there will be many such snaps in the future | 21:07 | |
| ogra_ | services and management tools in the same package ... | 21:07 |
| tedg | Wonder if we could make that easier. Like setup a socket for them that was also in the environment. | 21:08 |
| ogra_ | that wont help if your management app needs to write a config file | 21:09 |
| tedg | How is that going to work on a mobile device, will we allow services? | 21:09 |
| ogra_ | (which it reads on next startup) | 21:09 |
| ogra_ | no idea, but surely on a desktop and on appliances | 21:09 |
| tedg | ogra_, I was more thinking in addition to. | 21:09 |
| ogra_ | i can imagine that we want to allow things like an upnp service on a phone | 21:10 |
| tedg | Not that we'd remove the other mechanisms, just provide an easy way for them to build that app/service architecture. | 21:10 |
| ogra_ | or a streaming service | 21:10 |
| ogra_ | did you know that the first ubuntu phone hack by some external guys was to run a tomcat server on a nexus4 ? ... so i guess we will see that kind of insanity too :) | 21:12 |
| tedg | Wow, I don't even want Java in browser, much less Tomcat :-) | 21:13 |
| ogra_ | http://community.bonitasoft.com/blog/bonita-platform-running-smartphone | 21:13 |
| ogra_ | oh ! | 21:15 |
| ogra_ | i was wrong ... they even ran it on a galaxy nexus ! | 21:16 |
| * ogra_ just noticed the uname in the screenshot | 21:16 | |
| sergiusens | ogra_: wow, that brings back memories :-P | 21:17 |
| ogra_ | yeah :) | 21:18 |
| rsalveti | maguro, wow | 21:32 |
| rsalveti | that brings back memories indeed | 21:32 |
| elopio | rsalveti: ogra_: plars: sure, let me check it. | 22:07 |
| ogra_ | wow, SUI vs CMR just got interesting .. cameroon leads | 22:21 |
| rsalveti | sergiusens: ogra_: snappy on ppc? http://linuxgizmos.com/powerpc-based-iot-gateway-com-ships-with-linux-bsp/ | 22:28 |
| rsalveti | :-) | 22:28 |
| sergiusens | rsalveti: well we do have powerpc support :-) | 22:28 |
| ogra_ | no prob :) | 22:28 |
| rsalveti | yeah | 22:28 |
| ogra_ | (though i shouldnt speak to loud, we dont even manage to produce arm64 atm :P ) | 22:29 |
| sergiusens | ogra_: rsalveti we need to get out of fat packaging :-P | 22:39 |
| ogra_ | yeah, who came up with that insanity :) | 22:39 |
| sergiusens | we can blame Chipaca :-P | 22:39 |
| Chipaca | why do we need to get out of fat packaging? | 22:46 |
| Chipaca | we're doing a lousy job of it right now, fo sure :) | 22:46 |
| sergiusens | Chipaca: i dunno N arches and N gets bigger every day | 22:47 |
| sergiusens | Chipaca: we can be smart once we have the store list the files with hashes and tags them with arch (with automagic header reading) | 22:48 |
| Chipaca | sergiusens: yes, but on the one hand the app binaries are not what take up most of the disk space in many scenarios | 22:48 |
| sergiusens | Chipaca: well camlistore is ~10MB for each arch | 22:48 |
| Chipaca | sergiusens: and on the other hand nothing stops the store from stripping the non-arch things out (other than signage maybe?) | 22:49 |
| Chipaca | in my mind ideally we support both cases well | 22:49 |
| Chipaca | people that care package each arch separately | 22:49 |
| Chipaca | people that don't make a fat one and live simpler lives | 22:49 |
| sergiusens | Chipaca: probably | 22:50 |
| * sergiusens likes to live a simpler life | 22:50 | |
| Chipaca | that'd probably make the "store does magic" thing not be necessary | 22:50 |
| * ogra_ too | 22:50 | |
| Chipaca | so the answer is simpler | 22:50 |
| Chipaca | make a fat one | 22:50 |
| * Chipaca runs | 22:50 | |
| sergiusens | Chipaca: the WHO would have something to say about that | 22:51 |
| sergiusens | ... not the band :-P | 22:51 |
| * Chipaca moves to the netherlands | 22:51 | |
| Chipaca | on a more serious note, if we can agree on some conventions we can have the launcher do LD_PRELOAD and select the right arch binary if multiple are present | 22:53 |
| Chipaca | not LD_PRELOAD | 22:53 |
| Chipaca | LD_LIBRARY_PATH | 22:53 |
| Chipaca | i think that'd be a good first step :) | 22:53 |
| ogra_ | doesnt it do that already ? | 22:53 |
| sergiusens | Chipaca: conventions make things easy, that's how we quickly got things going with click (when moving away from deb) | 22:53 |
| Chipaca | ogra_: no | 22:53 |
| ogra_ | oh | 22:54 |
| * sergiusens stole the convention trick from go | 22:54 | |
| Chipaca | ogra_: yeah | 22:54 |
| sergiusens | ogra_: you can't LD_LIBRARY_PATH if you don't define where that will be | 22:54 |
| ogra_ | ubuntu-app-launch does it on the phone ... i thought that feature was in the snappy launcher too | 22:54 |
| sergiusens | ogra_: no, not there | 22:54 |
| ogra_ | sergiusens, yeah, i thought there was a default like on the phone | 22:54 |
| sergiusens | we can do it for binpath too | 22:54 |
| sergiusens | ogra_: that's why the magic script became popular | 22:55 |
| * sergiusens wonders if the channel will go silent in 40' | 22:55 | |
| ogra_ | on the phone is is <installpath>lib/<triplet>/ | 22:55 |
| ogra_ | why in 40 | 22:55 |
| Chipaca | ogra_: something something copa américa, i'm guessing | 22:55 |
| ogra_ | pffft regional stuff | 22:56 |
| sergiusens | ogra_: Argentina vs Uruguay :P | 22:56 |
| * ogra_ watches the *world* cup instead | 22:56 | |
| sergiusens | ogra_: is that world as the US defines it? "The world series" | 22:57 |
| ogra_ | cameroon switzerland was really great right now | 22:57 |
| ogra_ | switzerland actually lost ... completely unexpected and dramatic :) | 22:57 |
| ogra_ | sergiusens, nope | 22:57 |
| Chipaca | cameroon-switzerland is just as regional as argentina-uruguay | 22:58 |
| ogra_ | womens world cup ;) | 22:58 |
| Chipaca | ah, ok :) | 22:58 |
| Chipaca | (i was going to make a joke about them both being in the africa-eurasia region/continent, but didn't) | 23:00 |
| sergiusens | Chipaca: while you are at it... https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865 | 23:00 |
| Chipaca | afro-eurasia* | 23:00 |
| Chipaca | yeah, bring it on | 23:00 |
| Chipaca | gasp! installYaml is ready to go? | 23:00 |
| sergiusens | Chipaca: yeah, been ready for a while | 23:01 |
| Chipaca | sergiusens: took me a while to realise Boot was not a verb in diskimage | 23:03 |
| Chipaca | sergiusens: anything else? otherwise it's a wrap from me | 23:07 |
| sergiusens | Chipaca: wrap it up, personal is still downloading here... | 23:07 |
| Chipaca | k | 23:07 |
| sergiusens | thanks | 23:08 |
| ogra_ | sergiusens, good luck !! | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!