| elopio | sergiusens: kyrofa: would it be ok to add the nodejs version to the yaml? | 00:32 |
|---|---|---|
| elopio | it seems to work to package bonescript with node 0.10. | 00:32 |
| sergiusens | elopio, in the schema? | 00:36 |
| sergiusens | it does if we have links, yeah | 00:36 |
| sergiusens | is this older or newer? | 00:36 |
| elopio | sergiusens: older. | 00:37 |
| sergiusens | elopio, ah, then maybe test; if it is location indep as the current one it may be all ok | 00:38 |
| elopio | you are building the link from a constant. I think we can make that constant the default, and accept a variable from the conf. | 00:38 |
| sergiusens | elopio, as long as the semantics for installing are ok, we should be good | 00:38 |
| sergiusens | elopio, btw, for running the example tests, can we just download the image from mvo's pcc? | 00:39 |
| elopio | the problem is that the only example I have requires beaglebone, and I can't test if the generated snap works because bbb is busted. | 00:39 |
| elopio | sergiusens: yes, download it, start it in kvm, and then call ./runtests.sh --ip localhost --port 8022 | 00:40 |
| sergiusens | elopio, ah, nice | 00:40 |
| sergiusens | elopio, I'm no sure about adding the example as an example; since the example is not complete; what do you say? | 00:52 |
| elopio | sergiusens: do you mean the one by andreas? | 00:54 |
| sergiusens | elopio, yeah | 00:54 |
| elopio | sergiusens: yeah, I wasn't thinking about everything he has in there. | 00:54 |
| elopio | something more simple that shows the issue. | 00:54 |
| elopio | your unit tests are good, so this is not a blocker. But it would be nice to have. | 00:55 |
| sergiusens | elopio, something simple mean writing auto.*.ac and Makefile.am though and I am not profficient in that | 00:56 |
| sergiusens | let me see if I can find something simple | 00:56 |
| elopio | sergiusens: I understood you requested that from andreas. | 00:56 |
| fazer | Can anyone take a look at this pull request: https://github.com/ubuntu-core/snapcraft/pull/233 and let me know why it thinks the coverage has decreased? | 01:21 |
| fazer | nevermind, ignore my last comment. | 01:21 |
| fazer | elopio, kyrofa, sergiusens If possible can you take a look at this: https://github.com/ubuntu-core/snapcraft/pull/233 | 01:22 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| raspberrypifan | how does deduplication work | 04:51 |
| happyaron | what dedup you mean? | 05:04 |
| === kickinz1|eod is now known as kickinz1 | ||
| fgimenez | good morning | 08:03 |
| JamesTait | Good morning all! Happy Friday, and happy Hat Day! 😃 🎩 | 10:00 |
| liuxg | Chipaca, ping | 10:10 |
| Chipaca | liuxg: pong | 10:10 |
| liuxg | Chipaca, I accidentally installed snapcraft by running "python3 setup.py install", now my snapcraft version is totally wrong. do you know if there is any method to remove the installation? | 10:11 |
| Chipaca | liuxg: you installed it at the system level, by hand? | 10:11 |
| Chipaca | liuxg: ie you actually did "sudo python3 setup.py install"? | 10:12 |
| Chipaca | liuxg: or did that install it in your home directory? | 10:12 |
| liuxg | Chipaca, by hand, last time, snapcraft did not support the local source code, I reported a bug, and later on, sergiusens asked me to try it. I tried to install it by hand. | 10:13 |
| liuxg | Chipaca, I tried the method at https://stackoverflow.com/questions/1550226/python-setup-py-uninstall , since I pulled down the latest repository, and now my snapcraft version is 2.0. I think it should not be so right for me. | 10:14 |
| Chipaca | liuxg: I'm afraid I have no idea in what state you've managed to put your system | 10:14 |
| liuxg | Chipaca, yes, I actually did "sudo python3 setup.py install" manually on my PC. | 10:14 |
| Chipaca | oh dear | 10:14 |
| Chipaca | don't do that | 10:14 |
| Chipaca | ever | 10:14 |
| Chipaca | your system is now in an unknown state | 10:15 |
| liuxg | Chipaca, I know it is too late. I really want to get it back. the snapcraft is totally wrong. | 10:15 |
| Chipaca | you have actively decided to take control of your system away from apt and do it manually | 10:16 |
| Chipaca | so you will have to clean it up manually | 10:16 |
| Chipaca | and hope that that is enough | 10:16 |
| Chipaca | liuxg: do you have a log of the installation process? | 10:16 |
| Chipaca | liuxg: to know exactly what that setup.py install actually installed? | 10:16 |
| liuxg | Chipaca, now, the snapcraft info is like http://paste.ubuntu.com/14503790/ on my PC.. | 10:16 |
| liuxg | Chipaca, as said, I followed the link https://stackoverflow.com/questions/1550226/python-setup-py-uninstall, and now the files are http://paste.ubuntu.com/14503796/ | 10:18 |
| liuxg | Chipaca, I have removed the files already, however the snapcraft version still shows 2.0 | 10:19 |
| Chipaca | liuxg: do you have a log of the installation process? | 10:19 |
| liuxg | Chipaca, I do not have that unfortunately, it happened long time ago. Do you want me to try it again? | 10:20 |
| liuxg | Chipaca, the help content is still for 1.0 http://paste.ubuntu.com/14503819/ though the version shows 2.0 | 10:21 |
| Chipaca | no, do not try it again | 10:22 |
| Chipaca | liuxg: pastebin the output of: find /usr/local -ls | 10:23 |
| liuxg | Chipaca, http://paste.ubuntu.com/14503836/ | 10:25 |
| Chipaca | liuxg: ok, i can't guid you through that | 10:26 |
| Chipaca | liuxg: what you need to do is remove all traces of snapcraft from your system | 10:26 |
| Chipaca | liuxg: and all the dependencies that the manual install installed | 10:26 |
| Chipaca | liuxg: but you've got too much other cruft in /usr/local for me to help | 10:27 |
| Chipaca | liuxg: so | 10:27 |
| Chipaca | liuxg: first, sudo apt-get purge snapcraft && sudo apt-get --purge autoremove | 10:27 |
| Chipaca | liuxg: then, manually remove from /usr/local anything your manual install might've installed | 10:27 |
| Chipaca | you've got django and npm and who-knows-what-else in there, so good luck with that | 10:27 |
| Chipaca | also given you've got npm, you've probably got your system in a screwy state anyway. You're on your own. | 10:28 |
| Chipaca | next time you feel the need to install something in your system without using apt-get, use a virtual machine | 10:28 |
| liuxg | Chipaca, I have done sudo apt-get purge snapcraft && sudo apt-get --purge autoremove the command, so I need to reinstall it? | 10:28 |
| Chipaca | or tell whatever tool you're using to install stuff to do so in a local environment and not in the system itself | 10:28 |
| Chipaca | liuxg: you reinstall *after* cleaning /usr/local | 10:29 |
| liuxg | Chipaca, do I need to remove all of the snapcraft related directories manually? | 10:31 |
| Chipaca | liuxg: the ones you created manually? yes | 10:32 |
| Chipaca | by manually there i mean 'via python3 setup.py' also | 10:32 |
| liuxg | Chipaca, in fact, I did not manually create the directories. after running your "remove" command, the directory is like http://paste.ubuntu.com/14503863/ | 10:33 |
| liuxg | Chipaca, may I just go ahead to manually remove those snapcraft related directoies? | 10:34 |
| Chipaca | liuxg: those are the ones you created via 'python3 setup.py' | 10:34 |
| liuxg | Chipaca, I think so. I did not manually create those directories and files. | 10:35 |
| Chipaca | liuxg: apt-get did not create them; you created them yourself, using setup.py. You did not do 'mkdir', no, but you created them outside of the control of the packaging system | 10:36 |
| liuxg | Chipaca, yes, I think the setup.py created them. | 10:36 |
| liuxg | Chipaca, so, may I just remove them manually? | 10:37 |
| Chipaca | liuxg: I have told you yes twice already. This is the third time. Yes, remove manually those directories which you created using setup.py. | 10:37 |
| Chipaca | liuxg: as you have not kept a log of what you did with setup.py, I can't tell which those are. You're on your own. | 10:38 |
| liuxg | Chipaca, OK. thanks! I just want to double confirm it :) | 10:38 |
| liuxg | Chipaca, thanks for helping. now my snapcraft version become 1.0 :) | 10:42 |
| sanong | Help guys. I just download snappy OVA and run it. But default user/pwd not working | 10:43 |
| sanong | https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/ | 10:47 |
| sanong | cant logon with ubuntu / ubuntu | 10:47 |
| sanong | any one ? | 10:47 |
| sanong | any know default user/pass other than ubuntu/ubuntu | 10:53 |
| zyga | sanong: not that I know | 10:54 |
| sanong | i download .OVA and boot vm | 10:55 |
| sanong | cant logon | 10:55 |
| mvo | ogra_: so I looked a bit into the multiple initird stuff for snappy - one generic initird from ubuntu-core, one with the kernel specific bits from the kernel. it seems feasible but I will need some help with the uboot stuff, do you think you could give me a hand with that? | 10:57 |
| Chipaca | mvo: who creates the ova files? | 11:10 |
| mvo | Chipaca: ova files? what does that mean? | 11:21 |
| Chipaca | mvo: it's one of the options here https://cloud-images.ubuntu.com/snappy/rolling/core/edge/current/ | 11:21 |
| Chipaca | mvo: and was blogged about here https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/ | 11:21 |
| Chipaca | mvo: but i know we don't build 'em | 11:21 |
| mvo | Chipaca: oh, I think thats ben howard | 11:21 |
| Chipaca | mvo: and sanong above was saying he couldn't log in with u/u | 11:22 |
| mvo | Chipaca: with this particular image he can not log in? | 11:22 |
| Chipaca | <sanong> cant logon with ubuntu / ubuntu | 11:22 |
| mvo | he is no longer in the channel :/ did he/she mention what image? | 11:23 |
| beowulf | mvo: i think there's only one, i can try it on vmware now ... | 11:25 |
| mvo | thanks beowulf | 11:26 |
| sanong | OVA was published https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/ | 11:38 |
| sanong | by one of cannocal marketing | 11:39 |
| sanong | I think all snappy image will have same password. Any know ? | 11:39 |
| beowulf | mvo_: sanong: i see that too, the ubuntu/ubuntu password doesn't work on that image | 11:41 |
| beowulf | s/image/ova | 11:41 |
| sanong | anyone know password | 11:42 |
| mvo_ | utlemming: hi, I hope you are the right person to ask - do you know more about the ova images? we got a report from sanong that the login via ubuntu/ubuntu does not work with those. maybe thats intentional because of the cloud nature, but maybe https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/ could mention if the login is different | 11:46 |
| utlemming | mvo_: that is correct; OVA's are cloud targets | 11:47 |
| mvo_ | sanong: see above, this is intentional | 11:47 |
| beowulf | sanong: is this for virtualbox or vmware or something else? | 11:48 |
| utlemming | mvo_, sanong: http://blog.utlemming.org/2015/04/using-snappy-ova-images-when-you-dont.html | 11:48 |
| utlemming | sanong: use option 2 | 11:48 |
| ogra_ | mvo_, multiple ? | 11:49 |
| ogra_ | why multiple | 11:49 |
| ogra_ | just move the modules into a squashfs and mount them right before anything else | 11:49 |
| mvo_ | ogra_: one generic one with our scripts and one with kernel modules if you boot your snappy from a remote iscsi target | 11:49 |
| utlemming | sanong: cloud image targets need to have security. We can't have every cloud image of Snappy universally accessible by a well-known password | 11:50 |
| ogra_ | mvo_, well, if you boot from iscsi, your initrd needs to come from somewhere ... just put the modules suqshfs next to it in the same place | 11:50 |
| mvo_ | ogra_: right, we can do that if everything is in the kernel that is needed to mount root - this won't work right now even for us because of squashfs.ko. but mayb apw can help and make squashfs.ko a buildin for the kernel | 11:50 |
| ogra_ | and loop mount it | 11:50 |
| ogra_ | no | 11:51 |
| ogra_ | you dont need everything to mount root | 11:51 |
| ogra_ | you only need everything to loop mount the modules squashfs from the same place yoou load your intird from | 11:51 |
| mvo_ | ogra_: I'm not sure I follow. what if your initird comes from pxe boot? | 11:51 |
| sanong | wont work | 11:51 |
| ogra_ | well, tftp then | 11:51 |
| sanong | try that | 11:51 |
| sanong | already | 11:51 |
| ogra_ | if your initrd comes from the net that measn that you have a way to pull the suqashfs the same way | 11:52 |
| sanong | will that be the cause ? | 11:53 |
| ogra_ | i just dont see a need that we have more than /lib/modules|firmware in tthat squashfs | 11:53 |
| beowulf | utlemming: i've been using u-d-f and then qemu-img convert to vmdk for vmware ... option 3 :) | 11:53 |
| ogra_ | mvo_, indeed that requires to have squashfs and loop device support in the kernel itself | 11:54 |
| mvo_ | ogra_: so our generic initird would fetch (cp, tftp, *) a file right next to the initird img and use that for the modules? and we enforce that the kernel has enough support buildin to get to that place? that works for me | 11:54 |
| ogra_ | (though i guess we dont necessarily need it to be a squash image) | 11:55 |
| mvo_ | ogra_: so we just need to convince the kernel people to give us this kernel | 11:55 |
| mvo_ | ogra_: yeah, it can be anything | 11:55 |
| ogra_ | right | 11:55 |
| utlemming | orgra_: why not an initramfs script? | 11:56 |
| mvo_ | ogra_: works for me, lets talk about the details on monday | 11:56 |
| ogra_ | the PXE part will be a bit tricky since we need to do the loading from there ... we cant do it from the initrd, else we'd need all NIC modules | 11:56 |
| ogra_ | utlemming, ^ | 11:56 |
| ogra_ | :) | 11:56 |
| ogra_ | mvo_, yeah | 11:56 |
| utlemming | ah, right | 11:56 |
| * ogra_ is looking forward to finally implement the generic initrd :) | 11:56 | |
| ogra_ | oh ! | 11:57 |
| mvo_ | ogra_: well AIUI the multiple-initird is really just two initrds concacted so this approach might work for PXE | 11:57 |
| beowulf | sanong: if you try option 2 as utlemming outlines in his blog post it will work | 11:57 |
| mvo_ | (or multiple ones, not just two) | 11:57 |
| * ogra_ just noticed that the DSL update on his second DSL line has happened while being at the dentist ... | 11:57 | |
| ogra_ | WOHOOO !!! | 11:57 |
| ogra_ | from 2Mbit to 50 ! | 11:57 |
| mvo_ | ogra_: congrats | 11:57 |
| mvo_ | ogra_: thats a jump | 11:58 |
| ogra_ | yeah | 11:58 |
| shuduo | hi, after I sideload install a snap on snappy, what is its package name? for example, webcam-webui demo of snapcraft-examples | 11:58 |
| ogra_ | well, i need to reconfig the phone stuff now ... else susie will kill me | 11:58 |
| mvo_ | ogra_: enjoy, we talk monday. the pxe issue with the nics sounds serious to me though, worth thinking about it more IMO | 11:58 |
| stevebiscuit | shuduo: "webcam-webui.sideload" I believe | 11:59 |
| ogra_ | mvo_, yeah | 11:59 |
| shuduo | stevebiscuit: yes, it's . thanks. | 12:01 |
| apw | mvo_, there is cirtainly some support for multiple initrds concatentated yes, they all get unpacked | 12:01 |
| apw | mvo_, and if you want a generic one and a device specific one ramming them together on the rmeote server sounds like a good plan | 12:01 |
| apw | mvo_, not that you can look at them any more with the tooling but hey | 12:01 |
| mvo_ | apw: cool, we can write new tooling for that - if thats fully supported that sounds like the easiest option. | 12:03 |
| mvo_ | ogra_: -^ | 12:03 |
| mvo_ | ogra_: if its just a concat but otherwise looks like a normal initrd that seems like its what we want, right? | 12:03 |
| apw | mvo_, let me investigate to confirm, i know we use it for cpu firmware, that makes a dual initrfamfs | 12:03 |
| mvo_ | apw: thanks! | 12:03 |
| ogra_ | so the added part would have /lib/modules|firmware only ? | 12:03 |
| apw | mvo_, i believe you can literally cat A B >initrd and the kernel groks them | 12:04 |
| mvo_ | ogra_: yeah | 12:04 |
| apw | mvo_, if each is in the rigght format | 12:04 |
| mvo_ | apw: sweet | 12:04 |
| ogra_ | yeah, thats similar to mounting a squashfs i guess | 12:04 |
| ogra_ | just earlier | 12:04 |
| apw | mvo_, but let me go and confirm that on a VM first | 12:04 |
| mvo_ | apw: thanks! | 12:04 |
| apw | mvo_, the refulting file is just bits from a bootloader point of view | 12:05 |
| * mvo_ likes this | 12:05 | |
| apw | mvo_, and because we use it for cpu firmware i beleive we know the bootloaders ought to handle it right | 12:05 |
| mvo_ | apw: yeah, exactly, this is the part I like, pxe, uboot, grub all work as before, the smartz is in the kernel | 12:05 |
| apw | mvo_, anyhow leave it with me for a little and i'll report back | 12:05 |
| mvo_ | apw: and we don't even need to modify anything in our scripts | 12:05 |
| mvo_ | apw: sure, no rush really | 12:05 |
| apw | just the making the initrd needs to change | 12:05 |
| mvo_ | apw: I was waiting for an image upload and this was nagging in the back of my mind :) | 12:06 |
| apw | and ... i assume ninitramfs-tools already knows how becuase it does it for cpu firmwae | 12:06 |
| apw | mvo_, if i don't do it now i will forget :) | 12:06 |
| mvo_ | apw: yeah, well, we just make two initrds with the normal tooling and in the final stage do the cat - sounds easy | 12:06 |
| mvo_ | (foumous last words) | 12:06 |
| mvo_ | apw: ha! do it NOW | 12:06 |
| mvo_ | :) | 12:06 |
| * mvo_ gets lunch in the meantime | 12:06 | |
| mvo_ | ogra_: sounds exciting, generic initird afterall :) | 12:08 |
| ogra_ | \o/ | 12:08 |
| mvo_ | ogra_: but I leave you alone, enjoy your vac | 12:08 |
| mvo_ | :) | 12:08 |
| ogra_ | yeah, and my new teeth :) | 12:08 |
| * ogra_ just returned from dentist | 12:08 | |
| mvo_ | ogra_: woah, new dsl, new teeth, the year starts great it seems | 12:09 |
| mvo_ | (and generic initrd soon) | 12:10 |
| ogra_ | well, only interim teeth, but yeah ... after 20years the visibla gap is gone :) | 12:10 |
| apw | ogra_, nice | 12:10 |
| kyrofa | Good morning | 12:20 |
| kyrofa | sergiusens, would it be bad if plugins could add apps? | 12:29 |
| sergiusens | kyrofa, not at all, but we need to design for it | 12:30 |
| sergiusens | kyrofa, as in, lets not just bolt that together and hope for the best passing the full snapcraft yaml dictionary to plugins | 12:31 |
| sergiusens | kyrofa, are you thinking of catkin? | 12:31 |
| sergiusens | kyrofa, the problem then becomes, is it a daemon, a cli, a desktop icon... | 12:32 |
| kyrofa | sergiusens, right, which would need to be handled by the plugin as well. And yeah, catkin and roscore (I'm still trying to think of how to get rid of the roscore plugin :P ) | 12:33 |
| sergiusens | kyrofa, I don't see why the catkin plugin can't just do everything in there | 12:34 |
| kyrofa | sergiusens, only one single reason: When we have the ability to share roscore, what if someone wants to make a shared .snap containing JUST roscore? | 12:35 |
| kyrofa | I guess if I updated the catkin plugin to accept building no packages, then they could specify the stage package and the app just like normal | 12:36 |
| kyrofa | sergiusens, think that would be good enough? | 12:36 |
| apw | mvo_, ok confirmed if you make a second initramfs cpio.gz style image and literally cat play.gz >>initrd.img the kernel will load both and merge them before executing | 12:36 |
| apw | mvo_, and from what i can see of the code it literally keeps trying until there is no data, so you can have 10 | 12:37 |
| sergiusens | kyrofa, I think so | 12:38 |
| sergiusens | kyrofa, but lets get this in and work on that next week as I guess it is not a 1 hour task :) | 12:38 |
| sanong | updated : OVA option 2 : still cant logon with ubuntu/ubuntu | 12:39 |
| sanong | try 2 image now | 12:39 |
| sergiusens | ogra_, enjoy some ferocious meat eating then ;-) | 12:40 |
| ogra_ | haha, i will :) | 12:41 |
| kyrofa | sergiusens, agreed. And if we can figure out a good way for plugins to add apps, that would get really slick | 12:41 |
| sergiusens | kyrofa, sure, let's brainstorm that a bit next week ;-) | 12:42 |
| kyrofa | sergiusens, or the week after, considering where you'll be :P | 12:42 |
| kyrofa | sergiusens, I need to miss standup-- I need to watch the kiddo this morning | 12:51 |
| sergiusens | kyrofa, no worries | 12:54 |
| tsimonq2 | mvo_: o/ | 12:57 |
| tsimonq2 | mvo_: I have been here for the past few weeks :) | 12:57 |
| * zyga posted https://github.com/ubuntu-core/snappy/pull/329 | 12:59 | |
| zyga | more bool file work around security | 12:59 |
| * zyga refreshed https://github.com/ubuntu-core/snappy/pull/324 (merge with trunk, delta minimized) | 13:01 | |
| mvo_ | tsimonq2: haha, sorrry :) there is so much going on, I did not really notice :) | 13:09 |
| tsimonq2 | :) | 13:09 |
| sergiusens | kyrofa, good job on the branch, I just tried it with all the other branches and it works fine :-) | 13:11 |
| kyrofa | sergiusens, excellent! | 13:11 |
| sergiusens | kyrofa, so the only thing I don't like about squashing is that I can't see what changed between two pushes, any easy way to check from the github ui? | 13:13 |
| kyrofa | sergiusens, hmm... there is in gitlab... looking | 13:15 |
| zyga | fgimenez, elopio: what does it mean when github says "no test results found" for integration tests? | 13:15 |
| zyga | flaky tests? flaky test system? something else? | 13:17 |
| kyrofa | sergiusens, it doesn't seem so. If it was just us I'd suggest using --fixup commits in response to PR review, and one autosquash before merge, but I'm concerned about asking the community at large to do that | 13:19 |
| sergiusens | kyrofa, maybe we can merge without using github ;-) | 13:22 |
| kyrofa | sergiusens, what are you thinking? | 13:22 |
| sergiusens | doing it manually | 13:23 |
| sergiusens | or maybe an automated task with our merge strategy | 13:23 |
| kyrofa | sergiusens, haha, I mean in what situation? | 13:23 |
| sergiusens | kyrofa, just random friday thoughts though | 13:23 |
| kyrofa | sergiusens, that's what Fridays are for :) | 13:23 |
| kyrofa | sergiusens, what should REALLY happen is that github should autosquash upon merge FOR you. That's what I think | 13:24 |
| sergiusens | kyrofa, ask jono for that ;-) | 13:24 |
| kyrofa | sergiusens, ha! Brilliant! | 13:24 |
| kyrofa | sergiusens, I mean, it would always succeed and the commit message is a given because they're fixups | 13:25 |
| sergiusens | kyrofa, hmm, you coverage has dropped :-P | 13:25 |
| kyrofa | sergiusens, I know... stupid roscore plugin | 13:25 |
| kyrofa | sergiusens, I need to bite the bullet and toast it. Next week maybe | 13:26 |
| kyrofa | sergiusens, but I think that PR is good to go if you're good with it | 13:27 |
| sergiusens | kyrofa, yay for toasting, and yes, I'm merging it before elopio wakes up ;) | 13:31 |
| * sergiusens takes a break to run a bit | 13:44 | |
| kyrofa | mvo_, any idea when the new 15.04 image will be built? | 13:45 |
| mvo_ | kyrofa: its ready, I am prepareing the pre-build images as we speak | 13:48 |
| mvo_ | meeting right now | 13:48 |
| kyrofa | mvo_, excellent :) | 13:49 |
| fgimenez | zyga, that's normally because of a problem before the execution even starts, if you follow the "Details" link in the PR page you can reach the console log page to inspect the cause http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/344/console | 14:03 |
| fgimenez | zyga, it seems that there was a connectivity problem getting the dependencies | 14:04 |
| * zyga works on apparmor security module | 14:10 | |
| zyga | fgimenez: thanks! what's the procedure in that case? Retry/ | 14:10 |
| mvo_ | kyrofa: you should get the new 15.04 via snappy update already (if you haven't already) | 14:14 |
| kyrofa | mvo_, nothing yet | 14:15 |
| mvo_ | kyrofa: what does snappy list show you? and what does snappy info show? | 14:18 |
| kyrofa | mvo_, wait... I see a version 12 with the release date of today. Is that it? Must have been done automatically? | 14:19 |
| mvo_ | kyrofa: yep, magic :) | 14:19 |
| mvo_ | kyrofa: great, thanks! | 14:19 |
| fgimenez | zyga, yes, you can retrigger the execution with a comment "retest this please" | 14:21 |
| kyrofa | mvo_, jdstrand ah, 15.04.12~ppa15 of the security packages didn't make it in eh? | 14:28 |
| jdstrand | kyrofa: unfortunately not it seems. I just checked myself | 14:28 |
| jdstrand | kyrofa: I tried. the builder and mvo were too fast | 14:28 |
| kyrofa | jdstrand, haha, that's alright, I can work around it for now :) | 14:29 |
| jdstrand | mvo_: context> there is an update to ubuntu-core-security that kyrofa needs that I tried to sneak in last night | 14:29 |
| zyga | jdstrand: hello :) | 14:30 |
| mvo_ | jdstrand: heh, the builders were not exactly fast :) thats unfortunate, but there is always a next image. how urgent is that update? | 14:30 |
| jdstrand | mvo_: I'll let kyrofa comment on that | 14:31 |
| jdstrand | zyga: hello :) | 14:31 |
| sergiusens | elopio, going to be 15' late if you don't mind | 14:32 |
| sergiusens | kyrofa, just in case ^ | 14:32 |
| kyrofa | mvo_, how often are images built? Think another one will come out before Wednesday? | 14:32 |
| mvo_ | kyrofa: unlikely. we can build anohter one, why wednesday? | 14:32 |
| kyrofa | mvo_, deadline for the owncloud stuff, but I can always add permission to the .snap temporarily | 14:33 |
| zyga | jdstrand: do you know of any sysfs symlink attacks? | 14:33 |
| zyga | jdstrand: just curiosity around how I've structured some bits in the code so far | 14:34 |
| zyga | jdstrand: is it a security issue to resolve symlinks in sysfs multiple times vs doing it once and caching the result | 14:34 |
| zyga | (for the same path0 | 14:34 |
| jdstrand | zyga: not otoh but I'd like tyhicks to comment too | 14:36 |
| zyga | jdstrand, tyhicks: https://github.com/ubuntu-core/snappy/pull/329/files that's the place | 14:37 |
| kyrofa | sergiusens, nothing makes you appreciate mksquashfs like using 1.0 | 14:56 |
| sergiusens | kyrofa, lol | 14:57 |
| jdstrand | mvo_: oh, also, big thank you for the emergency update :) | 14:58 |
| * jdstrand hugs mvo_ | 14:58 | |
| mvo_ | jdstrand: heh, thanks! thank you for fixing it in the first place | 15:00 |
| jdstrand | mdeslaur: ^ :) | 15:01 |
| mvo_ | jdstrand: I read through the details of the cve | 15:01 |
| mvo_ | interessting stuff and scary | 15:01 |
| jdstrand | yeah, it was a really well done investigation | 15:01 |
| * jdstrand notes mdeslaur did the update-- he deserves the credit :) | 15:02 | |
| kyrofa | jdstrand, ooo I'd like to read this | 15:03 |
| jdstrand | kyrofa: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/OpenSSHClientRoaming. at the bottom, see Qualys findings | 15:04 |
| kyrofa | jdstrand, ah, that explains why SSH updated on all my servers last night | 15:05 |
| jdstrand | indeed :) | 15:05 |
| pindonga | elopio, I see your PR passed tests but stalled en coveralls | 15:11 |
| pindonga | is that normal? | 15:11 |
| elopio | pindonga: ugh, no, it was a lie. Travis playing with my feeligs. | 15:14 |
| elopio | Fails with this: call to remove-on-empty (freezer:0) failed: invalid request | 15:14 |
| elopio | pindonga: what if you skip your tests if the system is not xenial? | 15:14 |
| elopio | I will run them here, and once we get this working they will start running on CI. | 15:14 |
| pindonga | elopio, the problem is that my PR introduces a new dependency which currently is only available on xenial | 15:15 |
| pindonga | not sure if it's worth playing the backports game here | 15:15 |
| pindonga | unless of course we need the latest snappy to work on trusty | 15:16 |
| tyhicks | zyga: I'm not aware of any symlink attack possibilities in sysfs | 15:17 |
| elopio | pindonga: ah, right. We don't need to backport. So, let me bother stgraber one more time. | 15:17 |
| elopio | stgraber: I am now getting "call to remove-on-empty (freezer:0) failed: invalid request". Any pointers about how to fix that? | 15:17 |
| sergiusens | elopio, kyrofa mvo_ mind looking at this https://github.com/ubuntu-core/snapcraft/pull/234 it is the envvar replacement one | 15:18 |
| sergiusens | I'll run tests in the meantime | 15:18 |
| elopio | sergiusens: seems simple enough. And as snappy supports both for now, I won't even have to update my snaps. | 15:19 |
| sergiusens | elopio, right; that's why I want it in now; if people start uploading, they might as well have the smallest delta possible | 15:23 |
| elopio | agree. | 15:24 |
| zyga | tyhicks: thanks | 15:32 |
| sergiusens | mvo_, how do I get the latest snappy-debug on 16.04? | 15:56 |
| mvo_ | sergiusens: build as squashfs and upload to the edge channel with rolling as the target | 15:56 |
| mvo_ | sergiusens: this way you can only install it via snappy install snappy-debug/edge in 16.04 | 15:56 |
| mvo_ | sergiusens: but at least you can intsall it | 15:57 |
| mvo_ | and once the store is ready we can make it available without the edge | 15:57 |
| sergiusens | mvo_, I don't even know where snappy-debug sources are, I just consume it ;- | 15:59 |
| sergiusens | ;-) | 15:59 |
| mvo_ | sergiusens: neither do I, I would just download, unpack (dpkg-deb -x), repack and reupload :) | 15:59 |
| mvo_ | sergiusens: thats what I did with docker | 16:00 |
| sergiusens | mvo_, ack | 16:00 |
| fgimenez | elopio, for the deploy you need also to wait for the images to be built https://hub.docker.com/r/fgimenez/snappy-jenkins/builds/ https://hub.docker.com/r/fgimenez/snappy-jenkins-slave-xenial/builds/ and https://hub.docker.com/r/fgimenez/snappy-jenkins-slave-vivid/builds/ | 16:07 |
| sergiusens | elopio, green light ahead, just don't go to fast or a red light will get you crashing ;-) | 16:07 |
| elopio | sergiusens: do not be hasty, that is my motto. | 16:10 |
| elopio | https://i.ytimg.com/vi/8HHVPnvDBlU/maxresdefault.jpg | 16:10 |
| elopio | fgimenez: I forgot about this: https://github.com/ubuntu-core/snappy-jenkins/pull/45 | 16:14 |
| sergiusens | elopio, that IS south america :-P | 16:15 |
| elopio | fgimenez: for the cloud provision we are still using nova. | 16:30 |
| elopio | should we move that also to openstack? | 16:30 |
| fgimenez | elopio, yes we need to update that too, but it's not urgent IMO running from the laptop doesn't give the error, i'll take note of it | 16:31 |
| elopio | ack. | 16:32 |
| kyrofa | sergiusens, if vivid is EOL next month, what is the official recommendation for what people should be using for Ubuntu Core? | 16:36 |
| kyrofa | sergiusens, it can't really be rolling, can it? | 16:36 |
| elopio | fgimenez: do you know about this? http://pastebin.ubuntu.com/14505876/ | 16:38 |
| elopio | ah, that's the openstack bug. | 16:40 |
| fgimenez | elopio, yes https://bugs.launchpad.net/ubuntu/+source/python-keystoneclient/+bug/1242992, you are running from a canonistack instance, i forgot | 16:41 |
| ubottu | Launchpad bug 1242992 in python-keystoneclient (Ubuntu) "Unable to autolaunch a dbus-daemon without a $DISPLAY for X11" [Undecided,Confirmed] | 16:41 |
| elopio | ok, I'll do the update here. | 16:41 |
| sergiusens | kyrofa, in theory, mvo_ is working hard to get an alpha channel or similar for 16.04 | 16:42 |
| sergiusens | but they know the plan better, or maybe olli | 16:42 |
| fgimenez | elopio, all the docker images have finished building | 16:43 |
| mvo_ | kyrofa, sergiusens my suggestion is to (ab)use the "edge" channel for 16.04 snaps - if that was the question, I lack some context here it seems | 16:47 |
| kyrofa | mvo_, vivid EOL is next month. My question was "what should people use between then and 16.04?" | 16:48 |
| kyrofa | mvo_, or will vivid Ubuntu Core continue to receive updates? | 16:48 |
| mvo_ | kyrofa: I think we need to continue to do updates for some weeks | 16:48 |
| mvo_ | kyrofa: I would love to get an alpha out and delcare it good enough | 16:48 |
| mvo_ | but there are some gaps still | 16:49 |
| kyrofa | mvo_, yeah, okay good I'm glad to hear that | 16:49 |
| kyrofa | mvo_, I know that's more work, but I think it'll be appreciated | 16:49 |
| elopio | fgimenez: is nova boot --poll the same as openstack server create --wait? | 16:54 |
| fgimenez | elopio, yes, but not sure if the output has the same fields/format, maybe our checks needs some tweaking | 16:55 |
| elopio | I will know soon. | 16:56 |
| elopio | sergiusens: so this 2.0 release should work on all snaps? or also on the rolling edge non-all-snaps? | 16:57 |
| sergiusens | elopio, on both, but why? | 17:00 |
| elopio | sergiusens: just to see which one to flash. | 17:00 |
| sergiusens | elopio, flash all snaps | 17:00 |
| sergiusens | elopio, obviously ;-) | 17:00 |
| sergiusens | mvo_, bootloader stuff now lives in the kernel, rght? | 17:04 |
| sergiusens | or should live there | 17:04 |
| mvo_ | sergiusens: should, its not done yet, still the gadget that is doing it | 17:16 |
| sergiusens | mvo_, right, I'm just in "writing presentation" mode | 17:24 |
| kyrofa | sergiusens, can you explain now the tmp stuff works? In the binary wrapper I see `TMPDIR="/tmp/snaps/name/version/tmp"`, but when I look in /tmp I see /tmp/snap.0_name_version/ which contains a file called tmp | 17:34 |
| kyrofa | sergiusens, is there some confinement magic happening there? | 17:35 |
| sergiusens | cgroups and mounts | 17:39 |
| sergiusens | kyrofa, ^ | 17:39 |
| kyrofa | sergiusens, okay very good, thanks :) | 17:40 |
| elopio | sergiusens: the shout port is 9000, right? | 18:04 |
| sergiusens | elopio, I will lie if I say yes | 18:06 |
| sergiusens | elopio, check with netstat | 18:06 |
| elopio | sergiusens: shows only 22 for tcp. | 18:07 |
| elopio | I think it's not serving, but the logs show no errors, as far as I can see. | 18:08 |
| elopio | fails on rolling edge #320 and on all snaps. | 18:14 |
| elopio | sergiusens: kyrofa: can one of you verify if you can access the shout or webchat port from the host? | 18:14 |
| sergiusens | elopio, let me check | 18:16 |
| sergiusens | kyrofa, I still have /usr/bin/python, can you give it a try? | 18:20 |
| kyrofa | sergiusens, yeah one sec | 18:20 |
| elopio | One more thing. Latest rolling edge, I get (amd64)ubuntu@localhost:~$ java-hello-world.hello | 18:21 |
| elopio | /apps/java-hello-world.sideload/IKNMMGUUJQeN/command-hello.wrapper: 9: exec: /bin/wrapper: not found | 18:21 |
| elopio | sergiusens: kyrofa ^ | 18:21 |
| elopio | it works on all snaps. | 18:21 |
| elopio | maybe it doesn't have the short env vars. | 18:21 |
| sergiusens | elopio, I guess it is the cap | 18:22 |
| sergiusens | elopio, install hello-world.mvo and verify ;-) | 18:22 |
| elopio | sergiusens: hello-world.echo from hello-world.mvo works. | 18:23 |
| sergiusens | elopio, I mean, run hello-world.env and check the env :-) | 18:23 |
| elopio | ah | 18:23 |
| kyrofa | sergiusens, to verify: the ros example has stuff rewritten fine? | 18:24 |
| elopio | SNAPP_APP_PATH=/apps/hello-world.mvo/2.0 | 18:24 |
| sergiusens | kyrofa, yeah | 18:24 |
| elopio | sergiusens: what cap? | 18:24 |
| sergiusens | elopio, network-listener | 18:25 |
| elopio | sergiusens: oh, you mean the shout problem. | 18:25 |
| kyrofa | elopio, bit me yesterday too | 18:25 |
| sergiusens | elopio, yeah, all server things might need that | 18:25 |
| kyrofa | elopio, by default the cap is network-client, which doesn't allow binding | 18:26 |
| sergiusens | elopio, I don't see apparmor denials though | 18:26 |
| kyrofa | sergiusens, I think it's seccomp | 18:26 |
| sergiusens | kyrofa, how did you check those again? | 18:26 |
| elopio | where are seccomp problems printed? | 18:27 |
| kyrofa | sergiusens, I think snappy-debug still pulls them out though... what clued me in initially was an illegal syscall | 18:27 |
| kyrofa | sergiusens, i.e. my binary was aborted | 18:27 |
| sergiusens | kyrofa, snappy-debug does not work on rolling | 18:27 |
| kyrofa | sergiusens, which I believe should happen if it's a seccomp denial | 18:27 |
| kyrofa | sergiusens, oh | 18:28 |
| jdstrand | sergiusens: it doesn't work on rolling cause it isn't squashfs yet you mean? | 18:28 |
| sergiusens | jdstrand, no one asked for the full story ;-) | 18:28 |
| sergiusens | in any case I'm dpkg-deb -x'ing it and creating a snap again | 18:28 |
| jdstrand | sergiusens: does the store support targeting different releases yet? Ie, can we have snappy-debug as ar for stable and squashfs for rolling? | 18:29 |
| jdstrand | I saw in mvo's email that was coming but didn' | 18:30 |
| jdstrand | t see a subsequent announcement that it was implemented | 18:30 |
| sergiusens | elopio, confirmed * add one of 'firewall-management, network-listener, unix-listener' to 'caps' | 18:32 |
| sergiusens | jdstrand, the trick he said to use was to put rolling stuff on the edge channel | 18:33 |
| jdstrand | sergiusens: ack. sounds like you are handling the snappy-debug upload for rolling/edge then? | 18:33 |
| sergiusens | jdstrand, if you are fine with me unpacking and repacking and it is in the canonical account I forgot the password for, then sure ;-) | 18:34 |
| jdstrand | sergiusens: and for future reference, all I need for squashfs snaps is snapcraft 2.0? | 18:34 |
| jdstrand | well, I was actually just setting up a new all snaps vm | 18:34 |
| sergiusens | jdstrand, yes; which we are trying to get into xenial cleanly | 18:34 |
| sergiusens | jdstrand, the all snaps ones are much better than the s-i ones, so much more cleaner albeit you can't hack into the os | 18:35 |
| sergiusens | or any other snap for that matter | 18:35 |
| jdstrand | sergiusens: snapcraft 2.0 is in what ppa? | 18:35 |
| sergiusens | jdstrand, none today; planning on going straight into xenial | 18:35 |
| jdstrand | sergiusens: yes, I already have a debugging/development method involving bind mounts for that :) | 18:35 |
| jdstrand | sergiusens: ah, so if it isn't available anywhere, I'd prefer you handle the upload | 18:36 |
| jdstrand | I'm happy to test it though | 18:36 |
| jdstrand | sergiusens: in fact, if you upload it, ping me and I'll test it and approve it | 18:36 |
| sergiusens | jdstrand, http://people.canonical.com/~sergiusens/snappy/snappy-debug_0.11_all.snap | 18:38 |
| sergiusens | elopio, kyrofa in case you need it for rolling http://people.canonical.com/~sergiusens/snappy/snappy-debug_0.11_all.snap | 18:38 |
| kyrofa | Thanks sergiusens | 18:38 |
| elopio | sergiusens: kyrofa: network-listener works for shout on all snaps. Not for rolling edge, same error finding binaries. | 18:39 |
| elopio | I'll make a branch to add the caps. | 18:40 |
| sergiusens | elopio, don't worry about the s-i version of rolling | 18:42 |
| sergiusens | it has no new images being created | 18:42 |
| sergiusens | kyrofa, what if I just add the roscore part/plugin into facedetector ? | 18:44 |
| kyrofa | sergiusens, that won't get you anything | 18:45 |
| kyrofa | sergiusens, catkin has the same replacement logic | 18:45 |
| kyrofa | sergiusens, I'm building this now | 18:47 |
| sergiusens | kyrofa, I just don't understand how one works and the other doesn't | 18:47 |
| kyrofa | sergiusens, huh... yeah I can duplicate. What on earth | 18:50 |
| kyrofa | sergiusens, investigating now | 18:50 |
| bellyfeel | if I made changes to files in the /etc directory would the changes persist after a core kernel update? | 18:51 |
| kyrofa | sergiusens, how do my tests pass!? | 18:51 |
| bellyfeel | the snappy /etc directory, not the snaps | 18:52 |
| sergiusens | kyrofa, the face thing fails, the talker listener works just fine | 18:54 |
| sergiusens | bellyfeel, all writable locations should persist, yes | 18:55 |
| bellyfeel | sergiusens, thanks! | 18:55 |
| elopio | sergiusens or kyrofa: https://github.com/ubuntu-core/snapcraft/pull/235 | 18:57 |
| sergiusens | elopio, you are missing gopasted | 18:58 |
| kyrofa | sergiusens, I know what it is | 18:58 |
| kyrofa | Your stage-packages change | 18:58 |
| kyrofa | It's overwriting my customized files | 18:59 |
| kyrofa | With the ones from the .debs | 18:59 |
| sergiusens | elopio, and tomcat-maven-webapp | 18:59 |
| sergiusens | kyrofa, oh, that sucks; but they are migrated twice though | 18:59 |
| sergiusens | kyrofa, but you are indeed right | 19:00 |
| kyrofa | sergiusens, yeah the replacement happens in parts/ | 19:01 |
| sergiusens | kyrofa, that's fine | 19:01 |
| elopio | sergiusens: tomcat-maven-webapp works with network-client and network-service: https://github.com/ubuntu-core/snapcraft/pull/228/files | 19:01 |
| sergiusens | elopio, oh, then ignore me | 19:01 |
| elopio | sergiusens: should I replace those two with network-listener? | 19:01 |
| kyrofa | sergiusens, but then in stage/ they're definitely from the .debs. I'm not sure what the fix is, though | 19:02 |
| sergiusens | kyrofa, maybe shebangs should be taken care of in repo.py | 19:03 |
| kyrofa | sergiusens, hmm, yeah maybe that's the best way | 19:04 |
| kyrofa | sergiusens, but I'm not sure how comfortable I am with .debs clobbering my files, you know? | 19:04 |
| kyrofa | Can't they be staged the other way around? | 19:04 |
| kyrofa | Debs then built stuff so I can clobber IT? | 19:04 |
| sergiusens | kyrofa, can we hangout? I don't follow | 19:05 |
| kyrofa | sergiusens, sure :) | 19:05 |
| kyrofa | Let me use the restroom real quick, then standup room | 19:05 |
| elopio | kyrofa: sergiusens: I'm left with this one in gopaste: http://pastebin.ubuntu.com/14507643/ | 19:14 |
| elopio | clues? | 19:14 |
| kyrofa | elopio, why would it be using fchown? | 19:19 |
| jdstrand | beuno: is there a plan to handle the existing ar format snaps that targeted rolling now that all snaps images can't install them (but they show up in search)? | 19:20 |
| elopio | kyrofa: I don't know. | 19:21 |
| kyrofa | sergiusens, you're right, that works | 19:22 |
| kyrofa | sergiusens, I also noticed no time difference | 19:22 |
| kyrofa | sergiusens, want me to propose? | 19:23 |
| elopio | jdstrand: do you know anything about http://pastebin.ubuntu.com/14507643/ ? | 19:24 |
| jdstrand | sergiusens: fyi, the snap tests fine. there are other bugs in it related to all snaps but I'll fix those after I have an apt-gettable snapcraft | 19:24 |
| jdstrand | elopio: I sure do | 19:25 |
| jdstrand | elopio: you can't use the chown family of syscalls because of two things: we don't have per-app uids so the chown doesn't make sense under most cases, and for those cases that do make sense, we need syscall argument filtering | 19:26 |
| jdstrand | put more simply, do what it suggested and adjust to not use chown | 19:26 |
| jdstrand | the hope is we'll have argument filtering for seccomp and can loosen that up a bit | 19:27 |
| jdstrand | for 16.04 | 19:27 |
| sergiusens | kyrofa, sure | 19:27 |
| elopio | hum, the chown seems to come from here: https://raw.githubusercontent.com/mattn/go-sqlite3/master/code/sqlite3-binding.c | 19:29 |
| sergiusens | elopio, sqlite is not going to work without patching | 19:29 |
| sergiusens | kyrofa, this is my lame paste fwiw http://paste.ubuntu.com/14507965/ | 19:31 |
| sergiusens | elopio, that is a known issue we have with gopasted sadly | 19:31 |
| elopio | sergiusens: so, release without gopaste working? | 19:32 |
| jdstrand | sergiusens: ok, I uploaded 0.11 to rolling/edge which successfully keeps it out of stable, but 16.04 can't seem to find it | 19:32 |
| sergiusens | elopio, it has never ever ever worked | 19:33 |
| sergiusens | jdstrand, snappy install snappy-debug/edge iirc | 19:33 |
| jdstrand | yes, that's it | 19:34 |
| elopio | ok, so this is ready: https://github.com/ubuntu-core/snapcraft/pull/235 | 19:34 |
| sergiusens | \o/ | 19:34 |
| sergiusens | elopio, oh, for gopasted we can use the security-override and add fchown to the valid syscalls | 19:35 |
| sergiusens | elopio, in case you want to try https://github.com/ubuntu-core/snappy/blob/master/docs/security.md | 19:36 |
| jdstrand | one could do that, but that will block autoapprovals in the store | 19:38 |
| sergiusens | jdstrand, but it does enhance our examples knowledge base :-) | 19:39 |
| jdstrand | sergiusens: which examples? how to get your app require a human review? :P | 19:39 |
| sergiusens | jdstrand, exactly :-P | 19:39 |
| jdstrand | hehe | 19:39 |
| kyrofa | sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/236 . Prepare yourself. Don't be overwhelmed | 19:40 |
| jdstrand | kyrofa, elopio: fyi, on an allsnaps image: 'sudo snappy install snappy-debug/edge' | 19:40 |
| jdstrand | sergiusens: thanks for your help with that ^ | 19:40 |
| sergiusens | kyrofa, fwiw http://paste.ubuntu.com/14508130/ | 19:42 |
| sergiusens | kyrofa, progress, but not there yet | 19:43 |
| kyrofa | sergiusens, nooo | 19:44 |
| kyrofa | sergiusens, that's in /usr/bin | 19:44 |
| kyrofa | sergiusens, from the .deb | 19:44 |
| kyrofa | sergiusens, maybe repo really should do the shebang | 19:44 |
| elopio | https://github.com/ubuntu-core/snapcraft/pull/237 | 19:46 |
| elopio | it works. | 19:46 |
| sergiusens | elopio, there's an existing open bug for gopasted in case you want to link it | 19:46 |
| sergiusens | kyrofa, oh, goodie | 19:47 |
| elopio | sergiusens: I saw one, but I'm not too sure it's the same one. | 19:47 |
| elopio | I'll check. | 19:47 |
| sergiusens | elopio, it just says it doesn't work ;-) | 19:47 |
| sergiusens | kyrofa, how do we tackle this then? | 19:48 |
| sergiusens | kyrofa, what file is it specifically? | 19:48 |
| kyrofa | sergiusens, snap/usr/bin/rosversion | 19:48 |
| kyrofa | sergiusens, I guess we should extract the search_and_replace method into a more general place | 19:48 |
| sergiusens | kyrofa, into repo.py :-) | 19:49 |
| elopio | I need food. And help with gbp that only says: | 19:49 |
| elopio | gbp:error: Version 0.6 not found | 19:49 |
| elopio | bbs | 19:49 |
| kyrofa | sergiusens, well it still needs to be used by the catkin plugin though. Does repo.search_and_replace() make sense in that use case? | 19:49 |
| sergiusens | kyrofa, common, where we dump all the things with no home | 19:50 |
| sergiusens | kyrofa, do you want to tackle it or should I? | 19:50 |
| kyrofa | sergiusens, alright. If it's on your critical path (which it seems it is) please feel free, I'm neck deep in mysql at the moment | 19:50 |
| sergiusens | kyrofa, will do | 19:51 |
| kyrofa | sergiusens, but I'd be happy to check it out a bit later | 19:51 |
| kyrofa | sergiusens, alright | 19:51 |
| sergiusens | kyrofa, I don't think it's that (I layman fixed it fwiw) http://paste.ubuntu.com/14509383/ | 20:16 |
| kyrofa | sergiusens, that still looks the same... ? | 20:17 |
| sergiusens | kyrofa, yeah, but shebang is correct. My guess is it is missing a PATH | 20:18 |
| kyrofa | sergiusens, I thought the wrappers added usr/bin to the path | 20:18 |
| sergiusens | kyrofa, yeah, scratch that, just saw it was in usr/bin | 20:19 |
| sergiusens | elopio, does this need rebasing https://github.com/ubuntu-core/snapcraft/pull/237 ? | 20:30 |
| sergiusens | kyrofa, so happy to see this Jan 15 20:48:50 localhost.localdomain ubuntu-core-launcher[5196]: [ERROR] [1452890930.938570301]: Webcam: expected picture but didn't get it... | 20:49 |
| sergiusens | :-) | 20:49 |
| kyrofa | sergiusens, hey! Progress | 20:50 |
| kyrofa | sergiusens, do you see all sort of jpeg decoding errors? | 20:50 |
| sergiusens | yeah, now to fix the sys devices perms | 20:50 |
| sergiusens | kyrofa, not yet, just a repetition of that | 20:50 |
| kyrofa | sys devices perms? | 20:51 |
| kyrofa | sergiusens, you mean the camera permissions? | 20:52 |
| kyrofa | sergiusens, or is this unrelated? | 20:52 |
| sergiusens | kyrofa, http://paste.ubuntu.com/14510342/ | 20:52 |
| sergiusens | yeah | 20:52 |
| kyrofa | sergiusens, oh yeah, that's probably necessary, no? | 20:53 |
| sergiusens | jdstrand, what's the best path to solve ^ | 20:53 |
| sergiusens | the paste | 20:53 |
| kyrofa | sergiusens, not sue why it's trying to access mounts though | 20:54 |
| elopio | sergiusens: kyrofa: are we still planning to release today? | 20:55 |
| elopio | can I help you somehow? | 20:55 |
| sergiusens | kyrofa, me neither, hopefully harmless | 20:55 |
| kyrofa | sergiusens, indeed | 20:55 |
| sergiusens | elopio, I think I'll just keep polishing and go for a weekend release | 20:55 |
| sergiusens | elopio, just reviews | 20:55 |
| elopio | sergiusens: ack. I will be close during the weekend, so ping me on telegram if you need a hand. | 20:57 |
| kyrofa | sergiusens, regarding the link stuff... I see those File exists: errors as well but I don't understand what's causing them | 20:59 |
| kyrofa | sergiusens, which file exists? :P | 20:59 |
| sergiusens | kyrofa, it's the symlink issue | 20:59 |
| sergiusens | kyrofa, just copy what I did :-P | 20:59 |
| kyrofa | sergiusens, ohh, because os.remove follows a symlink? | 21:01 |
| jdstrand | sergiusens: are those denials fatal? we purposefully deny the mounts access cause it is an information leak (I've seen this as harmless in the past) | 21:06 |
| jdstrand | sergiusens: the other one I don't think can be solved with hwassign, but the new capabilities work should address that (that is part of why we are doing it) | 21:06 |
| jdstrand | it may also be a harmless denial | 21:08 |
| kyrofa | sergiusens, try adding them to the profile manually. Does it fix things? | 21:09 |
| sergiusens | jdstrand, the devices ones, those can be solved with a read-path, right? | 21:12 |
| sergiusens | kyrofa, I am; so close and yet so far :-P | 21:13 |
| sergiusens | since it's friday of course | 21:13 |
| kyrofa | sergiusens, no kidding | 21:13 |
| jdstrand | sergiusens: both of those denials can actually | 21:23 |
| sergiusens | kyrofa, https://github.com/ubuntu-core/snapcraft/pull/238 | 21:25 |
| sergiusens | kyrofa, I took the short path for now | 21:25 |
| kyrofa | sergiusens, it was literally only that one file? Sheesh | 21:26 |
| kyrofa | sergiusens, or at least usr/bin only | 21:26 |
| sergiusens | kyrofa, that file is the only one relevant there; to be fair, in the final snap, all the other ones aren't needed (2to3 is in there) | 21:27 |
| kyrofa | sergiusens, gotcha | 21:27 |
| sergiusens | kyrofa, now this is weird Jan 15 21:27:40 localhost.localdomain ubuntu-core-launcher[1654]: [camera-2] process has died [pid 1704, exit code -11, cmd /snaps/face-detector.sideload/IKNWUPeRbPPf/opt/ros/indigo/lib/usb_cam/usb_cam_node __name:=camera __log:=/var/lib/snaps/face-detector.sideload/IKNWUPeRbPPf/ros/log/cced8cc4-bbce-11e5-b9c1-0090f5ccd32c/camera-2.log]. | 21:29 |
| kyrofa | sergiusens, there should be more of a log than that... no? | 21:29 |
| sergiusens | nope | 21:30 |
| sergiusens | nothing | 21:30 |
| sergiusens | jdstrand, can read-paths be full dirs? | 21:31 |
| kyrofa | sergiusens, more apparmor/seccomp denials? | 21:31 |
| kyrofa | sergiusens, I've never seen it just collapse before | 21:31 |
| sergiusens | kyrofa, http://paste.ubuntu.com/14511298/ | 21:32 |
| sergiusens | kyrofa, I need to stop for a bit, might continue later or early tomorrow; my head is too tired | 21:32 |
| sergiusens | and family is requiring attention | 21:32 |
| kyrofa | sergiusens, understood :) | 21:32 |
| kyrofa | sergiusens, yeah those hw-assign denials might be killing it | 21:33 |
| kyrofa | sergiusens, I didn't envision using a usb device would be this difficult. That driver must be going about it in an unusual way? | 21:34 |
| jdstrand | sergiusens: with read-paths and write-paths, if you do /foo, that is access to a file. if you do /foo/, that is access to /foo/ and everything under it | 21:38 |
| jdstrand | sergiusens: you can also do things like /sys/**/devices/ | 21:38 |
| jdstrand | which matches /sys/foo/devices/ and /sys/foo/bar/devices/ | 21:39 |
| kyrofa | jdstrand, any idea why I wouldn't be able to use run-parts from a snap? | 22:21 |
| kyrofa | jdstrand, no denials... just a "run-parts: Operation not permitted" | 22:23 |
| jdstrand | kyrofa: DAC? | 23:01 |
| jdstrand | kyrofa: is the script executable, some other unix perms? | 23:01 |
| kyrofa | jdstrand, yeah it works fine if I do it in the terminal | 23:08 |
| kyrofa | jdstrand, but if I do it in a shell script launched with u-c-l I get that | 23:08 |
| jdstrand | kyrofa: it could be kernel rate limiting. snappy-debug.security tries to make that better, but the kernel has some issues in that area (a reboot and try again might help) | 23:10 |
| jdstrand | kyrofa: beyond that, an strace would likely be the way to go. scp strace to the device, then strace -f -o /tmp/trace /apps/bin/your.thing | 23:11 |
| jdstrand | (for example) | 23:11 |
| jdstrand | kyrofa: I have a very hard stop now though. if you see something wrong with the policy, I do read backscroll | 23:12 |
| jdstrand | kyrofa: oh, we also have a few explicit denials in the policy. you could comment out anything that starts with 'deny ...' in the generated policy | 23:12 |
| jdstrand | reload it and try again | 23:13 |
| jdstrand | they are explicitly denied for a reason-- to silence noisy denials. if you suspect one is the culprit, remove 'deny' from the rule and see if that fixes it for you | 23:13 |
| kyrofa | jdstrand, alright will do, and I understand hard stops! :) | 23:13 |
| jdstrand | (that turns it into an allow) | 23:13 |
| kyrofa | jdstrand, thanks for your help | 23:14 |
| jdstrand | np | 23:15 |
| jerryG | Chipaca, ping | 23:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
