[00:27] kyrofa, they go into edge daily and after manual testing into stable ... in the future we will have different builds for different channels, today edge is the same as stable, just untested [01:05] PR snapcraft#757 opened: Export important project variables [01:52] kyrofa https://github.com/snapcore/snapcraft/pull/757 tell me what you think [01:52] PR snapcraft#757: Export important project variables [01:52] elopio ^ === JanC is now known as Guest36120 === JanC_ is now known as JanC [02:15] elopio [02:15] elopio, ping [02:17] previously, on 15.04 ubuntu core, I used the command "sudo snappy hw-assign piglow.sideload /dev/i2c-1" to assign the hw to access the i2c device. On the series 16, we need to use interface, how can I assign the hardware? thank [02:21] does anyone know how to assign a hw on series 16? I used to do on 15.04 like "sudo snappy hw-assign piglow.sideload /dev/i2c-1". thanks [03:06] liuxg, no such capability exists right now. It will probably utilize hooks in some fashion, which also don't exist right now :) [03:07] liuxg, that said, you can access to some things via interfaces, as long as the paths don't change [03:07] kyrofa, in that case, I cannot do anything for the moment. I want to get the piglow working. my app is running, but it does not access the hardwware. [03:08] kyrofa, thanks for your reply on this. [03:09] liuxg, take a look here: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md [03:09] Do any of those cover your use-case? [03:12] kyrofa, for the i2c-1 device, it seems that it is not covered there. also for the current raspberry pi 2 device, the interfaces are http://paste.ubuntu.com/23087199/. previously, on 15.04, it seems to be more dynamic. as long as the device is available, we can always do the assignment. [03:13] liuxg, yeah, we'll get there [03:14] kyrofa, so, there will be a way to do that right? I think it should be generic instead of defining an interface for every device on the system. For example, I want to make use of the camera, the camera is there, but we cannot forecast how many more devices are there. on the contrary, the one on 15.04 is more flexible, and the command works for all [03:16] liuxg, I can't speak for the overall design, but things will definitely get more flexible with hooks === chihchun_afk is now known as chihchun [05:47] PR snapcraft#738 closed: nodjs, gulp plugins: use http_proxy to connect npm registry [06:51] PR snapd#1753 opened: asserts: Add an account-key-request assertion [07:04] PR snapd#1754 opened: tests: fix "tests/main/ack" to not break if asserts are alreay there [07:34] PR snapd#1754 closed: tests: fix "tests/main/ack" to not break if asserts are alreay there === ant_ is now known as Guest56195 [08:51] o/ [08:56] morning zyga [09:17] PR snapd#1755 opened: tests: remove snap confine workaround [09:18] ubuntu@dragonboard:~$ snap --version [09:18] snap 2.12+ppa199-1 [09:18] snapd 2.12+ppa199-1 [09:18] series 16 [09:18] ubuntu 16.04 [09:19] mvo, ^^^^ is that right ? [09:19] (i see 2.13+ppa206-1 on rpi) [09:22] mwhudson: good morning [09:22] mwhudson: I'm working on the namespace sharing feature in snap-confine [09:22] mwhudson: interested in reviewing the idea? [09:22] ogra: looks wrong, we should be on snapd 2.13 [09:23] ogra: I can have a look in a bit to ensure we really have 2.13 (or 2.13+something) [09:23] ogra: did the /etc/systemd/system.conf.d dir make it? [09:23] well, i just did an ubuntu-core rebuild since i thought it was a glitch in the edge PPA ... [09:23] yeah, the dirs are in [09:23] ("user" too) [09:24] ogra: yay! [09:25] ogra: thanks a bunch, plano people will love you for this [09:25] mvo, there you go https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial [09:25] doesnt build for all arches [09:25] (only amd64, armhf and i386) [09:25] ogra: oh, meh :( [09:28] mvo, i changed the arch list for that PPA, but s390x is missing yet ... (i guess i need to ping the LP team) [09:28] mvo, do you know how we can trigger a build ? [09:28] ogra: cool, I think thats not too terrible [09:30] mvo, oh, and btw, kernel snap builds work end to end too now, incvluding auto-upload and publishing (with a hacked snapcraft in the PPA though) [09:32] The whole Law is fulfilled in one statement: ‘You’ll love your neighbour as much as yourself’ - Galatians 5:14 [09:32] God bless you all and have fun using snappy! [09:35] what was that ? [09:40] PR snapd#1756 opened: asserts: add some stricter checks around format [09:42] ogra: yay [09:50] Bug #1616833 opened: need new interface: time-hardware [09:50] Bug #1616834 opened: need new interface: time-adjust [09:52] is there a "show me the generated apparmor and seccomp profile" shortcut - like being in tempfiles or even a command to show them? [10:04] Hi, I tried to disable getty on tty1 with: systemctl disable getty@tty1.service but it doesn't work, of course, previously I remounted filesystem on write mode. Ideas? [10:15] sorry, but is anybody there [10:15] ? [10:16] PR snapd#1755 closed: tests: remove snap confine workaround [10:20] youmin, only 290 people, why ? [10:20] youmin: sure there are, but most are busy hacking and only loock sometimes on chat :-) [10:21] ok, sorry... but I think I have a simple issue [10:21] when I disable getty on tty1 and I restart the system my configuration is lost, and of course I remounted the root partition [10:22] anybody has ideas about why? [10:22] youmin: I can only speak for myself that I don't know the answer - sorry - how is that snap related, do you do that from "iniside" your snap? [10:22] yes, I'm using dell gateway with snap [10:24] I'm afaraid you need to highlight a few more experienced users that can help or point you further - ogra zyga ^^ ? [10:24] cpaelzer, no idea about that, i would have to dig deep into ancient code, the dell gateways still run 15.04 i think [10:26] youmin, you could try to manually depete /etc/systemd/system/getty.target.wants/getty@tty1.service [10:26] *delete [10:27] orga: I did it, but I don't know why it appears again [10:35] elopio, can you trigger a snapd build in the edge channel, we just noticed it never built for all arches, i cahcnged that but dont know how to triggera build for the missing ones [10:39] I have created a snap for fswebcam (https://launchpad.net/ubuntu/+source/fswebcam) but it is a reserved name. I am not the project maintainer. Should I request the reserved name and transfer later if the maintainer wishes or use a new unique name like philroche-fswebcam? [10:45] zyga: ping [10:59] PR snapd#1746 closed: many: have AuthContext expose device store-id, serial and serial-proof signing to the store [11:00] PR snapd#1756 closed: asserts: add some stricter checks around format [11:04] Son_Goku: hello [11:04] Son_Goku: I saw your review, thank you [11:04] Son_Goku: I will do an upstream release rather than to switch to a snapshot if I can avoid it [11:09] zyga, also how are the patches coming for moving /snap? [11:09] Son_Goku: yes, all done, I just need to merge them upstream [11:10] hit the green button already then :P [11:10] Son_Goku: then I'll combine them into one patch to ship before the next release [11:10] Son_Goku: we just released last night but not everthing landed yet === hikiko is now known as hikiko|ln [11:10] Son_Goku: my patches are just for tests, everything else shoud be easy [11:10] Son_Goku: I need to look at snap-confine next, that is still a TODO [11:11] Son_Goku: but today I need to finish one feature (small but important), so I'm looking at snap-confine 1.0.41 and snapd 2.14 as the fedora target :) [11:11] cool === chihchun is now known as chihchun_afk [11:22] hi [11:23] notadeveloper: ho [11:24] hi cpaelzer [11:39] PR snapd#1743 closed: many: use make StripGlobalRootDir public [11:43] PR snapd#1738 closed: tests: the stable ubuntu-core snap has snap run support now [11:44] PR snapd#1751 closed: tests: add workaround for u-d-f to unblock all-snap image tests === hikiko|ln is now known as hikiko [12:15] I've uploaded a snap to myapps.developer.ubuntu.com (yesterday afternoon, 16 hours ago?) but can't snap install it yet; it's in devmode so I'm trying to install it with --beta but all I keep getting is snap not found === plars_ is now known as plars [12:25] how does one add dependencies (curl) to a plugin? === mup_ is now known as mup [12:30] PR snapd#1757 opened: asserts: authority-id and brand-id of serial must match [12:36] icey, are you installing with --beta or with --devmode ? [12:36] orga the snap is (I think) published on the beta channel [12:37] so you need both then [12:37] (you pshould know which channel you published to though ... the UI shows it on myapps...) [12:37] ok, it finds it now, but I get a 401 when downloading :) [12:38] that sounds like a bug ... is it actually published ? [12:40] myapps.delevelop.. says yes [12:41] ogra: ^ [12:41] whats the package name ? [12:41] * ogra will try to confirm your error [12:41] ogra: rust-coreutils === Tristit1a is now known as Tristitia [12:43] icey, looks fine to me http://paste.ubuntu.com/23088826/ [12:43] ogra: maybe I just tried too fast? [12:43] (apart from the fact thet the daemon cant start) [12:43] ogra: shouldn't be a daemon :) I'm working through my first snap :) [12:43] gah I stillg et a 401 [12:44] well, the systemd units :) [12:44] are you behind a proxy ? [12:44] ogra: https://paste.ubuntu.com/23088828/ [12:44] shouldn't be behind a proxy [12:46] icey, hmm, are you logged in (note that i am not and used sudo) [12:46] perhaps thats the deifference [12:46] I am logged in, and no sudo [12:46] so almost exactly different :-P [12:46] let me pop up a container [12:47] well, just use sudo [12:47] i guess that simply overrides the liogin [12:49] seems happy when not logged in, as root [12:49] ogra: [12:50] so there is something with the login credentials then i guess [12:50] not sure whom you need to poke for this [12:51] ogra: I'll just raise a bug :) [12:51] yeah [12:51] niemeyer: ping [12:51] that's why I'm snapping things anyway eh :) [12:55] pitti: can you help with a netplan question? https://github.com/snapcore/snapd/pull/1731/files#diff-52d12b07d34f6f20ac6190c87c325f8eR52 is the config what we generate (mwhduson to be precise), I use that and boot the system but no eth0 is coming up, how can I debug this? I fixed the verison:2 line? [12:55] PR snapd#1731: firstboot: generate netplan config rather than ifupdown [12:58] mvo: I already replied to mwhudson about that [12:58] pitti: oh, ok. where can I read that reply? [12:58] oh, he fixed the bad "dhcp4:" [12:59] mvo: oh, good point, that's another bug; "ethernets:" is on the same level as "version 2:" [13:00] mvo: easiest to just run "netplan generate" in the system and walk through the error messages [13:00] pitti: cool, thanks, that was all I needed [13:00] pitti: test is running now and will drop me in a debug shell in a minute, will figure it out, thanks for your help [13:03] pitti: yay, just the indent [13:04] mvo: Yet Another Moaning Language :) [13:04] switch to ini :P [13:04] PR snapd#1758 opened: Use netplan [13:05] ogra: and call them .network! [13:06] ! [13:06] jdstrand: hey [13:06] jdstrand: around? [13:06] tyhicks: or you? :) [13:06] mvo, that snapd package in the image PPA seems to come from some autobuild, do you know why ? [13:06] https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=snapd&field.status_filter=published&field.series_filter=xenial [13:07] Bug #1614177 changed: Can not connect cups-control interface [13:07] mvo, that looks like dupplication since elopio already builds it in the edge PPA [13:07] zyga: yes [13:14] sergiusens, your link is 404 (from the mail you just sent) [13:15] oh, because fo the spasec [13:15] *spaces [13:15] jdstrand: I'd like to discuss the namespace sharing thing [13:15] how crazy is that .... [13:15] jdstrand: can we do it here on irc with you and gustavo? [13:17] jdstrand: https://docs.google.com/document/d/13OoZKmVC-u3N-RskWTZeeZaO8Oz7N857bKnNA2RN-VQ/edit [13:17] jdstrand: this is my idea of how we can do this [13:17] zyga: yes, but I think tyhicks will want to be present too. he comes online in ~45 minutes [13:17] jdstrand: that's fine, we can postpone until he is around [13:18] pitti, we have a bunch of boards with wlan only or with wlan and eth ... we dont ship NM on ubuntu-core. will netplan be able to handle that (we use wpa-supplicant via ifupdown there atm) [13:19] pitti: could you please add http://paste.ubuntu.com/23088949/ to nplan? that would help snapd [13:19] ogra: in a meeting right now, we can talk later [13:19] ok [13:20] ogra: not ATM, wlan/wwan was supposed to be handled by NM [13:20] :( [13:20] thats not really mebedded firendly [13:21] *embedded friendly [13:21] (where size matters a lot) [13:21] ogra: we have a network-manager snap ready in the store you can just use for that [13:21] morphis, i dont want to use NM [13:21] and modem-manager as well [13:21] ogra: well, these discussion results are never final -- we build netplan as we want/need it, so it's certainly worth to file a bug at least and I'll check with slangasek/rharper etc. [13:21] ogra: what is wrong with it? [13:21] and i guess 90% f the embedded devs that use core wont want to use NM either [13:22] morphis, overheard ... [13:22] I thought the general direction was "drop ifupdown" [13:22] *overhead [13:22] morphis, you have a constantly running dbus service etc [13:22] mvo: hm, shipping empty directories? I don't mind much, but how does that help OOI? [13:22] ram, and disk space might be very limited [13:22] ogra: that is a froth and back discussion, but in the end you want something which does some more management than just a few shells cripts [13:23] even on IoT devices [13:23] pitti: its about the writable path handling, we can workaround this if you want (or if you don't want the empty dir) [13:23] Nest is using connman for a very good reason on their devices [13:23] ogra: if you only need a static configuration, it might just be enough to drive wpasupplicant, not necessarily ifupdown or NM, I figure? [13:23] morphis, well, adding wpa-ssid and wpa-psk to /e/n/i is enough mgmt for such devices usually [13:23] ogra: i. e. some people actually do use networkd with wifi, it's just not very user friendly (no GUI etc.) -- but we don't care about that, and we don't have a gui with ifupdown either [13:23] mvo: oh, I see [13:24] pitti: for ubuntu-core we create a writable directory in the writable space and we need a mountpoint, this is why we need the dir, but I can workaround if needed [13:24] pitti, well, it isnt static usually but dhcp ... but yeah, indeed ssid and psk need to be seeded [13:24] pitti: one more hack in livecd-rootfs :) [13:24] ogra: that still does the case where you want a lot more extended features [13:24] * ogra cries a little reading mvo's last line [13:24] ogra: but I agree, its a per use case decision [13:24] ogra: I cry a lot everytime I look at this code ;) [13:24] ogra: sorry, I meant "static" in the sense of "fixed config files with fixed AP and password" [13:24] morphis, right, i think netplan should support the non-NM case for wlan too [13:25] pitti, yeah [13:25] ogra: any concerns about the netplan landing? I'm keen to get it in today [13:25] drwxr-xr-x root/root 0 2016-08-19 19:10 ./etc/netplan/ [13:25] mvo, not beyond ... "hey, i'm just trying to SRU livecd-rootfs" :) [13:25] mvo, ogra, pitti: not sure, but did you do any testing with netplan and the nm snap to ensure both work fine together? [13:26] and the patch will be gigantic, infinity will hate me forever [13:26] mvo: https://git.launchpad.net/~netplan-developers/netplan/commit/?id=3ec75ae5 [13:26] morphis, not me [13:26] mvo: but I can't upload it right now due to beta freeze [13:26] pitti: \o/ - no worries [13:26] pitti, we have our own archive ;) [13:27] mvo, ogra: heh -- if you upload it to that, please don't call it 0.10, but 0.9something [13:27] (and are focused on xenial ... landing yakkety later is always fine) [13:27] oh [13:27] note that xenial's NM does NOT work with netplan [13:28] pitti, x.y.z-0ubuntuX+ppaX [13:28] is what we usually do [13:28] the package has Breaks: network-manager (<< 1.2.2-0ubuntu4~) for a good reason [13:28] ouch [13:28] so we need to backport a couple of fixes and adjustments for that [13:28] i doubt we can easily SRU the new NM ? [13:28] s_langasek mentioned yesterday that we want to do that [13:28] oh, we can [13:28] SMOP [13:28] heh, k [13:28] any good documentation on the interfaces available to snaps, or ways to access more unrestricted things (without --devmode)? [13:28] it's nothing earthshattering, just a bug fix or two and adding support for /run/NetworkManager/ config files [13:29] icey: hey, you can look at docs/interfaces.md [13:29] ogra: well, not really "P"rogramming, more like "P"aperwork :) [13:29] icey: you can request any interface, right now that will block you in the store for a manaul review if the interface is too "powerful: [13:29] icey: I believe soon we will also use assertions for that [13:29] pitti, heh, yeah, i know what you mean ... tyring to SRUall of https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial [13:29] zyga: the thing I'm trying to snap is the rust coreutils package, which ( I think) basically means it needs the world [13:29] PR snapd#1750 closed: store: request device session macaroon from store [13:30] ogra: can you please file a wishlist bug about wifi support? [13:30] this hasn't come up so far [13:30] icey: world? [13:30] icey: what does it need [13:30] pitti, netplan package or is there an upstream project ? [13:30] ogra: nplan package is fine; https://bugs.launchpad.net/netplan also exists [13:31] zyga: look through the list of folders at https://github.com/uutils/coreutils/tree/master/src ; it's a cross platform implementation of all of those [13:31] ok [13:31] so [13:31] but distro package is usually better, auto-closing of bugs and you knwo when it is really "in" [13:31] complete filesystem access, for one [13:33] pitti, uuuh ... there is a binary called netplan (from petter's "plan" package), did you know that ? [13:33] ogra: I do, that's why the package is called "nplan" :( [13:33] https://launchpad.net/ubuntu/+source/plan [13:33] ah [13:34] icey: that can be done with a sufficiently strong interface [13:34] long discussion, executive decision etc. pp. [13:34] icey: but also, remember about the chroot [13:34] ogra: in the end it doesn't matter that much as nplan is installed by default [13:34] Bug #1602845 changed: unity7 interface does not work with libnotify [13:34] yeah [13:34] i just remember all the issues we have with the snappy mediaplayer :) [13:34] zyga: would it be possible for the command snapped to use something like $(pwd) as the run location? MOST of the coreutils act on either the specified location, or . [13:35] icey: http://www.zygoon.pl/2016/08/snap-execution-environment.html [13:35] icey: they all do [13:35] icey: but read that first please [13:35] zyga will do :) [13:35] I'm sure I'll be back in a bit :) [13:36] icey: one thing has changed since, we now chdir to /var/lib/snapd/void instead of refusing to run when we cannot preserve the working directory [13:36] icey: it's better in practice [13:38] * zyga -> coffee break [13:39] pitti, bug 1616928 [13:40] Bug #1616928: netplan should support managing wlan devices via wpasupplicant and ifupdown [13:40] ogra: I suppose ifupdown is not actually a requirement (I'd really rather not have that), just "get my effing wifi working" [13:40] pitti, yeah, just without any overhead [13:41] question on snap daemons, how do you stop a daemon:forking snap from the command line? [13:41] (if you have only 128MB ram you really dont want to have NM and dbus running all the time [13:41] ) [13:41] use the snap binary or systemd (I don't see my snap listed in services --all-status) [13:41] ogra: yep, agreed; I'll have a look how this can be made to work [13:42] little reason to have the ifupdown wrapper around it, it could just generate a wpasupplicant conf directly [13:42] josvaz, systemct ... [13:42] l [13:42] ok [13:43] there used to be a "snap service" command, but that got dropped (i think it will return eventually, but is currently not there) [13:44] thanks [13:45] this doesn't even seem to be happy in devmode: http://pastebin.ubuntu.com/23089017/ [13:51] can somebody review my "sluice" snap, it's been pending since monday [13:59] ogra: https://bbs.archlinux.org/viewtopic.php?id=178625 sounds promising -- apparently Arch has a wpasupplicant@.service which DTRT (we don't, but I can't imagine it is rocket science) [13:59] ogra: essentially, we just need to start it once the interface comes up, which can be done with a relatively simple udev rule even [13:59] Odd_Bloke: so, this seems doable indeed [14:00] Odd_Bloke: sorry, meant ogra [14:00] pitti: :) [14:00] IRC clearly isn't clever enough -- what is all this talk about smart devices?? [14:01] ogra_ you can thank dekko from breaking urls ;-) === al_ is now known as Guest37767 [14:29] I have a question regarding the connection of my snap to a USB flash drive. With the "strict confinement" option, using the plugs "home", I can't access to the usb flash drive. Is there an other interface to connect to the usb ports ? [14:31] PR snapd#1731 closed: firstboot: generate netplan config rather than ifupdown [14:31] PR snapd#1757 closed: asserts: authority-id and brand-id of serial must match [14:33] tyhicks, jdstrand: do you have a moment to discuss the ns sharing design [14:33] mhall119: hey, didrocks seems afk, is there someone who can look at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7 ? [14:33] PR ubuntu/snapcraft-desktop-helpers#7: common/desktop-exports: don't dereference target symlink on upgrades [14:34] zyga: yes, I'm reviewing the doc now [14:34] mhall119: feel free to direct me to whoever [14:34] tyhicks: thank you, we don't have to have a hangout or anything, just give me feedback and suggestions please [14:35] jdstrand: not sure I'm qualified to give a "looks good" on that, but your explanation of the issue and fix sounds reasonable [14:38] zyga: This is significantly more complex than what I hoped for [14:38] cc jdstrand tyhicks [14:39] niemeyer: ideas welcome, this is the most basic version that lets us share the mount namespace IMHO [14:40] zyga: can you make that a numbered list so it is easier to speak to? [14:40] yes, sure [14:40] ne [14:40] done [14:41] thanks [14:41] so the gist of this is 4 and 6 [14:41] 4 gets us what to give to 6 [14:41] correct [14:42] the rest is just implementation detail, apart from the fork that is mandatory [14:42] and the rest is how to get there safely and cleanup [14:42] (because of how the mount namespace is diffrent from other namespaces, apparently) [14:42] (i.e. you cannot just bind mount it directly unlike the others) [14:44] will snapd know which snaps need to share namespaces? [14:44] so, 1 is about creating the mountpoint in a non-racy way. if I am in 1b, what is the next step? [14:44] tyhicks: AFAIK the design is that all processes belonging to a given snap share a namespace, if desired this can be delegated to an interface later [14:45] jdstrand: if you "lose" you spin lock on the files you'd open in 6 to become symlinks and then proceed [14:45] jdstrand: we can switch from spinlock to anything that lets them coordinate [14:46] zyga: so, once symlink is there, go to step 6 [14:46] (might be nice to capture that) [14:46]