| wililupy | kyrofa, that seemed to fix it. The modules and everything load up, but it is still quite odd that a clean custom image I build with ubuntu-device-flash shows no snaps installed until I install my snap, and then it downloads ubuntu-core and then when I reboot my system, it crashes. A clean install would show three snaps, ubuntu-core, my custom-kernel and pc, but now it says no snaps installed. | 00:00 |
|---|---|---|
| kyrofa | wililupy, sorry, I'm not sure what the situation is regarding all-snaps images. Have you tried downloading one of mvo's? | 00:01 |
| wililupy | I was just going to try that when my snapcraft snap finished and I tested that. | 00:02 |
| wililupy | Looks good so far, I have a dependency missing, so I have to figure that out... | 00:02 |
| wililupy | kyrofa: I am using a modified version of your fboss snap from github to work with the Wedge 100. | 00:03 |
| kyrofa | wililupy, ah, oay | 00:03 |
| kyrofa | okay* | 00:03 |
| wililupy | kyrofa: I'm going to push my updates to my fork and then look at mvo's all-snap tomorrow. I am including the kmods with the snap, so it is a little easier to try with the all-snap image instead of a custom kernel. | 00:04 |
| beisner | hi ev, niemeyer - looking to start using spread asap while we're redeploy some openstack ci infra. i've got a fresh xenial instance, can launch and list lxc a-ok as my user, but can't get spread to do the examples: http://pastebin.ubuntu.com/23091151/ ideas? | 00:17 |
| kyrofa | beisner, yeah, try running it from source instead | 00:51 |
| kyrofa | beisner, the snap doesn't have permission to reach out like that | 00:51 |
| kyrofa | beisner, do you need help with that? | 00:51 |
| kyrofa | (qemu backends have the same problem) | 00:52 |
| kyrofa | The snap is only really useful if you're using remote backends | 00:52 |
| === al_ is now known as Guest55102 | ||
| mwhudson | $ sudo snap refresh --beta --devmode ubuntu-device-flash | 02:03 |
| mwhudson | - Setup snap "ubuntu-device-flash" (9) security profiles (cannot setup apparmor for snap "ubuntu-device-flash": cannot load apparmor profile "snap.ubuntu-device-flash.ubuntu-device-flash": cannot load apparmor profile: exit status 10 | 02:03 |
| mwhudson | what? | 02:03 |
| mup | PR snapcraft#759 opened: Remove the useless call to os.path.join from the go plugin <Created by elopio> <https://github.com/snapcore/snapcraft/pull/759> | 02:03 |
| mwhudson | well rebooting and reinstalling fixed that | 02:12 |
| beisner | hi kyrofa thanks for the info. just for kicks i removed the snap, reinstalled it in devmode, still the same. so, go get ftw? | 02:45 |
| smoser | what does this mean ? | 02:51 |
| smoser | Cannot get permission from the store to upload this package. | 02:51 |
| smoser | trying to have launchpad build a snap package for me | 02:51 |
| smoser | it says: | 02:52 |
| smoser | If you ask Launchpad to automatically upload builds of this snap to the store on your behalf, then the login service will prompt you to authorize this request. | 02:52 |
| smoser | so i expected it to ask me or something, but it just says fail | 02:52 |
| mup | PR snapd#1765 opened: many: move network initialization to a separate service <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1765> | 04:36 |
| mup | PR snapcraft#760 opened: Removed statements not unused by the tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/760> | 04:48 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#1766 opened: image, asserts: add new asserts.Fetcher.SavedRefs() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/1766> | 07:16 |
| zyga | good morniong | 07:22 |
| zyga | *morning | 07:22 |
| josvaz | Question about snaps and folder access / interfaces. For my snap I need to mount a folder so that the normal users can write to it and the snap can read it. | 08:18 |
| josvaz | how can I achieve that? | 08:18 |
| mup | PR snapd#1766 closed: image, asserts: add new asserts.Fetcher.SavedRefs() helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1766> | 08:24 |
| ogra_ | mvo, mind if i ubpublish all the canonical-* snaps ? | 08:37 |
| mvo | ogra_: not at all | 08:37 |
| === AL_ is now known as Guest80394 | ||
| Guest80394 | Hi ! I am sorry to disturb the channel. I have a short question: I try to connect a USB drive to my snap. I did not find a way to do this with the "strict confinement" mode. It only works with the "devmode". Is there a way using interfaces ? | 08:58 |
| zyga | Guest80394: hey, I don't believe there is right now but it should be simple to add | 08:59 |
| zyga | Guest80394: look at the home interface, a similar interface could mediate access to /media or /run/media or anything like that | 09:00 |
| zyga | Guest80394: it should be very easy to contribute if you want to | 09:00 |
| Guest80394 | ok, I will look at this ! | 09:01 |
| ogra_ | mvo, hmm, did we seed subiquity already ? my serial console is a huge readable mess after rebooting on all my images | 09:01 |
| ogra_ | *unreadable | 09:01 |
| ogra_ | mvo, http://paste.ubuntu.com/23092374/ | 09:01 |
| ogra_ | the last line fill multiple pages | 09:02 |
| ogra_ | '*fills | 09:02 |
| zyga | Guest80394: look at zygoon.pl, I posted some articles about this there | 09:02 |
| zyga | Guest80394: and ping me here for advice :-) | 09:02 |
| mvo | ogra_: it landed last night | 09:02 |
| mvo | ogra_: apparently a hard landing | 09:02 |
| Guest80394 | Thanks a lot ! | 09:02 |
| ogra_ | mvo, extremely buggy ... and it seems to run regardless if the system is cionfigurede | 09:03 |
| ogra_ | *configured | 09:03 |
| mvo | ogra_: lets talk to cyphermox, mwhudson or slangasek about the bugs in console-conf: http://paste.ubuntu.com/23092374/ | 09:03 |
| ogra_ | on the dragonboard i now have a network config dialog | 09:03 |
| mvo | ogra_: if its too buggy we can revert the upload | 09:03 |
| mvo | ogra_: its a single line in livecd-rootfs from last night | 09:03 |
| ogra_ | it is more than console-conf ... unless that also does network config etc ... and it is definitely not safe for serial | 09:04 |
| mvo | ogra_: it does | 09:04 |
| mvo | ogra_: and yeah, it takes over the gettys | 09:04 |
| ogra_ | ah, i thought it cionfigures the coneole :) | 09:04 |
| mvo | ogra_: its a bit misleading the name | 09:04 |
| ogra_ | right, if it does so, it should probably use settings from d-i or so to make sure you dont end up with multiple lines of control chars :) | 09:05 |
| ogra_ | in any case i cant do any unattended reboot anymore | 09:05 |
| mvo | ogra_: and I want my getty back | 09:05 |
| mvo | ogra_: if its too anoying, just revert, I think that is fine | 09:06 |
| ogra_ | the boot hangs at a prompt (which i cant even see on the pi... but see on the dragonboard (different serial consoles i guess)) | 09:06 |
| ogra_ | mvo, oh, fun ... and it doesnt recognize my configured wlan0 devices on both boards ... so i'm stuck in the config screen | 09:08 |
| ogra_ | i'll unseed it once i reported all the bugs ... oh my | 09:08 |
| mvo | ogra_: oki doki, thanks | 09:09 |
| mup | PR snapd#1747 closed: overlord, daemon: add collect attribute hooks <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/1747> | 09:09 |
| mup | PR snapd#1767 opened: overlord, daemon: add collect attribute hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/1767> | 09:12 |
| mup | PR snapd#1763 closed: many: clarify/tie down model assertion <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1763> | 09:13 |
| mup | PR snapd#1616 closed: tests, integration-tests: implement the cups-control manual test as a spread test <Decaying> <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1616> | 09:14 |
| mup | PR snapd#1759 closed: asserts: fix GPG key generation parameters <Created by cjwatson> <Conflict> <https://github.com/snapcore/snapd/pull/1759> | 09:14 |
| * ogra_ sighs ... so how do i get out of this .. i cant boot at all anymore | 09:17 | |
| ogra_ | (it tries to configure the already configured wlan devices, falis and drops me back to the start screen ... there is no way to skip) | 09:18 |
| mup | PR snapd#1759 closed: asserts: fix GPG key generation parameters <Created by cjwatson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1759> | 09:18 |
| mup | Bug #1617231 opened: subiquity kills serial console after regular update <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1617231> | 09:32 |
| mup | Bug #1617232 opened: subiquity goes into endless configuration loop, no way to get out <Snappy:New> <https://launchpad.net/bugs/1617232> | 09:35 |
| ogra_ | pitti, i fear in the light of that one ^^^ Bug 1616928 should get a higher urgency | 09:36 |
| mup | Bug #1616928: netplan should support managing wlan devices via wpasupplicant <nplan (Ubuntu):Triaged> <https://launchpad.net/bugs/1616928> | 09:36 |
| ogra_ | (assuming that subiquity actually tries to use netplan in the backend) | 09:37 |
| mup | Bug #1617236 opened: console-conf falls over trying to create already existing logdir <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1617236> | 09:45 |
| mup | PR snapd#1753 closed: asserts: add an account-key-request assertion <Created by cjwatson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1753> | 09:48 |
| pitti | ogra_: ah, I can't get out either, as even though it is online it doesn't accept any email address of mine for registering to the snap store | 09:52 |
| ogra_ | what a mess | 09:52 |
| pitti | ogra_: but yes, wlan is another issue indeed | 09:52 |
| ogra_ | pitti, file a bug ..., i'll unseed it now and re-spin ubuntu-core afterwards | 09:52 |
| pitti | communication breakdown -- when this was discussed a few weeks/months ago, the plan was still "use NM for wifi".. | 09:52 |
| ogra_ | pitti, well, the worst is that the console-conf process actually consumes 16-25MB ... | 09:53 |
| pitti | ogra_: yep, will do; I'm sorting out some other console-conf issues with mwhudson (currently blocked on getting a VM image that actually works) | 09:53 |
| pitti | ogra_: welcome to python :) | 09:53 |
| ogra_ | and it spawns a new process every time i ctrl-c out of it | 09:53 |
| === hikiko is now known as hikiko|ln | ||
| ogra_ | yeah, the worst choice for arm | 09:53 |
| ogra_ | i guess that bumps our ram requirements from ~64MB to 128 for embedded boards ... | 09:54 |
| ogra_ | :((( | 09:54 |
| pitti | for those you could skip console-conf somehow perhaps (kernel arg or pre-create the firstboot stamp file etc.)? | 09:55 |
| ogra_ | so you mean for all of them ? | 09:55 |
| ogra_ | :) | 09:55 |
| ogra_ | (like all boards) | 09:55 |
| ogra_ | so depressing :/ | 09:57 |
| ogra_ | cyphermox, mwhudson, slangasek, i unseeded console-conf again for now, it breaks to many things atm | 10:01 |
| ogra_ | woah ... | 10:03 |
| ogra_ | ubuntu@dragonboard:~$ ps ax -orss=,args=|grep 24228 | 10:04 |
| ogra_ | 24228 python3 /usr/bin/console-conf | 10:04 |
| ogra_ | ubuntu@dragonboard:~$ sudo kill -9 24228 | 10:04 |
| ogra_ | ubuntu@dragonboard:~$ ps ax -orss=,args=|grep 24228 | 10:04 |
| ogra_ | 24228 python3 /usr/bin/console-conf | 10:04 |
| ogra_ | very reluctant to be killed :P | 10:04 |
| pitti | Restart=always | 10:08 |
| mup | Bug #1617250 opened: 401 errors trying to install a snap <Snappy:New> <https://launchpad.net/bugs/1617250> | 10:09 |
| mup | Bug #1617251 opened: console-conf unkillable <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1617251> | 10:09 |
| ogra_ | pitti, weeeelll ... wouldnt a restart assign a new PID ? | 10:09 |
| pitti | but systemctl stop console-conf.service also is broken as there are about three endless loops | 10:09 |
| pitti | ogra_: ^ | 10:09 |
| pitti | ogra_: err yes, kill -9 not working?? | 10:09 |
| ogra_ | right | 10:09 |
| ogra_ | it keeps the PID | 10:09 |
| ogra_ | no matter how often i kill -9 | 10:09 |
| mup | PR snapd#1744 closed: snap: use "up to date" instead of "up-to-date" <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1744> | 10:31 |
| rogpeppe | so, i've just made a snap that contains a single Go binary (app) that just makes HTTP connections. to make it work, I had to configure it with network, firewall-control and network-bind plugs. Anyone know why? It seems like I should only need "network". | 10:42 |
| rogpeppe | also, when I didn't have the required plugs, the binary just hung when I ran it. Is that the expected failure mode? | 10:42 |
| ogra_ | it needs to create a socket ... "network" is only for client side things ... for the socket creation you need -bind ... | 10:43 |
| ogra_ | not sure why you would need firewall though | 10:43 |
| rogpeppe | ogra_: how can you be a network client without creating a socket? | 10:44 |
| ogra_ | (i definitely dont need it for any of my network server snaps ) | 10:44 |
| rogpeppe | ogra_: ah, it's possible i don't need firewall-control - i added that first | 10:45 |
| rogpeppe | ogra_: i'd have thought that network-bind was only necessary for listening on network ports, not making outgoing connections | 10:45 |
| ogra_ | https://github.com/snapcore/snapd/blob/master/docs/interfaces.md | 10:46 |
| rogpeppe | network-bind says "Can access the network as a server" | 10:46 |
| ogra_ | network | 10:46 |
| ogra_ | Can access the network as a client. | 10:46 |
| ogra_ | Auto-Connect: yes | 10:46 |
| ogra_ | network-bind | 10:46 |
| ogra_ | Can access the network as a server. | 10:46 |
| ogra_ | Auto-Connect: yes | 10:46 |
| rogpeppe | ogra_: yeah. and this program isn't a server. | 10:46 |
| === hikiko|ln is now known as hikiko | ||
| rogpeppe | ogra_: it's just making an outgoing connection | 10:46 |
| ogra_ | so if your binary actually only does client connections network should be enough | 10:46 |
| rogpeppe | ogra_: that's what i thought | 10:47 |
| ogra_ | aks jdstrand once he is up :) | 10:47 |
| rogpeppe | hmm, and now i can't replace the snap because (whenever i do snap install or snap remove) i get 'snap "bhttp" has changes in progress' | 10:50 |
| ogra_ | well, look at snap changes (and "snap change $number" for details) ... | 10:52 |
| rogpeppe | hmm, and that's because i aborted a "remove" operation that seemed to be taking forever. i did "snap abort" and i still can't do "snap remove" | 10:53 |
| ogra_ | iirc you can also "snap abort" | 10:53 |
| ogra_ | give it a bit, it works async ... | 10:53 |
| rogpeppe | ogra_: yeah, i tried that. but "snap remove" takes forever | 10:53 |
| ogra_ | might need some time to time out | 10:53 |
| rogpeppe | ogra_: well, ok, i'll give it a few minutes | 10:53 |
| rogpeppe | ogra_: do you think 5 minutes should be enough? | 10:54 |
| ogra_ | no idea :) | 10:54 |
| stub | I've got a daemon that insists on not being run as root. Should my wrapper create the user and suid to it? Would that actually work? | 10:54 |
| ogra_ | no, it wouldnt | 10:55 |
| ogra_ | snap daemons always run as root | 10:55 |
| rogpeppe | ah, looks like this might be the culprit: Aug 26 11:52:56 snazzy umount[9073]: umount: /snap/bhttp/x1: target is busy | 10:55 |
| ogra_ | are you in there with your shell ? | 10:55 |
| stub | ok, so for now I need to patch unless they have hidden an option in there somewhere to allow it... | 10:56 |
| rogpeppe | ogra_: no, but there's a <defunct> process running the binary | 10:56 |
| ogra_ | ouch | 10:56 |
| ogra_ | stub, i fear so, yeah ... | 10:56 |
| mup | Bug #1617275 opened: the home interface doesn't allow access to $HOME/snap-confine <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1617275> | 10:57 |
| rogpeppe | ogra_: ok, success: i did "kill -9" on the defunct process, then aborted the remove operation and tried again and it worked. | 10:58 |
| rogpeppe | ogra_: not a fantastic user experience though... :) | 10:58 |
| ogra_ | rogpeppe, definitely not, file bugs ;) | 10:58 |
| rogpeppe | ogra_: will do; it'll be the third bug this morning :) | 10:58 |
| ogra_ | i'm at 5 for today :) chase me ;) | 10:59 |
| rogpeppe | ogra_: https://www.google.co.uk/imgres?imgurl=http://t1.gstatic.com/images%3Fq%3Dtbn:ANd9GcTLjo_Nzd7eLrqGEG9ddoRlkUaAV7Q24KziKV2u5i6R-weg4Kgb&imgrefurl=http://books.google.com/books/about/Snappy_Little_Bugs.html%3Fid%3DrC3iGAAACAAJ%26source%3Dkp_cover&h=769&w=621&tbnid=URJ9QWARZ6Uq5M:&tbnh=160&tbnw=129&docid=bPGBY9Q323zj2M&itg=1&usg=__-RYGSWUfDcjgnJL1FRx3M0oDlwI= | 10:59 |
| rogpeppe | ogra_: :) | 11:00 |
| ogra_ | haha | 11:00 |
| rogpeppe | ogra_: https://bugs.launchpad.net/snappy/+bug/1617278 | 11:05 |
| mup | Bug #1617278: remove hung forever due to defunct process <Snappy:New> <https://launchpad.net/bugs/1617278> | 11:05 |
| ogra_ | thx | 11:06 |
| mup | Bug #1617278 opened: remove hung forever due to defunct process <Snappy:New> <https://launchpad.net/bugs/1617278> | 11:06 |
| rogpeppe | ogra_: ok, it seems that only network and network-bind are needed. but what's weird is that the binary won't run at all (even to print a help message) without both of those plugs. | 11:08 |
| ogra_ | i guess your syslog should have some DENIED lines then | 11:09 |
| rogpeppe | ogra_: this is the line i see: | 11:10 |
| rogpeppe | Aug 26 12:10:40 snazzy kernel: [117476.140023] audit: type=1326 audit(1472209840.610:190): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=10082 comm="bhttp" exe="/snap/bhttp/x3/bin/bhttp" sig=31 arch=c000003e syscall=49 compat=0 ip=0x5fbcb4 code=0x0 | 11:11 |
| zyga | rogpeppe: that's bind | 11:11 |
| rogpeppe | zyga: syscall 49? | 11:11 |
| zyga | rogpeppe: it gets killed when it cannot use a syscall it tries | 11:11 |
| zyga | rogpeppe: yes, 49 is bind | 11:11 |
| ogra_ | mvo, seeing https://github.com/snapcore/snapd/pull/1684 ... should we also unseed the package (we explicitly have it in livecd-rootfs currently) | 11:12 |
| mup | PR snapd#1684: many: drop ubuntu-core-snapd-units package, use release.OnClassic instead <Reviewed> <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1684> | 11:12 |
| rogpeppe | zyga: hmm, i wonder why... i wonder if i can make it panic when it does that | 11:12 |
| zyga | rogpeppe: panic? | 11:12 |
| zyga | rogpeppe: you get SIGKILL from the kernel | 11:12 |
| rogpeppe | zyga: also, is it right that the binary should just hang when it does that? | 11:12 |
| zyga | rogpeppe: it kills the offending thread | 11:12 |
| rogpeppe | zyga: hmm, not the whole process? | 11:12 |
| zyga | rogpeppe: depending on the way your program works it will just hang | 11:12 |
| zyga | rogpeppe: nope | 11:12 |
| rogpeppe | zyga: ok, that's probably the reason - it's a go program with multiple threads | 11:13 |
| zyga | rogpeppe: yeah, it's unpredictable what will happen | 11:13 |
| rogpeppe | zyga: any way to configure different behaviour? | 11:13 |
| zyga | rogpeppe: not at present, I believe there's a bug about switching seccomp to return EPERM, we may be able to revive it | 11:14 |
| rogpeppe | zyga: ah, i see now - the Go net package uses bind to probe to see if the kernel has ipv6 functionality | 11:15 |
| zyga | rogpeppe: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001708.html | 11:16 |
| zyga | rogpeppe: that's correct, there's a separate bug about that, I've done the same investigation | 11:16 |
| rogpeppe | zyga: so you can't have *any* Go program that imports /net without allowing the network-bind plug | 11:16 |
| rogpeppe | zyga: i think i'll raise a Go bug about this | 11:17 |
| rogpeppe | ah, there already is a bug: https://github.com/golang/go/issues/16789 | 11:19 |
| zyga | I'm looking for the bug on golang | 11:19 |
| zyga | er | 11:19 |
| zyga | snapd | 11:19 |
| zyga | I cannot find it | 11:20 |
| ogra_ | i think you can work around that by using a wrapper script with exec, so that systemd handles it differently | 11:21 |
| zyga | I'm sorry | 11:21 |
| mup | Bug #1617264 opened: confusing error when installing snap when not logged in <Snappy:New> <https://launchpad.net/bugs/1617264> | 11:30 |
| mattyw | hey folks, the icon guidelines link here is broken: https://developer.ubuntu.com/en/publish/creating-a-good-icon/ | 11:42 |
| mattyw | ^^ where should I report that | 11:42 |
| mattyw | and can anyone tell me what dimension a snaps icon should be? | 11:42 |
| ogra_ | what do you think is broken about it ? | 11:45 |
| ogra_ | (my icons all work fine still) | 11:45 |
| mvo | ogra_: good point about unseeding the scripts bits | 11:48 |
| * ogra_ is happy about every bit he can remove ... :) just working on getting rid of all the partitioning tools and initramfs-tools in ubuntu-core | 11:49 | |
| ogra_ | (well, at least initramfs-tools-ubuntu-core ... seems apparmor has a hard dep on the generic initramfs-tools ) | 11:50 |
| zyga | Chipaca: https://github.com/snapcore/snap-confine/pull/120/files | 11:59 |
| mup | PR snap-confine#120: Fix regression test when re-exec kicks in <Created by zyga> <https://github.com/snapcore/snap-confine/pull/120> | 11:59 |
| zyga | Chipaca: care for a quick review of what we've just discussed? | 11:59 |
| Chipaca | zyga, three things | 12:00 |
| Chipaca | zyga, you're not stopping the .socket | 12:00 |
| Chipaca | zyga, and, you can start/stop n all together in a single line | 12:00 |
| zyga | Chipaca: I'm also not using it though I guess I can just stop it and be on the safe side | 12:00 |
| zyga | oh? | 12:00 |
| zyga | how :) | 12:00 |
| Chipaca | zyga, systemctl stop foo bar baz | 12:00 |
| zyga | ah | 12:00 |
| zyga | thanks, doing that | 12:00 |
| Chipaca | zyga, also also, systemctl stop snapd.{service,socket,refresh.timer} | 12:00 |
| Chipaca | but not sure if the bash these things run in has brace expansion | 12:01 |
| zyga | I've just spelled it out | 12:01 |
| Chipaca | fair | 12:01 |
| zyga | Chipaca: fixed, I also dropped sudo | 12:02 |
| zyga | look again please | 12:02 |
| Chipaca | zyga, question: instead of “umount $(ls -1d /snap/ubuntu-core/* | grep -v current | tail -1)”, wouldn't “ummount /snap/ubuntu-core/$(readlink /snap/ubuntu-core/current)” work? | 12:06 |
| zyga | Chipaca: perhaps, I didn't write this, jdstrand did | 12:07 |
| zyga | Chipaca: I'm happy to improve it when it is green again | 12:07 |
| Chipaca | ah ok | 12:07 |
| Chipaca | zyga, go for it (once green) | 12:08 |
| zyga | thanks | 12:08 |
| rogpeppe | so i seem to have published my snap (https://myapps.developer.ubuntu.com/dev/click-apps/5803/feedback/) but i still can't "snap install" it. anyone know what I'm doing wrong? | 12:09 |
| rogpeppe | is it just that i have to wait for a while for things to happen behind the scenes? | 12:09 |
| zyga | rogpeppe: is that snap published to the stable channel? | 12:10 |
| Chipaca | rogpeppe, what icon does the revision have next to it? a thumbs up, or a green box? | 12:11 |
| === chihchun is now known as chihchun_afk | ||
| rogpeppe | zyga: i think so. (i ran "snap release") | 12:11 |
| rogpeppe | Chipaca: checking | 12:11 |
| rogpeppe | Chipaca: a green box | 12:11 |
| Chipaca | rogpeppe, and what's the snap called? | 12:11 |
| rogpeppe | Chipaca: bhttp | 12:11 |
| Chipaca | rogpeppe, if i can ask :-) | 12:11 |
| rogpeppe | Chipaca: so that URL is personal? | 12:12 |
| Chipaca | rogpeppe, yes | 12:12 |
| rogpeppe | Chipaca: is there a URL for the snap that I can share? | 12:12 |
| Chipaca | i get “You just tried to access a feature which you don't have permission to use.” | 12:12 |
| Chipaca | rogpeppe, what channels is it published to? | 12:13 |
| rogpeppe | Chipaca: i'm not sure where there's a page i can search for snaps | 12:13 |
| rogpeppe | Chipaca: stable | 12:13 |
| Chipaca | rogpeppe, i can confirm it isn't there :-) | 12:13 |
| Chipaca | rogpeppe, I was about to point you at https://snapfui.herokuapp.com/ but it's broken right now :-( | 12:13 |
| Chipaca | beowulf, ^ | 12:13 |
| rogpeppe | Chipaca: what technique did you use to confirm that? | 12:14 |
| ogra_ | uappexplorer :) | 12:14 |
| * rogpeppe googles that | 12:14 | |
| Chipaca | rogpeppe, "snap find bhttp" | 12:14 |
| Chipaca | rogpeppe, is it ARM-only? | 12:14 |
| Chipaca | or i386 or something other than amd64 or all | 12:14 |
| rogpeppe | Chipaca: no, it's amd64-only | 12:14 |
| Chipaca | hmmm | 12:14 |
| rogpeppe | Chipaca: AFAIK | 12:14 |
| rogpeppe | Chipaca: i didn't set any architectures | 12:15 |
| rogpeppe | Chipaca: one mo, i'll send you a screenshot | 12:15 |
| Chipaca | rogpeppe, you could wait until somebody with more access than i takes a look, or you can send me a screenshot :-) | 12:15 |
| ogra_ | rogpeppe, does it have a little green box next to the version in the UI ? | 12:15 |
| Chipaca | rogpeppe, m v o should be able to see things, but he's a busy person | 12:15 |
| Chipaca | ogra_, yep | 12:15 |
| ogra_ | hmm | 12:15 |
| mup | PR snapd#1768 opened: many: automatically restart all-snap devices after os/kernel updates <Created by mvo5> <https://github.com/snapcore/snapd/pull/1768> | 12:17 |
| rogpeppe | Chipaca: http://imgur.com/a/5YksP | 12:17 |
| rogpeppe | it *looks* like it's published to me, but maybe i'm missing some crucial piece of info | 12:18 |
| mattyw | ogra_, hey there, sorry, this is very out of context now, but where you replying to me above? (the broken link) | 12:18 |
| Chipaca | rogpeppe, that should work | 12:19 |
| Chipaca | nessita, are you around? | 12:19 |
| ogra_ | mattyw, oh, i missed you meant a link, i thought you meant the instructions themselves | 12:19 |
| ogra_ | mattyw, not sure where to file it, davidcalle or dholbach might be able to point oyyu to the right place | 12:20 |
| rogpeppe | Chipaca: right, but... you verified that it's not actually there, right? | 12:20 |
| Chipaca | rogpeppe, right | 12:20 |
| Chipaca | rogpeppe, hence me poking nessita | 12:20 |
| rogpeppe | Chipaca: ok, i give up for now. i need to do some actual work :) let me know if you work anything out, please? | 12:20 |
| ogra_ | rogpeppe, if you scroll to the very bottom of the page there is also an "unpublish" button ? | 12:21 |
| nessita | Chipaca, indeed I am | 12:21 |
| rogpeppe | ogra_: you think i should unpublish so that i can try to publish again? | 12:21 |
| Chipaca | nessita, ohi | 12:21 |
| Chipaca | nessita, given http://imgur.com/a/5YksP | 12:22 |
| ogra_ | rogpeppe, no, i just want to know if that button is there | 12:22 |
| rogpeppe | ogra_: yes, it's there | 12:22 |
| Chipaca | nessita, which is https://myapps.developer.ubuntu.com/dev/click-apps/5803/ | 12:22 |
| Chipaca | nessita, what's missing, that snap can't find it? | 12:22 |
| nessita | Chipaca, let me check | 12:22 |
| Chipaca | nessita, thank you | 12:22 |
| nessita | version 0 looks suspicius, but "in paper" shouldn't be an issue | 12:23 |
| * nessita checks more | 12:23 | |
| zyga | tyhicks: https://github.com/snapcore/snap-confine/pull/119 | 12:23 |
| mup | PR snap-confine#119: Make snap mount directory configurable <Created by zyga> <https://github.com/snapcore/snap-confine/pull/119> | 12:23 |
| zyga | tyhicks: I didn't change the apparmor profile yet but I'm about to | 12:23 |
| nessita | Chipaca, not finding anything obvious, but I can't find it in CPI either, debugging more | 12:28 |
| cyphermox | ogra_: I can haz logs? what does it break? | 12:29 |
| cyphermox | the issue is this is hard to fix when I can't upload myself to that PPA and people leave pretty early | 12:30 |
| Saeron | hi guys | 12:32 |
| Saeron | i was looking for ubuntu disk image writer on snap | 12:33 |
| Saeron | there are nor a lot of apps on this repo | 12:33 |
| ogra_ | cyphermox, you got a bunch of bugs ;) | 12:33 |
| Chipaca | Saeron, early days :-) | 12:34 |
| Chipaca | Saeron, it would be a nice one to snap up, i agree | 12:34 |
| Saeron | can someone tell me if anyone can make a snap of this app | 12:34 |
| Saeron | i men ihave to be the developper? | 12:34 |
| Chipaca | Saeron, yes, anyone can make a snap of that app | 12:34 |
| Saeron | the problem is i am not actually using ubuntu | 12:34 |
| Saeron | and i cant find this app on manjara thats what i want a snap for it | 12:35 |
| ogra_ | cyphermox, but in general i think having some tool that adds an additionyl 25MB RAM requirement is not really a good idea, is there no way to do it in ncurses or dialog instead of python3 ? it currently actually doubles our minimal ram reqs. | 12:35 |
| cyphermox | ogra_: there shouldn't be that much; we build images with nearly the same stuff (probably a few revs behind in livecd-rootfs, but that's it) in our PPA with no issues whatsoever | 12:35 |
| cyphermox | no, there isn't. We'll have to see about the RAM usage. I'm shocked that it's as much as you say | 12:36 |
| Saeron | so exits the posibility of a good soul make a snap from this app? | 12:36 |
| ogra_ | cyphermox, on the dragonboard i get two console-conf binaries each occupying 25MB RSS ... i noted that in one of the bugs | 12:36 |
| Chipaca | Saeron, are you looking for the gtk version? | 12:36 |
| Saeron | yes i am looking for the main ubuntu version | 12:37 |
| ogra_ | cyphermox, but thats totally not unusual for python on arm ... it is about 10x slower and eats a lot more ram thgan i.e. C or perl | 12:37 |
| Saeron | Chipaca: yes | 12:37 |
| Chipaca | Saeron, i could snap it, but over the weekend, not now | 12:37 |
| Saeron | Chipaca: its all right, is not at urgent need is just i like a lot dat app and i think is a good one | 12:38 |
| cyphermox | ogra_: where did you open the bugs? | 12:38 |
| Saeron | Chipaca: thx, is gonna be awesome to have dat app on manjaro :) | 12:38 |
| Chipaca | :-) | 12:38 |
| ogra_ | cyphermox, against the snappy project with additional tasks against the subiquity package | 12:38 |
| ogra_ | you should find them all under subiquity | 12:38 |
| Saeron | Chipaca: i hope have time soon for see how to craft this apps | 12:39 |
| Saeron | Chipaca: its really necesary to have ubuntu for do it? | 12:40 |
| Chipaca | Saeron, i don't know about that side of things i'm afraid | 12:40 |
| Chipaca | sergiusens might, if he's around | 12:40 |
| ogra_ | cyphermox, i know that mvo and pitti also did hit other bugs, not sure against what they filed them | 12:40 |
| sergiusens | I am | 12:41 |
| sergiusens | what's up? | 12:41 |
| Chipaca | sergiusens, snapcraft on !ubuntu | 12:41 |
| Chipaca | sergiusens, workie? no workie? | 12:41 |
| sergiusens | Chipaca planned, not there yet | 12:41 |
| Saeron | Chipaca: afraid about what | 12:41 |
| ogra_ | Saeron, he is afraid he doesnt know about it :) | 12:41 |
| Saeron | what? | 12:41 |
| ogra_ | (justa phrase= | 12:42 |
| ogra_ | ) | 12:42 |
| ogra_ | *just a | 12:42 |
| Saeron | are you kidding me ? | 12:42 |
| Chipaca | Saeron, just an expression of apology for not knowing something | 12:42 |
| ogra_ | ? | 12:42 |
| sergiusens | Chipaca the plans we have involve snapd and core work as well; but that was a brainstorm with zyga, probably needs a concrete design | 12:42 |
| Saeron | ok but what you dont know? | 12:42 |
| Chipaca | Saeron, <Chipaca> Saeron, i don't know about that side of things i'm afraid | 12:43 |
| Saeron | about if i can craft snap on othres dist diferents from ubuntu? | 12:43 |
| mup | PR snapcraft#761 opened: Remove dangling symlink from JDK plugin <Created by gnuoy> <https://github.com/snapcore/snapcraft/pull/761> | 12:43 |
| Chipaca | Saeron, means: i don't know | 12:43 |
| Chipaca | Saeron, I then went on to mentions sergiusens was the person to ask about that | 12:43 |
| Chipaca | Saeron, and he has since said that it won't work | 12:43 |
| ogra_ | but that it is planned | 12:43 |
| Chipaca | ogra_, yes. Yes. | 12:43 |
| ogra_ | :) | 12:43 |
| ogra_ | nobody is kidding you ... we just seem to have a communication breakdown :) | 12:44 |
| Saeron | ok xd i dont understand nothing jajajajaja | 12:44 |
| sergiusens | Saeron subscribe to https://bugs.launchpad.net/snapcraft/+bug/1602258 | 12:44 |
| mup | Bug #1602258: Support other distributions as sources (Fedora, Mageia, openSUSE, Debian) instead of Ubuntu <centos> <debian> <fedora> <mageia> <opensuse> <rfe> <rpm> <snapcraft> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1602258> | 12:44 |
| Chipaca | hmmm | 12:44 |
| Saeron | ok now | 12:45 |
| Chipaca | Saeron, from your laugh i suspect spanish would work better | 12:45 |
| sergiusens | indeed ;-) | 12:45 |
| Saeron | there is not suport for others dis | 12:45 |
| Saeron | Chipaca: yeah i am a poor spanish | 12:45 |
| Saeron | Chipaca: dont know a lot about english | 12:46 |
| Chipaca | Saeron, nada de pobre, eh? | 12:46 |
| Saeron | Chipaca: asi que tambien eres español :) | 12:46 |
| Chipaca | Saeron, bueno, eso, que no funciona. Que está planeado, pero en realidad lo que está planeado es planearlo. | 12:47 |
| Saeron | Chipaca: ok bueno si haces el favor de hacer el paquete cuando tengas tiempo | 12:47 |
| Chipaca | Saeron, síp, parece interesante, y el fin de semana es largo para mí \o/ | 12:48 |
| Saeron | Chipaca: no hay prisa, es simplimente lo que mejor me servia para raspberry pi | 12:48 |
| Chipaca | Saeron, perfecto | 12:48 |
| Saeron | Chipaca: a mi se me esta haciendo ya largo con una version de tftop en tcp que tengo que hacer en java | 12:49 |
| ogra_ | Chipaca, if my guessing of that spanish is correct he should be able to use the classic shell on his pi to use snapcraft | 12:49 |
| Chipaca | and now back to your regularly scheduled programme | 12:49 |
| Saeron | Chipaca: :( | 12:49 |
| Chipaca | ogra_, he needs something to write things for the pi, not on the pi | 12:49 |
| * zyga sees spanish everywhere | 12:50 | |
| ogra_ | he can write wherever he wants .. and just build on the pi | 12:50 |
| Saeron | ogra_: mm maybe but i only have raspberry pi 1 so i think i cant | 12:50 |
| Chipaca | zyga, you're hallucinating | 12:50 |
| zyga | Chipaca: must be the coffee | 12:50 |
| zyga | ;-) | 12:50 |
| ogra_ | zyga, nah, it is all german, just with bavarian accent :P | 12:50 |
| Chipaca | zyga, it's the lack of mediterranean sun. | 12:50 |
| Saeron | ogra_: snap is not aviable on rp1 unfortunally :( | 12:50 |
| ogra_ | oh, pi1 | 12:51 |
| ogra_ | yeah, sorry, that wont work | 12:51 |
| zyga | Chipaca: it's surprisingly sunny here; always when holidays run out I guess | 12:51 |
| Chipaca | zyga, hence the qualifier | 12:51 |
| zyga | ogra_: I may learn some german soon, we're planning on visiting friends in dusseldorf | 12:51 |
| * Chipaca -> tea and meetings | 12:51 | |
| * zyga spread and meetings | 12:51 | |
| zyga | and meetings | 12:51 |
| zyga | and hopefully some code after | 12:52 |
| ogra_ | and altbeer :) | 12:52 |
| ogra_ | (regarding düüsseldorf) | 12:52 |
| zyga | oh | 12:52 |
| ogra_ | -ü | 12:52 |
| zyga | I need to package snapd-glib | 12:52 |
| zyga | well | 12:52 |
| zyga | that's easy by now | 12:52 |
| * zyga gets around to do it | 12:52 | |
| ogra_ | it isnt packaged ? | 12:52 |
| ogra_ | i thought it is | 12:53 |
| sergiusens | ogra_ for all distros he means ;-) | 12:54 |
| zyga | ogra_: maybe, I'm checking | 12:56 |
| mup | PR snapd#1769 opened: snap: add export-key --account= option <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1769> | 12:58 |
| ogra_ | sergiusens, ah, i thought for ubuntu | 13:00 |
| mup | PR snapcraft#759 closed: Remove the useless call to os.path.join from the go plugin <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/759> | 13:04 |
| ogra_ | urgh | 13:06 |
| ogra_ | morphis, so i just tried to install the nm snap on my pi3 (which has a perfectly fine configured /e/n/i setup for the wlan0 device already) ... over ssh ... | 13:07 |
| ogra_ | that now locked me out completely | 13:08 |
| ogra_ | why is it killing existing connections like that ? | 13:09 |
| mup | Bug #1617302 opened: Specifying a nonexistent part does cause any errors <Snapcraft:Triaged> <Snappy:New> <https://launchpad.net/bugs/1617302> | 13:19 |
| sborovkov | Hello. How do I keep snap in edge channel up to date? Should I add cron job to call snap refresh --devmode snap-name? | 13:20 |
| ogra_ | sborovkov, on a snappy image ? | 13:21 |
| ogra_ | if the image uses edge as well it will just auto-update | 13:21 |
| sborovkov | ogra_: I have classic image | 13:21 |
| ogra_ | (though --devmode will not autop-refresh i think) | 13:21 |
| ogra_ | ah, k | 13:21 |
| ogra_ | there i dont know then | 13:21 |
| sborovkov | Yes, that's why I was thinking what should I do. Considering that I need to specify both --devmode and snap's name to get it to refresh | 13:22 |
| ogra_ | yeah, i guess for --devmode there is no way around that | 13:22 |
| ogra_ | edge on an image that knows about edge wouldnt be a prob | 13:22 |
| ogra_ | hmm | 13:23 |
| sborovkov | Do you know if there is some recommended mechanism to make it so that snap login does not expire? | 13:23 |
| ogra_ | ppisati_, did you actually notice that since we moved the dtb on the pi3 so high in ram you cant actually boot with mem= anymore ? | 13:23 |
| ppisati_ | ogra_: uhm nope | 13:24 |
| ppisati_ | ogra_: you mean to reduce the visible memory? | 13:24 |
| ogra_ | yeah | 13:24 |
| ppisati_ | nope | 13:24 |
| ogra_ | seems it reduces enough to also hide the dtb | 13:24 |
| ogra_ | my kernel just hangs | 13:24 |
| ppisati_ | i have vague memoris of faffing with that options | 13:25 |
| ppisati_ | *memoris | 13:25 |
| ppisati_ | and i remember i disoverd way it hanged when reducing the visible memory | 13:25 |
| ppisati_ | but it was long ago | 13:26 |
| ogra_ | hmm, even hangs with mem=1024m | 13:26 |
| ppisati_ | and i'm not even sure it was the raspi board | 13:26 |
| ogra_ | which shoudl actually be more than the board has (944) | 13:26 |
| ogra_ | probably not related to the dtb position then | 13:26 |
| ppisati_ | i wonder if the fw has anything to do with it | 13:27 |
| ppisati_ | since the dtb, usually, has an empty memory field | 13:27 |
| ppisati_ | and it's a task of uboot to fill that field | 13:27 |
| ogra_ | well, theer are also various gpu defaults that might kick in | 13:28 |
| ppisati_ | right | 13:28 |
| ppisati_ | and then we take a slice for the gpu too | 13:28 |
| mup | Bug #1617314 opened: Cannot run daemons as non-root <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1617314> | 13:28 |
| ogra_ | yeah | 13:28 |
| ogra_ | so i guess it isnt a good system to try out differenmt ram sizes | 13:28 |
| ppisati_ | uhm nope | 13:29 |
| ogra_ | i know i was abnle to boot 15.04 on the BBB with mem=64m ... wanted to try out how the 16 images behave in that regard | 13:29 |
| ogra_ | but i guess i'd need a BBB image to actualyl do that (dragon is arm64 so not really representative) | 13:30 |
| ppisati_ | probably yes | 13:30 |
| smoser | so these failures here: https://code.launchpad.net/~smoser/+snap/azure-cli | 13:33 |
| smoser | thats simply "builders do not have internet access" right ? | 13:34 |
| smoser | am i missing somethign? or does that kind of mean that some large percent of the snapcraft.yaml that people would create will not work there. | 13:34 |
| morphis | ogra_: because nm currently doesn't take care of any connections defined in /etc/network/interfaces.d | 13:47 |
| morphis | only about those which are in /etc/network/interfaces | 13:47 |
| morphis | whoever introduced interfaces.d didn't adjust nm for this | 13:47 |
| morphis | we have a patch for that pending | 13:47 |
| ogra_ | morphis, well, it would be nice if it could simply check for a default route and not kill existing connections | 13:47 |
| morphis | but normally it should ignore all interface which are configured by ifupdown | 13:48 |
| ogra_ | i dont care if it trashes my /e/n/i setup as long as it doesnt lock me out out of the blue | 13:48 |
| morphis | ogra_: in this case it takes control over wlan0 completely as it doesn't see its already managed by ifupdown | 13:48 |
| morphis | ogra_: how should I do that if it does not have any provisioning information for that interface? | 13:48 |
| ogra_ | i.e. how would i switch over to nm on a remote device | 13:48 |
| morphis | what do you mean by that? | 13:49 |
| ogra_ | morphis, by looking for a default route | 13:49 |
| ogra_ | morphis, i would expect nm to not touch anything until i configured it ... simply installing the package should not kill my existing connection | 13:49 |
| ogra_ | it shoudl notice there is a default route added to an interface ... and leave that interface alone until i tell it to use it | 13:50 |
| morphis | afaik that makes things quite more complex, nm is supposed to be a network manager which is installed by default | 13:50 |
| ogra_ | it would even be fine if it already trashed my /e/n/i setup (and tells me it did) but doesnt ifdown the device | 13:50 |
| morphis | ogra_: it shouldn't trash your ifupdown setup | 13:51 |
| morphis | it should just ignore those interfaces ifupdown has under its control | 13:51 |
| morphis | it then gives metrics to the various routes | 13:51 |
| pstolowski | kyrofa, hey, can you ping me when you're back and have a moment for HO? i'd like to talk about snapctl | 13:52 |
| nessita | rogpeppe, hi, I'm debugging the issue with bhttp, would you give me some detils about how you uploaded the snap to the store? was it manually, with snapcraft, or LP? | 13:53 |
| rogpeppe | nessita: with snapcraft | 13:53 |
| nessita | rogpeppe, did you also release the revno with it? (so I can try to reproduce) | 13:54 |
| rogpeppe | nessita: what does "release the revno" mean? | 13:54 |
| ogra_ | morphis, well, i obviously installed nm to make use of it ... but doing that via ssh simply deconfigures the device during package install | 13:54 |
| nessita | rogpeppe, with snapcraft you first build the snap and push it to the store, and then you decide to release a revno to a given channel (release == publish) | 13:54 |
| ogra_ | (to make use of it = i dont care about /e/n/i anymore) | 13:55 |
| ogra_ | morphis, what makes you think an oem would pre-install nm | 13:55 |
| morphis | ogra_: as said, if a device is configured via ifupdown it should be ignore, that it isn't as of today is a bug and will be fixed | 13:56 |
| ogra_ | morphis, if i'm that hypothetical lawnmower manufacturer and have 500MB diskspace for OS and apps on that lawnmower, i surely dont want a 25MB nm package installed (25MB that i cant use for my autopilot app then) | 13:56 |
| rogpeppe | nessita: i ran: snapcraft release bhttp 2 stable | 13:56 |
| morphis | ogra_: second thing is taking over a network device which isn't configured by ifupdwon but manually by the other | 13:56 |
| ogra_ | morphis, well, it shouldnt matter how the device was configured before ... all that should matter is that it is actively in use (default route) | 13:57 |
| morphis | that is a different story and the easiest you can do is to reset the device to make sure you take it over in a well known state | 13:57 |
| ogra_ | right, so i send out a technician to hit the reset button ;) | 13:57 |
| tyhicks | zyga: why does the snap mount dir need to be configurable? | 13:58 |
| morphis | ogra_: so we over two (or three) ways today to configure network, netplan, ifupdown and nm | 13:58 |
| morphis | all play together and all three is what you can use as a manufacturer | 13:58 |
| smoser | anyone able to comment on my question above ? basically snap building on launchpad wont work unless everything comes from the repo or the ubuntu archive (or i guess a ppa) right ? | 13:58 |
| ogra_ | morphis, right, this isnt about how it was configured ... only about what is currently in use | 13:58 |
| morphis | ogra_: if you go and build your own you're off and it gets harder to support all of these | 13:59 |
| morphis | ogra_: yeah and it takes only ifupdown as indicator for that right now | 13:59 |
| zyga | tyhicks: because some distributions will use a different location | 13:59 |
| zyga | tyhicks: I've just updated the pull request to adjust apparmor profile (there's almost no change in practice) | 14:00 |
| morphis | ogra_: what should we then do with such a device in nm? | 14:00 |
| zyga | tyhicks: similar changes are almost ready for snapd | 14:00 |
| morphis | mark it as unmanaged? | 14:00 |
| zyga | tyhicks: https://github.com/snapcore/snap-confine/pull/119/commits/c77ce3d7e521b93a2375bbad5019338bb176f9cc is the new thing | 14:00 |
| mup | PR snap-confine#119: Make snap mount directory configurable <Created by zyga> <https://github.com/snapcore/snap-confine/pull/119> | 14:00 |
| mup | Bug #1598225 changed: htop unable to send signals to other processes <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1598225> | 14:01 |
| nessita | rogpeppe, thanks | 14:02 |
| * zyga lunch | 14:02 | |
| morphis | ogra_: size is a thing which matters for sure, there are some parts we can still optimize to reduce the footprint of the snap | 14:02 |
| morphis | but in the end Ubuntu chose NetworkManager which hasn't the smallest footprint and isn't made for this | 14:02 |
| === JanC is now known as Guest12120 | ||
| === JanC_ is now known as JanC | ||
| tyhicks | jdstrand: thanks for reviewing the profile changes | 14:03 |
| morphis | then you want connman or just ifupdwon | 14:03 |
| tyhicks | jdstrand: I already reviewed the code changes | 14:03 |
| tyhicks | I'll leave a comment | 14:03 |
| ogra_ | morphis, i installed nm to configure it with nm ... but i cant because nm locked me out on package install | 14:03 |
| ogra_ | my point is that it should respect that the device is in use ... i will most likely want to then set up an nm config (because i installed the package) and reboot | 14:03 |
| ogra_ | so what did configure the device before doesnt really matter ... that i cant configure nm now does though | 14:03 |
| ogra_ | morphis, well, add a check for the default route to the systemd start script ... and make sure to not tear down the device if the default route points to it | 14:04 |
| mup | Bug #1586547 changed: allow browsers to use user namespaces in its sandbox <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1586547> | 14:04 |
| morphis | ogra_: so you configured the device with ifupdown before? | 14:04 |
| ogra_ | morphis, well, i perfer using /e/n/i or wpa-supplicant directly, so i dont waste ram and diskspace (this isnt only about the 25MB disk but also about eating system resources) | 14:05 |
| morphis | sure | 14:05 |
| ogra_ | morphis, yeah ... but it shouldnt matter how it was configured | 14:05 |
| ogra_ | sint i just installled a tool that i will likely use in the future to configure it | 14:05 |
| ogra_ | *since | 14:06 |
| ogra_ | so the past shouldnt be taken into account ... if i install nm it is fine to assume i want to configure my devices with it ... what matters is the present | 14:06 |
| ogra_ | since i can snap install nm via ssh | 14:06 |
| mup | Bug #1596717 changed: please add getsockopt to pulseaudio interface <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1596717> | 14:07 |
| mup | Bug #1600085 changed: interface for making bpf syscalls <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1600085> | 14:07 |
| mup | Bug #1605768 changed: incomplete 'opengl' interface <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1605768> | 14:07 |
| morphis | ogra_: can you file a bug agaisnt https://bugs.launchpad.net/snappy-hwe-snaps ? | 14:07 |
| ogra_ | will do | 14:08 |
| morphis | awe: can we easily tell network-manager to not reset a network device a default route is configured for when its first started? | 14:10 |
| awe | morphis, ?; can you give me some more context? | 14:10 |
| morphis | ogra_ describes his use case: he has a network device configured and a default route set | 14:11 |
| awe | configured by...? | 14:11 |
| morphis | now he installs the nm snap which removes all routes + interface configuration on first start | 14:11 |
| awe | nm? | 14:11 |
| morphis | awe: manual | 14:11 |
| awe | or cloud-init/ifupdown | 14:11 |
| awe | totally manual? | 14:11 |
| awe | as in no eni or eni.d iface? | 14:12 |
| morphis | if it would be ifupdown it should be ignored but isn't right now due to us not respecting e/n/interfaces.d/ | 14:12 |
| awe | right; s16? | 14:12 |
| morphis | awe: or phrase it like this: should be ignore whenever it is not configure by ifupdwon or nm itself | 14:12 |
| morphis | awe: yes | 14:12 |
| awe | if so, doesn't your new snap fix? | 14:12 |
| morphis | awe: it does and it would ogra_ problem | 14:13 |
| morphis | but he worries that this will be a problem for people who may configure their interfaces manually and then lock themself out | 14:13 |
| mup | Bug #1603113 changed: add fuse filesystem interface <lxd> <snapd-interface> <Snappy:Fix Released by stgraber> <https://launchpad.net/bugs/1603113> | 14:13 |
| morphis | which should be a very small number as everything is meant to be ifupdown/netplan in the default ubuntu core images | 14:14 |
| ogra_ | apw, morphis bug 1617344 | 14:14 |
| mup | Bug #1617344: snap install of network-manager should not tear down the device holding the default route <snappy-hwe-snaps:New> <https://launchpad.net/bugs/1617344> | 14:14 |
| ogra_ | awe, it shouldnt matter how the device was configured (could be some shell script i put in place myself that called "ifconfig up" and dhclient) ... it should just not kill my current ssh connection | 14:16 |
| ogra_ | awe, so that i have a chance to put an nm confiig in place after i installed the nm package ;) | 14:16 |
| awe | well.... that's what you get for mixing a manually configured device with a daemon that wants to own everything | 14:16 |
| mup | Bug #1583371 changed: GPIO interface request <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1583371> | 14:16 |
| awe | let me give some thought to how we can address this... | 14:17 |
| ogra_ | awe, just make the nm syystemd job chec for the default route and do not touch the device til there is an nm config for it i guess | 14:17 |
| awe | did you add an iface into e/n/i.d? | 14:17 |
| morphis | ogra_: that would be a little bit of a hack as you still want nm to take over control when its configured correctly | 14:18 |
| morphis | awe: he did | 14:18 |
| awe | then why don't we just add ssweeny's patch? | 14:18 |
| morphis | yes | 14:18 |
| awe | doens't that solve the problem? | 14:18 |
| morphis | not in ogra's eyes :-) | 14:18 |
| ogra_ | awe, yes, thats the current default recommendation, using /e/n/i.d/wlan0 ... | 14:18 |
| morphis | he says we should ignore the device regardless of it was configured when it provides the current default route | 14:18 |
| ogra_ | awe, all i want it that i'm not locked out of the device just because i installed a package :) | 14:19 |
| morphis | ogra_: first of all if you install a network-manager you should know what you do | 14:19 |
| ogra_ | right, i just dont want to have my ssh connection killed when installing NM | 14:19 |
| morphis | its quite a fundamental thing for a system | 14:19 |
| awe | ogra_, we're sitting on a patch that fixes the problem | 14:19 |
| morphis | ogra_: and you wouldn't when its properly configured with ifupdwon | 14:19 |
| awe | not sure why we'd want to do anything different? | 14:20 |
| ogra_ | awe, good then | 14:20 |
| morphis | ogra_: so securing the remaining 1% of use cases where the user configured the device manually sounds a bit like overhead | 14:20 |
| awe | +1 | 14:20 |
| ogra_ | morphis, well, i perhaps (or rather most likely) installed nm to manage the device with nm in the future | 14:20 |
| ogra_ | and perhaps my device sits on a pole in the arctic sea | 14:20 |
| morphis | ogra_: but then you should have configured it properly with ifupdown | 14:21 |
| awe | ogra_, people are going to use netplan or cloud-init | 14:21 |
| ogra_ | when the device gets killed by the package install i have no way to actually put any nm config in place | 14:21 |
| awe | if they device in the north pole | 14:21 |
| awe | and they configure manually | 14:21 |
| ogra_ | awe, how do you knwo ? | 14:21 |
| awe | and then install NM blindly without having tested it first... | 14:21 |
| awe | welll | 14:21 |
| morphis | they shoot themself off IMHO | 14:21 |
| awe | yup | 14:22 |
| morphis | we can't prevent them from running "sudo shutdown -h now" as well | 14:22 |
| awe | I suppose the other thing we could consider | 14:22 |
| ogra_ | awe, imagine i'm an OEM with a 233MHz/128MB device that runs on solar power to measure sea temp ... and i use ubuntu-iage to roll myown very minimal image | 14:22 |
| awe | and you're not going to stage your software first? | 14:22 |
| awe | and test? | 14:22 |
| ogra_ | i do stage my software ... and i do test it ... it worked and i installed it on that pole | 14:23 |
| ogra_ | now someone comes along and tells me i should rather use nm even though that eats my resources ... | 14:23 |
| mup | PR snapd#1710 closed: tests: add content-shareing binary test that excersises snap-confine <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1710> | 14:23 |
| ogra_ | so i ssh into the device, notice there is actually enough space to use nm (yay) ... and install nm | 14:23 |
| ogra_ | *boom* | 14:23 |
| awe | ogra_, is there a way to install a snap and have a job disabled upon install? | 14:23 |
| morphis | no | 14:23 |
| ogra_ | i have to find a ship that goes to my pole to reset the device | 14:24 |
| morphis | you wouldn't do such a critical operation on a production device | 14:24 |
| awe | exactly | 14:24 |
| awe | that's what I keep saying | 14:24 |
| morphis | without testing and having the gurantee it works | 14:24 |
| ogra_ | awe, no, and why would you | 14:24 |
| awe | this would be a good case for it, no? | 14:24 |
| ogra_ | all i want is that my current connection doesnt get orn down out of the blue | 14:24 |
| ssweeny | jdstrand, zyga, so I'm back to this mount namespace thing. I got debug output from snap-confine by changing the daemon to a command and running it from a shell. Here's the output: https://paste.ubuntu.com/23093357/ | 14:24 |
| ogra_ | *torn | 14:24 |
| ssweeny | jdstrand, zyga, I'm still not seeing the mounts outside of the snap though | 14:24 |
| awe | ogra_, you want to hop on #nm and discuss? | 14:24 |
| morphis | ogra_: it does not if you have it configured properly with ifupdwon | 14:25 |
| ogra_ | being locked out of a device just because you install some package is evil | 14:25 |
| ogra_ | we should prevent that | 14:25 |
| morphis | ogra_: but you would discover in your testing that this is broken and wouldn't do it | 14:25 |
| ogra_ | i.e. look at ubuntu server ... if you upgrade ssh it will *never ever* kill your current sshd | 14:25 |
| ogra_ | and snap should not behave different in that regard | 14:25 |
| ogra_ | no matter what package i install | 14:26 |
| morphis | ogra_: we support that use case very well (if that single bug is fixed I mentioned before) | 14:27 |
| nessita | Chipaca, rogpeppe bhttp is now available, we are still troubleshooting but we re-publihs it to unblock you | 14:27 |
| awe | ogra_, I still think the right way to do this would be so have NM installed in a state where it's idle, until enabled | 14:27 |
| ogra_ | morphis, well, thats fine then | 14:27 |
| awe | I honestly don't think playing around with the code that handles the routing table for a case where someone's manually configured their device is correct | 14:28 |
| ogra_ | awe, whatever keeps my sshd alive is fine :) i dont care how it is solved | 14:28 |
| awe | as morphis said, in 99.99% of the cases, cloud-init or netplan will be used, and NM will stay from any devices configured via those | 14:28 |
| ogra_ | locking people out of thir devices is just wrong ... thats the core point here | 14:28 |
| awe | in this, the person has locked themselves out | 14:29 |
| ogra_ | awe, i suspect most peope doing actual embedded stuff will not want to use NM | 14:29 |
| awe | they were flying without a net | 14:29 |
| awe | I agree | 14:29 |
| ogra_ | since your resources are precious on such HW | 14:29 |
| morphis | ogra_: and we support that for 99% percent of the use cases and the remaining 1% should be discovered in testing before deploying such a fundamental change in a critical production environment | 14:29 |
| awe | that said, I definitely could see a need for being able to specify that a service is disabled by default upon install | 14:30 |
| ogra_ | morphis, well, you never know what weird manager takes over that sea tem measuring project ... and what insane orders he gives to devs ;) | 14:30 |
| ogra_ | *sea temp | 14:30 |
| awe | to allow the service to be *configured* before it's used | 14:30 |
| morphis | ogra_: then he is responsible | 14:30 |
| sergiusens | smoser we have an open bug for that launchpad issue (pull/build with or without internet access for the latter step) | 14:31 |
| morphis | awe: sure that is another use case we could support but that would require some features we don't have in snapd yet | 14:31 |
| ogra_ | morphis, doesnt matter ... before he gets fired he gives a bunch of interviews telling the press how badly ubuntu snappy sucks ;) | 14:31 |
| awe | agreed, I'm just saying that's the way I'd handle this | 14:31 |
| ogra_ | awe, and i agree ... we should have a way to handle initial state for systemd units | 14:32 |
| ogra_ | but we dont atm | 14:32 |
| morphis | ogra_: but somebody could say similar if ubuntu core doesn't prevent you from stopping the machine with "sudo shutdown -h now" on critical machines | 14:32 |
| sergiusens | smoser if cjwatson gets his way we need to build in pull, I am not against that as I was before as that pull will only ""build"" your deps and not your actual referred to source | 14:32 |
| smoser | sergiusens, i went asking in launchpad, and cjwatson said | 14:33 |
| ogra_ | morphis, indeed :) | 14:33 |
| smoser | <cjwatson> Builders have internet access but only during the pull phase. | 14:33 |
| smoser | <cjwatson> ... which is the case here. | 14:33 |
| smoser | <cjwatson> There's a known but undiagnosed problem with npm. | 14:33 |
| smoser | <cjwatson> https://bugs.launchpad.net/launchpad-buildd/+bug/1588870 | 14:33 |
| mup | Bug #1588870: npm doesn't seem to use snap proxy <lp-snappy> <launchpad-buildd:Triaged> <https://launchpad.net/bugs/1588870> | 14:33 |
| awe | ogra_, patches welcome... but as mentioned, this probably should be discussed with upstream | 14:33 |
| awe | you could do the same thing with the deb pkg | 14:33 |
| ogra_ | does that kill my running interface ? | 14:34 |
| morphis | ogra_: I am not against adding sth in nm to ignore already configured devices but I have the feeling that the effort to implement this (which could be very tricky) isn't worth it | 14:34 |
| ogra_ | i dont think it does | 14:34 |
| morphis | ogra_: if it is configured with ifupdwon the deb doesn't :-) | 14:34 |
| awe | it's the same code ogra_ | 14:34 |
| morphis | but if it is configured manually it will for sure | 14:34 |
| ogra_ | morphis, well, whatever the solution is, as long as my ssh connection persistst i'm all fine | 14:34 |
| awe | just in a deb instead of a snap | 14:35 |
| ogra_ | awe, same systemd unity ? | 14:35 |
| morphis | ogra_: ok, then lets ignore the 1% and concentrate on the 99% | 14:35 |
| ogra_ | *unit | 14:35 |
| awe | ogra_, NM wants to own all of the networking on a device | 14:35 |
| awe | unless it's explicitly told otherwise | 14:35 |
| morphis | ogra_: in gernal yes | 14:35 |
| awe | again... if you really want this fixed, then hop on #nm with me, and we can discuss there | 14:36 |
| awe | but I agree with morphis | 14:36 |
| ogra_ | hmm, so if i'd install ubuntu-desktop+rdesktop remotely on a cloud instance that would kill the cloud instance networking ? | 14:36 |
| * ogra_ doubts thats ture | 14:36 | |
| ogra_ | *true | 14:36 |
| morphis | ogra_: if you install the nm deb package no matter where, it will take over all not by ifupdown managed network devices | 14:38 |
| sergiusens | smoser yeah, doing all that in `pull` would make your build/install twice (go through it). It is what we do with the python plugins today | 14:38 |
| smoser | sergiusens, so is that an easy snapcraft.yaml config change that i can make to try ? | 14:39 |
| ogra_ | morphis, ah, in that case thats probably the ifupdown setup that prevents it from doing that in the cloud | 14:39 |
| morphis | ogra_: yes | 14:39 |
| ogra_ | and that patch you guys talked about will actually add that feature to the snap ? | 14:40 |
| morphis | it will | 14:40 |
| ogra_ | well, then all is fine | 14:40 |
| morphis | ogra_: or said differently, I suspect nm on the desktop has the same problem with /etc/network/interfaces.d as the snap has | 14:40 |
| morphis | as this isn't fixed anywhere yet | 14:41 |
| rogpeppe | nessita: ok, thanks | 14:41 |
| rogpeppe | nessita: do you know what might've gone wrong? | 14:41 |
| morphis | ogra_: even not in the deb packages we have nor upstream | 14:41 |
| nessita | rogpeppe, nothing is standing out, we are now trying to reproduce the same flow you used to see if we have a bug | 14:42 |
| nessita | rogpeppe, also, we are adding more logging because we noticed we need some more for cases like this (ie no errors but still log when publishing ocurrs) | 14:42 |
| ogra_ | morphis, well, i remember when asac maintained NM it never touched ifupdown devices | 14:43 |
| ogra_ | due to a distro patch though | 14:43 |
| ogra_ | and thats is years ago | 14:43 |
| zyga | jdstrand: hey | 14:43 |
| zyga | jdstrand: I've updated the milestones on launchpad so that snapd 2.12, .13 and .14 exist | 14:43 |
| ogra_ | it has definitely been cpable of that for quite a while | 14:44 |
| ogra_ | *capable | 14:44 |
| zyga | jdstrand: and .12 although released, can be used as a bug target | 14:44 |
| zyga | jdstrand: when you update bugs like you did just now would you mind also flipping the milestone to include this information | 14:44 |
| morphis | ogra_: it ignores /etc/network/interfaces, yes | 14:44 |
| ogra_ | right | 14:44 |
| morphis | ogra_: but not interfaces.d | 14:44 |
| zyga | jdstrand: this is very useful for looking at changes per whole milestone | 14:44 |
| ogra_ | ah ! | 14:44 |
| morphis | ogra_: not sure when this was introduced but nobody added support for that in nm | 14:44 |
| morphis | and that is what we're fixing | 14:45 |
| ogra_ | i think i.d exists forever (years for sure) but hasnt been widely used | 14:46 |
| zyga | is robert ancell somewhere far away from europe, timezone-wise? | 14:47 |
| ogra_ | zyga, only australia ... not that far | 14:47 |
| zyga | ah | 14:47 |
| ogra_ | (could be worse ... like .nz) | 14:47 |
| zyga | ok, I'll just talk to him later tonight | 14:47 |
| zyga | er. wait, it's Friday | 14:48 |
| ogra_ | he | 14:48 |
| zyga | well, on Sunday then | 14:48 |
| morphis | ogra_: maybe that is the reason why :-) | 14:50 |
| ogra_ | yeah :) | 14:50 |
| * ogra_ hugs morphis and awe | 14:51 | |
| morphis | :-) | 14:51 |
| sergiusens | smoser it is not in snapcraft.yaml where the change is needed but the plugins instead | 15:14 |
| cjwatson | sergiusens: the logs suggest that npm *is* being called in pull though | 15:20 |
| cjwatson | oh, no | 15:20 |
| smoser | bah. | 15:20 |
| smoser | ok. so 2 changes needed. | 15:20 |
| cjwatson | I must have misread it | 15:20 |
| smoser | so.. i have figured it out. | 15:21 |
| cjwatson | sergiusens is right, it's just about moving the dep install into the pull phase | 15:21 |
| smoser | as documented npm pays attention to HTTP_PROXY and HTTPS_PROXY as it says | 15:21 |
| smoser | that i simply not true | 15:21 |
| smoser | however, you can make it care with --proxy= and --http-proxy= | 15:21 |
| smoser | so i'm looking at a change to the nodejs plugin that will add --proxy= and --http-proxy= according to environment variables | 15:22 |
| sergiusens | smoser it is really not a proxy problem; network is disabled for `build` from launchpad itself | 15:22 |
| smoser | sergiusens, sure, but it doesnt read proxy anyway | 15:22 |
| smoser | so moving it to another stage doesn't fix it unless you make it respect proxy, right? | 15:23 |
| sergiusens | smoser npm is supposed to read http_proxy and https_proxy | 15:23 |
| smoser | or do they have un-fettered access to internet in pull | 15:23 |
| smoser | sergiusens, yes. it is documented as doing so | 15:23 |
| smoser | it does not | 15:23 |
| sergiusens | elopio ^ maybe reopen the PR | 15:24 |
| zyga | Pharaoh_Atem: does this look okay? https://github.com/snapcore/snap-confine/pull/121 | 15:24 |
| mup | PR snap-confine#121: Allow the use of capabilities over setuid bit <Created by zyga> <https://github.com/snapcore/snap-confine/pull/121> | 15:24 |
| bulldog | hi everyone once again am here :D | 15:24 |
| Pharaoh_Atem | zyga: LGTM | 15:25 |
| bulldog | with updates on snapcraft-gui :P | 15:25 |
| zyga | Pharaoh_Atem: will setcap be a problem for fedora's %install target? | 15:25 |
| zyga | Pharaoh_Atem: I suspect it runs under some sort of fakeroot but I'm not sure | 15:25 |
| zyga | (does it?) | 15:25 |
| elopio | smoser: sergiusens: the problem seems to be when http_proxy is http:// and https_proxy is https:// | 15:26 |
| bulldog | check out https://github.com/keshavbhatt/snapcraft-gui | 15:26 |
| Pharaoh_Atem | rpm runs chroot() for all actions, including building packages, I believe | 15:26 |
| elopio | smoser: have you seen https://bugs.launchpad.net/snapcraft/+bug/1611372 ? | 15:26 |
| mup | Bug #1611372: add proxy support for nodejs plugin <Snapcraft:Invalid> <https://launchpad.net/bugs/1611372> | 15:26 |
| zyga | chroot is one thing, does it run as root so that setcaps can run | 15:26 |
| * zyga just goes to try | 15:26 | |
| Pharaoh_Atem | zyga: though the best place to ask these things is in #rpm.org | 15:26 |
| zyga | ok | 15:26 |
| Pharaoh_Atem | zyga: you'll need libcap as a BR though | 15:28 |
| Pharaoh_Atem | err | 15:28 |
| Pharaoh_Atem | zyga: you'll need /usr/bin/setcap | 15:29 |
| Pharaoh_Atem | as a BR | 15:29 |
| Pharaoh_Atem | fuck | 15:29 |
| Pharaoh_Atem | it's /usr/sbin/setcap | 15:29 |
| smoser | elopio, hm.. | 15:30 |
| zyga | as BR? | 15:30 |
| smoser | my path was not goign to be to set config ('npm config') | 15:30 |
| zyga | build requires? | 15:30 |
| zyga | that's okay, that's easy | 15:30 |
| smoser | but to set flags on the npm install line | 15:30 |
| smoser | npm install --proxy= --https-proxy= | 15:31 |
| smoser | which works | 15:31 |
| zyga | Pharaoh_Atem: I'm about to call it a day, I will do a .41 soon and with .14 around the corner (of snapd) we should have all the we need | 15:32 |
| zyga | Pharaoh_Atem: over weekend I'll look at selinux for the socket | 15:32 |
| zyga | and maybe more :) | 15:32 |
| zyga | Pharaoh_Atem: I'm going to break and spend some time with my family, I'll grab you next week :) | 15:33 |
| zyga | have a good weekend everyone! | 15:33 |
| Pharaoh_Atem | bye | 15:33 |
| smoser | hm.. | 15:33 |
| zyga | tyhicks: https://github.com/snapcore/snap-confine/pull/121 | 15:33 |
| mup | PR snap-confine#121: Allow the use of capabilities over setuid bit <Created by zyga> <https://github.com/snapcore/snap-confine/pull/121> | 15:33 |
| Pharaoh_Atem | zyga: it'd be awesome if you could get the alternate path stuff done today | 15:33 |
| zyga | Pharaoh_Atem: for snap-confine it is ready upstream, for snapd it was (sans test) for a while | 15:33 |
| barry | anybody know what this problem is: | 15:36 |
| barry | $ sudo snap install hello-world | 15:36 |
| barry | $ hello-world | 15:36 |
| barry | multiple nvidia drivers detected, this is not supported | 15:36 |
| barry | 15:36 | |
| barry | can't check bugs because launchpad.net/snappy is timing out for me | 15:36 |
| nacc | barry: there's a bug for that | 15:37 |
| zyga | barry: I do | 15:37 |
| zyga | barry: yes, one sec | 15:37 |
| barry | cool, thx | 15:37 |
| zyga | barry: https://bugs.launchpad.net/snap-confine | 15:37 |
| zyga | barry: ideas welcome | 15:37 |
| zyga | barry: if you come up with something simple it will be fixed in the next release | 15:37 |
| * barry looks | 15:38 | |
| zyga | oh alberto suggested an idea | 15:38 |
| nacc | https://bugs.launchpad.net/snap-confine/+bug/1615248 this one? | 15:38 |
| mup | Bug #1615248: ubuntu-core-launcher nvidia driver detection is bogus <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1615248> | 15:38 |
| zyga | sound like a plan if security agrees with it :) | 15:38 |
| zyga | tyhicks: can you please also look at https://bugs.launchpad.net/snap-confine/+bug/1615248 and tell me if looking at /sys/module/nvidia/version can be used as a way to know which driver to bind mount | 15:39 |
| zyga | tyhicks: if so I can easily do that | 15:39 |
| zyga | barry: as a workaround, purge unused drivers | 15:39 |
| zyga | barry: sorry! | 15:39 |
| barry | zyga: thanks, will try that | 15:40 |
| nacc | zyga: why does u-c-l care about nvidia drivers? just for context | 15:40 |
| zyga | nacc: because world is terrible and it has to | 15:41 |
| zyga | nacc: and for real... | 15:41 |
| zyga | nacc: because on classic there is no kernel snap so no nvidia modules or userspace so we have to take them from the classic world | 15:41 |
| zyga | nacc: so snap-confine has logic to find and bind mount the driver | 15:41 |
| zyga | nacc: into the snap execution environment | 15:41 |
| zyga | nacc: there's a different version of that for ubuntu and for arch, so far no other distro is supported | 15:42 |
| nacc | zyga: ah! | 15:42 |
| zyga | nacc: and they differ quite widely because of how packaging there works | 15:42 |
| nacc | zyga: sure, it was just a surprising bug to my naive view of what u-c-l woudl care about :) | 15:42 |
| zyga | nacc: and also among driver versions (nvidia switched to libglvnd or whatever that name is GL vendor) later | 15:42 |
| zyga | nacc: well, surprise ;) | 15:42 |
| zyga | nacc: I wish I had nvidia GPU with recent drivers to test | 15:43 |
| * zyga has to order and expense GTX 960 | 15:43 | |
| bulldog | how to browse all snap packages availble in store | 15:43 |
| elopio | kyrofa: can I interest you in https://bugs.launchpad.net/snapcraft/+bug/1615242 ? | 15:45 |
| mup | Bug #1615242: etcd tree drives snapcraft dump plugin insane <Snapcraft:Confirmed> <https://launchpad.net/bugs/1615242> | 15:45 |
| barry | zyga, nacc i followed up on the bug. i'm going to try to purge the old drivers and reboot. if i come back then at least i'll know that wasn't a horrible idea ;) | 15:47 |
| elopio | smoser: so npm install --proxy=http://... --https-proxy=https://... works ? | 15:47 |
| bulldog | snap find wont load all packages :( | 15:47 |
| elopio | if so, that looks better than the other solution. | 15:47 |
| ogra_ | zyga, barry, well, long term the nvidia driver should really stop leaving cruft behind :) | 15:48 |
| barry | ogra_: of course! ;) | 15:48 |
| ogra_ | that seems to go on since multiple releases ... | 15:49 |
| bulldog | ogra_, how to browse all snap packages available in store any idea ?? snap find not working | 15:49 |
| barry | btw, i'm not sure this will solve the problem because i think i'll still be left with nvidia-367 and nvidia-367-prime | 15:49 |
| ogra_ | bulldog, no idea, all i know is that it was disabled | 15:49 |
| ogra_ | bulldog, you could try if uappexplorer helps | 15:49 |
| bulldog | ogra_, no i want list all packages available in snapcraft-gui | 15:50 |
| ogra_ | eeek ... mvo !! | 15:50 |
| ogra_ | (why did he just share the ps gadget with me again) | 15:50 |
| ogra_ | *pc | 15:51 |
| barry | anyway. rebooting with fingers crossed | 15:51 |
| ogra_ | bulldog, well, they you have to wait til snapd grows such a feature | 15:51 |
| smoser | elopio, it does | 15:51 |
| smoser | but now i just seem to see HTTP_PROXY and HTTPS_PROXY working | 15:51 |
| bulldog | ogra_, snap find was there for that but it is dropped feature idk why :( | 15:51 |
| smoser | so maybe all we need is to do the build in the pull | 15:52 |
| smoser | as was suggested | 15:52 |
| smoser | what environment does the buildd set up for us? | 15:52 |
| ogra_ | bulldog, no, it wasnt .... it just listed 100 random snaps | 15:52 |
| smoser | is that documented? | 15:52 |
| bulldog | ogra_, oh :D | 15:52 |
| elopio | smoser: I don't know. You need somebody from launchpad. | 15:52 |
| bulldog | ogra_, and what snap find <snapname > does is look for package online ?? | 15:53 |
| ogra_ | yes | 15:53 |
| bulldog | daem , but thats not gonna help me :D | 15:53 |
| ogra_ | just talk to the local snapd | 15:55 |
| bulldog | wont look online ?? | 15:55 |
| ogra_ | it has a REST API | 15:55 |
| ogra_ | sure it will look online | 15:55 |
| bulldog | cool | 15:55 |
| ogra_ | thats the only package DB that exists | 15:55 |
| ogra_ | so it has to look online :) | 15:55 |
| bulldog | i wil allow users to look online and then allow them install via gui | 15:55 |
| bulldog | ty :P | 15:56 |
| ogra_ | i think a gui to manage interfaces would abe a lot more interesting though | 15:56 |
| ogra_ | *would be | 15:56 |
| bulldog | manage interfaces mean ?? | 15:56 |
| barry | zyga, nacc purging the old drivers doesn't help | 15:56 |
| ogra_ | snaps are installable through the software center already, so there is a GUI installer | 15:57 |
| bulldog | showing users the interfaces snap will use or what ? | 15:57 |
| ogra_ | but there is no GUI tool yet to manage the snap interfaces | 15:57 |
| ogra_ | only a few of them connect automatically | 15:57 |
| bulldog | ogra_, am making all in one ,snapcraft-gui have a package manager too | 15:57 |
| ogra_ | well, as you like | 15:57 |
| bulldog | ogra_, make me clear about managing interfaces | 15:58 |
| smoser | sergiusens, you said do the build twice ? | 15:58 |
| smoser | why not *only* in the pull as oppoosed to pull and build ? | 15:58 |
| bulldog | what u mean ?? how you want user manage em | 15:58 |
| ogra_ | bulldog, well, snap interfaces ... snap connect ... guis for these ... | 15:58 |
| ogra_ | so that you can manage permissions for installed snaps | 15:58 |
| bulldog | oh | 15:58 |
| ogra_ | currently that requires commandline | 15:58 |
| ogra_ | even if you installed through the software center | 15:59 |
| bulldog | ogra_, is it a feature available in cli snapd | 15:59 |
| ogra_ | snap help | 15:59 |
| ogra_ | :P | 15:59 |
| bulldog | ogra_, :D | 15:59 |
| kgunn | ogra_: you used to have a dragonboard readme with how to setup wifi i used to cheat with :) | 15:59 |
| kgunn | but now it's missing | 15:59 |
| bulldog | ogra_, can we allow any snap allow interface access ?? with command line? | 16:00 |
| ogra_ | kgunn, http://paste.ubuntu.com/23093640/ | 16:00 |
| kgunn | ogra_: thanks! | 16:00 |
| bulldog | ogra_, what u mean by manage man ?? | 16:01 |
| ogra_ | bulldog, no, only defined plugs can use defined interfaces | 16:01 |
| Chipaca | seb128, does gnome-software not use polkit right now? | 16:01 |
| bulldog | plz , so what u mean by manage | 16:01 |
| ogra_ | Chipaca, most likely | 16:01 |
| ogra_ | bulldog, manage the connections | 16:01 |
| bulldog | example please | 16:02 |
| Chipaca | ogra_, I imagined so; I'm trying to understand an email | 16:02 |
| ogra_ | bulldog, "snap interfaces" | 16:02 |
| bulldog | seen that | 16:02 |
| seb128 | Chipaca, no it doesn't, why would it? | 16:02 |
| ogra_ | bulldog, https://github.com/snapcore/snapd/blob/master/docs/interfaces.md | 16:02 |
| bulldog | ogra_, let me check it | 16:02 |
| seb128 | Chipaca, that was not needed until those recent snapd changes | 16:02 |
| Chipaca | seb128, I ask because robert ancell's first approach to snapd was adding polkit support | 16:03 |
| ogra_ | seb128, no admin rights for installing packages ? | 16:03 |
| seb128 | Chipaca, right, which the snappy team rejected | 16:03 |
| Chipaca | seb128, so I imagined that was how you wanted to do it | 16:03 |
| ogra_ | i would have thought sw-center asks for a pw | 16:03 |
| seb128 | ogra_, aptdaemon does | 16:03 |
| ogra_ | ah | 16:03 |
| bulldog | google making a non linux based OS .DAEM :@ | 16:03 |
| ogra_ | bulldog, and ? even the linux foundation does that https://www.linuxfoundation.org/news-media/announcements/2016/02/linux-foundation-announces-project-build-real-time-operating-system | 16:05 |
| ogra_ | it'S just a kernel after all | 16:06 |
| === mup_ is now known as mup | ||
| bulldog | ogra_, am not a IT Student ,what u think about my future ? lol | 16:06 |
| bulldog | choosing Biology as my subjects in school was biggest mistake i made :( | 16:07 |
| cyphermox | ogra_: do you happen to still have around copies of the broken OS snaps? I keep getting timeouts from Launchpad; it would help to be able to debug this for myself | 16:07 |
| ogra_ | barry, indeed purging doesnt help :) you need to remove the dirs to cheat the check mechanism | 16:07 |
| slangasek | ogra_: so I have an update for the pc amd64 gadget snap to make it ubuntu-image compatible; AFAICS nothing in u-d-f will care about the stuff I'm adding, so it should be safe to merge this, and from my side it's ready to merge now or in the near future. Thoughts? lp:~vorlon/snappy-hub/snappy-systems/ | 16:08 |
| ogra_ | slangasek, oh, did you just share the pc gadget with me ? | 16:09 |
| ogra_ | (silly that the store doesnt tell who actually did that share request) | 16:09 |
| slangasek | ogra_: hmm? no | 16:09 |
| ogra_ | ah, well, then it was mvo | 16:09 |
| slangasek | ogra_: I have no store privs :) | 16:10 |
| ogra_ | :) | 16:10 |
| * ogra_ neither | 16:10 | |
| slangasek | ogra_: oh, but it was also just shared with me :D | 16:10 |
| * ogra_ pokes LP with a pointy stick ... | 16:10 | |
| slangasek | ogra_: does this mean I should be able to upload the snap now? | 16:11 |
| ogra_ | timeouts galore | 16:11 |
| ogra_ | slangasek, yep | 16:11 |
| slangasek | wow | 16:11 |
| ogra_ | slangasek, oooooh !!!!!!! | 16:11 |
| * ogra_ dances | 16:11 | |
| slangasek | ogra_: I guess it would help me if you would steer the upload for the moment, I haven't used the store much yet and would flounder - so your input on the merge question is still appreciated | 16:11 |
| ogra_ | slangasek, tell me when i can drop the grub packages :) | 16:11 |
| slangasek | haha | 16:12 |
| slangasek | not yet | 16:12 |
| ogra_ | (just saw your change) | 16:12 |
| ogra_ | well, go ahead and upload ... if edge breaks it breaks ... its edge after all | 16:12 |
| ogra_ | (just dont release it to stable :) | 16:12 |
| slangasek | not until a) we actually fix ubuntu-image to implement mbr stuff (we're almost there), b) we get everyone to use ubuntu-image instead of ubuntu-device-flash ;) | 16:13 |
| ogra_ | slangasek, its one checkbox to unpublish it ... iirc the store just falls back to the former version then | 16:13 |
| ogra_ | ah, right, udf doesnt have mbr handling at that level for grub | 16:14 |
| ogra_ | cyphermox, armhf http://people.canonical.com/~ogra/snappy/ubuntu-core_360.snap ... arm64 http://people.canonical.com/~ogra/snappy/ubuntu-core_361.snap | 16:17 |
| mvo | ogra_: yes, me | 16:17 |
| ogra_ | (i dont have x86 ones) | 16:17 |
| ogra_ | mvo, ah ... did anything change that you shared it again with me ?= | 16:18 |
| ogra_ | or was that group vs user ? | 16:18 |
| mvo | ogra_: I think for some reason you were not listed as a collaborator | 16:18 |
| ogra_ | well, i had access :) | 16:18 |
| cyphermox | ogra_: in that case, do you happen to also have the other snaps I need to build an armhf image? | 16:18 |
| cyphermox | (preferably the same ones you used) | 16:18 |
| mvo | slangasek: I'm writing a mail now about this, but you are already ahead of me (like always :) | 16:19 |
| mvo | slangasek: you can upload the gadget in any way you want, u-d-f does not actually look at the content, it has its own version that is known to work | 16:19 |
| ogra_ | cyphermox, just pi2-kernel and pi2 or pi3 for a pi image ... and dragoboard + dragonboard-kernel for a dragonboard image ... you need the udf snap | 16:19 |
| ogra_ | (installed i mean) | 16:19 |
| cyphermox | ok | 16:20 |
| ogra_ | mvo, please make sure to only share with snappy-dev people if it comes to ubuntu-core or kernels ... since that controls also who can trigger builds via the LP UI | 16:20 |
| mvo | ogra_: you can control that list too | 16:21 |
| ogra_ | oh, i didnt know | 16:21 |
| ogra_ | oh, kyrofa is a powerful man :) | 16:21 |
| * ogra_ notes he has ubuntu-core access :) | 16:22 | |
| cyphermox | well, for one I see /var/lib/console-conf is not a writable path; so console-conf explodes because of that | 16:23 |
| slangasek | cyphermox: oh. do we have livecd-rootfs or ubuntu-core-config changes still in our ppa that haven't made it over to snappy-dev? | 16:25 |
| slangasek | cyphermox: we actually have a newer version of ubuntu-core-config in our ppa; can you reconcile those and give me (or ogra) something to publish to snappy-dev/ | 16:27 |
| ogra_ | note that i made a change to that package yesterday ... so your changelog might be behind | 16:27 |
| slangasek | ogra_: ok; so my plan is to locally validate the MBR case (once I finish all the bits in ubuntu-image to actually implement this), then publish | 16:27 |
| ogra_ | yeah | 16:28 |
| ogra_ | you need to accept the invide to th3e pc gadget still :) | 16:28 |
| ogra_ | (says the store) | 16:28 |
| slangasek | yawp, accepting now | 16:29 |
| cyphermox | slangasek: doesn't seem to me like it's a different version of ubuntu-core-config at all | 16:36 |
| cyphermox | oh, wrong ppa | 16:37 |
| ogra_ | cyphermox, dont forget the dir needs to exist if you add it to writable-paths ... so make sure to also add it to your debian/dirs file in console-conf | 16:38 |
| cyphermox | it still doesn't explain why everything seemed to be working correctly when I and mwhudson did the testing on amd64. | 16:40 |
| ogra_ | did you build with the right PPAs and proposed enabled ? | 16:41 |
| cyphermox | yes | 16:41 |
| ogra_ | when creatinmg your ubuntu-core | 16:41 |
| ogra_ | then this is indeed weird | 16:42 |
| slangasek | cyphermox: surely, the difference is some dependency in *our* ppa that is missing from snappy-dev | 16:43 |
| cyphermox | not to explain these failures | 16:43 |
| ogra_ | no | 16:43 |
| ogra_ | there is a writabvle dir missing, that cant be due to a dependency ... | 16:43 |
| cyphermox | well I'm simply going to copy all the packages to our PPA, and build an image from there | 16:44 |
| ogra_ | could be due to a a version number not being high enough though | 16:44 |
| ogra_ | ubuntu-core-config - 0.6.40+ppa6 | 16:44 |
| ogra_ | that is whats in the snappy-dev PPA | 16:44 |
| ogra_ | yours needs to be higher to be considered indeed | 16:44 |
| slangasek | no, ours needs to be merged into the snappy-dev ppa | 16:45 |
| ogra_ | sure, i was referring to cyphermox' test buiulds | 16:45 |
| ogra_ | wheer he added your PPA additionally | 16:45 |
| slangasek | cyphermox: please don't copy things from snappy-dev ppa to ours, there really should be no need | 16:46 |
| cyphermox | the only way we can reliably figure this out is to reduce the delta between the two ppas, and build more images | 16:46 |
| cyphermox | I won't do this in "prod" | 16:46 |
| ogra_ | dont hold back :) | 16:46 |
| ogra_ | there is no prod | 16:46 |
| cyphermox | well, snappy-dev must not be broken, is this not the case?\ | 16:47 |
| ogra_ | there is only edge (where you admittedly can annoy devs) | 16:47 |
| slangasek | cyphermox: ~canonical-foundations/ubuntu/ubuntu-image should be a thin layer on top of the snappy-dev ppa. You shouldn't need to copy things over, that will just clutter | 16:47 |
| ogra_ | snappy-dev can be broken for a bit, as long as you unbreak | 16:47 |
| slangasek | cyphermox: I see the ppa doesn't actually have a ppa dep that I thought it did; I'll add that now | 16:47 |
| cyphermox | it shouldn't matter for the build actually, snapcraft.yaml defines the PPAs to use | 16:48 |
| slangasek | ah | 16:48 |
| ogra_ | for ubuntu-core ? | 16:48 |
| ogra_ | nope | 16:48 |
| cyphermox | yes | 16:48 |
| ogra_ | the Makefile does | 16:48 |
| cyphermox | well, that code branch | 16:48 |
| ogra_ | unless you changed my setup drastically | 16:48 |
| cyphermox | the Makefile, then | 16:49 |
| slangasek | cyphermox: in which case, you just need to be sure that everything present in snappy-dev is merged into ours | 16:49 |
| ogra_ | snapcraft.yaml only defines the outer chroot | 16:49 |
| slangasek | not copied wholesale | 16:49 |
| ogra_ | the actual build PPAs come from the live-build call in the makefile | 16:49 |
| ogra_ | http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-snap/trunk/view/head:/Makefile | 16:50 |
| ogra_ | from the "ENV" var at the top | 16:50 |
| cyphermox | yes | 16:50 |
| ogra_ | if you dont explicitly add it to the EXTRA_PPAS var in there it wont be taken into account inside the live-build chroot | 16:51 |
| slangasek | PROPOSED=1 PROJECT=ubuntu-core SUBPROJECT=system-image EXTRA_PPAS='snappy-dev/image snappy-dev/edge canonical-foundations/ubuntu-image' IMAGEFORMAT=plain SUITE=xenial ARCH=amd64 lb clean | 16:51 |
| slangasek | LGTM? | 16:52 |
| ogra_ | yeah | 16:52 |
| cyphermox | that isn't the issue | 16:52 |
| rogpeppe | in snapcraft.io, it says: | 16:57 |
| rogpeppe | ~/snap/<name>/current/ ← $SNAP_USER_DATA that can be rolled back | 16:57 |
| rogpeppe | ~/snap/<name>/common/ ← $SNAP_USER_COMMON unversioned user-specific data | 16:57 |
| rogpeppe | is that still true? | 16:57 |
| rogpeppe | i don't see any "current" or "common" directories inside ~/snap/<name> | 16:57 |
| rogpeppe | just x[0-9] directories | 16:58 |
| elopio | rogpeppe: they are in /var/snap | 16:59 |
| elopio | rogpeppe: please file a bug about that. | 17:00 |
| rogpeppe | elopio: ok | 17:00 |
| rogpeppe | elopio: so what's the role of the directories in ~/<name>/x[0-9] ? | 17:02 |
| rogpeppe | elopio: they definitely seem to be used | 17:02 |
| wililupy | Thats odd. I use the image from all-snaps on my device, it shows the three snaps, but one that I create does not... | 17:04 |
| elopio | rogpeppe: your snap can read and write files in that directory. | 17:05 |
| ogra_ | wililupy, which ubuntu-device-flash snap did you use ? is it up to date ? | 17:05 |
| rogpeppe | elopio: so it's independent of current and common? | 17:06 |
| rogpeppe | elopio: it seems that $HOME points there | 17:06 |
| wililupy | ogra_: version 10 Rev 9 in devmode | 17:06 |
| elopio | I'm not sure if it has an env var. Maybe there's something wrong and it should be the same as the one in /var. | 17:06 |
| ogra_ | yeah, sounds correct | 17:06 |
| rogpeppe | elopio: yeah, it's $HOME, because i was being confused because i ran the command and it wasn't finding data files that i was expecting | 17:07 |
| wililupy | I updated it yesterday. It did work before giving me the 3 snaps on a clean image, but since then it hasn't. The image works, but as soon as I install a snap, it downloads ubuntu-core and then hoses up the device after a reboot. | 17:07 |
| camako | CMAKE_C_COMPILER | 17:09 |
| camako | ugh ignore that | 17:09 |
| ogra_ | wililupy, which ubuntu-snap version ? | 17:09 |
| ogra_ | err | 17:09 |
| ogra_ | ubuntu-core | 17:09 |
| ogra_ | should be in the 360's somewhere | 17:10 |
| wililupy | ogra_, 16.04.1 Rev 352 | 17:10 |
| ogra_ | that sounds outdated | 17:10 |
| camako | Do we have a known CI problem? Just updated my PR for the playpen and the travis job failed ---- > https://travis-ci.org/ubuntu/snappy-playpen/builds/155385333 | 17:10 |
| camako | "No CMAKE_C_COMPILER could be found" | 17:11 |
| camako | "No CMAKE_CXX_COMPILER could be found" | 17:11 |
| camako | ? | 17:11 |
| wililupy | ogra_ I just ran sudo snap refresh --edge ubuntu-core and it updated to 366 | 17:11 |
| ogra_ | yay | 17:11 |
| ogra_ | see if that works then | 17:11 |
| wililupy | I'll give it a shot after my snap finishes building. | 17:11 |
| camako | Hmmm I see that other's jobs are failing too ---> https://travis-ci.org/ubuntu/snappy-playpen/builds/130943227 | 17:13 |
| wililupy | Another quick question, after updates, how to I get rid of the previous versions? I have 7 /dev/loop* but only 2 snaps running. I'd like to get rid of the 3 previous versions of ubuntu-core that I'm not going to use. Plus I haven't been able to get rollback to function right... | 17:14 |
| mup | Bug #1617399 opened: snapcraft.io documents persistent state incorrectly <Snapcraft:Invalid> <Snappy:Confirmed> <https://launchpad.net/bugs/1617399> | 17:15 |
| ogra_ | i dont think rollback is there yet | 17:15 |
| wililupy | ogra_, I'll have to remember that for my demo ;) | 17:16 |
| rogpeppe | is there any way i can give permission to a snap to open a page in a web browser? | 17:16 |
| ogra_ | i see code landing for it regulary ... but doesnt look like it released yet | 17:16 |
| ogra_ | rogpeppe, theoretically snapd-xdg-open should provide that ... but i think it is still broken | 17:18 |
| ogra_ | (install the deb and see ) | 17:18 |
| rogpeppe | ogra_: ah, i haven't seen that | 17:18 |
| rogpeppe | ogra_: is that an interface that can be installed? | 17:19 |
| ogra_ | but mind you, i think it still doesnt work right ... | 17:19 |
| ogra_ | no, shouldnt need any interfaces | 17:19 |
| ogra_ | it will become part of snapd or a dependency or some such | 17:19 |
| rogpeppe | ogra_: this particular code uses sensible-browser to open the web page | 17:19 |
| rogpeppe | ogra_: are you saying that would need to change? | 17:20 |
| ogra_ | well, it hands it through to the host | 17:20 |
| ogra_ | but that bit doesnt work yet | 17:20 |
| rogpeppe | ogra_: so... how does this work? the snap executes a command called "snapd-xdg-open <url>" ? | 17:20 |
| rogpeppe | ogra_: or rather, i guess, how *would* it work if it did work? :) | 17:21 |
| ogra_ | if your app tries to open an url it intercepts that | 17:21 |
| ogra_ | and then calls xdg-open on the host | 17:21 |
| rogpeppe | ogra_: what does it mean to "open a URL" ? | 17:21 |
| ogra_ | open a web link | 17:21 |
| rogpeppe | ogra_: what does my app need to do to trigger that? | 17:21 |
| rogpeppe | ogra_: when you say "open", what's that? | 17:21 |
| ogra_ | iirc only the http mime types are implemented yet | 17:21 |
| rogpeppe | ogra_: call the open command? | 17:21 |
| rogpeppe | s/call/exec/ | 17:22 |
| ogra_ | if you click a url on an app ... | 17:22 |
| rogpeppe | ogra_: this is a command-line app | 17:22 |
| ogra_ | that would spawn something in the os ... | 17:22 |
| rogpeppe | ogra_: there's no UI | 17:22 |
| mup | PR snapcraft#760 closed: Removed statements not used by the tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/760> | 17:22 |
| ogra_ | but since your snap doesnt run in an actual os this call is handed over to xdg-open on the host | 17:22 |
| ogra_ | oh, not sure ift works from some non UI call | 17:22 |
| rogpeppe | ogra_: so my code would need to exec the xdg-open command? | 17:23 |
| ogra_ | you could try to just call xdg-open directly and hope for the best | 17:23 |
| rogpeppe | ogra_: odd, the browser code calls xdg-open in freebsd, netbsd and openbsd but not linux | 17:23 |
| ogra_ | but it might only be hooked into the desktop launchers ... so no guarantee that anything happens if you do that from a cmdline app | 17:23 |
| rogpeppe | s/browser/open-browser/ | 17:23 |
| rogpeppe | ogra_: ok, so a command line app probably can't open a page in a web browser. | 17:24 |
| ogra_ | probably | 17:24 |
| * ogra_ has no idea ... :) | 17:24 | |
| rogpeppe | ogra_: fair enough :) | 17:24 |
| ogra_ | i know it is supposed to work from gui apps (but currently doesnt) | 17:24 |
| sergiusens | rogpeppe the code or the execution of such code? | 17:24 |
| rogpeppe | sergiusens: ? | 17:25 |
| sergiusens | maybe it defaults to some sort of os system() since it cannot find xdg-open in path | 17:25 |
| * ogra_ wonders why everyone and his grandma tries to snap neovim :) | 17:25 | |
| Pharaoh_Atem | because vim is evil | 17:26 |
| Pharaoh_Atem | :) | 17:26 |
| ogra_ | lol | 17:26 |
| ogra_ | right | 17:26 |
| rogpeppe | sergiusens: this is the code: https://github.com/juju/webbrowser/blob/master/webbrowser.go | 17:26 |
| Pharaoh_Atem | of course, the vim codebase finally had DOS support removed | 17:26 |
| ogra_ | geez, really ?!? | 17:26 |
| ogra_ | the world ends ! | 17:26 |
| rogpeppe | sergiusens: it would be quite nice if we could make that code work in a snap; or at least return an appropriate error. | 17:27 |
| Pharaoh_Atem | ogra_: yep, vim 8.0 will be the first version of vim to not be able to run on DOS | 17:30 |
| ogra_ | not a big loss if you ask me :) | 17:31 |
| Pharaoh_Atem | anyone able to review/merge zyga's PR? https://github.com/snapcore/snapd/pull/1745 | 17:37 |
| mup | PR snapd#1745: overlord/snapstate: respect SnapMountDir in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1745> | 17:37 |
| sergiusens | rogpeppe it is indeed in the code | 17:37 |
| hatch | I've noticed that tab complete doesn't work - appears to be a regression https://bugs.launchpad.net/snapcraft/+bug/1570506 should I file another bug or re-open this one? | 17:38 |
| mup | Bug #1570506: Snapcraft should use bash-completion <verification-done> <Snapcraft:Fix Released> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Released> <snapcraft (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1570506> | 17:38 |
| sergiusens | rogpeppe oh and sensible-browser is `alternatives` based. ogra_ you sill love this :-) | 17:39 |
| sergiusens | rogpeppe I would switch to xdg-open | 17:39 |
| sergiusens | about the error though, the code should raise the error, is it not? | 17:39 |
| ogra_ | oh, lovely | 17:40 |
| cyphermox | ogra_: how can I make sure my ubuntu-device-flash or whatever is good enough to create proper images? | 17:40 |
| ogra_ | cyphermox, just make sure to have the latest snap | 17:40 |
| ogra_ | mvo updates it regulary | 17:41 |
| cyphermox | I don't have snaps | 17:41 |
| mup | PR snapd#1684 closed: many: drop ubuntu-core-snapd-units package, use release.OnClassic instead <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1684> | 17:41 |
| ogra_ | then you cant use udf | 17:41 |
| ogra_ | we only hae it as a snap now | 17:41 |
| ogra_ | *have | 17:41 |
| cyphermox | how is it called? | 17:42 |
| cyphermox | $ snap install ubuntu-device-flash | 17:42 |
| cyphermox | error: cannot install "ubuntu-device-flash": snap not found | 17:42 |
| elopio | hey hatch! does it fail for the commands? Like snapcraft p<tab><tab> ? | 17:43 |
| ogra_ | --devmode --edge | 17:43 |
| ogra_ | (or --beta ... should both work) | 17:43 |
| hatch | elopio: those work but I can't do `snap install he<tab>` | 17:45 |
| elopio | hatch: right, those have never worked, so no regression. Let me try to find the bug. | 17:45 |
| hatch | where 'he' is the hello world snap in my current path | 17:45 |
| hatch | elopio: ohh ok, I looked but maybe my search foo is weak :) | 17:45 |
| ogra_ | yeah, thats a very old bug ... | 17:45 |
| ogra_ | open since snap's childhood | 17:46 |
| hatch | haha, it happens :) | 17:46 |
| elopio | hatch: https://askubuntu.com/questions/795253/how-can-i-enable-auto-completion-for-the-snap-command/795412#comment1199447_795412 | 17:46 |
| hatch | thanks elopio | 17:46 |
| ogra_ | bug 1600083 ... but i think there is an older one | 17:47 |
| mup | Bug #1600083: 'snap' tool bash completion does not complete local file names <Snappy:Confirmed> <https://launchpad.net/bugs/1600083> | 17:47 |
| ogra_ | there must be one in the 15xxxx numbering | 17:47 |
| elopio | hatch: snapcraft however has no bug for $ snapcraft upload he<tab>. Could you please file one? | 17:47 |
| hatch | elopio: I'd imagine that would simply be an expansion on https://bugs.launchpad.net/snappy/+bug/1600083 no? | 17:48 |
| mup | Bug #1600083: 'snap' tool bash completion does not complete local file names <Snappy:Confirmed> <https://launchpad.net/bugs/1600083> | 17:48 |
| elopio | hatch: no, because it's in a different project. https://bugs.launchpad.net/snapcraft | 17:49 |
| hatch | ohh I see | 17:49 |
| hatch | sure | 17:49 |
| elopio | thank you. | 17:50 |
| cyphermox | ogra_: presumably I shouldn't have to download the gadget and kernel snaps locally to be able to run this correctly? | 17:51 |
| ogra_ | right | 17:51 |
| ogra_ | note you need sud and the full path though | 17:51 |
| ogra_ | sudo /snap/bin/ub.... | 17:51 |
| cyphermox | of course | 17:51 |
| cyphermox | that's not the issue | 17:51 |
| cyphermox | it can't find the gadget snap | 17:51 |
| ogra_ | which one ? | 17:51 |
| ogra_ | (show me your command) | 17:52 |
| cyphermox | why don't you paste me a full command I can use? | 17:52 |
| ogra_ | because i would have to type it myself :P | 17:52 |
| ogra_ | (it isnt like i have 500 terminal windows open here keeping old commands around :P) | 17:52 |
| cyphermox | sudo /snap/bin/ubuntu-device-flash --verbose core rolling -o console-conf.img --channel edge --enable-ssh --gadget canonical-pc --kernel pc-kernel --os ubuntu-core_16.04.1_amd64.good.snap | 17:52 |
| ogra_ | --gadget pc | 17:53 |
| ogra_ | the rest looks fine | 17:53 |
| cyphermox | I tried that too | 17:53 |
| ogra_ | --enable-ssh is a no-op | 17:53 |
| ogra_ | oh | 17:53 |
| ogra_ | s/rolling/16/ | 17:53 |
| ogra_ | havent seen that one in a while :) | 17:53 |
| cyphermox | thing is, there is just about no documentation on all of this | 17:54 |
| ogra_ | that should fix you | 17:54 |
| cyphermox | yeah, it does | 17:54 |
| ogra_ | and it is obsolete code :) | 17:54 |
| ogra_ | slangasek, and barry will make sure we have proper docs for image building once we have a tool :) | 17:54 |
| cyphermox | ogra_: I really don't care which tool, as long as I can make an image that works. | 17:55 |
| ogra_ | udf is really dead and buried since quite some time ... | 17:55 |
| ogra_ | which is why it isnt promoted anywhere or any docs are put up | 17:55 |
| ogra_ | mvo wrote a long mail when it switched to be a snap though | 17:55 |
| ogra_ | documenting the command call | 17:56 |
| cyphermox | why isn't that in a wiki or doc somewhere? | 17:57 |
| ogra_ | because it changes nearly weekly | 17:58 |
| ogra_ | or used to at least | 17:58 |
| ogra_ | and now it is dead | 17:59 |
| cyphermox | right, surely something replaces it? | 18:00 |
| cyphermox | that thing should also be documented. | 18:00 |
| ogra_ | yes, ubuntu-image | 18:00 |
| ogra_ | as i said above | 18:00 |
| cyphermox | and how do I use that? | 18:01 |
| ogra_ | it isnt ready yet | 18:01 |
| slangasek | cyphermox: you can grab it from git@github.com:CanonicalLtd/ubuntu-image.git and follow the instructions in docs/notes.rst for the moment | 18:05 |
| slangasek | which is incredibly hairy | 18:05 |
| slangasek | until I validate the mbr work ;) | 18:05 |
| cyphermox | that's fine | 18:05 |
| cyphermox | for now ubuntu-device-flash will do; if there are any more days of mucking necessary, I will dogfood ubuntu-image. | 18:06 |
| ogra_ | cyphermox, note that the worst bug i filed is actually bug 1617231 though ... testing on amd64 wont really help with all the serial breakages on the different devices | 18:09 |
| mup | Bug #1617231: subiquity kills serial console after regular update <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1617231> | 18:09 |
| ogra_ | (beyond subiqity not respecting that the system already has user and network setup) | 18:10 |
| ogra_ | i'm not sure what exactly you use as UI library ... but colors are definitely a very bad idea for that ;) | 18:10 |
| cyphermox | ogra_: the point *is* that you won't have the ubuntu user, and that the network setup you might really want to change to something else. | 18:12 |
| cyphermox | as for the colors; something to look into | 18:13 |
| ogra_ | i definitely dont | 18:13 |
| cyphermox | then hitting Done should DTRT | 18:13 |
| ogra_ | (i mean, yes, i might want to use another user ... but definitely not switch away from ifupdown for my wlan) | 18:13 |
| cyphermox | everything is switching away from ifupdown | 18:13 |
| ogra_ | the tool seems to detect there is a working connection | 18:13 |
| slangasek | console-conf doesn't give you the option to switch away from ifupdown for wlan at the moment | 18:13 |
| ogra_ | but doesnt accept it | 18:14 |
| cyphermox | well, wlan is admittedly probably not working correctly right now, netplan probably doesn't do anything to make it work | 18:14 |
| ogra_ | slangasek, well, currently it doesnt do anything at all except hogging 50MB in my ram and breaking all serial consoles :P | 18:14 |
| ogra_ | (and being unkillable ... even with sudp kill -9 ) | 18:15 |
| ogra_ | *sudo | 18:15 |
| ogra_ | (which is very very odd) | 18:15 |
| slangasek | ogra_: the last is certainly not a bug in our package ;) | 18:16 |
| slangasek | the first two are serious bugs, yes | 18:16 |
| ogra_ | well, i have no explanatiojn for the last at all | 18:17 |
| slangasek | I guess the first means that subiquity doesn't currently have a proper serial console driver | 18:17 |
| slangasek | sure | 18:17 |
| slangasek | but it's not a bug in our package, because kill -9 is handled in the kernel | 18:17 |
| ogra_ | yeah | 18:17 |
| * ogra_ goes afk | 18:23 | |
| ogra_ | cyphermox, i'll check IRC sporadically in case you need anything like an ubuntu-core build or anything (slangasek has upload permission to the snappy-dev PPA afaik) | 18:23 |
| slangasek | ogra_: as does cyphermox now :) | 18:23 |
| ogra_ | ah, cool | 18:23 |
| ogra_ | snappy-dev people can also trigger ubuntu-core builds, but i think the store currently auto-accepts only mvo and me for the uploads | 18:24 |
| lazyPower | elopio o/ | 18:24 |
| mbruzek | Hello elopio | 18:24 |
| mbruzek | elopio: I am interested in charming some container stuff, such as kubernetes | 18:25 |
| eldarkg | hello guys. How to exchange copy plugin with dump: "files: ./*: usr/share/kicad/modules/" ? | 18:26 |
| elopio | lazyPower: hello mbruzek: hello | 18:27 |
| elopio | mbruzek: we have been playing with related stuff in the playpen. mbruzek: do you think it would make sense to share your work in progress there? | 18:28 |
| lazyPower | elopio - we only have the client binary packed as a snap, and its using the dump plugin | 18:28 |
| lazyPower | the build env for kubernetes wont "just work" using hte golang plugin | 18:29 |
| lazyPower | we need support to invoke make targets along with exports | 18:29 |
| mbruzek | elopio: Is there the ability to run a script. | 18:29 |
| eldarkg | elopio: How to exchange copy plugin with dump. Now with copy plugin "files: ./*: usr/share/kicad/modules/" ? | 18:30 |
| elopio | mbruzek: lazyPower: you'll find this one interesting: https://github.com/ubuntu/snappy-playpen/pull/223/files | 18:30 |
| mup | PR ubuntu/snappy-playpen#223: Add the etcd snap, in devmode <Created by elopio> <https://github.com/ubuntu/snappy-playpen/pull/223> | 18:30 |
| lazyPower | interesting, this is more complex than the etcd snap i came up with | 18:30 |
| lazyPower | but it doesn't run the daemon either | 18:31 |
| sergiusens | stokachu hey, where is your snapcraft.yaml for conjure-up? | 18:31 |
| elopio | our idea is that people should use a custom plugin, instead of just executing a script. That causes some issues, so there's an open bug and a couple of PRs we are discussing. | 18:31 |
| elopio | eldarkg: hello. I'm not too sure, I would have to play with it but I'm testing snapd atm. | 18:31 |
| elopio | sergiusens: we need a guide to migrate from copy to dump. It's not easy. | 18:32 |
| eldarkg | elopio: ok ) | 18:32 |
| sergiusens | elopio ok | 18:32 |
| elopio | lazyPower: ah, I have that question. Most of the guides tell you to launch the binary, instead of using an autostart daemon. | 18:32 |
| eldarkg | sergiusens: Hi. How to exchange copy plugin with dump. Now with copy plugin "files: ./*: usr/share/kicad/modules/" ? | 18:32 |
| sergiusens | elopio it should be if people had been using organize/snap/stage/filesets more, but copy got the need for that out | 18:32 |
| lazyPower | well, its like this elopio | 18:32 |
| elopio | we could easily add daemon: simple, but I didn't know if that was the right thing to do. | 18:33 |
| lazyPower | if you start etcd, and hten make a cluster configuration change, and you have a dirty data dir, you're going to have a bad time | 18:33 |
| lazyPower | once raft takes over, its slightly easier, but its still not a stellar process | 18:33 |
| elopio | I love that you people are here ^_^ I just had toy examples, now we can make it really useful and find better blocker bugs. | 18:34 |
| elopio | lazyPower: mbruzek: so, how can I help? Should we start with one project and make it awesome? | 18:35 |
| mup | PR snapd#1770 opened: overlord/assertstate,asserts/snapasserts: give snap assertions helpers a package, introduce ReconstructSideInfo <Created by pedronis> <https://github.com/snapcore/snapd/pull/1770> | 18:36 |
| lazyPower | elopio - well.... we're currently blocked on a missing docker snap (or instructions on how to bin pack the docker daemon *and* get it running in the k8s snap) | 18:37 |
| eldarkg | sergiusens: Have you answer? I try organize but it doesn't understand './*' | 18:38 |
| mbruzek | elopio I running the kubernetes build in a snap. | 18:38 |
| lazyPower | while i dont want to just willy nilly spin up engine instances, if we could conglomerate pack the daemon in the k8s snap, that works for us for now and we can get unblocked | 18:38 |
| lazyPower | we're stuck on that portion in the mean time, as its a baseline dependency for k8s | 18:38 |
| elopio | lazyPower: well, starting with kubernetes might not be the best idea. It's too hard. I would suggest to start with simpler services that it will consume, like etcd, | 18:39 |
| lazyPower | "its too hard" - neverrrr | 18:40 |
| elopio | I have seen lool and jdstrand comenting about docker. They probably know about the timeline. | 18:40 |
| lazyPower | oh i'm looped in on some of those discussions and we're a ways out from having anything ready for us to consume | 18:41 |
| lazyPower | re; etcd - thats fine by me, but we also need to talk about how thats going to function in reality | 18:41 |
| lazyPower | clustering etcd manually is painful | 18:41 |
| eldarkg | elopio: Is it possible to have access to media storage like USB flash card? | 18:41 |
| lazyPower | we've had a lot of success clustering with juju | 18:41 |
| eldarkg | elopio: from snap app | 18:41 |
| elopio | eldarkg: it will be: https://bugs.launchpad.net/snappy/+bug/1604885 | 18:43 |
| mup | Bug #1604885: Access to mounted USB drives <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1604885> | 18:43 |
| eldarkg | elopio: thanks. sorry for noise | 18:44 |
| elopio | lazyPower: but that's where the charm comes into play, right? I don't much about either, so please be patient with the stupid questions. | 18:44 |
| lazyPower | elopio - no worries, and yeah | 18:44 |
| lazyPower | thing is | 18:44 |
| lazyPower | 1 sec | 18:44 |
| elopio | as I see it, we will have the snap. Juju will install it in many machines, and then configure them to talk to each other. | 18:44 |
| elopio | eldarkg: hey, no worry, you are not noise. Is it your first time here? | 18:45 |
| smoser | sergiusens, elopio https://github.com/snapcore/snapcraft/pull/762 if you're interested. | 18:45 |
| mup | PR snapcraft#762: node plugin: run build in pull phase to download dependencies <Created by smoser> <https://github.com/snapcore/snapcraft/pull/762> | 18:45 |
| eldarkg | elopio: yes | 18:45 |
| lazyPower | elopio - https://github.com/juju-solutions/layer-etcd/issues/31 -- comment halfway down by neiljerram. If its not coming from the archive, they aren't trusting it, and they are a real consumer of the etcd charm | 18:45 |
| lazyPower | so i dont know how keen they are giong to be moving from archive to a snap, as resources had the same property | 18:45 |
| mup | PR snapcraft#762 opened: node plugin: run build in pull phase to download dependencies <Created by smoser> <https://github.com/snapcore/snapcraft/pull/762> | 18:46 |
| elopio | smoser: oh, that could be a mess, but it's just what sergiusens was suggesting. Call build twice. | 18:46 |
| elopio | however, I didn't imagine pull calling build. Hum... | 18:46 |
| smoser | i'm not certain that is what you were looking for, but the things i've added (--cache-min=Infinity) is required. and i've tested that the idea works. | 18:46 |
| elopio | eldarkg: welcome! | 18:46 |
| smoser | http://paste.ubuntu.com/23094486/ <-- | 18:46 |
| eldarkg | elopio: thank you :) | 18:47 |
| smoser | there, do a 'npm install' with internet, and then take away internet and do it again. | 18:47 |
| elopio | sorry people, I have a meeting. BBS. | 18:48 |
| eldarkg | elopio: bye | 18:48 |
| eldarkg | who can to answer what status of https://bugs.launchpad.net/snappy/+bug/1611063 | 18:49 |
| mup | Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611063> | 18:49 |
| eldarkg | sergiusens: can you tell anything about this bug https://bugs.launchpad.net/snapcraft/+bug/1617002 ? | 18:52 |
| mup | Bug #1617002: LP build: "/usr/bin/ld: cannot find -llibrary" <build> <lp> <Snapcraft:New> <https://launchpad.net/bugs/1617002> | 18:52 |
| jdstrand | roadmr: hi! can you pull r719 of the review tools. not an emergency | 18:57 |
| jdstrand | roadmr: oh, actually, hold off on that (the commits are fine, I forgot I wanted to add a few more checks) | 18:59 |
| mup | PR snapd#1771 opened: store: refresh expired device sessions <Created by matiasb> <https://github.com/snapcore/snapd/pull/1771> | 19:03 |
| kyrofa | jdstrand, what is happening here? http://pastebin.ubuntu.com/23094551/ | 19:05 |
| kyrofa | jdstrand, how is that possible without the snapd-control interface? | 19:05 |
| kyrofa | (FYI, this is the released snapd, not my PR) | 19:05 |
| jdstrand | kyrofa: that's curious (cc tyhicks) | 19:07 |
| kyrofa | jdstrand, I've verified, the only place /run/snapd.socket is present is the snapd-confine interface apparmor snippet | 19:08 |
| kyrofa | And since I can't ls /run or /run/*, there isn't something else covering that | 19:08 |
| jdstrand | kyrofa: so, /run is not allowed by the policy so ls /run doesn't work. /run/snapd.socket is also not allowed by the policy-- you can cat /run/snapd.socket. but what is curious is that you can ls -l /run/snapd.socket even though '/run/ r,' is not allowed | 19:09 |
| kyrofa | Indeed | 19:09 |
| jdstrand | kyrofa: s/you can cat /run/snapd.socket/you can cat /run/snapd.socket to verify/ | 19:09 |
| kyrofa | jdstrand, indeed, and I can't dial it or anything either | 19:09 |
| elopio | lazyPower: that's a good question. It would be great to let people choose the source, either deb from the archive, deb from a ppa, snap, or download a tar. | 19:09 |
| kyrofa | But the ls... and os.Stat I tried to do... | 19:10 |
| kyrofa | Which I figured would fail. Doesn't! | 19:10 |
| elopio | but that sounds like the problem is now 4 times harder. | 19:10 |
| tyhicks | yikes, that's not right | 19:10 |
| jdstrand | tyhicks: I think kyrofa discovered a bug | 19:10 |
| jdstrand | tyhicks: the access to the file is not allowed. but ls /foo/bar is allowed when there is no '/foo/ r,' rule | 19:11 |
| tyhicks | yeah, I'm going to narrow down if it specific to socket files or regular files | 19:11 |
| tyhicks | and compare to older ubuntu releases to see if it is a regression | 19:11 |
| jdstrand | thanks | 19:11 |
| jdstrand | kyrofa: thanks for bringing that up | 19:12 |
| kyrofa | jdstrand, of course, thanks for looking into it tyhicks! | 19:12 |
| tyhicks | np | 19:12 |
| stokachu | sergiusens: http://github.com/conjure-up/conjure-up | 19:12 |
| jdstrand | tyhicks: do you need me to do anything? one thing I thought that might have an impact is that /run is bind mounted on classic | 19:13 |
| tyhicks | jdstrand: not right now | 19:13 |
| tyhicks | jdstrand: that's a good though | 19:13 |
| jdstrand | kyrofa: did you see this on classic? | 19:13 |
| tyhicks | s/though/thought/ | 19:13 |
| kyrofa | jdstrand, indeed | 19:13 |
| jdstrand | kyrofa: 16.04? | 19:13 |
| kyrofa | jdstrand, yessir | 19:13 |
| jdstrand | k | 19:13 |
| jdstrand | tyhicks: ^ | 19:13 |
| tyhicks | thanks | 19:13 |
| jdstrand | tyhicks: thanks! :) | 19:13 |
| eldarkg | kyrofa: hi. can you tell anything about this bug https://bugs.launchpad.net/snapcraft/+bug/1617002 ? | 19:14 |
| mup | Bug #1617002: LP build: "/usr/bin/ld: cannot find -llibrary" <build> <lp> <Snapcraft:New> <https://launchpad.net/bugs/1617002> | 19:14 |
| kyrofa | eldarkg, you're probably missing a build-package | 19:16 |
| kyrofa | That you have installed on your build machine, but isn't available by default | 19:17 |
| eldarkg | kyrofa: what pkg? | 19:17 |
| eldarkg | kyrofa: I build ngspice from src in this snapcraft.yaml | 19:18 |
| kyrofa | eldarkg, oh, I missed that :) | 19:18 |
| ahoneybun | anyone know what's up with travis? | 19:18 |
| eldarkg | kyrofa: ok) | 19:18 |
| nacc | eldarkg: i'm guessing that you need to tell kicad's build where to find the staged ngspice | 19:19 |
| nacc | *libngspice | 19:19 |
| ahoneybun | trying to put otter-browser in the playpen | 19:19 |
| ahoneybun | https://github.com/ubuntu/snappy-playpen/pull/221 | 19:19 |
| mup | PR ubuntu/snappy-playpen#221: Added otter-browser <Created by ahoneybun> <https://github.com/ubuntu/snappy-playpen/pull/221> | 19:19 |
| eldarkg | nacc: why in local machine this is not need? | 19:20 |
| nacc | eldarkg: on your local machine are you running `snapcraft build`? and do you have a system libngspice installed? | 19:20 |
| eldarkg | eldarkg: on local machine I use `snapcraft prime`. Yes installed | 19:21 |
| kyrofa | eldarkg, is there a reason you're building that lib from source instead of using one from the archive? | 19:22 |
| kyrofa | Ah, maybe there isn't one | 19:22 |
| nacc | eldarkg: right, i think you could start with just using stage-packages: libngprime (or what the package is called)? | 19:22 |
| nacc | if it's packaged, that is | 19:22 |
| eldarkg | kyrofa: yes) | 19:22 |
| eldarkg | nacc: libngspice | 19:23 |
| nacc | eldarkg: err, yes, sorry! | 19:23 |
| eldarkg | nacc: isn't in ubuntu repo. It builds from src | 19:23 |
| nacc | eldarkg: ah i see | 19:24 |
| roadmr | jdstrand: oops... sure, just let me know which revno you need | 19:25 |
| eldarkg | nacc: I think running of `snapcraft snap` on local and on LP should be identical shouldn't to use system libs. | 19:25 |
| jdstrand | roadmr: well, you could queue up r719 | 19:25 |
| jdstrand | roadmr: but I have another couple things to add | 19:25 |
| jdstrand | (unrelated to what's in there) | 19:25 |
| nacc | kyrofa: you probably know better the details than I, but I think that means eldarkg'd need to pass perhaps a configure-like flag which tells kicad to use the staged libngspice? | 19:25 |
| jdstrand | ratliff: so just trying to save you time | 19:25 |
| jdstrand | roadmr: ^ | 19:26 |
| jdstrand | ratliff: nm | 19:26 |
| roadmr | jdstrand: ok, will do | 19:26 |
| kyrofa | nacc, yeah probably, eldarkg happy to help in just a sec, trying to schedule the all-important internet installation | 19:26 |
| eldarkg | kyrofa: ok. I waiting | 19:27 |
| tyhicks | jdstrand, kyrofa: quick update - this is not a regression in behavior | 19:28 |
| eldarkg | nacc: but how kicad build found other build-packages like libboost? | 19:28 |
| tyhicks | jdstrand, kyrofa: I've tested on all LTS releases all the way back to 12.04 | 19:28 |
| kyrofa | tyhicks, yikes | 19:28 |
| tyhicks | jdstrand, kyrofa: https://paste.ubuntu.com/23094631/ | 19:28 |
| sergiusens | smoser looks interesting, aesthetically though I'd prefe to not call self.build from pull, better factor out the common things in build :-) | 19:29 |
| tyhicks | I'll glance at the code and see if I can spot something | 19:29 |
| nacc | eldarkg: you specificed 'libboost-all-dev' in build-packages | 19:29 |
| smoser | sergiusens, i did that at first | 19:29 |
| smoser | but then the diff looked bigger. | 19:29 |
| jdstrand | tyhicks: that's interesting | 19:29 |
| eldarkg | nacc: yes. but I don't set to kicad where it should find libboost | 19:29 |
| smoser | sergiusens, i have no strong feeling at all on it. | 19:30 |
| nacc | eldarkg: yes, but you told it to install it in the snap build environment | 19:30 |
| nacc | eldarkg: and so it's installed int he 'system' level view, whichis probably the default for kicad's build | 19:30 |
| elopio | <- lunch. | 19:31 |
| nacc | eldarkg: whereas your part for ngspice maybe is not | 19:31 |
| eldarkg | nacc: how to install library compiled from source to snap build env? | 19:32 |
| nacc | eldarkg: let's let kyrofa help, i'm mostly just conjecturing based upon my own experience. I'm still pretty new to snaps myself :) | 19:32 |
| kyrofa | Some people go out to lunch. But when elopio wants to eat, lunch comes to him | 19:32 |
| eldarkg | nacc: ok. thanks to help | 19:33 |
| eldarkg | what about this bug https://bugs.launchpad.net/snappy/+bug/1611063 ? | 19:34 |
| mup | Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611063> | 19:34 |
| elopio | -> lunch. I have to cook today. | 19:35 |
| kyrofa | Hahaha | 19:36 |
| eldarkg | kyrofa: you don't forgot about me ? :) | 19:36 |
| kyrofa | eldarkg, still on the phone, sorry | 19:37 |
| kyrofa | eldarkg, I can talk, but can't think ;) | 19:37 |
| mup | Bug #1581167 changed: package snap (not installed) failed to install/upgrade: a tentar sobre-escrever '/usr/share/man/man1/snap.1.gz', que também está no pacote snapd 2.0.2 <amd64> <apport-package> <xenial> <One Hundred Papercuts:Confirmed> <Snappy:Confirmed> <snap (Ubuntu):Confirmed> <snapd | 19:37 |
| mup | (Ubuntu):Confirmed> <https://launchpad.net/bugs/1581167> | 19:37 |
| eldarkg | kyrofa: ahh OK :) | 19:37 |
| mup | Bug #1605080 changed: package snap (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/snap.1.gz', which is also in package snapd 2.0.10 <amd64> <apport-package> <package-conflict> <xenial> <One Hundred Papercuts:Confirmed> <Snappy:Confirmed> <snap | 19:40 |
| mup | (Ubuntu):Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1605080> | 19:40 |
| bull_ | mup, | 19:44 |
| bull_ | nick/ bulldog | 19:44 |
| kyrofa | Alright eldarkg, off now | 19:44 |
| === bull_ is now known as bulldog | ||
| eldarkg | kyrofa: ok | 19:45 |
| kyrofa | Let me take a look here | 19:45 |
| kyrofa | I suspect nacc was right, though | 19:45 |
| eldarkg | kyrofa: I listen you | 19:45 |
| bulldog | good night guys :( | 19:45 |
| nacc | i'm not sure if this is the best way to test, but one way i've debugged issues like this one eldarkg is to temporarily comment out the broken part, build the rest and then `unsquashfs -l` the resutling .snap to see where things are in the snap's environment. I'm sure there is a better way to do that, but it wasn't obvious to met yet | 19:46 |
| nacc | *me | 19:46 |
| eldarkg | nacc: to find libngspice? | 19:49 |
| kyrofa | nacc, you don't need to squash and then unsquash, just look in the prime/ directory | 19:50 |
| nacc | kyrofa: ah true, except i do everything via cleanbuild :) | 19:50 |
| kyrofa | nacc, ah, then you're a bit stuck | 19:50 |
| nacc | i guess i could flip it and start a container that is my building env | 19:50 |
| nacc | and then what you suggest woudl work | 19:50 |
| nacc | i'll retool my brain :) | 19:50 |
| kyrofa | nacc, that's what I do-- I fire up an ephemeral container every time someone asks me to debug something (like now) | 19:50 |
| bulldog | OerHeks, haha yyou here too ? | 19:51 |
| nacc | kyrofa: yep, makes sense -- i almost wish that was what cleanbuild did | 19:51 |
| nacc | kyrofa: then i could drop to that container's shell on failure | 19:51 |
| kyrofa | nacc, actually, we're working on just that | 19:51 |
| kyrofa | In fact, it may have landed already | 19:51 |
| nacc | kyrofa: awesome! | 19:51 |
| kyrofa | sergiusens can give you more info | 19:51 |
| nacc | kyrofa: great, thanks! | 19:51 |
| sergiusens | nacc use master and do snapcraft cleanbuild --debug | 19:53 |
| kyrofa | nacc, that'll be in the next release | 19:53 |
| nacc | sergiusens: cool, will try that | 19:53 |
| nacc | kyrofa: ah great, that was going to be my next question :) | 19:53 |
| kyrofa | nacc, we release weekly | 19:54 |
| nacc | yep | 19:54 |
| eldarkg | who know status of https://bugs.launchpad.net/snappy/+bug/1611063 ? | 19:54 |
| mup | Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611063> | 19:54 |
| kyrofa | eldarkg, I'm working on building this, but my internet is dreadful, this will take a bit | 19:54 |
| eldarkg | kyrofa: how many? | 19:55 |
| kyrofa | It says 37 minutes | 19:55 |
| kyrofa | But it jumps to 50-something too | 19:55 |
| eldarkg | kyrofa: ouuu. what time in your country ? my 22:56 :) I want to sleep :) | 19:56 |
| kyrofa | eldarkg, 1300, haha. Go to bed, come back Monday and ping me | 19:56 |
| eldarkg | kyrofa: ok :)) | 19:57 |
| kyrofa | Or if I figure something out, I'll put it on the bug | 19:57 |
| eldarkg | kyrofa: ok | 19:57 |
| eldarkg | kyrofa: you know something about https://bugs.launchpad.net/snappy/+bug/1611063 ? | 19:57 |
| mup | Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611063> | 19:57 |
| === davmor2 is now known as davmor2_hols | ||
| kyrofa | eldarkg, yeah I do | 20:03 |
| eldarkg | kyrofa: what? | 20:03 |
| kyrofa | zyga, are you still around? I think the latest snap-confine SRU fixes that bug, right? ^^ | 20:04 |
| kyrofa | eldarkg, anyway, that was caused by a lack of communication between two tools, snapd and snap-confine | 20:07 |
| kyrofa | One thought the other tool was creating it, so neither did :P | 20:07 |
| kyrofa | If it's not fixed already it'll be fixed in the next release | 20:08 |
| eldarkg | kyrofa: ok. | 20:08 |
| eldarkg | kyrofa: good bye. I'll ping you on Monday | 20:08 |
| kyrofa | eldarkg, sounds good, talk to you then | 20:08 |
| slangasek | sergiusens: hi, I've been granted store perms on the pc snap, but I get a strange error from 'snapcraft push'; can you help me decipher this?: | 20:17 |
| slangasek | Received 403: '{"error_list": [{"message": "Developer profile is missing short namespace.", "code": "user-not-ready"}]}' | 20:17 |
| slangasek | command was 'snapcraft push pc_16.04-0.5_all.snap', snapcraft help output doesn't give any clues | 20:18 |
| sergiusens | slangasek yeah, talk to ev ;) | 20:19 |
| ev | le sigh | 20:19 |
| sergiusens | slangasek you basically need to go to the store (myapps... and create that) | 20:19 |
| slangasek | hmm | 20:19 |
| sergiusens | ev well you need to fix it faster :-) | 20:19 |
| slangasek | ok, set | 20:19 |
| sergiusens | slangasek nice to se the error list stuff is working! I will implement a nicer error for that now ;-) | 20:20 |
| ev | I know, believe me - I’ve been moaning about the short namespace ever being a thing for snaps. But we have frankly more important things to deal with first | 20:20 |
| slangasek | yeah, I was managing to work my way through the error message to do what it was asking me, was just confused about why this would be related to my upload - I guess it's understood to be a bug ;) | 20:20 |
| slangasek | There has been a problem while analyzing the snap, check the snap and try to push again. | 20:20 |
| slangasek | ... | 20:20 |
| ev | sergiusens: we should check for the short namespace on snapcraft login | 20:20 |
| sergiusens | ev how? as in with what api? or are you talking server side | 20:21 |
| sergiusens | slangasek if there was a problem, check your inbox | 20:21 |
| sergiusens | slangasek or click-review it | 20:21 |
| slangasek | "found binaries for architecture 'all': ... ok then | 20:21 |
| slangasek | sergiusens: one of the rejects was because 'gadget requires manual review', so if I click that button and somebody manually reviews it, is the architecture mismatch ignorable? | 20:23 |
| ev | sergiusens: right, we’d need an API for it | 20:23 |
| slangasek | ogra_: btw why is there a 16.04-0.5 in the store that's not in bzr? | 20:23 |
| ev | but even with SSO usernames we’re going to have this problem | 20:24 |
| ev | unless there’s some magic way of making them required for anyone who already has an account | 20:25 |
| wililupy | Is there a handy list of what the different $SNAP variables are? like $SNAP and $SNAP_APP. What else is there? I am specifically looking for the writable space for my snap. | 20:28 |
| slangasek | sergiusens: "check my inbox"> never received any email about this fwiw | 20:30 |
| qengho | wililupy: "snap install hello-world; hello-world.env |grep SNAP" | 20:32 |
| hatch | is the lack of support in an lxd a snappy or lxd issue? | 20:34 |
| hatch | (for running snaps, not building them) | 20:34 |
| slangasek | jdstrand, ev: who can 'manually review' a gadget snap that I've uploaded? | 20:39 |
| jdstrand | slangasek: I can | 20:39 |
| jdstrand | slangasek: what is the store url? | 20:40 |
| slangasek | jdstrand: cool, https://myapps.developer.ubuntu.com/dev/click-apps/5508/rev/5/ | 20:40 |
| jdstrand | slangasek: curious, do that use all the nifty new gadget yaml? | 20:42 |
| jdstrand | does* | 20:42 |
| slangasek | jdstrand: yes | 20:42 |
| jdstrand | cool | 20:43 |
| jdstrand | slangasek: approved btw | 20:43 |
| ahoneybun | mhall119: make a snap tut video or talk about it at the release party | 20:43 |
| slangasek | jdstrand: thanks :) | 20:43 |
| slangasek | jdstrand: it's passed local boot tests for both UEFI and BIOS boot, so now we can give people something compatible with ubuntu-image that they can play with :) | 20:46 |
| wililupy | qengho: exactly what I was looking for! Thanks! | 20:50 |
| mhall119 | ahoneybun: if the venue is good for it, I can give a presentation | 20:55 |
| jdstrand | slangasek: nice! :) | 21:10 |
| === tvoss_ is now known as tvoss | ||
| ogra_ | slangasek, i dont think so | 21:29 |
| ogra_ | (but i also dont really touch the x86 side in teh tree) | 21:31 |
| slangasek | ogra_: you don't think so> you don't think why there's a version in the store that's not in bzr? | 21:33 |
| slangasek | :) | 21:34 |
| slangasek | fwiw I checked the contents and they were no changes except the version | 21:34 |
| slangasek | so I ignore it | 21:34 |
| cjwatson | smoser: environment> easy enough to see from http://bazaar.launchpad.net/+branch/launchpad-buildd/view/head:/buildsnap, which is short enough | 22:38 |
| cjwatson | (it is not otherwise documented I'm afraid) | 22:39 |
| wililupy | hmm. For some reason, when I build an image with ubuntu-device-flash and a custom kernel, it doesn't show any snaps installed. | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!