[00:07] PR snapcraft#1902 closed: many: use in-snap unsquashfs and readelf if running from snap [00:10] PR snapcraft#1899 closed: elf: readelf dependency [00:33] jdstrand: ack, thank you, I'll add comment tomorrow [00:36] greyback: thanks! [02:34] jdstrand: I am not sure I understand the question, but I'll give it a go. the bpf filesystem is registered during fs init on kernel boot [02:34] PR snapcraft#1903 opened: elf: use surrogate escape when decoding readelf output [02:40] PR snapcraft#1885 closed: Release 2.39 [03:50] PR snapd#4578 opened: Expose payment and account URLs in /v2/system-info [05:11] Hello [05:12] I love Snapcraft !! Does anyone else think this might be a revolutionary design idea ? [06:15] morning [06:29] zyga: good morning [06:29] mvo: zyga: morning guys [06:31] morning [06:31] prepping kids for school [06:32] hey mborzecki [06:49] aaand they've gone :-) [06:50] rain rain rain, but my mood is great today [06:50] mvo: did you restart https://github.com/snapcore/snapd/pull/4577 ? [06:50] PR #4577: snap: fix command-not-found on core devices [06:56] zyga: yes [06:56] zyga: it had header timeout errors [06:56] zyga: what is gone? [07:01] mvo: ah, that was just a reference to my kids and wife, they've all gone to school [07:01] zyga: :) ok [07:12] greyback: hello [07:12] greyback: https://github.com/snapcore/snapd/pull/4572 can land, just add a comment [07:12] PR #4572: mir: software clients need access to shared memory /dev/shm/#* [07:22] hmmm [07:22] irc spam [07:22] that's new [07:26] error: cannot find snap "core": Get [07:26] https://api.snapcraft.io/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Clicense%2Cbase%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdev [07:26] eloper_id%2Cprivate%2Cconfinement%2Cchannel_maps_list: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) [07:28] PR snapd#4568 closed: tests: new spead test for openvswitch-support interface [07:30] zyga: can you try to install this snap locally? http://apps.syncloud.org/apps/rocketchat_180201_amd64.snap [07:31] zyga: i'm seeing this https://paste.ubuntu.com/26499308/ [07:31] core 16-2.31~rc2+git528.a129e36 3982 canonical core [07:32] mborzecki: sure, one moment [07:33] or... 20 minutes [07:33] slow server? [07:33] nah, ramping up [07:33] ~250KB/s [07:33] 8 minutes [07:33] tmaybe it's capped [07:34] anyway, take a look at the log, install hook fails, ale last line `cannot snap-exec: no such file or directory` [07:34] mborzecki: what does the install hook look like? a shell script? a binary? [07:35] omg, it's a python script, `#!/snap/platform/current/python/bin/python` [07:35] platform? [07:51] mborzecki: so, since we established that this hook depends on a snap called "platform" and thus won't work (it cannot execute anything from snaps other than itself) shall I still install it? [07:51] zyga: no, thanks though :) [08:00] mborzecki: actually, that's something that could be checked store-side [08:01] hey o/ [08:03] hey hey :) [08:03] reading your PR now :0 [08:04] morning [08:22] zyga, thanks! which one? [08:23] pstolowski: 4551 [08:31] PR snapd#4577 closed: snap: fix command-not-found on core devices [08:33] greyback: looks like 4572 is good except for this one comment that jamie asks for, once that it is added this can go in [08:41] PR snapd#4459 closed: snap: add support for `snap advise-snap pkgName` [08:44] 4049 needs a second review [08:48] PR snapd#3456 closed: many: add interfaces.SystemKey() helper [08:51] PR snapd#4579 opened: many: add interfaces.SystemKey() helper [09:02] mvo: I just pushed the requested comment to 4572 [09:02] thank you [09:02] thank you! [09:03] PR snapd#4580 opened: tests: ensure disalbled services are masked [09:04] ogra_: we have code that masks the rsyslog/ssh units, I added an explicit integration test above. if this does not work for you, I need to know the version of snapd and what command you use and the output of systemctl status rsyslog.service and the output of ls -l /etc/systemd/system [09:06] mvo, note that this install comes with rsyslog disabled from the gadget by default ... it definitely was off on fresh install so it must have enabled itself during an upgrade (running edge with locally built gadget and kernel) [09:09] mvo, https://paste.ubuntu.com/26499622/ [09:09] ogra_: was it an old install with a core that would not mask on diable? [09:09] nope, thats a few days old [09:10] ogra_: fwiw, because of "synced" for /etc/systemd/system when it is not masked it will come back [09:10] ogra_: is this fresh image available somehwere? i.e. I wonder if there is a way to boot it and then inspect the state right after boot [09:10] mvo, i know ... but i checked that it is off right after install ... so i'm confident it was originally off ... i didnt check the link explicitly though [09:10] ogra_: afaik the codepath for "snap set core service.rsyslog.disable=true" and the gadget disable is the same but maybe not [09:11] ogra_: also, the gadget.yaml would be great [09:11] mvo, you wouldnt have the HW to run it but i can push the rootfs somewhere [09:11] Chipaca: I have some post-facto comments on #4575 [09:11] PR #4575: config: add (Get|Set)SnapConfig to do bulk config e.g. from snapshots [09:11] ogra_: in snap changes, did you see a core refresh around jan 28, 11:50 ? [09:12] pedronis: hm, i can do a followup [09:12] phew ... there were a bunch of refreshes ... /me checks [09:12] pedronis: is that why the other ones take *s? [09:12] yes [09:12] see snapstate.Set for example [09:12] ogra_: the mtime of the symlink looks different from most other times in this dir [09:12] ok, i'll take a stab at it [09:12] ogra_: so I suspect writable-path re-creating it [09:12] in a bit [09:13] ogra_: the rootfs will not be that useful as the disable will happen on firstboot [09:13] Chipaca: I don't think element of config can be nil but good to double check [09:13] mvo, thats long scrolled off ... changes starts only at 2018-01-31 [09:13] ogra_: so just by looking at the rootfs I will not see much unfortunately [09:13] ogra_: ok [09:14] mvo, sadly non-registered devices spam changes very regular, changes is pretty unusable during development through that " Error 2018-02-01T09:10:37Z 2018-02-01T09:10:40Z Initialize device" every few mins [09:14] :/ [09:14] no exp backoff? [09:14] i'll have to do a re-install later today ... i'll see what i can do to trigger it again [09:14] zyga: sure, from seconds to minutes :P [09:15] ogra_: an ls -l /etc/systemd/system right after firstboot would be great. ideally using the image you had [09:15] ogra_: I mean the same image as you used for this one [09:15] ok [09:15] :) [09:16] Chipaca: also notice that Get can give you nil bu Set will not take it, so it's probably a problem either way [09:16] the lack of symmetry [09:18] mvo, oh, crap i just notice i have overwritten that specific image ... but i'll try the oldest one i have [09:18] pedronis: I don't need the * to make the nil check on save though [09:19] ogra_: no worries, iirc masking was added a little bit later, i.e. for a brief time there was a bug in our new corecfg when it did not mask, let me check when it was fixed [09:19] ah ! [09:19] Chipaca: that's true [09:19] pedronis: a nil json.RawMessage is unserialisable, so I can just check that [09:19] Chipaca: the code is broken right now though [09:19] ogra_: it was added 2017-11-30 [09:19] if you pass a nil [09:20] mvo, well, the image was on auto-update and was definitely built this week ... [09:20] ogra_: the masking [09:20] various things will likely end up unhappy [09:20] pedronis: yep, noticed that :-) was checking on the caller side [09:20] pedronis: will address in a followup and then tweak my callers [09:20] ogra_: one week indicates something else is going on, I look forward to your ls and servicectl output [09:20] mvo, that could match, i built it onday or tuesday morning [09:20] *monday [09:43] pedronis: do you remember why the cleanup task waited for an ensure run to kick in? (am I forgetting something non-obvious, or has it always been like this?) [09:44] Chipaca: in which sense? [09:44] all tasks get triggered by an Ensure cycle [09:46] pedronis: right, and in api.go we do an EnsureBefore(0) to kick them off [09:46] yes [09:46] but there is also logic in taskrunner [09:46] to also do that [09:46] pedronis: but the cleanup task (one added with "AddCleanup") waits for the _next_ ensure before running [09:46] if there are dependents [09:46] Chipaca: might be missing a kick in task runner [09:46] in some cases [09:47] or maybe it's hard to decide [09:47] to do the kick [09:47] pedronis: ok, when i can push to github i'll pester you about this again; i'm probably missing something silly :-) [09:48] I know I have a test where this is an issue [09:48] but there is more related to not having all the right managers [09:48] around [09:58] Chipaca: have you run run-checks --static locally recently? it logs a lot about tests/lib/snaps/test-snapd-validate-container-failures/hell [09:58] it doesn't error but it's a bit on the noisy side [10:00] i put that thing there to stress test some checkers, but not sure which one is getting tricked in --static [10:01] seems spell checking afaict [10:03] PR snapd#4581 opened: overlord/configstate/config: make SetSnapConfig delete on empty [10:04] pedronis: ^ [10:14] Hello, is there a way to transfer a snap with all of it's data to another server? [10:14] Chipaca: ^^ snapshots? [10:15] ish [10:15] yes :-) [10:15] except user data might make things weird [10:15] apply55gx: currently, in released snapd, you could do it manually with some care [10:16] @mborzecki do you mean whole server snapshots or is there a way to create a snapshot just of the snap? [10:16] apply55gx: I'm working on a feature to do snapshots of a snap [10:16] apply55gx: but it's not even up for review yet [10:16] so at least a month before it's on stable [10:17] Chipaca: Thank you for your answer. How would you manually do this? [10:17] PR snapd#4582 opened: many: at seeding try to capture cloud information into core config under "cloud" [10:18] apply55gx: assuming the snap is public, I'd install the snap in the new server, disable it (snap disable $thesnap) so it's there but the services are all stopped, and then rsync /var/snaps/ over [10:18] Just copying it won't work, does it? [10:19] apply55gx: if the snap uses 'snap set' to do config there's an extra step [10:19] apply55gx: just copying the snap? it could; you'd need the assertion as well as the snap but you have it [10:20] apply55gx: simpler to just re-get it if you can, but otherwise yes you can just copy it and the assertion, then 'snap ack ' and 'snap install ' [10:21] apply55gx: if you don't want to figure out which assertion to ack, you _could_ copy everything and ack the whole lot :-) [10:21] apply55gx: that's /var/lib/snapd/assertions/asserts-v0/ [10:21] Chipaca: Ok, I'm gonna try getting the snap and just copy the /var/snap/ folder. The other thing seems a bit too complicated for me :-) [10:22] Chipaca: Thank you for your quick answer :) [10:22] apply55gx: if you're able and have the time to describe what you want to do as a feature request, it'd be neat to have it documented [10:22] apply55gx: but no rush for that :-) [10:23] it's just that as far as I know we don't currently have a user story for "copy this snap and all its data to that machine" [10:23] it'd be a step further down the snapshot road [10:23] and enable some nifty migrations, i reckon [10:23] anyhow, back to coding snapshots [10:24] Chipaca: I'll try to document it as good as possible :) Where should I put the documentation afterwards? [10:25] apply55gx: if it's story-ish, https://forum.snapcraft.io; if it's bug-ish, https://bugs.launchpad.net/snapd/+filebug [10:25] apply55gx: if in doubt, chose one at random and we'll sort it out :-) [10:25] Ok, thank you :-) [10:39] mvo, ok ... fresh re-install of the oldest image i have here (and in fact the core is from yesterday) ... https://paste.ubuntu.com/26499992/ [10:40] mvo, so i guess something with applying the gadget config on first boot goes wrong [10:40] ogra_: this is first-boot? [10:40] ogra_: i.e. nothing else was run yet? [10:40] only ran through console-conf yet ... didnt reboot [10:40] ogra_: what is the output of "snap changes"? [10:40] ogra@localhost:~$ snap changes [10:40] ID Status Spawn Ready Summary [10:40] 1 Done 2018-02-01T10:27:24Z 2018-02-01T10:28:13Z Initialize system state [10:40] 2 Error 2018-02-01T10:28:10Z 2018-02-01T10:29:24Z Initialize device [10:40] 3 Error 2018-02-01T10:34:24Z 2018-02-01T10:34:27Z Initialize device [10:41] ogra_: great, yeah, it looks like first-boot config is broken just not running, the output of journalctl -u snapd might be good [10:41] ogra_: *maybe* there is an error in there [10:42] mvo, nothing in journald https://paste.ubuntu.com/26500004/ [10:43] (the chopped off likes are just "installing kernel" and "installing gadget" [10:43] ) [10:43] * kalikiana coffee break [10:44] ogra_: ta [10:46] ogra_: looks like a real bug :( [10:46] yes [10:52] any recommendation on how to give someone a custom snapd to test? [10:54] write it to a USB key ... get a padded envelope ... put stamps and an address on ... write a note with instructions and send it ? [10:56] greyback: a binary build for their target arch? push to a url, then ask $person to "wget $url", systemctl stop snapd.socket snapd.server; sudo cp custom-snapd /usr/lib/snapd/snapd; sudo systemctl start snapd.socket snapd.service [10:57] mvo: ok, so the obvious. Thanks [10:57] ogra_: you sir need some sugar, you're getting grumpy [10:57] lol [11:07] https://pastebin.ubuntu.com/26500106/ [11:07] * Chipaca might be having a little too much fun [11:08] Chipaca: at least you're having fun :) [11:08] :-) [11:08] i like the 'probably *fine*' === mup_ is now known as mup === diddledan_ is now known as diddledan [11:48] mvo, https://bugs.launchpad.net/snapd/+bug/1746714 [11:48] Bug #1746714: regression: gadget defaults are not applied with latest snapd [11:48] PR snapd#4583 opened: many: pull apart develoepr and publisher [11:48] Chipaca: -^ we talked about the developer/publisher entanglement. the above may help, feedback welcome (cc pedronis) [11:48] ogra_: thanks, I have a look this afternoon, just wanted to finish the above PR [11:51] mvo, yeah, i just wanted a papertrail [11:58] mvo: have you talked with snapcraft and store people about that? [12:00] mvo: developer_id in the store is the publisher ATM [12:01] and we don't track the developer much really (it's an open task but I don't see it happen soon) [12:02] mvo: basically without starting from the store this will just confuse us more [12:02] zyga: quick qn: I accidentally pushed a commit to my branch, and have commited a revert. Would you rather I redo the branch to have a cleaner history? (https://github.com/snapcore/snapd/pull/4545/commits) [12:02] PR #4545: interfaces/x11: allow X11 slot implementations [12:03] greyback: nah, just --force push [12:04] greyback: drop that commit and push the right one [12:04] pedronis: uh, developer_id is publisher_id? and developer_name is also publisher_name? [12:04] yes [12:04] in the new APIs [12:04] they will be called publisher [12:04] basically I don't think this makes much sense [12:04] until we have a new details API [12:05] pedronis: fair enough, I will extract the interessting bits from the PR and close it after [12:06] mvo: the only place where we get the developer would be snap-revision, but that is also not true atm [12:06] because of historical reasons [12:06] pedronis: what do we get there? [12:06] again the publisher [12:06] /o\ [12:06] ok [12:07] as I said until it is fixed/improved in the store [12:07] adding the distinction in snapd is not super useful [12:07] we could start adding publisher == developer in packages.go [12:07] I suppose [12:07] but not much else [12:08] pedronis: so you think we should not expose ddeveloper at all in the rest api? or just not yet ? [12:08] pedronis: I'm fine starting with developer = publisher for now and provide publisher via the rest api and then users can transition to the new field. does that make sense? [12:09] yes, that make sense [12:09] the changes in store/ are problematic [12:09] pedronis: great, I will update the PR accordingly and add some big explanation around this to avoid further confusion [12:10] pedronis: sure, I will revert those [12:10] pedronis: well, revert and add comments [12:10] pedronis: thanks for your input! [12:11] it's a bit my fault [12:11] PR snapd#4583 closed: many: pull apart develoepr and publisher [12:11] PublisherID [12:11] and - info.PublisherID = d.DeveloperID [12:11] at some point [12:11] but didn't add a comment [12:11] * mvo nods [12:13] mvo: also we don't capture the string because we go from id to strings using the account assertion [12:13] pedronis: should we remove the string then? [12:13] we didn't have it before [12:14] there was no publisher [12:14] I mean all of store changes need to be reverted [12:14] * zyga takes a break to lay down, back pain [12:14] pedronis: aha,ok, I misunderstood [12:14] pedronis: yes, will do that [12:14] and maybe added comments [12:14] that means also some bit of snap/info.go go away [12:14] as well [12:18] pedronis: thanks, I will do that (and revert bits in info.go too) [12:39] * zyga will skip standup today, not so fun from bed; I'm not feeling good for the last few hours and I'm trying to write docs and examples on new features [12:42] zyga: clearly writing docs is bad for your health :-P [12:57] PR snapd#4584 opened: Introduce LimitedWriter to limit the number of data read from the std… [13:19] I'm seeing some really weird issues trying to use snapcraft ATM. [13:20] I have lxd installed as a deb, but `snapcraft cleanbuild` fails with: subprocess.CalledProcessError: Command '['lxc', 'file', 'push', '/home/daniel/snap/lxd/common/snapcraft_8v82248/core_3887.assert', 'local:snapcraft-paretically-cressiest-elana/run/core_3887.assert']' returned non-zero exit status 1. [13:20] That path looks extremely suspicious. [13:21] (Also, when using a remote lxd, there's no reason to believe that the local path will exist at all snap or otherwise.) [13:21] So I think to myself, "fair enough, let's just build locally for now", and then pip segfaults: subprocess.CalledProcessError: Command '['/bin/sh', '/tmp/tmp9uadnku3', '/home/daniel/dev/cloud-test-framework/parts/cloud-test-framework/install/usr/bin/python2', '-m', 'pip']' died with . [13:26] I see the lxd issue on both the edge and stable snaps; it looks like the stable snap might not have the local-build issue. [13:28] * kalikiana moving to coffee shop for lunch [13:52] hi, is there a way to get locales to work in a snap? can they be included in the snap itself? [13:56] ackk, while this is a very old snap, the wrapper stuff should still work i the new world http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh [13:57] (check the stage-packages in snapcraft.yaml too) [13:58] ogra_, thanks [14:13] PR snapd#4583 opened: many: pull apart develoepr and publisher [14:16] * pstolowski lunch [14:25] pstolowski: left you some comments in 4584 [14:30] PR snapd#4585 opened: daemon: refactor snapFooMany helpers a little [14:31] mborzecki, thanks [14:31] kalikiana please look into Odd_Bloke's issue with lxd [14:34] re [14:35] PR snapd#4586 opened: cmd/snap: add completion conversion helper to increase DRY === juergh_ is now known as juergh [14:37] Odd_Bloke: Did you see any errors from lxc? That is, before the Python error message [14:38] Odd_Bloke: Also, what are you finding suspicious there? Snapcraft creates a temporary folder in ~/snap/lxd/common to store files that will be pushed into the container [14:49] kalikiana both kyrofa and popey saw this yesterday too [14:50] kalikiana: Well, I don't have the lxd snap installed, so that's a weird path to use. [14:51] (Also, this isn't the lxd snap, so that's a weird path to use even if I did have it installed.) [14:51] Surely that should be in ~/snap/snapcraft... ? [14:51] PR snapcraft#1904 opened: lxd: raw.idmap expects host and container id respectively [14:51] But also, the path it thinks should exist there doesn't, which is a definite problem. [14:56] Odd_Bloke: That path is used so the lxd snap can read the files despite confinement when you use it. It's removed after Snapcraft is done, so it would indeed be empty if you're looking for it afterwards [14:57] sergiusens: Is it related to bug 1746612 ? I tried it with the lxd in Xenial earlier. I still need to try with the backports version as well to see if that's different [14:57] Bug #1746612: Snapcraft cleanbuild doesn't work if you're not using the LXD snap [14:59] kalikiana: https://paste.ubuntu.com/26501059/ is the full log. [14:59] Basically the file that snapcraft is telling lxd to use isn't present. [14:59] Odd_Bloke: Thanks! [14:59] Odd_Bloke: Actually, does ~/snap/lxd not exist at all? Snapcraft should be creating it [14:59] It does. [14:59] Or is it empty? [15:00] I wiped it out earlier, and it does still have stuff in there. [15:00] /home/daniel/snap/lxd/common/snapcraftyu2pnqwq looks like it was just created by my cleanbuild run. [15:01] Odd_Bloke: It should've re-created folder regardless of the lxd snap being there [15:01] Although I can appreciate that it seems a little "odd" [15:03] Odd_Bloke: On my system I can see ~/snap/lxd/common with no contents even after removing ~/snap/lxd [15:03] Not sure if there's some other intermediary step I'm overlooking [15:07] Odd_Bloke: btw which version of lxd are you using? ie. `apt show lxd | grep Version` [15:08] Why would ~/snap/lxd/common exist if you've removed ~/snap/lxd? [15:08] Odd_Bloke: Because Snapcraft creates it :-) [15:08] That is all sorts of crazy, IMO. [15:08] But whatever. [15:09] I'm running lxd 2.21-0ubuntu2 (in bionic). [15:09] Odd_Bloke: If LXD is confined, it can't read arbitrary stuff in your ~ [15:09] Sure, but my lxd isn't confined, nor is it even local, so snapcraft shouldn't create random folders in my filesystem. [15:10] But I don't particularly care about that ATM, it doesn't work even doing that. :p [15:11] kalikiana: OK, hold on, that file does exist locally. But /var/lib/snapd/hostfs/ is empty. [15:15] * kalikiana wishes Launchpad's search wasn't so terrible, trying to confirm if this is related to another known issue [15:15] * kalikiana can't even find *this* bug report by searching for it... [16:07] kalikiana: hey [16:07] zyga@fyke:~/content-interface-2.0/hub-app$ snapcraft [16:07] Issues while validating snapcraft.yaml: Additional properties are not allowed ('license' was unexpected) [16:07] where can I specify the license? [16:11] zyga: Where did you try to put it? It should be a toplevel item like summary or description [16:11] kalikiana: yeah, there [16:12] snapcraft, version 2.34+17.10 [16:12] kalikiana: I put [16:12] license: MIT [16:14] zyga: can you paste the YAML somewhere? then I can double-check if it works here [16:15] sure [16:15] http://paste.ubuntu.com/26501365/ [16:22] zyga: Doesn't seem to work indeed.... not sure tbh [16:23] seems like something that fits the overal license work now [16:31] niemeyer: ^ FYI (on license) [16:31]