| === chihchun_afk is now known as chihchun | ||
| zyga | morphis: hey | 06:55 |
|---|---|---|
| morphis | zyga: hey! | 06:56 |
| fgimenez | good morning | 07:19 |
| dholbach | hello hello from mvo's place :-) | 08:03 |
| === bigcat_ is now known as bigcat | ||
| clobrano | morning :) | 08:11 |
| ogra_ | moinsen | 08:26 |
| Odd_Bloke | Morning all. | 08:26 |
| Odd_Bloke | We have a fix for cloud-init for snappy on Azure; where in the normal Ubuntu development lifecycle does this have to get for edge builds to pick it up? Will an upload to wily be sufficient? | 08:27 |
| ogra_ | Odd_Bloke, stable pulls from the official vivid archive (incl. sercurity and updates) and from https://launchpad.net/~snappy-dev/+archive/ubuntu/image | 08:33 |
| ogra_ | s/stable/15.04/ | 08:34 |
| ogra_ | rolling pulls from wily | 08:34 |
| Odd_Bloke | ogra_: Cool, thanks. :) | 08:37 |
| * guest42315 they see me rollin' la la la | 08:39 | |
| ogra_ | uh | 08:41 |
| ogra_ | my snapcraft build doesnt build anymore | 08:41 |
| ogra_ | Branched 4 revisions. | 08:41 |
| ogra_ | [1mIssues while validating snapcraft.yaml: [{'exec': 'usr/bin/bipmkpw', 'name': 'bipmkpw'}] is not of type 'object'[0m | 08:41 |
| ogra_ | Traceback (most recent call last): | 08:41 |
| ogra_ | what does that mean ? | 08:41 |
| ogra_ | did the definition for "binaries" change since yesterday ? | 08:45 |
| mvo | ogra_: I think so :/ | 08:48 |
| ogra_ | where is that documented then ? | 08:48 |
| mvo | ogra_: where is your project? could you push it somewhere? | 08:48 |
| mvo | ogra_: I hope in the snapcraft docs of the branch | 08:48 |
| * ogra_ is happy to make changes as long as he knows which :P | 08:48 | |
| ogra_ | mvo, not really, thats onle the generic stuff from the website | 08:49 |
| mvo | ogra_: binaries:\n name: foo -> changes to binaries:\n foo:\n exec: foo" | 08:49 |
| mvo | ogra_: if you push your stuff I can have a look and help with the diff | 08:49 |
| mvo | ogra_: if its not documented we need to fix that too :/ | 08:50 |
| ogra_ | well, the docs dir in the snapcraft tree has exactly the two pages we have on developer.u.c | 08:50 |
| ogra_ | not sure there are other docs hidden anywhere | 08:50 |
| ogra_ | bah, and the services description changed too it seems | 08:52 |
| ogra_ | ah, got it by blindly poking around | 08:54 |
| ogra_ | (and by looking at the schema file) | 08:54 |
| ogra_ | and hello snappy-bip ! | 08:56 |
| JamesTait | Good morning all; happy Thursday, and happy Punctuation Day! 😃 | 09:36 |
| === ogra2 is now known as ogra-snappy-test | ||
| Chipaca | JamesTait: instead of punctuation day today I'm celebrating I've been a dad officially for 11 years and haven't killed anybody yet \o/ | 10:36 |
| JamesTait | 🙌 | 10:36 |
| ogra_ | congrats to the calmness ! | 10:36 |
| JamesTait | Chipaca, that definitely is cause for celebration! | 10:36 |
| JamesTait | Is there cake? | 10:36 |
| Chipaca | there is not. Because the boys are in France on a school trip. | 10:36 |
| Chipaca | \\\\\o////// | 10:36 |
| clobrano | ;D | 10:37 |
| davmor2 | for the last 11 years no wonder you haven't killed them | 10:37 |
| Chipaca | instead i can stay hacking until 4am and not have to get up at 6 to kickstart their day :) | 10:37 |
| Chipaca | davmor2: har :) | 10:38 |
| Chipaca | davmor2: just this week :) | 10:38 |
| Chipaca | davmor2: for several of those years i couldn't afford the milk they needed, let alone fancy schmancy france :) | 10:38 |
| Chipaca | well. maybe it was a couple of months. felt like years :) | 10:39 |
| davmor2 | Chipaca: hahaha | 10:39 |
| Chipaca | kas1000, wherever you are, i hope your rabbits are all dead | 10:40 |
| Chipaca | clobrano: thanks to your branch we found we were misfiling the CLA emails, so double thanks for that :) | 10:41 |
| clobrano | :D, I find also bugs I am not even looking for | 10:42 |
| Chipaca | clobrano: reviewed! | 10:56 |
| Chipaca | clobrano: needs fixing, but good job | 10:56 |
| Chipaca | clobrano: (i wouldn't be surprised if you told me the code you're replacing suffers from the same problems i called out in your code, fwiw) | 10:56 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | clobrano: another alternative would be to write a couple of variations of the AtomicWrite helper, one for append, one with a line-at-a-time interface | 11:10 |
| Chipaca | or maybe write a whole atomic-writable type that did the whole dance behind the scenes | 11:10 |
| clobrano | Chipaca: I'll have a look at it ;) | 11:18 |
| Chipaca | clobrano: fwiw I think you should do as i suggested in the review | 11:19 |
| Chipaca | clobrano: the other things can be done in later branches | 11:19 |
| clobrano | Chipaca: ook | 11:19 |
| Chipaca | clobrano: sorry if the "atomic-writable file type" sounded very exciting | 11:31 |
| Chipaca | :) | 11:31 |
| * Chipaca would be tempted too | 11:31 | |
| Chipaca | but that's how branches get un-reviewable | 11:31 |
| clobrano | :D | 11:31 |
| clobrano | well, actually I thought about using AtomicWriteFile, but I misinterpreted the description and didn't look at the code well | 11:32 |
| Chipaca | asac: ricmm: http://chipaca.com/post/129773078277/talking-http-to-an-abstract-unix-socket fwiw | 11:35 |
| Chipaca | asac: ricmm: as people trying to use the rest api have stumbled on this a bit | 11:36 |
| Chipaca | clobrano: https://github.com/dchest/safefile fwiw :) | 11:52 |
| Chipaca | pitti: when you have a bit of time, i've got a systemd question just for you | 11:54 |
| Chipaca | pitti: not urgent, not work related | 11:54 |
| Chipaca | trying to start a user unit on a udev event; have gotten the device to show up, but the user unit doesn't | 11:54 |
| pitti | Chipaca: what is your udev rule? | 11:57 |
| pitti | Chipaca: we do that quite a lot, usually through something like ..., ENV{SYSTEMD_WANTS}+="my_unit.service" | 11:58 |
| pitti | Chipaca: for those (SYSTEMD_WANTS) you need to add TAG+="systemd" so that systemd creates a .device unit for it | 11:58 |
| pitti | Chipaca: or you can call systemctl start --no-block in a RUN rule directly too, of course | 11:58 |
| Chipaca | pitti: sorry, xchat crashed and missed that, let me pastebin the bits i have | 12:01 |
| Chipaca | pitti: this is 99-batteries.rule: http://pastebin.ubuntu.com/12541325/ | 12:02 |
| Chipaca | pitti: which results in | 12:02 |
| Chipaca | sys-devices-LNXSYSTM:00-LNXSYBUS:00-PNP0C0A:01-power_supply-BAT1.device loaded active plugged /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:01/power_supply/BAT1 | 12:02 |
| Chipaca | pitti: and this is cbatticon@.service: http://pastebin.ubuntu.com/12541330/ | 12:03 |
| Chipaca | pitti: i tried with BindTo=%i.device also, and didn't have it work | 12:04 |
| pitti | Chipaca: BindTo= doesn't exist, you probably mean BindsTo= | 12:04 |
| pitti | Chipaca: but what is that supposed to do? the After= should already be implied | 12:05 |
| Chipaca | pitti: the internets told me to do it! | 12:05 |
| Chipaca | couldn't find documentation that mentioned BindTo | 12:05 |
| pitti | Chipaca: WantedBy= also seems redundant/unnecessary as you start this from an udev rule, not from a target | 12:05 |
| pitti | Chipaca: man system.unit | 12:06 |
| pitti | Chipaca: but aside from these nitpicks, what does it do? if you plug in the battery, what does systemctl status -l .. show? | 12:06 |
| pitti | Chipaca: i. e. does it get activated and fail, or not activated at all, etc? | 12:06 |
| Chipaca | pitti: it never shows up in systemctl --user status | 12:07 |
| pitti | Chipaca: why would it be in --user? | 12:07 |
| Chipaca | pitti: because SYSTEMD_USER_WANTS? | 12:07 |
| pitti | you start it through udev, that's system | 12:07 |
| pitti | Chipaca: oh sorry, I thought that's SYSTEMD_WANTS | 12:08 |
| Chipaca | pitti: the device unit does show up, as above | 12:08 |
| zyga | hey everyone | 12:11 |
| guest42315 | QUESTION: what's the difference between snaps and clicks? | 12:11 |
| morphis | hey! | 12:11 |
| zyga | we're building a small experimental framework | 12:11 |
| zyga | we're (morphis and me) using bluez 5.34 | 12:11 |
| pitti | Chipaca: ok, then I don't have an off-hand answer, I'm afraid | 12:11 |
| ogra_ | yay, bluez support ! | 12:11 |
| zyga | if anyone is interested to follow us, the code is currently in https://git.launchpad.net/~zyga/+git/snap-manual-bluez5/tree/ | 12:12 |
| Chipaca | guest42315: you can think of snaps as clicks v2 | 12:12 |
| zyga | ask us questions about this anytime if you are interested | 12:12 |
| pitti | Chipaca: "systemd-analyze set-log-level debug", and watching the journal while you plug in the battery might be insightful | 12:12 |
| Chipaca | guest42315: also, HELLO, why the QUESTION format? :) | 12:12 |
| ogra_ | click is in "maintenance mode" | 12:12 |
| ogra_ | snap is actively going forward | 12:12 |
| zyga | morphis: passing bt via -bt hci,host didn't work | 12:13 |
| zyga | morphis: I'll try -bt hci,null | 12:13 |
| morphis | zyga: for too | 12:13 |
| zyga | morphis: just to see if there's anything on the inside | 12:13 |
| morphis | fails with a: qemu: `hci0' not available | 12:13 |
| zyga | morphis: for too? | 12:13 |
| guest42315 | Chipaca, oh, is not live yet? | 12:13 |
| zyga | morphis: oh, where did you see that | 12:13 |
| Chipaca | pitti: found BindsTo, dunno why i was reading it as BindTo all the time (and unable to find it like that) | 12:13 |
| zyga | morphis: in my branch I have redirected qemu lots | 12:13 |
| zyga | logs* | 12:13 |
| zyga | morphis: so that they don't spam the terminal | 12:14 |
| zyga | morphis: but Ididn't see anything about hci | 12:14 |
| zyga | (I think) | 12:14 |
| Chipaca | guest42315: 12:30 utc is in 17 minutes | 12:14 |
| zyga | morphis: trying now with: qemu-system-x86_64 -m 768 -nographic -snapshot -redir tcp:8022::22 -bt hci,null kvm.img >qemu-serial.log & | 12:14 |
| guest42315 | oh, soon then | 12:15 |
| guest42315 | so Chipaca .. what would be the name for v3? v1 is clicks, v2 is snaps, | 12:15 |
| zyga | guest42315: claps ;) | 12:15 |
| Chipaca | guest42315: pops | 12:16 |
| Chipaca | guest42315: poofs | 12:16 |
| guest42315 | no no no | 12:16 |
| Chipaca | guest42315: booms | 12:16 |
| Chipaca | guest42315: kapows | 12:16 |
| Chipaca | probably not "no no nos", no | 12:16 |
| JamesTait | Cracks | 12:16 |
| guest42315 | ^^ +1 | 12:16 |
| JamesTait | As in "I'm addicted to updating, I just have to have the latest Crack." | 12:17 |
| guest42315 | hehe | 12:17 |
| zyga | JamesTait: heh :) | 12:17 |
| Chipaca | or maybe we sell out and call it the Big CoproporationTM Asynchronous Atomic Secure Boring System And Package Maintenance Agent, or bcaasbsapma for short | 12:18 |
| guest42315 | home edition? | 12:19 |
| * Chipaca would not put any chits on that number | 12:19 | |
| Chipaca | guest42315: the home edition would let you use more than one core at a time! | 12:19 |
| Chipaca | guest42315: for only 99 a month more | 12:19 |
| guest42315 | :))) | 12:19 |
| guest42315 | 10 min left | 12:19 |
| dholbach | yep :( | 12:19 |
| dholbach | :-) | 12:19 |
| morphis | zyga: problem solved, do a sudo hciconfig hci0 up | 12:20 |
| Chipaca | dholbach: you have people queueing up to see you. It's the price of fame I'm afraid. | 12:20 |
| morphis | but before: systemctl stop bluetooth | 12:20 |
| dholbach | Chipaca, they all want to see sergiusens | 12:20 |
| Chipaca | dholbach: ah. So you're the bass player in the group, I see. | 12:20 |
| JamesTait | Drummer. 😉 | 12:21 |
| zyga | ohh | 12:21 |
| zyga | I'm such a dummie | 12:21 |
| zyga | I kept running the old snap :) | 12:21 |
| zyga | morphis: so what is that with host or null? | 12:21 |
| morphis | with host | 12:21 |
| morphis | push a chnage in a minute | 12:21 |
| Chipaca | pitti: do i have to "enable" the @.service, or is that automatic? | 12:21 |
| dholbach | Chipaca, JamesTait: works for me - hip hip chin chin to the rhythm section | 12:21 |
| * JamesTait is the roadie or something. | 12:22 | |
| morphis | zyga: pull | 12:22 |
| zyga | morphis: nice! | 12:23 |
| morphis | we could also use vhci support if we want | 12:23 |
| zyga | morphis: trying | 12:23 |
| zyga | morphis: what is vhci exactly? | 12:23 |
| morphis | qemu seems to have support for that | 12:23 |
| morphis | a virtual HCI device | 12:23 |
| pitti | Chipaca: no, if you start it from udev you don't want/need to start it at boot (which is what enabling does -- you say that some target that is already started at boot pulls in that) | 12:23 |
| zyga | morphis: is it a totally virtual bt | 12:23 |
| morphis | yes | 12:24 |
| zyga | morphis: or some sort of sharing from the real one | 12:24 |
| zyga | morphis: can we boot two qemu boxes | 12:24 |
| morphis | no, totally virtual | 12:24 |
| zyga | morphis: and have them talk over those virtual bts? | 12:24 |
| morphis | never tried that | 12:24 |
| zyga | I'll check that passthrou works | 12:25 |
| zyga | morphis: what do we do next if this works? | 12:25 |
| morphis | zyga: verify if we find any available bluetooth devices :) | 12:25 |
| zyga | morphis: ok, let's see | 12:26 |
| morphis | doing that already | 12:26 |
| zyga | morphis: mine stil boots | 12:26 |
| morphis | hm | 12:26 |
| morphis | why doesn't the bluetooth device appear | 12:26 |
| zyga | morphis: is it possible that we need udev rule for something | 12:28 |
| morphis | it isn't in /sys | 12:29 |
| morphis | that is where it should be | 12:29 |
| morphis | there is no bt device in 7dev | 12:29 |
| zyga | morphis: where should it be in /sys/ ? | 12:30 |
| zyga | sys/class/hci or somethingf? | 12:30 |
| zyga | (slow slow slow) | 12:30 |
| morphis | /sys/class/bluetooth | 12:30 |
| guest42315 | QUESTION: can i install snappy on my home router? | 12:30 |
| zyga | morphis: yep, it is empty | 12:30 |
| dholbach | just about to start | 12:31 |
| zyga | morphis: any modules we might be missing? | 12:31 |
| guest42315 | live | 12:32 |
| zyga | morphis: what does your systemctl status say? mine says degraded | 12:32 |
| ogra_ | yay | 12:32 |
| guest42315 | wave o/ | 12:32 |
| yashi_ | live :) | 12:32 |
| guest42315 | install snappy on a toaster! live | 12:32 |
| morphis | zyga: rebooting .. | 12:32 |
| davidcalle | o/ | 12:33 |
| zyga | morphis: where do logs go? syslog or dedicated | 12:33 |
| morphis | zyga: that is what I am not sure about | 12:33 |
| morphis | trying to figure out how this bt forwarding works | 12:33 |
| ogra_ | journalctrl or syslog | 12:33 |
| ogra_ | (both atm) | 12:33 |
| guest42315 | starcraft? | 12:33 |
| ogra_ | snapcraft is our start, yes | 12:34 |
| ogra_ | *star | 12:34 |
| ogra_ | :) | 12:34 |
| guest42315 | :D | 12:34 |
| morphis | zyga: some documentations says only the M800, M810 qemu machine type has a emulated hci ctrl | 12:34 |
| zyga | morphis: I think the mistake is that we switch off bluez on the host | 12:34 |
| zyga | morphis: (bluez only) The corresponding HCI passes commands / events to / from the physical HCI identified by the name id (default: hci0) on the computer running QEMU. Only available on bluez capable systems like Linux. | 12:34 |
| morphis | "The Transport Layer is decided by the machine type. Currently the machines "n800" and "n810" have one HCI and all other machines have none." | 12:35 |
| zyga | morphis: it seems that the actual hardware says on the host, what happens is tha the gues just sees some events injected by qemu? | 12:35 |
| morphis | no | 12:35 |
| zyga | morphis: ok, let's try USB pass-thru | 12:35 |
| morphis | the host interface needs to be on | 12:35 |
| zyga | morphis: that works for sure (we used it) | 12:35 |
| morphis | qemu will forward all HCI commands to the enabled host interface | 12:35 |
| noizer | Is there an gui for snappy? | 12:35 |
| ogra_ | noizer, only a web gui for the store atm | 12:36 |
| noizer | When will there an release with a gui? | 12:36 |
| morphis | zyga: looks like the missing emulated device in qemu is the reason | 12:36 |
| zyga | morphis: I think you are right | 12:36 |
| guest42315 | and a snap scope? on the phone? | 12:36 |
| * zyga looks at how to identify the right bt device to use | 12:36 | |
| morphis | zyga: so usb forwarding .. | 12:37 |
| ogra_ | noizer, planned for the future, but the focus is currently headless ... once that is 100% solid there will be UI bits on top (essentially anything that can use Mir/XMir | 12:37 |
| ogra_ | no ETA yet though | 12:37 |
| ogra_ | guest42315, i thinnk that exists already (but doesnt do much, needs snap integration on the bottom layer) | 12:38 |
| morphis | zyga: look at /sys/class/bluetooth/hci0/device/uevent | 12:38 |
| morphis | gives you PRODUCT= | 12:38 |
| zyga | morphis: lsusb | 12:39 |
| guest42315 | ogra_, yeah someone posted a video on youtube, if i remember correctly | 12:39 |
| zyga | morphis: for me that says Bus 004 Device 003: ID 0a5c:2145 Broadcom Corp. BCM2045B (BDC-2.1) [Bluetooth Controller] | 12:39 |
| morphis | or that way | 12:39 |
| zyga | morphis: then I just add -usb -device usb-host,hostbus=4,hostaddr=3 \ | 12:39 |
| zyga | morphis: testing now | 12:40 |
| zyga | morphis: needs sudo :) | 12:40 |
| morphis | is a bit more complex here | 12:40 |
| morphis | connected over an internal hub | 12:40 |
| zyga | morphis: how? | 12:41 |
| rbasak | mvo wrote a God daemon? :) | 12:41 |
| ogra_ | rbasak, to make snappy rule the world ;) | 12:41 |
| ogra_ | it is confined though | 12:41 |
| zyga | morphis: I removed the hci up and service shut-down | 12:41 |
| morphis | zyga: do I have to leave the port number just out when setting up the forwarding? | 12:41 |
| zyga | morphis: not sure if that's needed | 12:41 |
| morphis | zyga: you need to unload the bluetooth driver your system has loaded | 12:42 |
| zyga | morphis: port number for tcp redirects? | 12:42 |
| morphis | btusb normally | 12:42 |
| morphis | |__ Port 11: Dev 13, If 0, Class=Wireless, Driver=btusb, 12M | 12:42 |
| zyga | (booting now, we'll see shortly) | 12:42 |
| zyga | morphis: for wifi we did not touch any modules | 12:42 |
| zyga | morphis: maybe bt is different, let's see what I get | 12:43 |
| ogra_ | staging the stage | 12:44 |
| sergiusens | staging phase | 12:44 |
| dholbach | :) | 12:45 |
| willcooke | thanks dholbach | 12:45 |
| carif_ | uoa question: are the sections/stanzas for the .yaml file described in detail somewhere? | 12:46 |
| ogra_ | carif_, there si a schema file in the snapcraft source that is supposed to be turned into a proper doc | 12:47 |
| zyga | morphis: success | 12:47 |
| zyga | morphis: it worked! | 12:47 |
| morphis | yeah! | 12:47 |
| morphis | didn't get my usb device forwarded yet | 12:47 |
| carif_ | ogra_, ty | 12:47 |
| zyga | morphis: I'll push my setup | 12:47 |
| ogra_ | carif_, http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/schema/snapcraft.yaml | 12:47 |
| ogra_ | there will be a proer example snapcraft.yaml based on that | 12:48 |
| ogra_ | *proper | 12:48 |
| * guest42315 witchcraft | 12:48 | |
| yashi_ | uoa: it's very nice to see that snapcraft pulls all dependencies for you | 12:48 |
| zyga | morphis: but I can already see that confinement aside this really works | 12:48 |
| morphis | zyga: yeah! | 12:48 |
| morphis | zyga: next things: | 12:48 |
| morphis | run bluetoothctl | 12:48 |
| morphis | > power on | 12:48 |
| morphis | > scan on | 12:48 |
| morphis | waiting for devices being found | 12:48 |
| zyga | morphis: works | 12:49 |
| zyga | morphis: I see my speaker! | 12:49 |
| morphis | wow! | 12:49 |
| zyga | morphis: it works :D | 12:49 |
| zyga | haha | 12:49 |
| zyga | nice | 12:49 |
| yashi_ | uoa: any reason why libgthread is not listed in snap: section? | 12:49 |
| zyga | how long did it took us? | 12:49 |
| zyga | :D | 12:49 |
| morphis | zyga: you have some LE device? | 12:49 |
| zyga | o/ | 12:49 |
| zyga | morphis: no, I don't :-( | 12:49 |
| morphis | zyga: half a day :) | 12:49 |
| morphis | zyga: I have one | 12:49 |
| zyga | morphis: amazon links appreciated | 12:49 |
| zyga | morphis: test it! | 12:49 |
| morphis | search for TI sensortag | 12:50 |
| morphis | zyga: let me get some lunch first | 12:50 |
| pratt | QUESTION: do the asterisks at the end of the file names in the yaml file have significance? | 12:50 |
| morphis | zyga: would be great if you can help until I am back with how to forward my usb device the right way: http://paste.ubuntu.com/12541750/ | 12:50 |
| zyga | morphis: ok | 12:51 |
| morphis | it's: |__ Port 11: Dev 13, If 0, Class=Wireless, Driver=btusb, 12M | 12:51 |
| zyga | morphis: lsusb? | 12:51 |
| carif_ | UOA question: can I use language packages as parts, e.g. python pip packages? | 12:51 |
| zyga | morphis: you can try both | 12:51 |
| morphis | just using bus=1 and addr=13 didn't worked | 12:51 |
| zyga | morphis: look at my branch, I used sudo as well | 12:51 |
| zyga | oh | 12:51 |
| zyga | hmm | 12:51 |
| ogra_ | carif_, i thnk you can | 12:52 |
| morphis | zyga: oh wonder | 12:52 |
| morphis | with your changes it just seem to work | 12:53 |
| morphis | lets wait until the device has booted | 12:53 |
| morphis | zyga: you have another BT Usb dongle? | 12:53 |
| morphis | zyga: or an Ubuntu phone? | 12:53 |
| carif_ | yup, that answered it, ty | 12:54 |
| zyga | morphis: yes | 12:54 |
| zyga | morphis: both :) | 12:54 |
| zyga | morphis: what do you have on your mind? | 12:54 |
| morphis | setting up a GATT service | 12:54 |
| zyga | morphis: though the dongle I have is ancient, it's not 4.0 | 12:55 |
| morphis | ah | 12:55 |
| zyga | morphis: my desktop has 4.0 though | 12:55 |
| zyga | morphis: it's pretty fresh | 12:55 |
| zyga | morphis: and I also have the phone | 12:55 |
| morphis | that is the one used in the vm? | 12:55 |
| zyga | morphis: (all kinds) | 12:55 |
| zyga | morphis: no, the one in the VM is whatever my thinkpad x200 has | 12:55 |
| zyga | morphis: BCM2045B | 12:55 |
| zyga | morphis: though I can boot the KVM image on another machine | 12:56 |
| carif_ | lol | 12:57 |
| zyga | morphis: so what would be the best target to try | 12:58 |
| morphis | zyga: great | 12:58 |
| morphis | zyga: bluez-5.34/tools/gatt-service.c is the one you need to run there | 12:58 |
| morphis | with bluetoothd running | 12:58 |
| pratt | QUESTION: could you go into more detail about stage-packages? i don't understand whether you have to have them or they are helpful but optional | 13:00 |
| ogra_ | pratt, the stage dir is always there ... not always used for packages though, it is just the place wheer all bits are collected for later consumption | 13:01 |
| zyga | morphis: it's not built by the current config, trying to build it explicitly | 13:02 |
| morphis | zyga: http://paste.ubuntu.com/12541848/ | 13:02 |
| yashi_ | QUESTION: does `snapcraft run` can run ARM instance on amd64 host? | 13:03 |
| ogra_ | not yet, no | 13:03 |
| morphis | zyga: that is my small LE key finder | 13:03 |
| zyga | :) | 13:03 |
| zyga | morphis: let me try something like that | 13:03 |
| ogra_ | snapcraft also can not cross build yet, you need to run it in an arm chroot or on arm HW | 13:03 |
| pratt | thanks! | 13:03 |
| morphis | so, now its really time for lunch | 13:03 |
| zyga | morphis: later on you have to tell me what's the right comand sequence | 13:05 |
| zyga | morphis: pair vs connect | 13:05 |
| zyga | morphis: http://pastebin.ubuntu.com/12541867/ | 13:05 |
| zyga | morphis: I had to fiddle with on/off button on the device to make it discoverable | 13:05 |
| sergiusens | https://wiki.ubuntu.com/Snappy/Parts | 13:06 |
| longsleep | Is there any news for building multi-arch snaps with snapcraft? | 13:06 |
| ogra_ | longsleep, not yet, nope | 13:06 |
| yashi_ | QUESTION: .snap packages are mean to be self contained, meaning there shouldn't be any dependecies like .debs. What is the current plan to support basic libraries like libc or libz for dependecies from existing C applications? Are we gonna have API versions/levels like Android? | 13:11 |
| rbasak | Debian policy says "Packages must not require the existence of any files in /usr/share/doc/ in order to function [115]." | 13:12 |
| rbasak | So perhaps it is acceptable for snappy to default to exclude that by default since it is guaranteed to not break anything. | 13:13 |
| ogra_ | rbasak, well ... | 13:13 |
| ogra_ | rbasak, debs often ship the copyright file in there ... if your snap includes deb binaries you will likely want at least the copyrigth to persist | 13:14 |
| rbasak | I imagine that maintaining copyright and licensing information should be part of a separate process | 13:15 |
| ogra_ | why ? | 13:15 |
| yashi_ | ah, ok. so apps should target to an lts release? | 13:15 |
| rbasak | As debs are only once source of files being delivered, and one that happens to embed this information. What about the others? | 13:16 |
| ogra_ | if you have existing copyright files there is no need to re-write that or copy it around | 13:16 |
| carif_ | uoa question: so to clarify, I make a .snap with snapcraft and i install a .snap with snappy. 'snapcraft run' fires up a container and 'snap install' s the snap, right? | 13:16 |
| ogra_ | rbasak, well, for other projects the mechanism they actually use is used ... i.e. make install | 13:16 |
| rbasak | Need to define some way to pull those in and present the information to the end user. When grabbing from debs grab the copyright file (only), when grabbing from other sources then use what is defined for that (or from the main yaml file or whatever). Then consolidate all of that into one place. | 13:17 |
| ogra_ | rbasak, there are no plans to "present" it | 13:17 |
| T-mon | Hello! Is there a snapcraft part type for qmake-projects? | 13:17 |
| ogra_ | rbasak, but we need to chip it in the snap | 13:18 |
| ogra_ | *ship | 13:18 |
| rbasak | If shipping it in the snap is how you define "present" it, then that's fine. | 13:18 |
| rbasak | Wiki parts seem like a really neat way to make it easy for snappers to share parts. Good job to whoever came up with that :) | 13:19 |
| * ogra_ would like to see /usr/share/doc/ contents gone btw ... since its a waste of space ... | 13:19 | |
| ogra_ | but we have to keep the copyright file there | 13:19 |
| thibautr | Is there a list of all the project types supported by snapcraft? | 13:20 |
| rbasak | My point is that you don't have to keep it *there*. As long as you ship it. | 13:20 |
| ogra_ | sure, but that would mean more modification | 13:20 |
| rbasak | Forget usr/share/doc. It makes no sense to a snap consumer anyway, since they aren't seeing things on a per-package basis. | 13:20 |
| ogra_ | (in the course of deleting content from the dir it could indeed copy the copyright file someweher else) | 13:20 |
| carif_ | dholbach, mvo, sergiusens, ty for uoa tutorial | 13:21 |
| dholbach | thanks a bunch everyone! | 13:21 |
| yashi_ | thanks! | 13:22 |
| willcooke | thanks | 13:22 |
| sergiusens | carif_, no problem, was a pleasure | 13:22 |
| ogra_ | thibautr, there is a doc planned (not sure if early work exists already) ... sergiusens ? | 13:23 |
| sergiusens | thibautr, I intend to add this to snapcraft's cli, but for now all plugins are defined in /usr/share/snapcraft/plugins | 13:23 |
| sergiusens | ogra_, yes there is a doc planned being written as we speak which will eventually go into developer.u.c | 13:23 |
| ogra_ | \o/ | 13:24 |
| sergiusens | s/as we speak/as we write and read/ | 13:24 |
| ogra_ | moar docs !! | 13:24 |
| ogra_ | do we have a qmake type yet ? | 13:25 |
| mvo | thanks, yeah, it was a pleasure! | 13:25 |
| ogra_ | (see T-mon''s question above) | 13:25 |
| sergiusens | ogra_, I answered live about that | 13:26 |
| ogra_ | oh | 13:26 |
| * ogra_ missed that | 13:26 | |
| sergiusens | repeating just in case, there is no qmake type for a part but we are glad to help you write one if you feel like it :-) | 13:26 |
| yashi_ | sergiusens: about api level, is there anyway to specify which release an app is targetting to? | 13:32 |
| ogra_ | no | 13:34 |
| ogra_ | well, in the sotre there is ... but not inside the snap | 13:34 |
| ogra_ | *store | 13:35 |
| beuno | right, and the store makes sure the right release gets the right snap | 13:35 |
| yashi_ | ogra_, beuno: i see | 13:35 |
| === fginther` is now known as fginther | ||
| yashi_ | how about dynamic load module? many code specify absolute path for dlopen, does snappy has any trick for that? | 13:40 |
| ogra_ | you would have to patch the source for that i fear | 13:42 |
| ogra_ | to read the path from the execution env | 13:42 |
| Saviq | sergiusens, snapcraft tries to download from http://.archive.ubuntu.com here | 13:45 |
| Saviq | where does it try to take the country bit from? | 13:45 |
| sergiusens | Saviq, I fixed that, geoip | 13:45 |
| sergiusens | Saviq, just need to do an interim release :-/ | 13:46 |
| Saviq | kk | 13:46 |
| ogra_ | sergiusens, btw, i copied your 0.2 around in the daily PPA for the other releases, cjwatson needed that for LP | 13:47 |
| sergiusens | Saviq, already in trunk, will land soon in tools-proposed and makes it way to tools as soon as we go over validation; ftr bug #1499158 | 13:47 |
| ubottu | bug 1499158 in Snapcraft "geoip does not work on launchpad servers" [Critical,New] https://launchpad.net/bugs/1499158 | 13:47 |
| plars | sergiusens: ah, I was just going to ask about the _get_geoip_country_code_prefix() failure, is there a quick workaround? | 13:47 |
| sergiusens | plars, build from trunk :-) | 13:47 |
| plars | sergiusens: I'll re-pull thanks | 13:47 |
| Saviq | error while executing external command kpartx -ds 15.04.img: device-mapper: remove ioctl on loop0p5 failed: Device or resource busy | 13:52 |
| Saviq | loop deleted : /dev/loop0 | 13:52 |
| Saviq | any idea about ↑? this was snapcraft run, and AFAICT after that it's stuck trying to ssh in | 13:52 |
| sergiusens | Saviq, oh, not that again :-) bug report please; also provide me your working dir | 13:54 |
| sergiusens | Saviq, it's u-d-f failing to unmount the image; so it is either something missed closing it's file descriptor (seems to be trendy these days) or the kpartx unmount bug | 13:55 |
| sergiusens | also mention the release please | 13:55 |
| Saviq | sergiusens, whole working dir? there's the image in there now, too | 13:55 |
| Saviq | wily, fwi | 13:56 |
| Saviq | w | 13:56 |
| sergiusens | Saviq, k; yeah I don't need curdir/pwd | 13:56 |
| * sergiusens needs a wily instance | 13:56 | |
| * sergiusens thinks of elopio triaging Saviq's bug :-) | 13:56 | |
| Saviq | sergiusens, bug #1499376 | 13:57 |
| ubottu | bug 1499376 in snapcraft (Ubuntu) "snapcraft run stuck after device busy error" [Undecided,New] https://launchpad.net/bugs/1499376 | 13:57 |
| yashi_ | ogra_: thanks :-) | 14:01 |
| T-mon | Hello! Just a quick question...I hope! I'm using sqlite3 in my snapp and I save my db in $SNAP_APP_DATA_PATH | 14:20 |
| T-mon | but this works only if I use security-template: unconfined | 14:21 |
| T-mon | which is not allowed for the store | 14:21 |
| T-mon | which template do I have to use for sql? | 14:21 |
| T-mon | do I have to write my onw apparmor file? | 14:22 |
| ogra_ | that shouldnt be depending on the template at all if whatever uses the db is in the same snap and knows the right path | 14:22 |
| ogra_ | all your binaries should be able to read and write stuff underneath $SNAP_APP_DATA_PATH | 14:23 |
| T-mon | yes, for the settings this works | 14:23 |
| T-mon | my service says: LogEngine: Opening logging database "/var/lib/apps/guh.sideload/0.1.4/guhd.log" | 14:24 |
| ogra_ | so drop the unconfined template and watch syslog/dmesg for the exact denials | 14:24 |
| sergiusens | T-mon, as ogra_ mentions it should all just work if in the right data paths, sqlite should just work | 14:25 |
| ogra_ | unless some binary does calls outside of the snap env and seccomp blocks it or so | 14:26 |
| Chipaca | T-mon: emphasis on should :) | 14:26 |
| Chipaca | T-mon: logs, and we can fix it for you and/or for everyone | 14:26 |
| ogra_ | yeah | 14:26 |
| T-mon | hmm...I'getting following error:audit: type=1326 audit(1443096021.115:672): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1861 comm="guhd" exe="/apps/guh.sideload/0.1.4/usr/bin/guhd" sig=31 arch=40000028 syscall=207 compat=0 ip=0x7654e836 code=0x0 | 14:27 |
| T-mon | 14:27 | |
| sergiusens | right, but sqlite has no magic last I saw; unless whatever wrapping lib wants to do something special | 14:27 |
| sergiusens | ah, seccomp | 14:27 |
| ogra_ | use sc-logresolve | 14:27 |
| ogra_ | that translates it a bit :) | 14:27 |
| ogra_ | (at least it lets you know what syscall=207 refers to in human speak) | 14:28 |
| T-mon | ok, I have to rebuild the snapp, just a moment :) | 14:28 |
| Chipaca | T-mon: sudo sc-logresolve /var/log/syslog | 14:29 |
| Chipaca | T-mon: should do it | 14:29 |
| ogra_ | yeah | 14:29 |
| ogra_ | do you even need /var/log/syslog in that line ? | 14:30 |
| jdstrand | mvo: hey, I know you're busy, but if you could express an opinion on the bug in https://bugs.launchpad.net/snappy/+bug/1499109 it would help my doc writing | 14:30 |
| ubottu | Launchpad bug 1499109 in Snappy "hw-assign and oem assign are inconsistent" [Undecided,New] | 14:30 |
| Chipaca | ogra_: if no file specified, stdin | 14:30 |
| ogra_ | ah | 14:30 |
| Chipaca | ah | 14:31 |
| Chipaca | no | 14:31 |
| Chipaca | ogra_: no :) | 14:31 |
| ogra_ | heh | 14:31 |
| jdstrand | mvo: basically, they work differently. at one point, that was by design iirc, but then a commit came in that made me think they were supposed to be aligned | 14:31 |
| Chipaca | ogra_: If <logfile> is unspecified, use '/var/log/syslog'. If <logfile> is '-', use <stdin>. | 14:31 |
| ogra_ | yeah | 14:31 |
| ogra_ | i thinnk i ran it before without any option | 14:31 |
| jdstrand | mvo: I guess depending on what you say, there is a third option: "Won't Fix" :) | 14:32 |
| T-mon | audit: type=1326 audit(1443105156.359:695): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=3040 comm="guhd" exe="/apps/guh.sideload/0.1.4/usr/bin/guhd" sig=31 arch=40000028 syscall=207(fchown32) compat=0 ip=0x76592836 code=0x0 | 14:33 |
| T-mon | once I started the service with unconfined, and the log file exists | 14:34 |
| T-mon | it worked even without the security template | 14:34 |
| T-mon | then I deleted the log file and I got the Bad system call again | 14:34 |
| jdstrand | T-mon: chown isn't allowed because there isn't a reliable uid to chown into | 14:34 |
| sergiusens | well, unconfined is unconfined | 14:34 |
| mvo | jdstrand: sure, I have a look, in a meeting right now | 14:35 |
| jdstrand | T-mon: at some point we will provide an optional uid to snaps | 14:35 |
| jdstrand | mvo: it isn't urgent-- just want to have the doc bits in place by eow/next week | 14:36 |
| mvo | jdstrand: hm, " * adds a generic apparmor write-path for all devices (ie, /dev/**)" sounds wrong indeed | 14:36 |
| T-mon | if the service creates the log file, why he has to change the ownership? | 14:38 |
| jdstrand | mvo: well, remember, the launcher looks for that 'needle' string. if it finds it, it uses cgroups for access to /dev, otherwise it uses apparmor | 14:38 |
| jdstrand | *only* apparmor | 14:39 |
| jdstrand | T-mon: logically, you are right, it shouldn't have to. you'll have to look at the code to see what it is try to do | 14:40 |
| ogra_ | T-mon, does guhd have a config file where you can define a user ? perhaps set that to root | 14:40 |
| ogra_ | (if it checks for ownership before the chwon that might be enough) | 14:41 |
| jdstrand | mvo: (so adding /dev/** to the override is correct if we want to use cgroups) | 14:41 |
| mvo | jdstrand: yeah, I am remembering the details now | 14:41 |
| T-mon | jdstrand: https://github.com/guh/guh/blob/master/server/logging/logengine.cpp#L44 | 14:41 |
| T-mon | ogra_: guhd is a service, I checkd the userid and it will always be started as root | 14:42 |
| ogra_ | ah, k | 14:42 |
| jdstrand | mvo: no worries-- I am pulling all that up from deep swap trying to document it :) | 14:45 |
| mvo | jdstrand: right, I re-read this and I think we need to go with option (2), i.e. make it consitent with the oem snap. | 14:45 |
| jdstrand | mvo: btw, sorry for all the hw-assign bugs-- in documenting it I found a few things | 14:45 |
| mvo | jdstrand: just the opposite, thanks a lot for finding the issues! | 14:46 |
| jdstrand | mvo: ok, well, think about it and respond whenever | 14:46 |
| jdstrand | I'll keep an eye out for it and adjust the doc accordingly | 14:46 |
| elopio | sergiusens: Saviq: I think it's the same as https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1496484 | 14:47 |
| ubottu | Launchpad bug 1496484 in goget-ubuntu-touch (Ubuntu) "device-mapper: remove ioctl on loop0p5 failed: Device or resource busy" [Undecided,New] | 14:47 |
| elopio | it happens sometimes here. Less often than last week. | 14:47 |
| sergiusens | elopio, Saviq then I need to run u-d-f in a debug mode I have and see if the latest and greatest from snappy has a dangling fd | 14:48 |
| sergiusens | we already had these issues | 14:48 |
| elopio | sergiusens: Saviq: and it is also https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1473333 | 14:53 |
| ubottu | Launchpad bug 1473333 in goget-ubuntu-touch (Ubuntu) "exits with zero on error" [High,Confirmed] | 14:53 |
| elopio | if udf exits with != 0, snapcraft run wouldn't try to ssh into the vm. | 14:54 |
| rickspencer3 | can anyone tell me where to find a list of existing plugins for snapcraft? | 15:11 |
| T-mon | jdstrand: ok, I found out the QSqlQuery makes the "Bad system call" -> https://github.com/guh/guh/blob/master/server/logging/logengine.cpp#L240 | 15:11 |
| T-mon | this makes no sense to me :( | 15:12 |
| clobrano | Chipaca: after pushing new changes for your review, I've to go to "resubmit proposal"? | 15:12 |
| Chipaca | clobrano: nope | 15:12 |
| Chipaca | clobrano: just tell me you've pushed them in case i don't see the email | 15:12 |
| clobrano | Chipaca: so... I pushed them :D | 15:12 |
| T-mon | rickspencer3: ls -l /usr/share/snapcraft/plugins/ | 15:12 |
| rickspencer3 | thanks T-mon | 15:13 |
| yashi_ | hmm... py3version returns list of versions on wily, and that isn't expected in snapcraft | 15:13 |
| yashi_ | might be better to check the return val in Python3ProjectPlugin::python_version()? | 15:15 |
| sergiusens | rickspencer3, /usr/share/snapcraft/plugins (I'm going to spec a cli option for this) | 15:17 |
| sergiusens | yashi_, bug please :-) | 15:18 |
| jdstrand | T-mon: so, to unblock yourself for development until you figure out how to fix that in your app, you can add the missing syscall to /var/lib/snappy/seccomp/profiles/<your app> | 15:23 |
| === vrruiz_ is now known as rvr | ||
| T-mon | jdstrand: thx! though I have no idea how to create a db without a query...yet :) but I will do some experiments | 15:29 |
| yashi_ | sergiusens: bug #1499429 | 15:33 |
| ubottu | bug 1499429 in Snapcraft "snapcraft dies with "export: python3.5/dist-packages: bad variable name"" [Undecided,New] https://launchpad.net/bugs/1499429 | 15:33 |
| jdstrand | T-mon: I would imagine that code is triggering something else lower | 15:34 |
| fgimenez | elopio, i'm executing the suite in kvm rollling edge and flashing for bbb | 15:36 |
| elopio | fgimenez: cool. Let me know how it goes, but don't stay after your EOD. I have plenty of hours ahead of me today. | 15:39 |
| elopio | mvo: so, we wait on your fix for the ppp order? | 15:39 |
| mvo | elopio: I'm investigating it now | 15:41 |
| fgimenez | elopio, mvo should snappy config work for ppp in 181? i'm getting this http://paste.ubuntu.com/12543133/ | 15:42 |
| T-mon | jdstrand: It workes now (temporary) by uncomment the fchown32 in the /var/lib/snappy/seccomp/profiles/ ...thx for the hint! I'm trying now to find out whats going on in the query. | 15:44 |
| mvo | fgimenez: hm, it should. I just tested it (with a upgraded image though) and it worked for me | 15:46 |
| mvo | pitti: does it make sense to have a "Before=network.target" line in a systemd unit? sorry for the basic question? | 15:48 |
| pitti | mvo: yes, under the right circumstances | 15:49 |
| pitti | mvo: this woudl be the right thing for e. g. firewall services, which must be started before the first serfice on the network starts | 15:50 |
| mvo | pitti: whats the difference between networking.service and network.target? so I want to ensure that my workaround that fixes some ppp files is run before the ppp daemon gets a chance to run | 15:50 |
| pitti | mvo: and conversely on shutdown it means that services on the network (which must have After=n.t) get stopped before stopping firewalls and the like | 15:50 |
| pitti | mvo: networking.service is just /etc/init.d/networking, i. e. bringup of "auto" ifupdown interfaces | 15:51 |
| pitti | mvo: it's best not to depend on that unless you know what you are doing | 15:51 |
| fgimenez | elopio, i'm still hitting this http://paste.ubuntu.com/12543228/ only in the initrd failover test, we may need to update the partition.NextBootPartition function for that case | 15:51 |
| pitti | mvo: (as this doesn't help you with NM or networkd) | 15:51 |
| elopio | fgimenez: we have not landed that change, or are you using my branch? | 15:51 |
| mvo | pitti: so for my use-case network.target is the better one? | 15:51 |
| pitti | mvo: ah, then I figure you might want Before=network-pre.target | 15:52 |
| mvo | pitti: aha, great | 15:52 |
| fgimenez | elopio, i'm executing from trunk, is that fixed? | 15:52 |
| pitti | mvo: as you don't just want to run before services on the network, but even before things like ifupdown which configure hte network | 15:52 |
| pitti | mvo: see man systemd.special | 15:52 |
| mvo | pitti: great | 15:52 |
| pitti | mvo: sorry, need to leave for today, my better half just arrived | 15:52 |
| elopio | fgimenez: no. yesterday I could reproduce this https://code.launchpad.net/~elopio/snappy/new_kernel_file_name/+merge/271901/comments/685415 | 15:53 |
| elopio | only on 15.04. Didn't have time to understand why. | 15:53 |
| elopio | so it's not ready to land. | 15:53 |
| elopio | fgimenez: please report your config error. | 15:54 |
| fgimenez | elopio, it seems to be the same issue as the try mode, the mode is not set to try and systemab is not updated | 15:54 |
| fgimenez | elopio, it happens only for the zero size initrd failover test, the test is may be doing something wrong now in that case | 15:59 |
| fgimenez | elopio, https://bugs.launchpad.net/snappy/+bug/1499446 | 16:00 |
| ubottu | Launchpad bug 1499446 in Snappy "snappy config fails for ppp" [Undecided,New] | 16:00 |
| elopio | fgimenez: you flashed a new 181, right? | 16:01 |
| fgimenez | elopio, yep | 16:01 |
| elopio | fgimenez: I just tried and it works here. I'll comment in there. | 16:01 |
| fgimenez | elopio, let me try again | 16:02 |
| elopio | it's weird. I'll try one more time. | 16:02 |
| Chipaca | clobrano: you still around? | 16:04 |
| fgimenez | elopio, yes, i still get it http://paste.ubuntu.com/12543356/ | 16:06 |
| elopio | fgimenez: I still don't get it http://paste.ubuntu.com/12543383/ | 16:08 |
| elopio | we must be doing something different in here. | 16:08 |
| elopio | fgimenez: that's 15.04, right? | 16:09 |
| elopio | fgimenez: your ubuntu-core says it's from the 22nd. Mine is from today http://paste.ubuntu.com/12543396/ | 16:10 |
| fgimenez | elopio, that's it, i'm on rolling :) | 16:10 |
| elopio | let me get a rolling. | 16:10 |
| mvo | elopio: I uploaded a new ubuntu-core-config, once that is build i nthe ppa, maybe ogra_ can trigger a new image (or I can do it after dinner) and we can test if that is sufficient | 16:16 |
| ogra_ | sure, i can | 16:16 |
| elopio | mvo: right, thanks. | 16:16 |
| elopio | ogra_: can you teach me what is it that you touch to get a new edge image? | 16:17 |
| ogra_ | elopio, not really, we havent gotten an accessible UI for that ready yet and manual building needs server access that requires you to be in ubuntu-cdimage | 16:18 |
| elopio | ogra_: ok, then I'm glad I have you. | 16:18 |
| ogra_ | i have getting it into the isotracker on my TODO (on low prio though) ... then you will be able to just trigger images from there | 16:19 |
| elopio | ogra_: the lp:snappy recipe shows this: https://launchpadlibrarian.net/218712096/upload_992086_log.txt | 16:19 |
| elopio | could it be the reason why we have an older ubuntu-core in rolling? | 16:19 |
| ogra_ | why does it have the same old version ? | 16:20 |
| ogra_ | https://launchpad.net/~snappy-dev/+archive/ubuntu/image has 1.6ubuntu1-1+714~ubuntu15.10.1 | 16:20 |
| ogra_ | so it should be in the rolling/edge image | 16:21 |
| elopio | so many things about this that I don't yet understand. | 16:23 |
| ogra_ | elopio, what do you mean exactly by "older ubuntu-core in rolling" ? | 16:23 |
| elopio | I don't get what's the difference between 15.04 and rolling that makes ppp config fail. | 16:24 |
| elopio | ogra_: http://paste.ubuntu.com/12543356/ | 16:24 |
| elopio | it shows ubuntu-core #181, but from the 22nd. | 16:24 |
| elopio | shouldn't it be one from yesterday or today? | 16:24 |
| ogra_ | elopio, not on rolling, no | 16:25 |
| ogra_ | http://system-image.ubuntu.com/ubuntu-core/rolling/edge/generic_amd64/ .... shows a timestamp from 22nd for 181 | 16:26 |
| ogra_ | looks like the nightly builds didnt run since | 16:26 |
| ogra_ | sigh | 16:27 |
| elopio | oh good. So in a new image it should just work (tm) | 16:27 |
| ogra_ | elopio, because infinity commented out the whole crontab for freeze | 16:27 |
| elopio | now why the nightly didn't work? | 16:27 |
| ogra_ | i'll trigger one for you | 16:27 |
| elopio | ogra_: ah. | 16:27 |
| ogra_ | kicked | 16:28 |
| ogra_ | and i enabled nightly builds again | 16:28 |
| elopio | ogra_: please do one for 15.04 too. ubuntu-core-config is ready on the ppa. | 16:29 |
| ogra_ | elopio, there were two builds after it landed in the PPA | 16:30 |
| ogra_ | latest 15.04 should have all you need | 16:30 |
| elopio | cooool | 16:31 |
| mvo | elopio: just fyi, I triggered a new image for in 10min, so ~45min from now we should have something to test the ppp workaround issue you noticed | 16:31 |
| ogra_ | (funnily 15.04 was not disabled ... and my manual build from last night should have it too) | 16:32 |
| ogra_ | mvo, eeek | 16:32 |
| * ogra_ hopes our builds dont clash mid-air now | 16:32 | |
| * elopio waits for the fireworks. | 16:36 | |
| ogra_ | elopio, mvo, sigh, so my rolling/edge build failed ... more /etc/passwd trouble | 16:46 |
| ogra_ | bah and indeed the archive is frozen | 16:48 |
| ogra_ | grrr | 16:48 |
| lool | jdstrand: ah I thought it was enough to set bus-name for simple dbus services, but it seems I need to set the apparmor and seccomp files too | 16:53 |
| lool | jdstrand: should I copy the ones from hello-dbus, or is there some forward-compatible way of declaring just the dbus name? | 16:54 |
| lool | tyhicks: ^ | 16:55 |
| tyhicks | lool: sorry, I'm not following - you have a service that is attempting to own a specific bus name and apparmor is denying that? | 16:58 |
| lool | tyhicks: yes; hello-dbus example provides a .apparmor and .seccomp | 16:58 |
| lool | tyhicks: am I supposed to copy these from hello-dbus? | 16:58 |
| lool | tyhicks: I do declare bus-name | 16:58 |
| lool | tyhicks: I have: | 16:59 |
| lool | - bus-name: org.freedesktop.NetworkManager name: networkmanager-service security-template: unconfined start: bin/network-manager.wrapper | 16:59 |
| lool | tyhicks: but that's not sufficient it seems, I still get denials | 16:59 |
| lool | tyhicks: so I intend to add a .apparmor and .seccomp, just not sure what to base them on | 16:59 |
| lool | the hello-dbus one seems to include a lot of copy-pasted stuff that I fear will soon be out of date | 17:00 |
| tyhicks | lool: hrm... I don't know the hello-dbus-fwk policy off the top of my head | 17:02 |
| lool | tyhicks: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/hello-dbus/ | 17:02 |
| lool | http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/hello-dbus/package-dir-fwk/meta/svc.apparmor | 17:02 |
| tyhicks | lool: you'd need to change line 30 to match the name that you're binding to | 17:03 |
| lool | tyhicks: yes, got it so far, it's the rest I'm worried about | 17:04 |
| tyhicks | lool: right, line 35 and 36 need to be changed to match the path and interface that you're receiving messages on | 17:04 |
| * tyhicks looks further down | 17:04 | |
| lool | tyhicks: I mean the whole rest of what seems to be not specific to my dbus service | 17:04 |
| lool | tyhicks: I'd like to say "standard policy + dbus stuff that I know about" | 17:05 |
| jdstrand | lool, tyhicks: I'm here | 17:05 |
| jdstrand | lool: so, bus-name sets dbus bus policy for the service on the system bus | 17:05 |
| jdstrand | lool: an unconfined dbus service is then able to start a dbus service and listen | 17:06 |
| lool | jdstrand: ok, that didn't work for me | 17:06 |
| lool | jdstrand: with just bus-name that is | 17:06 |
| jdstrand | lool: however, apps can't connect to it without framework-policy. if the service is to be confined, then you also need dbus rules in its security-policy | 17:06 |
| lool | jdstrand: perhaps I'm doing something wrong though | 17:06 |
| tyhicks | lool: can you paste the denial? | 17:07 |
| jdstrand | lool: I suggest you look at both the framework-template and hello-dbus-fwk for inspiration | 17:07 |
| lool | jdstrand: yes, I'm not that far though, right now I cant listen | 17:08 |
| jdstrand | lool: is the service confined? | 17:08 |
| lool | it says unconfined | 17:08 |
| lool | I cant find the denial though | 17:08 |
| jdstrand | there may not be one | 17:09 |
| jdstrand | it might be you used the wrong bus-name | 17:09 |
| jdstrand | and you have a dbus bus policy denial | 17:09 |
| jdstrand | (ie, not security policy) | 17:09 |
| jdstrand | lool: do you have a file in /etc/dbus-1/system.d for your service? | 17:09 |
| lool | I'm getting: | 17:10 |
| lool | 2015-09-24T16:51:19.422175Z NetworkManager <error> [1443113479.422051] [nm-dbus-manager.c:802] nm_dbus_manager_start_service(): Could not acquire the NetworkManager service. Error: 'Connection ":1.56" is not allowed to own the service "org.freedesktop.NetworkManager" due to security policies in the configuration file' | 17:10 |
| lool | from the app | 17:10 |
| lool | but nothing in dmesg | 17:10 |
| jdstrand | lool: (also snappy service logs <snap> should give you logging info that I would think would include the bus policy) | 17:10 |
| jdstrand | right | 17:10 |
| lool | jdstrand: I do not get a dbus system file | 17:10 |
| jdstrand | so your bus-name needs to be org.freedesktop.NetworkManager | 17:10 |
| lool | yes, I have: - bus-name: org.freedesktop.NetworkManager name: networkmanager-service | 17:10 |
| lool | in meta/package.yaml before snappy build | 17:11 |
| lool | jdstrand: but somehow the dbus file isn't generated | 17:11 |
| jdstrand | lool: something is wrong. I suggest uninstalling the snap and trying again. when you specify bus-name snappy is supposed to give you wide open dbus bus policy via a file in /etc/dbus-1/system.d | 17:11 |
| lool | jdstrand: I did uninstall, find / with anything looking like it, then installed again | 17:12 |
| lool | jdstrand: when I run sudo aa-clickhook -f, I get a warning | 17:12 |
| lool | jdstrand: Could not parse click manifest | 17:12 |
| jdstrand | lool: what happens if you 'click-review /path/to/snap' | 17:12 |
| jdstrand | (and why is that still not on by default?) | 17:13 |
| lool | when I run click-review, my CPU load rises | 17:14 |
| lool | ;-) | 17:14 |
| jdstrand | it is hard at work :) | 17:14 |
| beuno | we might be mining some bitcoins in there as well | 17:15 |
| lool | jdstrand: one of the json files under /var/lib/apparmor is empty | 17:15 |
| lool | I need a faster laptop, click-review is still running | 17:15 |
| jdstrand | lool: how big is this snap? | 17:15 |
| lool | jdstrand: http://paste.ubuntu.com/ | 17:16 |
| lool | gah | 17:16 |
| jdstrand | lool: is the empty file something from this snap? | 17:16 |
| tyhicks | jdstrand: could this be the hyphen in the binary name issue again? | 17:16 |
| lool | jdstrand: http://paste.ubuntu.com/12544050/ | 17:16 |
| jdstrand | tyhicks: that is what I'm thinking | 17:16 |
| elopio | mvo: flashed #178, the ppp service doesn't start. updated to #182, reboot, the service starts. All good! | 17:16 |
| lool | I dont have any underscore | 17:17 |
| lool | is hyphen forbidden as well? | 17:17 |
| jdstrand | doesn't look like that is the issue | 17:17 |
| jdstrand | no, hyphen is fine | 17:17 |
| jdstrand | lool: fyi, use 'architecture' | 17:17 |
| lool | snap is 64M | 17:17 |
| lool | round numbers are nice | 17:17 |
| jdstrand | lool: what version of snappy are you using to generate this? | 17:18 |
| lool | jdstrand: oh wow, that's probably it; my snapcraft is from yesterday but I see my snappy is much older | 17:18 |
| jdstrand | lool: also, description has been required for services and binaries | 17:19 |
| jdstrand | but yes, upgrade your snappy | 17:19 |
| jdstrand | then come back | 17:19 |
| jdstrand | lool: also, clean out all the empty files in /var/lib/apparmor that you mentioned | 17:20 |
| jdstrand | (that cleaning is a snappy remove or a rm -f depending on if the snap is installed or not | 17:20 |
| jdstrand | i) | 17:20 |
| jdstrand | ) | 17:20 |
| lool | jdstrand: Yeah, I have a big find + rm | 17:22 |
| lool | after snappy remove | 17:22 |
| mvo | elopio: \o/ | 17:23 |
| mvo | elopio: thank you so much for verifying | 17:23 |
| elopio | mvo: np, that was the easy part. I'll make a card to add a test to check that no service faild to load. | 17:24 |
| lool | jdstrand: well I thought 1.5 from july was old | 17:25 |
| lool | jdstrand: but it's still what's in wily; am I supposed to take 1.6 from proposed? | 17:25 |
| jdstrand | it should be ok | 17:25 |
| jdstrand | bus-name has been around for a while | 17:25 |
| lool | jdstrand: then that's not it | 17:25 |
| jdstrand | but the empty file has me concerned | 17:25 |
| mvo | elopio: nice | 17:25 |
| jdstrand | as in, snappy install might be bailing out early cause something went wrong | 17:26 |
| lool | jdstrand: I had a bunch of cases where I ended up with a failed install and /apps having an app dir in it, but no files | 17:27 |
| jdstrand | hmm | 17:27 |
| lool | I did clean up religiously with remove+purge+find && rm -rf each time | 17:27 |
| lool | ah I just reproduced this | 17:27 |
| lool | jdstrand: empty file again | 17:28 |
| jdstrand | can you give me the snap? | 17:29 |
| jdstrand | lool: which file is empty? | 17:29 |
| lool | jdstrand: the /var/lib/apparmor/clicks/network-managerblah.json | 17:30 |
| lool | jdstrand: and /apps/network-manager.sideload/blah as well | 17:30 |
| lool | in fact just /apps/network-manager.sideload got created | 17:30 |
| lool | jdstrand: yes I can give you the snap | 17:30 |
| jdstrand | ok | 17:30 |
| jdstrand | well, /var/lib/apparmor/clicks/network-managerblah.json is surely empty because /apps/network-manager.sideload/blah is | 17:31 |
| lool | jdstrand: I'll hand you the snapcraft yaml first, that's easier to upload and I have to go afk for a bit in some minutes | 17:31 |
| jdstrand | it didn't unpack right | 17:31 |
| lool | jdstrand: yes, that's what I thought as well | 17:31 |
| lool | not sure why though | 17:31 |
| jdstrand | disk space? | 17:31 |
| jdstrand | might be easier to create a new vm | 17:31 |
| lool | hmm it's not impossible | 17:32 |
| lool | unpacked snap is 2xx MB, I have some 3xx MB free | 17:33 |
| lool | that woudl be quite a stupid way to waste both our time (NB: didn't get an out of space error) | 17:33 |
| lool | awe_, jdstrand: lp:~snappy-dev/+junk/nm-snap I'll be back in ~3h or so | 17:35 |
| lool | it has some crude hacks still | 17:35 |
| lool | I've just did some untested renames to drop the hyphens and such | 17:35 |
| elopio | zyga: I've just added a card to check that no service has failed loading. Is that good enough for you? | 17:40 |
| elopio | if you want us to add more validations, this is your moment :) | 17:40 |
| zyga | elopio: yeah, that's a great sanity check | 17:40 |
| ogra_ | elopio, you might have services that will be started manually or via a snappy-config option or so | 17:40 |
| zyga | elopio: no, for now that's okay, especially that TPM testing requires a hell lot of manual interaction, visits to BIOS and stuff | 17:40 |
| ogra_ | i.e. watchdog was seeded last week, it wouldnt start | 17:41 |
| zyga | elopio: (and that is by desing) | 17:41 |
| zyga | elopio: we'll do more validation tomorrow on select devices | 17:41 |
| ogra_ | (and shouldnt) | 17:41 |
| zyga | ogra_: does it start now or is it still off by default? | 17:41 |
| ogra_ | zyga, ricmm said there would be a script starting it | 17:41 |
| zyga | ogra_: for testing ,yes | 17:42 |
| ogra_ | the sysv generator doesnt work on watchdogs init script ... so it cant be started atm | 17:42 |
| zyga | ogra_: for consumer projects, it would perhaps be good to tie it to snappy config as we go | 17:42 |
| ogra_ | sure | 17:42 |
| ogra_ | long term thats supposed to be fixed | 17:42 |
| zyga | ogra_: do you think watchdog should become a service or can it have a config hook in the os snap? | 17:42 |
| elopio | ogra_: we have opencryptoki.service loaded failed failed LSB: starts pkcsslotd | 17:42 |
| ogra_ | what i meant to point out is that not all installed services will necessarily start | 17:43 |
| elopio | is that something you are working on? | 17:43 |
| zyga | ogra_: right | 17:43 |
| ogra_ | so just doing a broad test looking at the services might not be enough | 17:43 |
| ogra_ | (due to false positives) | 17:43 |
| rickspencer3 | so, I deployed a snap with snapcraft run, but I don't see where my print statements are going, they don't seem to be in journalctl | 17:44 |
| lool | mvo: not sure you saw there's a testsuite failure in the 1.6 wily upload: panic: can not set option description for "package name" | 17:44 |
| lool | rickspencer3: there's a new service logs command now | 17:44 |
| lool | hmm | 17:44 |
| lool | awe_: so that's all I had for now; currently it fails in various ways, notably dbus, but that might be due to my vm having too little storage | 17:46 |
| lool | awe_: I'm playing with various hacks, and the app dir is not truly kep readonly, however plugin to load and startup fails while binding to dbus | 17:46 |
| awe_ | lool, can you give me the snap, and any source code you have? As mentioned, I've been working from the bottom up | 17:50 |
| awe_ | lool, are you statically building NM?? | 17:52 |
| lool | awe_: i"m using the debs | 17:52 |
| awe_ | and extrating them into the snap? | 17:52 |
| awe_ | extracting | 17:52 |
| lool | awe_: yes, snapcraft does it all | 17:52 |
| awe_ | k | 17:53 |
| awe_ | so you didn't get to the point where you were re-building NM? | 17:53 |
| awe_ | to change rundir for instance? | 17:53 |
| lool | awe_: I'm uploading the snap to http://people.dooz.org/~lool/network-manager_1.0_amd64.snap but I've got to run now; it will be done in ~10mn | 17:53 |
| awe_ | k | 17:54 |
| lool | hmm or maybe not | 17:54 |
| * lool switches to LTE | 17:54 | |
| awe_ | do you have a branch for your networkmanager.patched? | 17:55 |
| lool | awe_: lp:~snappy-dev/+junk/nm-snap (as above) | 17:55 |
| lool | awe_: network-manager.patched is NetworkManager sed-ed | 17:55 |
| lool | I knew you'd love this | 17:56 |
| awe_ | the binary? | 17:56 |
| lool | yeah | 17:56 |
| lool | awe_: upload complete | 17:56 |
| awe_ | cough, hack, why? | 17:56 |
| awe_ | can't rebuild it? | 17:56 |
| awe_ | ;)- | 17:56 |
| lool | awe_: that was the quickest | 17:56 |
| lool | sed: 10s to write, 0s to run | 17:56 |
| awe_ | and where's the sed script? | 17:57 |
| awe_ | I assume we don't want to ship that | 17:57 |
| awe_ | if so, please leave my name off | 17:57 |
| * awe_ finishes his lunch | 17:58 | |
| zyga | lool: OMG, what did you sed? | 17:59 |
| zyga | lool: I think you are close this not making sense as debs repackaged | 17:59 |
| zyga | lool: "dear customer, our engineers _hand crafted_ this binary" ;) | 18:00 |
| rayn | hello there. Um looking for apps and frameworks, like tomcat. Where are they? | 18:25 |
| rayn | i* | 18:25 |
| ogra_ | not there yet, but you can package them ;) | 18:28 |
| ogra_ | elopio, rolling just finished building the rootfs ... should be there after the next system-image import | 18:31 |
| ogra_ | 20-30min | 18:31 |
| Chipaca | elopio: ogra_: http://www.commitstrip.com/wp-content/uploads/2015/08/Strip-Apr%C3%A8s-le-match-650-finalenglish.jpg | 18:34 |
| Chipaca | just for you | 18:34 |
| === j12t_ is now known as j12t | ||
| ogra_ | HAHA! | 18:35 |
| sergiusens | rayn, you can develop locally with snapcraft and integrate tomcat into what you need | 18:38 |
| rayn | sergiusens, ogra_, thanks. I figured that uot. Is there an official ubuntu repository for it? | 18:41 |
| rayn | Where can we find all the apps that have been made? | 18:43 |
| sergiusens | rayn, maybe start here https://developer.ubuntu.com/en/snappy/snapcraft/ | 18:43 |
| rayn | where this command searchs? "snappy search ..." | 18:45 |
| sergiusens | rayn, querying the store I guess https://uappexplorer.com/apps?sort=relevance&type=snappy | 18:45 |
| sergiusens | rayn, you need to run that on a snappy system (ubuntu-core) | 18:45 |
| elopio | lol. | 18:46 |
| rayn | sergiusens. thanks. I hava ubuntu core installed but i dont know where are stored the apps | 18:48 |
| sergiusens | rayn, run 'snappy search' with no args | 18:52 |
| sergiusens | rayn, or install webdm (snappy install webdm) | 18:52 |
| sergiusens | and you can open a browser and look at them | 18:52 |
| ogra_ | elopio, both images are done | 19:33 |
| elopio | thanks ogra_. Get some rest :) | 19:34 |
| ogra_ | havent copied to alpha yet ... | 19:34 |
| * ogra_ finishes dinner | 19:34 | |
| ogra_ | copy running ... | 19:37 |
| rickspencer3 | sergiusens, so, I'm using snappy run | 19:38 |
| rickspencer3 | what do you make of this? | 19:38 |
| rickspencer3 | 2015-09-24T19:22:40.288952Z systemd Starting service hello for package python-snap... | 19:38 |
| rickspencer3 | 2015-09-24T19:35:36.367400Z ubuntu-core-launcher starting service | 19:38 |
| rickspencer3 | ^ a 13 minute lag between systemd and ubuntu-core launcher? | 19:38 |
| rickspencer3 | it seems to be consistent | 19:39 |
| ogra_ | elopio, alpha images ready | 19:39 |
| elopio | thanks | 19:40 |
| zyga | lool: still there? | 19:58 |
| sergiusens | rickspencer3, hey sorry, was on the phone and distracted; is that with your snap? And is that the output of snappy service logs [snap] ? | 20:35 |
| lool | zyga: yup | 22:14 |
| zyga | lool: re :) | 22:16 |
| zyga | lool: did you see what jdstrand found? | 22:16 |
| lool | zyga: yup, great | 22:16 |
| zyga | lool: you were missing a framework type | 22:17 |
| zyga | lool: but then more weirdness happens | 22:17 |
| lool | zyga: what happens next? | 22:17 |
| zyga | lool: and the bottom line is we need to patch n-m source to get it fixed :/ | 22:17 |
| zyga | lool: !usr (that's not a typo) | 22:17 |
| lool | zyga: that's my sed | 22:17 |
| zyga | lool: and some things that are not exposed as --option of any kind need to be patched | 22:17 |
| zyga | lool: ah, I didn't know | 22:17 |
| lool | I picked an uncommon char I could use in a pathname | 22:17 |
| zyga | lool: did you try to do a symlink from !usr ? | 22:18 |
| lool | zyga: exactly; !usr -> usr | 22:18 |
| lool | instead of /usr | 22:18 |
| zyga | does it work? jdstrand did't get it | 22:18 |
| lool | e.g. /usr/lib/NM becomes !usr/lib/NM which because of the symlinks points at /apps/.../nm/usr/lib/NM | 22:18 |
| lool | zyga: it does! | 22:18 |
| zyga | lool: neat!! | 22:19 |
| * lool just typed sudo snappy reboot | 22:19 | |
| lool | instead of sudo reboot | 22:19 |
| zyga | lool: today you will dream of snappy ;) | 22:19 |
| zyga | lool: we have no such luck in bluez, everything uses string concatenation in the preprocessor | 22:20 |
| zyga | lool: so we're patching bluez | 22:20 |
| zyga | lool: but it's not terrible, without patches it seems to work to a good degree | 22:20 |
| zyga | lool: we also have a real policy now, not just unconfined | 22:20 |
| zyga | lool: but your idea with the simlink now made me think :) | 22:21 |
| lool | zyga: I'm pretty sure it would wokr with Bluez too | 22:21 |
| lool | zyga: but there are limits | 22:21 |
| zyga | lool: I was thinking about a kernel module that expands $SNAP_APP_PATH | 22:21 |
| zyga | lool: based on process environment | 22:21 |
| zyga | lool: but this is easier to get to work today ;) | 22:21 |
| lool | zyga: the other crazy approach I did at a customer site was using LD_PRELOAD like in the early deb2snap stuff | 22:21 |
| zyga | lool: well, I can configure for prefix /usr and do the sed as you did | 22:21 |
| lool | that actually got us quite some way along | 22:21 |
| lool | but it's too limiting and messy | 22:21 |
| lool | especially with 32/64 bits libs | 22:22 |
| zyga | lool: yeah, that's a somewhat saner bit | 22:22 |
| lool | which happened to be the case | 22:22 |
| zyga | lool: like fakeroot | 22:22 |
| lool | zyga: exactly, it was the same thing | 22:22 |
| lool | but selective fakechroot | 22:22 |
| lool | fakeroot => just uids, pretty good; fakechroot => all pathnames, pretty fragile | 22:22 |
| zyga | lool: a symlink handled by the kernel would work in all cases (suid apps too) | 22:23 |
| lool | yes | 22:23 |
| zyga | lool: I'll try to hack that next week, if time permits | 22:23 |
| zyga | lool: /proc/snap | 22:23 |
| zyga | lool: then --prefix=/proc/snap/ and we're "done" with relocatable apps | 22:24 |
| lool | zyga: might be possible with some kind of overlay rootfs | 22:24 |
| zyga | but this feel very ugly | 22:24 |
| zyga | lool: apparently overlayfs breaks apparmour | 22:24 |
| zyga | lool: did you hear about the /var $current symlink? | 22:25 |
| zyga | lool: that could help in many things, | 22:25 |
| zyga | lool: /var/$SNAP_NAME/current AFAIR | 22:25 |
| lool | zyga: I personally would like us to avoid hardcoding absolute pathnames as much as possible | 22:26 |
| lool | while it could become a required layout, I think it's nicer if we keep things relocatable, like on the phone for preinstalled apps | 22:26 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| zyga | lool: to some degree I agree but what's the difference in expanding it in one spot vs another? | 22:26 |
| sergiusens | zyga, lool can you share the snapcraft project that breaks with c that you mentioned? | 22:27 |
| zyga | lool: yes, I agree, though the only practical difficulity is that C tends to make this harder than languages that people use on the phone, and we have more incentive to allow existing projects (bluez) to work | 22:27 |
| zyga | sergiusens: yes, that's the older bluez example | 22:28 |
| zyga | sergiusens: it broke at 0.2 | 22:28 |
| zyga | sergiusens: stopped configuring entirely | 22:28 |
| zyga | sergiusens: the same configure line works without snapcraft | 22:28 |
| zyga | sergiusens: the addition of -I in CFLAGS seems to cause this but I did not dig deeper | 22:28 |
| zyga | sergiusens: do you need a link? | 22:28 |
| zyga | sergiusens: https://code.launchpad.net/~zyga/+git/snap-example-bluez5 | 22:29 |
| sergiusens | zyga, yes please | 22:29 |
| zyga | sergiusens: https://code.launchpad.net/~zyga/+git/snap-manual-bluez5 (without snapcraft) | 22:29 |
| zyga | sergiusens: FYI https://git.launchpad.net/~zyga/+git/snap-manual-bluez5/tree/Makefile#n68 this has nice usability | 22:30 |
| zyga | sergiusens: if you agree I'll patch that into snapcraft too | 22:30 |
| zyga | sergiusens: and make reinstall, saves time on VM bootstrap a _lot_ (on my older laptop) | 22:30 |
| zyga | sergiusens: usability == redirecting qemu output | 22:31 |
| sergiusens | sure , the qemu output is more of a, is it working thing I guess | 22:32 |
| zyga | sergiusens: in python we could just pipe it and spin a spinner | 22:32 |
| zyga | sergiusens: it "works" and the output can be pretty | 22:32 |
| zyga | sergiusens: here I just log it (which is useful too) | 22:33 |
| sergiusens | zyga, if you want to make a spinner branch I am all for it! | 22:36 |
| lool | sergiusens: hmm I have a weird behavior with snapcraft; it looks like only the last symlink gets copied as a symlink | 22:37 |
| zyga | sergiusens: cool, I'll be my pleasure :) | 22:37 |
| zyga | sergiusens: I'd love if parts could start to use pkg_config sensibly | 22:38 |
| zyga | sergiusens: perhaps we could set PKG_CONFIG_PATH? | 22:39 |
| sergiusens | zyga, it is set | 22:39 |
| zyga | sergiusens: it seems that it's a cheaper way to cure cross-part usage than -I / -L | 22:39 |
| zyga | sergiusens: oh? hmmm | 22:39 |
| sergiusens | zyga, PKG_CONFIG-PATH | 22:39 |
| sergiusens | zyga, let me get the MP that did that | 22:39 |
| zyga | sergiusens: maybe I used it before | 22:39 |
| zyga | sergiusens: then it still didn't work | 22:40 |
| sergiusens | zyga, or else the godd example wouldn't compile | 22:40 |
| zyga | sergiusens: I can have a look at that later, today == plainbox | 22:40 |
| sergiusens | zyga, yeah, it works since less than 4 days ago at most | 22:40 |
| zyga | sergiusens: I'd like to iterate on bluez / nm examples later to build more things inside the snap as parts | 22:40 |
| sergiusens | zyga, releasing the fix for Left overs? :-) | 22:40 |
| sergiusens | zyga, if those parts use the built in plugins, it would be awesome to have them on the wiki | 22:41 |
| zyga | sergiusens: no, spineau is handling our releases, it will be done after QA | 22:41 |
| zyga | sergiusens: I'm adding features | 22:41 |
| zyga | sergiusens: I will certainly try, now I'm split between the flexibility and predictability of the makefile I wrote | 22:41 |
| zyga | sergiusens: and the urge to fix core issues I see in snapcraft today (subprocess mess, some caching bugs) | 22:42 |
| zyga | sergiusens: also, make has a working dependency engine, it makes a lot of difference when you iterate, just make and it's fresh instantly (*when upstream didn't f*** up) | 22:42 |
| zyga | sergiusens: whereas snapcraft really needs some idea on how to remake parts during hacking and I kept ending up doing rm -rf equivalent | 22:43 |
| sergiusens | zyga, right, we need to implement the 'detect' if dirty | 22:43 |
| sergiusens | zyga, you can force | 22:43 |
| sergiusens | zyga, snapcraft stage --force | 22:43 |
| sergiusens | but that will walk down the pull phase too | 22:43 |
| zyga | sergiusens: I tried building one part out of few | 22:43 |
| zyga | sergiusens: and that didn't work either (look at the $secret snap in $secret project) | 22:44 |
| zyga | sergiusens: so I just ended up rm -rf ing, maybe it's all fixed now, it was last week | 22:44 |
| lool | zyga: I personally echo the stage into the file | 22:45 |
| zyga | lool: which file? | 22:46 |
| lool | zyga: the state file | 22:46 |
| zyga | sergiusens: FYI, http://plainbox.readthedocs.org/en/latest/manpages/plainbox-job-units.html#job-flag-simple this will make all snapcraft tests faster | 22:46 |
| lool | zyga: under the part | 22:46 |
| zyga | lool: ah, I see | 22:46 |
| sergiusens | zyga, \o/ | 22:47 |
| zyga | sergiusens: s/faster/easier/ | 22:47 |
| sergiusens | zyga, better harness, makes for faster development | 22:47 |
| sergiusens | ;-) | 22:47 |
| sergiusens | zyga, so it is in some way all your fault :-P | 22:47 |
| zyga | sergiusens: hehe | 22:47 |
| zyga | sergiusens: plainbox has come a long way, compare that simple job to this... | 22:48 |
| zyga | http://bazaar.launchpad.net/~zyga/checkbox/tpm-hacking-patches/view/head:/providers/plainbox-provider-tpm/units/tpm.pxu#L19 | 22:49 |
| lool | root 3489 0.1 1.4 460364 14152 ? Sl 22:53 0:00 \_ NetworkManager.patched --state-file=/var/lib/apps/network-manager/IBYLbSAATUQC/NetworkManager.state --config-dir=/apps/network-manager/IBYLbSAATUQC/etc/NetworkManager --config=/apps/network-manager/IBYLbSAATUQC/etc/NetworkManager/NetworkManager.conf --log-level=DEBUG --no-daemon | 22:54 |
| lool | woot | 22:54 |
| zyga | lool: cooool! | 22:55 |
| zyga | lool: nmcli? | 22:55 |
| zyga | lool: does it work? | 22:55 |
| lool | not yet | 22:55 |
| lool | I mean NM seems happy | 22:55 |
| lool | nmcli not | 22:55 |
| zyga | lool: right | 22:55 |
| lool | but then I didn't open the dbus for nmcli yet | 22:55 |
| lool | I'd like to try it without confinment first though | 22:56 |
| lool | (amd64)ubuntu@localhost:/apps/network-manager/current$ LD_LIBRARY_PATH=$PWD/usr/lib/x86_64-linux-gnu usr/bin/nmcli general status | 22:57 |
| lool | STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN | 22:57 |
| lool | connected full enabled enabled enabled enabled | 22:57 |
| lool | hmm this stuff depends on policykit, that wont be nice | 22:59 |
| zyga | lool: uhhh | 22:59 |
| zyga | lool: what do you think we should do about polkit? | 22:59 |
| zyga | lool: remove it or put it into snappy itself? | 22:59 |
| lool | I dont know yet | 22:59 |
| lool | let's try whether it brings up eth0 | 23:00 |
| lool | there are loads of errors in the logs | 23:00 |
| zyga | lool: careful, eth0 is how you ssh into the box ;) | 23:00 |
| zyga | lool: how do you test btw/ | 23:00 |
| lool | I have a console on the box | 23:01 |
| zyga | lool: KVM? | 23:01 |
| lool | nah | 23:02 |
| lool | ok, so denials from dhclient | 23:02 |
| lool | but the snap is unconfined hmmm | 23:03 |
| zyga | lool: what kind? | 23:03 |
| lool | (amd64)ubuntu@localhost:/apps/network-manager/current$ LD_LIBRARY_PATH=$PWD/usr/lib/x86_64-linux-gnu usr/bin/nmcli general status | 23:04 |
| lool | STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN | 23:04 |
| lool | connected full enabled enabled enabled enabled | 23:04 |
| lool | [ 2679.122645] audit: type=1400 audit(1443135850.522:61): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/sbin/dhclient" name="run/systemd/journal/dev-log" pid=4476 comm="dhclient" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 | 23:04 |
| lool | ups | 23:04 |
| lool | tyhicks or jdstrand ^ so my service is policy-template: unconfined, but is getting this denial | 23:05 |
| zyga | lool: I may be wrong but unconfined is not "all in", it's still restricted to some degree (more than the shell you have) but very very permissive | 23:05 |
| lool | looks like dhclient is trying to log, and somehow apparmor doesn't like not finding who owns that file?! | 23:06 |
| jjohansen | lool: right but the dhclient profile is the one that is failing because it doesn't have permission | 23:06 |
| lool | jjohansen: so it's because of the /sbin/dhclient apparmor profile that we ship | 23:06 |
| lool | jjohansen: shoudl I disable something to get it to work, or ship my own or...? | 23:06 |
| lool | oh I already ship dhclient | 23:06 |
| jjohansen | lool: you can add the flag attach_disconnected to the dhclient profile as a work around | 23:07 |
| jjohansen | it will looks something like | 23:07 |
| lool | jjohansen: where is this profile though? | 23:07 |
| jjohansen | /sbin/dhclient flags=(attach_disconnected) { ... } | 23:08 |
| jjohansen | lool: probably in /etc/apparmor.d/sbin.dhclient | 23:08 |
| lool | jjohansen: I see it's under /etc, but that's supposed to be read-only | 23:08 |
| lool | /etc/apparmor.d/local/sbin.dhclient | 23:08 |
| lool | /etc/apparmor.d/sbin.dhclient | 23:08 |
| zyga | lool: at least it's not selinux | 23:09 |
| jjohansen | lool: to test you can copy it somewhere else, and then do | 23:09 |
| jjohansen | sudo apparmor_parser -r edited_profile_file | 23:09 |
| zyga | lool: it's been a decade and it's still something people turn off | 23:09 |
| jjohansen | zyga: people turn apparmor off as well, heck they will turn off passwords and any security inconvenience that they can | 23:10 |
| lool | jjohansen: yeah; it's just I need to fix this properly; I'd rather avoid rootfs changes and I dont want to lose the security benefits | 23:10 |
| lool | perhaps NM launches dhclient in the wrong way | 23:10 |
| lool | dhclient works when called from ifup | 23:11 |
| lool | and probably works on the desktop too with the same apparmor profile | 23:11 |
| lool | so my NM must be doing something different | 23:11 |
| jdstrand | lool: I imagine that you'll want a child profile for dhclient in the network-manager security-policy which would avoid the binary attachment and that you could tailor to the snap's data dirs | 23:11 |
| lool | jdstrand: yeah; that sounds good | 23:11 |
| lool | it does sound like a lot of work too though | 23:11 |
| lool | plus, keeping the dhclient policy in sync | 23:12 |
| jdstrand | lool: I wouldn't get hung up on dhclient. add attach_disconnected to the file in /etc/apparmor.d to unblock yourself, then we can adjust when its time to implement security-policy for this service | 23:12 |
| jdstrand | lool: you don't have to keep it in sync. it only has to work with your snap writable areas | 23:12 |
| jdstrand | lool: it isn't terribly much work. see the email I CC'd you on wrt bluez | 23:13 |
| jdstrand | ok, really heading out | 23:14 |
| lool | do I need to run something? | 23:14 |
| lool | probably apparmor_parser | 23:14 |
| jdstrand | lool: yes | 23:14 |
| jdstrand | apparmor_parser -r /etc/apparmor.d/sbin.dhclient | 23:15 |
| jdstrand | (under sudo) | 23:15 |
| lool | yup | 23:15 |
| jdstrand | -r is for reload | 23:15 |
| jdstrand | your change will survive reboots, but don't forget we have to address dhclient before people consume this | 23:15 |
| jdstrand | :) | 23:15 |
| jdstrand | ok, really, really gone | 23:15 |
| lool | oh no | 23:15 |
| lool | [ 3367.581854] audit: type=1400 audit(1443136539.036:81): apparmor="DENIED" operation="open" profile="/sbin/dhclient" name="/apps/network-manager/IBYLbSAATUQC/lib/x86_64-linux-gnu/libisccfg-export.so.90.1.0" pid=5446 comm="dhclient" requested_mask="r" denied_mask="r" fsuid=0 ouid=101 | 23:16 |
| lool | blah | 23:16 |
| lool | I think I want to use my dhclient now | 23:16 |
| * zyga pushes a plainbox feature up | 23:21 | |
| zyga | https://code.launchpad.net/~zyga/checkbox/no-resource-limits/+merge/272319 :) | 23:22 |
| zyga | launchpad feels slow tonight | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
