[01:04] PR snapd#4516 closed: spread: setup machine creation on Linode [06:09] morning [06:37] linode:ubuntu-14.04-64:tests/main/snap-service is failing accross diferent PRs, looking into it [07:04] well, seems that the test is passing when run manually [07:19] o/ [07:19] good morning [07:26] zyga-ubuntu: hey, morning [07:27] hey :) [07:27] I just made some warm coffee [07:27] we may have some unusual work to do today === chihchun_afk is now known as chihchun [07:27] is mvo around already? [07:27] hey chihchun [07:27] * zyga-ubuntu did a nice walk last evening, 5K in the dark and cold of winter [07:28] I didn't anticipate that I could get to so unpopulted areas of warsaw this quickly [07:35] good morning mvo [07:39] mvo: I replied to the thread with jamie now [07:40] hey zyga-ubuntu [07:40] zyga-ubuntu: thank you, checking [07:40] mvo: morning [07:40] mvo: morning [07:41] pff [07:41] wrong window :P [07:42] mborzecki: good morning! [07:50] PR snapd#4528 opened: cmd/snap: improve `snap aliases` output when no aliases are defined [08:00] snappy morning [08:01] kalikiana: morning [08:03] good morning! [08:03] pstolowski: morning [08:49] - linode:ubuntu-14.04-64:tests/main/snap-service fails recently [08:50] PR snapd#4512 closed: tests: new spread test for ssh-public-keys interface === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [10:08] zyga-ubuntu: tried running it separately a coupe of times, but all runs were successful [10:10] mborzecki: it probably needs to be ran in sequence with other tests, using the same random seed [10:20] sergiusens, is https://github.com/snapcore/snapcraft/pull/1617 good for merging? [10:20] PR snapcraft#1617: Add options to configure applications socket activation [10:39] zyga-ubuntu: reproduced test-snap-service problem [10:39] mborzecki: what do you see? [10:41] an ancient systemd :) [10:42] zyga-ubuntu: calling reload does nothing, or iow, nothing is logged in the journal [10:44] uh [10:44] 14.04 [10:45] zyga-ubuntu: Process: 18961 ExecReload=/usr/bin/snap run --command=reload test-snapd-service (code=exited, status=0/SUCCESS) [10:45] and the service is active/running [10:45] just that there is no log [10:49] same thing after restarting the service [10:50] btw. the *.service file looks fine [10:50] any reason it would regress [10:50] i'll try something more direct, like kill -HUP $MAINPID and setup a trap in the main process [10:50] it does work sometimes [10:55] zyga-ubuntu: https://paste.ubuntu.com/26450449/ seems to work [10:57] zyga-ubuntu: https://paste.ubuntu.com/26450461/ notice how there's no long from the reload command [10:58] mborzecki: so was it just a race? [10:59] idk why journal is not capturing the reload command output [11:03] i'll open a PR and we'll see if this is enough of a fix or not [11:03] thank you [11:10] PR snapd#4526 closed: tests: new spread test for gpg-public-keys interface [11:10] PR snapd#4529 opened: tests/lib/snaps/test-snapd-service: refactor service reload [11:13] hmm [11:20] hi there. I have a problem installing lxd with snap, not sure if the problem is from snap itself or the lxd package [11:20] snap list lxd gives: lxd 2.21 5447 canonical - [11:21] $which lxd /snap/bin/lxd [11:21] but $ lxd init [11:21] lxd: error while loading shared libraries: liblxc.so.1: cannot open shared object file: No such file or directory [11:24] the command "snap run hello" runs fine, but this app may not need shared libs [11:29] so I just installed chromium and it runs ok, so I guess the problem is within the lxd 'package' [11:31] mvo, hey, can #4063 land? [11:31] PR #4063: tests: add new kernel refresh/revert test for spread-cron [11:32] is jdstrand back? [11:32] ikey: yes, he is [11:33] pstolowski: yeah, I think so, we need to set it to manual: true and cachio needs to integrate it with the spread-daily [11:33] awesome ty [11:33] Can we get some attention on this topic then please? :) https://forum.snapcraft.io/t/blowing-off-steam-lets-plan-steam-support-interface/3457 [11:34] mvo, i see, so i cannot click 'merge' just yet right? [11:34] ikey: I think jamie has some backlog of topics to cover but I'm sure he will look at this as well [11:34] awesome, ty [11:34] basically i just need some basic gotchas so i can get some traction on it [11:35] this whole steam snap thing has been dragging on a really long time now ^^ [11:36] pstolowski: better not yet, we need to coordinate with cachio [11:36] k [11:42] Bug #1667829 changed: console-conf v0.0.5 crashes if no config needed [12:00] Bug #1650096 changed: 'snap list' does not show devmode property after disable and re-enable a snap [12:00] Bug #1666873 changed: Snap icon is not visible when called from terminal but it does when called from dash [12:07] niemeyer: hey, when around, things went wrong somehow this morning: https://travis-ci.org/MirServer/mir/jobs/332706784 [12:07] Saviq: Heya [12:07] looking at https://travis-ci.org/snapcore/snapd/builds/332735121 - linode is having trouble [12:08] Saviq: Checking [12:10] Saviq: I think this is an issue on my end actually [12:11] or that :) [12:11] Saviq: Well.. sort of.. the error on the snapd branch does not match the first one, and is a problem on Linode itself [12:12] yeah they are different [12:13] Saviq: I'll look into this [12:14] tx [12:16] * Chipaca returns from the dead [12:17] niemeyer: o/ [12:18] Chipaca: Heya [12:18] niemeyer: when can we chat about snapshots? [12:19] or when can i read what you've written, if it's written :-) [12:19] Chipaca: I want to unblock you, so we can do that now if you have a moment.. I haven't read your forum post yet with all the spreadness yesterday, sorry, but we can catch up live [12:19] sure, let me get my earphones [12:22] niemeyer: standup h/o? [12:22] Chipaca: Yeah, there already [12:45] PR snapd#4529 closed: tests/lib/snaps/test-snapd-service: refactor service reload [12:48] Chipaca how was the highway "from" hell? :-P [13:01] sergiusens: rocky [13:01] sergiusens: also rolly [13:03] niemeyer: forum post updated, give it a once over in case i got it wrong [13:17] o/ sergiusens [13:18] * kalikiana going to have lunch in ~10 [13:19] ikey: hey, I am. I've got a todo to respond to your forum post [13:22] kalikiana, sergiusens: when will cleanbuild support building on a bionic base? There's a lxc image available at ubuntu-daily:18.04 already and we have the base-18 snap [13:23] jdstrand, hey, i was just asked by a customer if we have a hdparm snap (indeed we dont) ... packaging it is less than a 20 lines snapcraft.yaml, but i cant really find an interface that would allow me to not run it in devmode ... do you have any idea ? [13:24] ogra_: I'd have to see the denials [13:24] (devmode works fine as a mometary workaround ... but i fear the audit logging might actually falsify the measuring data) [13:25] I presume /dev/[sv]d* and friends [13:25] jdstrand, this is what i get in devmode on my laptop https://paste.ubuntu.com/26451245/ [13:25] (nvme disk ... ) [13:26] right nvme [13:26] anyway, that would need a new interface. it would obviously be massively powerful [13:26] not sure why it touches all these loop devices [13:27] it is probably deciding that it doesn't need to look at them [13:27] [13:27] I've seen that before with something [13:27] (this was just hdparm -tT ... i bet there will be a lot other switches needed for the gazillion of options hdparm has) [13:28] yeah, would be probably a bit over-powered ... raw-blockdevice-access or some such .. [13:29] ogra_: I suspect it would be a subset of the udisks2 slot policy [13:29] ah [13:29] only a subset ? [13:29] well, yeah. it doesn't have a dbus service [13:29] probably something like: [13:29] /run/udev/data/b[0-9]*:[0-9]* r, [13:29] oh, udisks2 only comes from the snap ... not inside core [13:29] /sys/devices/**/block/** r, [13:30] i see [13:30] /dev/sd* r, [13:30] /dev/mmcblk* r, [13:30] /dev/vd* r, [13:30] (and nvme*) [13:30] yeah [13:30] probably a couple a capabilities [13:31] thx [13:31] then the udev rule to tag all block devices [13:31] (i might just keep it devmode for now ... after all that works for the moment ... sounds like a bigger project to add such an interface) [13:32] anyway, happy to review if you send something up. if you need me to do it, it will be a while (though let me know so I can capture this conversation) [13:33] yeah [13:34] kyrofa: I'm dealing with the Go environment and setting my workspace correctly. However in my Go files I have functions that execute commands to the console such as `sudo snap install name.snap` the problem is that I need sudo privileges and when I do `sudo snapcraft` the Go env paths disappear. [13:38] mvo, do you know who can approve membership of the canonical-snapcraft email list? kenvandine has been pending for a couple of weeks now [13:42] jdstrand: hello [13:42] zyga-ubuntu: fyi, https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/56 (not sure you can see comments to merged PRs-- istr people have that issue) [13:42] zyga-ubuntu: hey [13:43] jdstrand: I did, I responded to them (though let me recheck) [13:43] jdstrand: if you want I can just disable the whole user/mode part for now [13:45] mvo: looks like the license field should be avaialble in the client, but we're just not showing it [13:46] zyga-ubuntu: responed via the forum [13:46] jdstrand: I'll do that quickly [13:47] jdstrand: btw, for 4329, do you think this is close to landing? [13:47] mvo will release 2.31 today [13:48] zyga-ubuntu: I'm still going through email which includes the responses to my reviews, but my feeling yesterday was, yes, 4329 is close [13:49] OK, I'll get to layouts now [13:49] I'm also surprised that 2.31 will be released today. I had a pile of policy updates... :\ [13:49] mborzecki: yeah, it seems we also do not store it locally, i.e. when doing "snap info local-snap" the info seems to get lost [13:50] ETOOMANYHIGHPRIORITYITEMS [13:50] EPANIC [13:50] losing a week to the sprint didn't help either [13:50] EAGAIN :) [13:50] mvo: ^^ [13:50] mvo: maybe postpone 2.31 for some time? [13:50] mvo: hey, willcooke_ mentioned that xdg-settings needed to be in 2.31 [13:51] Hey guys, can tell me how can I specify in the snapcraft.yaml a package in goland that I created and I need it to go to the GOROOT path into the pkg folder as a *.a lib? [13:51] mvo: I reviewed it yesterday and its close. not through email yet (so don't know if you addressed things), but wanted to touch base since 2.31 is imminent on xdg-seettings going into 2.31 [13:58] jdstrand: *must* is a strong word [13:58] jdstrand: I have a meeting now but lets chat after that [13:58] jdstrand: there is always 2.32 but yeah, there is some stuff I would love to have in 2.31 [13:58] jdstrand: the trouble is that statement is always true however long one waits ;) [13:59] mvo: I don't think I said 'must' :) [13:59] mvo: sure, willcooke contacted me and said it was critical [13:59] jdstrand: for policy updates I can certainly include it in 2.31~rc2 for example [13:59] jdstrand: today would be ~rc1 [14:01] PR snapd#4530 opened: snap,interfaces/mount: disallow nobody/nogroup [14:02] mvo: I think I can get a PR up today/tomorrow at the latest. if it doesn't make it, well, it doesn't make it [14:03] mvo: I'll look at 4530 today [14:03] err [14:03] zyga-ubuntu: ^ [14:04] jdstrand: thank you [14:06] PR snapcraft#1617 closed: Add options to configure applications socket activation [14:10] zyga-ubuntu: I accidentally approved 4329. please see https://github.com/snapcore/snapd/pull/4329#discussion_r163555093 for the last remaining item [14:10] PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) [14:10] jdstrand: ack [14:11] niemeyer, mvo, pedronis has there been any progress at https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 (we'd need it for some customer images) [14:11] kyrofa fwiw, `pkg.name not in package_names` is what makes adding libc6 as a stage-packages entry work [14:30] re [14:36] Does anyone can help me out with a doubt? In the snapcraft.yaml in a part I have `stage-packages: [libbluetooth-dev, bluez]` and I get the error `apt.cache.FetchFailedException: W:Can't drop privileges for downloading as file '/home/sid/.cache/snapcraft/stage-packages/apt/656cd207e1d22` [14:37] On Ubuntu Core Raspberry Pi 3 amrhf it works. On Ubuntu core amd64 it doesn't work... [14:50] brunosfer: are you running as root or anything like that? [14:59] PR snapd#4531 opened: cmd/snap: display snap license information [15:00] niemeyer: did you get a chance to review the updated text about snapshots? [15:02] mborzecki: reviewed [15:02] Chipaca: Yes, I do have to run sudo. [15:02] brunosfer: why? [15:03] Chipaca: Because installing a downloaded snap requires sudo. [15:03] brunosfer: no it doesn't [15:03] Chipaca: Let me recheck again... [15:04] brunosfer: if you're a developer, you can log in (snap login), and then snapd can see your private snaps [15:05] brunosfer: if you haven't logged in, it should prompt you for your password to confirm the operation, but not require sudo [15:05] brunosfer: sorry, i meant, you can login, in which case it won't ask you for anything, and as a plus it'll see your private snaps [15:06] Chipaca: I think we are talking about different things. Let me explain better. [15:08] Chipaca: The problem occurres in a ubuntu desktop with the snapcraft tool installed. [15:09] zyga-ubuntu: thanks, posted some example output also [15:09] mborzecki: got that, looks good [15:10] Chipaca: I have a golang file in my code that executes the cmd line `sudo snap install name.snap` and when I run the snapcraft to build the snap it throws me the error I mentioned before. [15:10] zyga-ubuntu: saw your forum post about licence files. I'm still very confused about this. Most snaps will have multiple parts and muliple stage-packages, and may have many different licences. Is a single licence field appropriate? [15:11] brunosfer: for what it's worth, the "drop privileges" thing is a warning, not an error [15:11] mcphail: yes, the license field is a SPDX expression that can have many many licenses in one thing [15:11] brunosfer: but, why do you have a file in your code that does that? [15:11] mcphail: so you can see that an app uses, say, "MIT and LGPL-2" [15:11] brunosfer: (the W: before the message means 'warning') [15:12] brunosfer: and, the message is from apt, not from snap [15:12] zyga-ubuntu: so do we dump multiple licences in the meta/LICENSE file? [15:13] mcphail: no, unless those are standard [15:13] mcphail: if you have that MIT and LGPL-2 example you don't need the license text for that [15:13] mcphail: the license text would only apply if you really have a custom license [15:13] mcphail: spdx license expressions allow multiple licenses [15:13] mcphail: all licenses known to SPDX are covered by the existing system [15:13] you can do license algebra! license matrixes! license eigenvectors! [15:14] * Chipaca runs away [15:15] mcphail: https://spdx.org/sites/cpstandard/files/pages/files/using_spdx_license_list_short_identifiers.pdf [15:16] ok. cheers chaps. However, all MIT licenses (for example) are bespoke to the individual packages and are supposed to be distributed with the copyright line unmodified. How do we cope with that? [15:17] "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software" [15:17] mcphail: you ship the license, just not in meta/ [15:18] Hmm. OK. So there's inevitable duplication there between adding it to the metadata format and shipping the actual licence? [15:18] mcphail: or you ship it as meta/LICENSE (was that the file in meta/ we settled on? not sure), but also include license: MIT in the .yaml so the license itself is ignored by the business logic [15:19] same goes for BSD licenses [15:20] especially since BSD licenses get kinda weird [15:20] heh [15:23] Chipaca: I had a chance to have lunch! :) [15:23] niemeyer: :-) [15:23] niemeyer: basically my question is whether the 'just one file' applies to all snaps in a snapshot, or if i should make them per-snap [15:24] I'm reading it now [15:40] Issue snapcraft#1688 closed: Documentation for advanced grammar for sources [15:46] niemeyer: poke [15:47] Chipaca: Sorry, still working on it (mid other things, appologies) [15:48] apologies even [15:48] yeah i know things a busy for you right :-) [15:57] Chipaca: Sent some initial comments there [15:58] hmm [15:58] tests are not happy [15:59] niemeyer: from your comment about the snapshot filename I understand your answer to my question is to have a single snap per snapshot [15:59] seems tests just terminate machines in random places [15:59] niemeyer: ^ perhaps related to new spread allocation [16:00] sample log: https://api.travis-ci.org/v3/job/332828272/log.txt [16:00] * kalikiana wishes that one day Google fixes hangout links in notifications to use the right account [16:00] Chipaca: That seems slightly more expectable and perhaps nicer to work with [16:00] Chipaca: Note we can still draw a line across multiple snapshots by sharing some information [16:01] zyga-ubuntu: Looking [16:01] zyga-ubuntu: Do you have the URL for the build? [16:01] THese files are pretty ugly to look at while raw [16:01] niemeyer: sure https://github.com/snapcore/snapd/pull/4530 [16:01] PR #4530: snap,interfaces/mount: disallow nobody/nogroup [16:02] or https://travis-ci.org/snapcore/snapd/builds/332828271?utm_source=github_status&utm_medium=notification [16:02] zyga-ubuntu: Okay, and what sholud I look for other than 50 thousand lines? [16:02] niemeyer: look at 1st few error, it seems that the logs are just cut in random places [16:02] niemeyer: as if those machines got axed [16:03] hmm hold on, is that the right build [16:03] sorry, rechecking, too many tabs open [16:04] https://travis-ci.org/snapcore/snapd/builds/332769268?utm_source=github_status&utm_medium=notification <- here [16:05] we seem to die when installing packges in the first few errors [16:05] not sure what to make of that really [16:06] zyga-ubuntu: Yeah, that may be conflicts and two different systems trying to allocate the same machine.. I need to fix that today [16:06] zyga-ubuntu: Just restart for now please [16:06] thank you [16:13] niemeyer: is there anything blocking 4471 left? [16:13] zyga-ubuntu: I'll have to look at it to be able to ttell [16:14] PR snapd#4532 opened: store: use the "publisher" when populating the "publisher" field [16:14] ack [16:20] Chipaca: quick question about developer/publisher - should we expose both via the rest api? [16:21] Chipaca: context is that I'm looking at this right now for g-s (minimal fix is in 4532) but it looks like there is a bit more to make this nice [16:21] mvo: I fear I'm lacking context [16:21] heh [16:21] Chipaca: sorry, so right now it seems in our code we are not super clear when publisher and when developer is used [16:21] sergiusens: could you copy mvo on the email about ^ you sent me today? [16:22] sergiusens: looks like he's aching to fix the issue :D [16:22] Chipaca: and I wonder if should untangle this properly and always have those two everywhere (rest api, snap.Info etc) [16:26] `snap info` output has to be valid yaml [16:26] intersting [16:26] mborzecki: there's a bunch of TODOs on that still though [16:26] mborzecki: but, yes, ideally yes [16:31] hmm the core snap does not have the license set? [16:39] mborzecki: it might be that its local and therefore the license get lost [16:39] mborzecki: its labeled in the store as "other open source" [16:43] sergiusens, I meant to ask: what priority would you like me to give the load_plugin work? I've still got a chunk of docs to write [16:43] sergiusens, shall we create an issue for it and put it on the next milestone? [16:43] kyrofa something to do on Friday maybe or when you are on a creative block [16:43] kyrofa an issue sounds like a good plan [16:44] Chipaca ack [16:44] mvo: that's likely it [16:44] sergiusens, good call, those happen. I'll make an issue for it [16:44] mborzecki: yeah, I think we just need to store it locally, its store metadata [16:46] mvo: looks like a followup PR on #4531 [16:46] PR #4531: cmd/snap: display snap license information [16:46] mvo, 2.31 is comming today? [16:46] Issue snapcraft#1882 opened: Toast load_plugin [16:52] cachio: I'm waiting for some PRs to get green [16:52] mborzecki: +1 [16:57] mvo, ok, tx [17:02] if i have an "architectures: [ all ]" snap that is installed on a system and eventually add a binary to that snap (which forces me to change to "architectures: [ foo ]" ... will that snap be upgraded on my syystem ? [17:02] or would my user have to remove/install manually ? [17:06] * ogra_ files https://forum.snapcraft.io/t/what-happens-if-an-architectures-all-snap-becomes-arch-specific/3675 [17:11] * kalikiana wrapping up for the day [17:12] popey: are you around ? [17:15] Ya [17:16] popey: https://github.com/snapcrafters/sublime-text/pull/5 [17:16] PR snapcrafters/sublime-text#5: Snapcraft yaml cleanup [17:16] After that I think we should move that to stable. It has been working perfectly fine. [17:16] PR snapd#4533 opened: errtracker: include detected virtualisation [17:19] nacc, did Laney ever get back to you about autopkgtests? I didn't see anything [17:20] om26er: i dont think that architectures stanza does what you think it does [17:20] om26er: certainly won't stop build from trying to make an i386 snap [17:31] popey: oh, do you know a way to do that ? [17:32] I always thought that would limit the architectures my snap will build on [17:40] kyrofa: nor I [17:40] kyrofa: i'll ping again [17:44] om26er: sadly not. [17:44] been pouring over docs and web posts but in hours haven't found an answer to a question: [17:45] what sets the number of revisions kept for a snap? [17:45] om26er: https://github.com/canonical-websites/build.snapcraft.io/issues/556 [17:45] what or where? [17:45] acknack, I believe it's hard-coded in snapd [17:45] ouch. [17:45] yeah, i believe so [17:45] acknack, why, are you wanting to change it? [17:45] (and if so, why?) [17:45] it's apparently > 2 [17:45] Yeah, it's three [17:46] and i can only go back one revision by the cli? [17:46] kyrofa: looks like it might get re-enabled tmrw [17:46] No, you can revert multiple times, or revert to a specific revision [17:47] nacc, ah, excellent, thank you :) [17:47] kyrofa: yw [17:47] okay. being able to revert more than one didn't make an impression during my research [17:48] i can specify a revision to remove. would you believe i was thinking the number of revisions would be configurable not hardcoded because of the VMS filesystem? [17:51] acknack, if that's a feature you believe would be helpful, by all means feel free to request it [17:51] specify a specific* revision to manually* remove [17:51] i can see a dev wanting a few revisions around. i was hoping to be tidy and set it to 2. [17:51] the apps are small enough but core is sizable [17:54] k. thanks. i'll have a look at the code. is there an existing external config file for snapd? [17:55] otherwise, i'm thinking a cli param and a tweak to the systemd stuff which fires up snapd [17:56] "per snap" rev limit would be lovely but overkill, i think, yes? [17:58] in an ideal world you could say "call this bit of business logic to decide" [17:58] but... no :-) [18:00] * Chipaca ~> dinner [18:01] VMS filesystem (and later implementions in other OSes) has a root dir rev limit which is inherited and ability to set per file rev limit. just fyi. [18:02] external config file exists for snapd? yes/no? [18:35] hmm. yes, '42' is the Great Answer. overlord provides a hook for setting upper rev limit? [18:36] PR snapd#4528 closed: cmd/snap: improve `snap aliases` output when no aliases are defined [18:48] * zyga-ubuntu cooked dinner for the first time in weeks [18:48] ttyl :) [18:54]