=== JanC is now known as Guest69133 === JanC_ is now known as JanC === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [04:21] how we can run nodejs based application on ubuntu snap ? any link for how to translate nodejs app to snapcraft based app === chihchun_afk is now known as chihchun [08:28] does anyone know the correct usage for using config-flags with autotools plugin ? [09:04] @any * [09:04] driftwoof: No such command! [11:19] re [11:20] sorry, had a power failure last night and didn't realize my server was down [11:50] Mirv, would you mind reviewing https://github.com/ubuntu/snapcraft-desktop-helpers/pull/39 ? [11:54] oSoMoN: done, indeed it makes sense. I don't have commit rights though. [11:55] Mirv, thanks [12:02] barry: just wonder if autopkgtest of ubuntu-image 0.14 is broken at this moment? === hikiko is now known as hikiko|ln [12:03] barry: some tests are failing, not sure it's caused by build environment or its just does not work in this release? https://gist.github.com/chihchun/59c4845da7b493c0e26ccfe2b5224e08 === chihchun is now known as chihchun_afk === hikiko|ln is now known as hikiko [13:45] what bugs are blocking snapd 2.21 from reaching updates? [13:47] none [13:47] the SRU was just set to verification-done [13:47] ok cool [13:47] next run of the SRU team should move it to updates [13:48] ogra_, perfect, thanks [13:48] * stokachu getting anxious [14:21] Hi folks; I've got a question regarding a snap packaging. It's quite simple, but I've not found the answer yet. How do you guys handle a configuration files of your software within your packages? [14:21] as long as $SNAP root directory is read-only, how can I copy it (in the installation phase of snap app) to the writable directory, so end-user could modify the configuration file on his own? [14:22] i [14:22] is it even possible? [14:22] tito_: hey [14:22] tito_: it all depends on what kind of software stack are you dealing with [14:23] tito_: on one extreme end there are pre-built debian packages that keep everything in /etc and have no way to look elsewehre [14:23] tito_, you can create configuration hooks in your snap that call scripts/tools in the backend to adjust app configuration and are managed via snap set/get commands [14:23] http://snapcraft.io/docs/build-snaps/hooks has some docs about this [14:23] tito_: on the other extreme end you can have software that was built to understand snappy and the configure hook and read-only code / writable data [14:23] tito_: most real software falls in the middle [14:23] yeah [14:24] tito_: you can typicall pass configuration to daemons / services [14:24] tito_: so even if the hard-coded defaults are in /etc/foo, you specifiy `foo -c $SNAP_DATA/foo.cfg` [14:24] tito_: you can copy good defaults from your snap ($SNAP) to $SNAP_DATA on start-up (if they are missing) [14:24] tito_: you can patch software to be smarted abotu all of this [14:25] tito_: on top of that snappy supports per-snap configuration [14:25] tito_: so you can give users unified way to configure something [14:25] tito_: (unified across snaps) [14:25] tito_: this translates to the configure hook [14:25] correct [14:25] tito_: that system is more complex but also ultimately better [14:25] tito_: (I don't know if we have docs for that) [14:26] zyga: [14:26] ogra: [14:26] thanks!: ) [14:26] so [14:26] is it a good way to copy the configuration file [14:26] to $SNAP_DATA [14:26] in a command wrapper ? [14:26] just copy it in a wraper [14:26] yeah [14:26] right [14:26] ok [14:26] aha ok - so the last question then [14:26] (for now :D) [14:27] how do you deal with custom wrappers ? [14:27] I am sure that I am doing it wrong [14:27] but here are my steps: [14:27] 1. normally,when snapcraft.yaml is done i perform: snapcraft command [14:27] tito_: I copy them to /usr/bin and use them from snapcraft.yaml instead of my comman [14:27] command* [14:27] it creates all prime stuff etc [14:28] then I modify the prime/command-wrapper [14:28] tito_: no, don't edit snapcraft-generated wrappers, you will just waste your time [14:28] and perform another snap packaging with: snapcraft snap prime/ [14:28] SUX right? [14:28] tito_: as I said :) [14:28] tito_: you can use a simple dump part [14:28] tito_: that copies your wrapepr over [14:28] tito_: or a simple makefile part [14:28] tito_: (I prefer makefiles) [14:28] so [14:29] when I will eventually type on a ubuntu core system [14:29] snap_name.command [14:29] will it look first in usr/bin ? [14:29] (For the wrapper) [14:29] no [14:29] hm [14:29] it will look at snap.yaml [14:29] and run that [14:29] that will run the generated wrapper [14:29] yes [14:30] then that wrapper can run what you specified [14:30] chihchun_afk: 0.14 should pass its autopkgtests. it did in zesty because it's in the main archive, and it actually does in x and y too because they're in proposed waiting for sru approval (but they pass their tests). curious to hear more details about your failures [14:30] just call it foo.wrapper [14:30] and in that generated wrapper calls another one ? [14:30] and expose it as "foo" app [14:30] yep [14:30] ok [14:30] so another level of inception :D [14:30] Ok ok [14:30] now I get it [14:30] deception ;) [14:30] anyway - I like this stuff, great work [14:32] * zyga gets back to content interface [14:32] btw. ok last, really last question. [14:33] Is it possible to update snapd over snap or it is "to core" in the OS ? [14:33] hmm? [14:33] we're planning to spit the core snap into a core snap and a base snap [14:33] Why I am asking. I want to develop custom interface [14:33] where >1 base is available [14:33] and test it on the machine that is not my developer machine [14:33] for that, the answer is: do it upstream [14:33] you can easily test that, we have tools for it [14:34] https://github.com/snapcore/snapd/pull/2709#pullrequestreview-18381601 [14:34] hmm [14:34] bad link [14:34] https://github.com/zyga/devtools [14:34] tito_: ^^ [14:34] may be somewhat stale but still works ok [14:34] should work ok [14:35] tito_: once snapd and base snap are separate the process may change [14:35] tito_: no ETA on that yet [14:35] (but I like the ability to use other base snaps) [14:35] e.g. debian base or fedora base [14:35] (insert joke about fedora core) [14:35] lol [14:35] hey [14:35] I will go over this thanks [14:35] but when I think now [14:35] good luck, ping if you get stuck [14:36] about copying [14:36] configuration stuff in a command wrapper [14:36] then I think that it won't work [14:36] eg, [14:36] when user changes the copied configuration file [14:36] it will be overwritten on a second command wrapper run [14:36] right ? :D [14:36] you can only copy it if it's not there, obviously [14:37] GOOD ONE! [14:37] and if you do it so that the config hook manages all the changes [14:37] you can even do sensible updates with new revisions of your snap [14:38] ok, thanks guys [14:38] once again. [14:40] ogra_: http://es.farnell.com/bitscope/bb01b/bitscope-blade-uno/dp/2546576 [14:40] ogra_: or maybe https://es.farnell.com/MarketingProductList?orderCode=2546576,2546577,2546578&COM=referral-handler&CMP=SOM-FACEBOOK-PRG-NPI-BITSCOPE-BLADE-TRANS-GBL [14:40] ogra_: pi ... rack? [14:40] ogra_: doesn't support pi 3 (probably just not tested) but supports pi2 [14:40] well, you need a blade chassis for that [14:41] but yeah, pretty cool [14:41] they have one [14:41] * zyga looks [14:43] https://es.farnell.com/MarketingProductList?orderCode=2546576,2546577,2546578&COM=referral-handler&CMP=SOM-FACEBOOK-PRG-NPI-BITSCOPE-BLADE-TRANS-GBL [14:43] gah [14:44] still wrong link [14:45] ogra_: http://www.bitscope.com/product/blade/?p=about [14:45] yeah [14:46] http://bitscope.com/product/blade/03.jpg [14:48] ogra_: the money link is http://my.bitscope.com/store/?p=list&a=list&i=cat+3 === ant_ is now known as ant__ [15:45] jdstrand: hey [15:46] jdstrand: I was looking at raw-usb and I see it doesn't work unless your USB devices are on the PCI bus [15:46] jdstrand: any objection to let it allow access to things like: /sys/devices/platform/soc/3f980000.usb/usb1/idVendor [15:47] jdstrand: so e.g. /sys/devices/platform/soc/*.usb/usb[0-9]** r, [16:11] zyga, ogra_: if you guys are thinking of making a beowulf cluster of raspis (or some such), you may be interested in the raspi compute module: http://arstechnica.com/information-technology/2017/01/raspberry-pi-upgrades-compute-module-with-10-times-the-cpu-performance/ [16:11] yeah, i thought of that [16:12] here's more info on the old one: https://www.raspberrypi.org/blog/raspberry-pi-compute-module-new-product/ [16:12] when zyga showed the above :) [16:12] but for that you also need a case with slots and power supplies [16:13] alecu: I'm well aware of those [16:13] alecu: just hard to get and not as flexible for *testing* PI [16:13] great :-) [16:13] i wonder if the blade setup doent come out cheaper in the end if you sum up all the bits you need [16:13] ogra_: yeah, that's likely. [16:15] blade also supports hats and allows for more flexible test setup [16:15] compue feels like an embedded/cloud thing [16:40] jdstrand: https://github.com/snapcore/snapd/pull/2716 [16:41] jdstrand: that's a one liner [16:42] jdstrand: if you can review that quickly it would make it into the next release [17:16] ogra_, kgunn : we were talking to Robert Wolff from linaro yesterday. He has a live show on thursdays, and he would like to talk about ubuntu core. Would you like to join him and show the dragonboard image and kiosk? [17:18] i havent used the dragonboard image as kiosk setup yet ... only pi [17:18] ogra_: you can just present the image part. And leave the kiosk part to kgunn . [17:19] hmm ... k [17:19] he apparently wants to do two or three separate shows. [17:19] when would that be (i assume not ad-hoc tomorrow ?) [17:19] ogra_: he said february. The 2nd or 16th, I think. [17:20] that works [17:20] and I'm not sure about the third show. Maybe we can talk about snapcraft, but that's not really related to the dragonboard. We would have to make something up. [17:21] ogra_: great! I'll tell him. I can help you if you need something, and maybe kyrofa too (?). [17:21] we can at least join the video conference and cheer you. [17:22] cool, just get me in the conversation loop [17:23] yes. He said he will send more details on Friday. And he even mentioned about giving away some dragonboards with ubuntu core preinstalled to the attendees :) [17:23] whee ! [17:23] well, to a few attendees. [17:26] ogra_: and what about making an ubuntu testing day with us on the 10th ? :D [17:33] elopio, sure [17:34] ogra_: woohoo, you will get many new fans :) Please choose a time that's good for you on the 10th, and I will add it to the ubuntu on air calendar. [17:35] 14:00 UTC [17:35] (or later) [17:36] ogra_: I think 14 it's too early for kyrofa. 16UTC ? [17:36] thats fine [17:37] elopio, ogra_ yes thank you :P [18:34] zyga: looking [20:02] noise][: I'm still working with your sample store, now i'm traying to use the download functionality but i'm getting the following error from the snapd: "error: Get : unsupported protocol scheme """ [20:02] noise][: any ideas ? [20:03] was that on doing 'snap install foo'? and what did you set for the URL in /etc/environment? [20:05] noise: my /etc/environment "SNAPPY_FORCE_CPI_URL=http://localhost/api/v1/" [20:05] noise][: and i was running snap download [20:10] azubieta: is your snapstore running on port 80? default is 5000, i.e. SNAPPY_FORCE_CPI_URL=http://localhost:5000/api/v1/ [20:11] but as noted before, you will still get blocked after that when snapd tried to download and verify assertions for the local snaps ("error: cannot fetch snap signatures/assertions") [20:11] noise][: so i can't use the download command either ? [20:12] it does successfully download the snap and then fail after trying to get the assertion [20:13] noise][: so i'll not get my file to later run snap install on it [20:13] so e.g. this is working for me: snap download foobar25; snap install foobar25_1.snap --dangerous [20:14] noise][: mmm, which code are you using? the master branch on github ? [20:14] metadata_tests branch [20:15] i need to find a bit of time to get that merged [20:15] noise][: letme try with that [20:16] niemeyer: hello, I'm trying to pick up the unity8 interface work that tedg started. kgunn suggested to me that I try to land an incomplete version of it in snapd and iterate on it from there to at least drive down apparmor warnings, even if it doesn't work yet. It seems that you folks generally prefer things to land only once they're complete, but I was [20:16] curious if you had particular feelings on the above strategy in unity8's case. The current WIP branch doesn't let apps run confined yet, but having it in trunk--even partially--might ease releasing our own apps that try to use it unconfined since it would be a known interface [20:19] mterry: note that it being a known interface should not be a problem with the store. I have added a special case in the review tools so that the 'unity8' does not block approval [20:19] jdstrand: ah cool, I thought we were able to land in edge only. That's good news [20:20] Well driving down warnings and getting wider testing are still reasons to maybe land a partial interface [20:21] mterry: my two cents if niemeyer agrees> I would try to focus on slot side permanent policy and not do any policy for plugs. make it so you can run unity8 in strict mode so that your apparmor policy denials are gone [20:21] But I don't know the side effects of updating an interface after the fact [20:22] noise][: it seems that my snap command is ignoring the port on the enviroment path and is giving my the following error: cannot find snap "bar": Get http://localhost/api/v1/snaps/details/bar?channel=: dial tcp [::1]:80: getsockopt: connection refused [20:22] mterry (cc niemeyer): then we document that the interface allows unity8 to run but doesn't allow snaps to connect to it yet. this way, the interface offers no 'holes' in the security policy. you install it and apps in devmode [20:22] jdstrand: the slot side policy, it looked to me like it's only used once there is at least one connection to a plug? [20:23] mterry: there are slots and plugs and there is permanent and connected policy [20:23] jdstrand: but OK that's good advice, I had been coming at the problem from the other side (the plug side) [20:23] jdstrand: ah right that makes sense [20:24] mterry: permanent slot policy is the policy that is needed for the snap to run at all. connected slot policy and connected plug policy are what are used to make snaps talk to each other [20:24] jdstrand: well OK that's a strategy I can pursue. Doesn't help the apps for a while, but I think getting closer to landing anything is good [20:24] mterry: Heya [20:24] mterry: We actually always land big changes in small chunks rather than at once [20:25] jdstrand: thanks for the review :) [20:25] azubieta: did you restart snapd after fixing the port in the config? (sudo service snapd restart) [20:25] mterry: I suspect you would be able to easily add some connected policy for common cases [20:26] mterry: eg, for say something simple like a calculator to run (ie, don't need the whole breadth of Touch policy) [20:27] mterry: So polishing over time seems fine.. we should also have that strictly bound to unity8 itself via assertions, so the risk of creating problems by the organic landing is pretty much nil [20:27] noise][: yes! twice [20:27] mterry: that would cut down the policy denials by a huge amount. then chip away at the various wervice sin followup PRs [20:28] s/wervice sin/services in/ [20:28] zyga: np [20:28] noise][: "snap find bar" does work but "snap download bar" desen't [20:31] mterry: by assertions, niemeyer is saying make the base declaration restricted such that a snap declaration is required to use the interface at all [20:31] mterry: then in the store we say what snaps can connect to unity8 [20:32] niemeyer, jdstrand: OK. So I'll work on a bare bones (maybe empty) starting unity8 interface (that is restricted by assertion) and work that to a landing (so we can remove jdstrand's special case in the store at least). Then I can focus on the slot side, and eventually plug side over future PRs [20:32] mterry: at a later date we lift the base declaration restriction when the interface is deemed 'safe' [20:32] noise][: by the way my "snap --version snap 2.20+git44.gdf4776c05 snapd 2.20+git44.gdf4776c05 series 16 debian 9" [20:33] niemeyer: that's a nice idea for rolling out a partial interface btw [20:34] jdstrand: please add this to your queue, unfinished but I'd like to see what you think: https://github.com/snapcore/snapd/pull/2718 [20:35] jdstrand: as well as (lower priority) https://github.com/snapcore/snapd/pull/2658 [20:36] zyga: the second is in the queue. thank you for letting me know its relative priority [20:36] * jdstrand adds 2718 [20:37] jdstrand: thanks [20:45] mhall119: https://github.com/nickgermaine/Eden-Browser.git [20:45] that would be cool with sitter's new kde fw snap content [20:50] noise][: sorry i went offline, I was testing in another enviroment, I had to reboot the whole system in order to make it work now i'm getting the same error as you but the snap is being downloaded [20:52] azubieta: great! i mean as far as things are at the moment at least :) [20:53] noise][: thanks !! I'll keep working on the store I'm considering make an interface for management with django [22:38] mwhudson, console-conf is taking foreeeeevvvvvaaaar to contact the store on the dragonboard. What exactly is happening? [22:38] kyrofa: i don't know! [22:38] kyrofa: it doesn't happen all the time [22:38] Oh you've experienced this as well? [22:38] yes [22:38] Huh. [22:39] but never when i've got SNAPD_DEBUG_HTTP=4 or whatever it is set [22:39] Interesting! [22:39] kyrofa: as far as i can tell it's just the something in the networking stack being really slow [22:39] I hate those turn on debugging -> problem goes away problems [22:39] kyrofa: have a look in syslog/journalctl after it completes? [22:39] mwhudson, sure thing [22:40] (assuming it does, iirc it always does for me) [22:40] can take 2-3 mins though [22:40] Took me like 10. But yeah, for the second time, completes fine [22:40] huh [22:41] mwhudson, is the wifi useless for you, too? [22:41] kyrofa: um, it kinda works sorta, i haven't pushed it a lot? [22:42] i also haven't tried anything at all with it for a good few weeks [22:42] mwhudson, whenever I made it "do" anything (enable classic, or apt update in classic) it just goes down. I reflashed to I could run console-conf again on my ethernet adapter instead [22:42] kyrofa: hmm [22:45] kyrofa: lovely lovely devboard experience i guess [22:45] mwhudson, I see a LOT of these types of messages: /usr/lib/snapd/snapd[1510]: booted.go:81: cannot get info for "dragonboard-kernel": cannot find snap "dragonboard-kernel" [22:45] Normal? [22:45] kyrofa, bug 1638537 [22:45] (just looking for out-of-the-ordinary things that could cause the slowness) [22:45] * ogra_ tickles the bot [22:45] ogra_, yeah it's been sad the last few days [22:46] its been sad forever [22:46] ogra_, oh! [22:46] oh, i meant thee image, not the bot :) [22:46] Well, "please press enter" actually came up pretty quick for me. Everything works fine until I enter my SSO email address and hit "go" [22:46] yeah [22:47] the press enter comes up fast since we started generating the pyc files at image creation [22:47] Ahh, okay [22:47] but snapd is still eating the system [22:48] also the dragonboard is ~10 times faster than a bbb :) [22:48] its all snappy and fast once it is through console-conf [22:48] Yikes [22:48] mwhudson, i see it on all arm boards [22:48] Wonder what snapd is doing [22:50] producing I/O :) [22:50] Hahaha [22:53] ogra_, is /etc/network writable? [22:54] hmm, might only be /etc/network/interfaces.d ... one sec [22:54] Yeah that's really what I was asking-- can I still configure interfaces that way? [22:54] ogra@localhost:~$ grep network /etc/system-image/writable-paths [22:54] bah [22:54] sill yIRC [22:55] ogra@localhost:~$ grep network /etc/system-image/writable-paths [22:55] /etc/network/interfaces.d auto persistent transition none [22:55] /etc/network/if-up.d auto persistent transition none [22:55] /etc/systemd/network auto persistent transition none [22:55] there we go [22:55] kyrofa: that message is because until we are first booted, the kernel and core refs in the boot loader env don't make sense to snapd yet... I think we can avoid those though [22:55] Oh! I didn't know that file existed, awesome [22:55] i'm about to move it one level up though [22:55] pedronis, I was just trying to figure out what was causing the slowdown. Do you think that's it? [22:56] I don't know [22:56] just saying that for sure it will spam logs [22:56] which is bad anyway [22:56] Indeed [22:56] Well, the slowdown doesn't provide for the best out-of-the-box experience. https://bugs.launchpad.net/snappy/+bug/1638537 has no responses [22:57] there iis a trello card ... i guess an strace session is due [22:59] it could be related to netplan/console-conf updating the network but not really switching to the new config without reboot [23:00] you get an IP thats coming from networkd on boot before console-conf runs ... usually the system keeps that instead of downing/upping the interface [23:01] i could imagine that snapd gets confused by that or so [23:06] niemeyer, looks like mup dropped off here ... [23:09] * ogra_ vanishes into the night again