[06:05] hello [06:06] what's purpurse this forum? [06:07] are there any live guys? [06:12] PR snapd#3547 closed: snap-seccomp: skip socket() tests on systems that use socketcall() instead of socket() [08:11] PR snapd#3533 closed: tests: extend find-private test to cover more cases [08:16] hmpf ... [08:18] mouse battery died .. with no warning, nothing ... takes me ten minutes to find new batteries ... when i return to my desktop a warning about my mouse battery being low pops up ... tsk ... [08:18] (would really help to have warnings *before* the events happen :P ) [08:23] popey, what they call "ubuntu-core" is actually some self-bootstrapped classic install... i think the friendlyarm wiki should actually have an image linked for the air ... === chihchun_afk is now known as chihchun [08:27] looks like http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air should have something [08:34] popey, and here we go ... "NanoPi NEO AIR has an Ampak AP6212 chip, which needs special firmware files" ... http://linux-sunxi.org/FriendlyARM_NanoPi_NEO_%26_AIR [08:35] (it is a broadcom device as i suspected (ampak builds chips around broadcom stuff usually) [09:03] PR snapd#3530 closed: cmd/snap: include snap type in notes [09:03] PR snapd#3540 closed: overlord/state: Abort() only visits each task once === chihchun is now known as chihchun_afk [11:01] Could somebody please retry https://travis-ci.org/snapcore/snapd/builds/248376205 ? I don't think the timeout is the fault of my PR. [11:11] Morning all [11:11] cjwatson: Looking [11:12] ta [11:12] cjwatson: Restarted.. there are MBR errors in the log.. Linode seems to have broken their image feature in the last 10 days or so [11:13] They're investigating [11:13] We'll give them one more week or so, and if they can't get it together we'll move elsewhere [11:14] niemeyer: does that mean we'll have a new backend for spread in about a week? :-) [11:14] niemeyer: how was your trip back, btw? [11:14] Chipaca: Well, it means I'll start working on one in a week :) [11:14] Chipaca: It was as good as it gets :) [11:15] Chipaca: Thanks for asking.. I'd guess yours was even better? :P [11:15] niemeyer: I can't comment === chihchun_afk is now known as chihchun [11:20] PR snapcraft#1389 opened: Use newer distro module with no tuple === chihchun is now known as chihchun_afk [11:57] niemeyer: hey, i see some lines in linode like "Cannot allocate linode:ubuntu-16.04-64: cannot create Linode disk with ubuntu-16.04-64: you do not have enough unallocated storage to create this Disk (608 requested, but only 0 available)" (https://travis-ci.org/snapcore/snapd/builds/249550256#L712). anything we can do about this? [11:58] niemeyer: also in the same run in line 816: Cannot allocate linode:ubuntu-core-16-64: cannot boot linode:ubuntu-core-16-64 (Spread-64): cannot Direct Disk boot a disk with no MBR: - do we need to update a config there maybe? [12:00] mvo: What machines are you seeing this in? I'll have a look [12:01] mvo: The second issue is known and has been reported late last week [12:02] niemeyer: spread-33, spread-70, spread-52 seems to be candidates [12:03] mvo: Thanks, I'll do a complete pass [12:03] mvo: These are likely follow ups from the primary issue of thawing images being broken [12:04] niemeyer: thank you! === chihchun_afk is now known as chihchun [12:10] mvo: np, I could find a single machine where there was space issues, Spread-14 [12:11] niemeyer: that matches the log its right before the error message [12:11] niemeyer: shall I restart? [12:11] mvo: Ok, we're good then, thanks for the note [12:11] mvo: Yeah.. although note that I think Linode is still broken in terms of image thawing, so it may be a bit frustrating still [12:11] mvo: Please let me know if you see other/unknown issues [12:17] niemeyer: thank you, will do === chihchun is now known as chihchun_afk [13:03] Bug #1702095 opened: snap enable removes complain for daemons [13:59] * pedronis break [14:29] PR snapcraft#1369 closed: Handle I/O errors in os.link (LP: #1689956) [14:47] PR snapd#3549 opened: many: epose services commands for snap services [14:48] anybody looking to review that ^ please let me know if you'd rather I split it into individual PRs (or maybe 1 for osutil&systemd changes, one for daemon&cleint&cmd/snap changes) [14:48] each commit stands on its own (and on those coming before it) [14:50] it is bigly [14:57] PR snapd#3550 opened: update firewall-control to allow {arp,ip,ip6}tables to control bridged vlan/ppoe-tagged traffic [14:58] pedronis: ok, adding an intermediate PR with osutil&systemd, let's see how that split works [15:00] PR snapd#3551 opened: systemd, osutil: rework systemd logs in preparation for services commands [15:04] pedronis: ^ there [15:04] not sure it helped much :-) [15:05] Chipaca: it didn't :) [15:06] so maybe up to daemon and client and cmd/snap ? [15:06] (I don't know how big each checkin is) [15:06] pedronis: the commits are separate, and would be the PRs [15:06] anyway, maybe ignore me, not sure I'm going to look at it today [15:07] pedronis: daemon: +625 −7 [15:07] pedronis: client: +335 −0 [15:07] pedronis: cmd/snap: +218 −0 [15:07] ¯\_(ツ)_/¯ [15:07] ok, so 3 PRs would be reasonable [15:07] or 2 PRS [15:07] pedronis: osutil+systemd, daemon, cmd+client? [15:07] yes [15:07] on my way [15:09] PR snapd#3552 opened: daemon: implement service commands === pbek_ is now known as pbek [15:15] ogra_: are the uboot version for the pi2/pi3 snaps similar/the-same or different? the timestamps indicate similar versions, is that the case? [15:16] yeah, similar (same tag/branch) but different builds [15:16] ogra_: cool, thank you - same tag/branch is all the info I need [15:17] i'm planning to move them all to "build directly from upstream source" soon ... then you can just check the branch version in snapcraft.yaml in the future [15:17] ta [15:18] (should both be v2017.01) [15:25] niemeyer: http://i.imgur.com/gPbCUdF.png [15:26] Chipaca: hahaha [15:27] mvo: i take it i wasn't too subtle then :-D [15:27] (this is via https://dev.to/rly fwiw) [15:28] Chipaca: great stuff [15:32] Chipaca: We may be about to write the last chapter :) [15:59] PR snapcraft#1377 closed: kernel plugin: add default targets per powerpc, ppc64el and s390x [16:08] PR snapcraft#1390 opened: meta: bash completion support [16:15] * Chipaca hugs sergiusens [16:17] sergiusens: we were talking about that the other day while I was walking across London, and I don't know if we finished that conversation [16:18] Chipaca: I was walking as well ;-) [16:18] fwiw, I think this needs to be automatic, also, I searched for complete.sh in the defined locations from your blog post and could not find it [16:19] sergiusens: the release of snapd that has that has not reached ubuntu yet [16:19] sergiusens: which is why i haven't worked on making it more automatic [16:19] Chipaca: hmm, I was told it had.. :-( [16:19] stgraber: fyi ^ [16:20] sergiusens: but you'll probably have it in /snap/core/current/usr/lib/snapd/complete.sh [16:20] ls: cannot access '/snap/core/current/usr/lib/snapd/complete.sh': No such file or directory [16:20] installed: 16-2 (1689) 83MB - (latest/stable) [16:22] sergiusens: ah well, at least the world is consistent [16:23] sergiusens: (i assumed you were tracking something newer than stable, but it makes sense for you) [16:24] sergiusens: in any case, we're working on the next release (yes it's delayed for a number of good reasons), should be in stable soon and then i can move on to the next step of the evil^Wmaster plan [16:40] Chipaca: oh, I was told 2.26 had it, it's even in the announcement [16:41] stgraber: I do believe 2.26 does have it [16:43] stgraber: yep, confirmed 2.26 (at least as in artful) does have it [16:44] sergiusens: ^ fwiw [17:47] Chipaca: hmm, I am on zesty, maybe I should move... [18:00] hello all [18:00] I'm working on a snap for a rails app [18:01] I'm hitting two issues, 1) I need to symlink a yml file into the app config dir [18:02] 2) I can't seem to access $SNAP_COMMON, $SNAP_USER_COMMON from with the install srcipt for some reason [18:03] is there a recommended way of linking files into the versioned snap dir? [18:03] I'm working with this http://paste.ubuntu.com/25012754/ [18:04] lines 43-47 depict where I'm having the issue [18:04] the application.yml needs to exist so that assets:precompile can run [18:05] so I keep an empty string filled application.yml with the application code [18:05] that the snap uses to run assets:precompile [18:06] in the install step [18:06] following that, I need to remove that application.yml and point the app to an application.yml that can be configured by the user [18:06] on a per deploy basis [18:07] one that lives outside of the versioned snap dir [18:08] I cant seem to access the $SNAP_COMMON and $SNAP_USER_COMMON (where I feel like this file should go) from the install scriptlet [18:08] so I decided to try moving it to /srv/ and symlink from there to the versioned application dir [18:08] this worked to some degree [18:09] the symlink exists from the versioned snap dir to /srv/prm/config [18:10] but the rails app it self doesnt seem to be able to access it ... even though the symlink exists where the application.yml shoudl be in the config/ [18:15] one more thing [18:16] how can I make a configurable value for RAILS_ENV [18:16] such that the rails env could be set on a per install basis? [18:20] PR snapd#3553 opened: interfaces: enable access to bridge settings [18:40] bdx, your chances to catch some snapcraft devs are higher on https://rocket.ubuntu.com in the #snapcraft channel [18:44] ogra_: thx [20:02] PR snapcraft#1372 closed: cli: Containerbuild clean === matteo` is now known as matteo [22:11] PR snapcraft#1385 closed: lxd: Don't assume user ID to 1000 for raw.idmap [22:17] PR snapd#3554 opened: client: wrap services calls