=== AmarokNelg_ is now known as AmarokNelg [06:09] morning [07:21] o. [07:21] o/ [07:22] good morning everyone [07:23] zyga: hey [07:59] o/ [07:59] morning, zyga [08:07] hey pawel [08:08] sorry for being absent earlier, my son is ill and I'm trying to get him ready for a visit at the doctor's [08:08] so 2.30 is out, any hiccups on your machines? [08:08] mborzecki, pstolowski: can you check snap changes for any failures? [08:09] zyga, looks sane here [08:09] PR snapd#4432 opened: cmd/snap, tests/main/classic-confinement: fix snap-exec path when running under classic confinement [08:12] thank you mborzecki, looking :) [08:12] zyga: also reenabled one of the classic confinements tests on fedora now ;) [08:14] sweet [08:15] mborzecki: approved [08:15] great [08:15] mborzecki: I was thinking about the fedora symlink, perhaps we could enable that in prepare.sh globally [08:15] not a big deal and perhaps a risk in itsel [08:16] let's see if more tests start to need that [08:16] hm better talk to Son_Goku first [08:16] uhh, you're talking about tests [08:16] yes, just tests [08:21] pstolowski: can you please review https://github.com/snapcore/snapd/pull/4315 [08:21] PR #4315: cmd/snap-update-ns: add execWritableMimic [08:21] it has one +1 and I want to land it [08:21] it's from november :'( [08:21] looks like there's just a handfull of 'classic' confiment tests, we could enable fedora in those explicitly [08:23] mborzecki, pstolowski: in case you need to do it, this is how to release the core snap: https://new.zygoon.pl/post/core-snap-release-mechanics/ [08:25] zyga: good i'm not the only one finding arch/revision combination confusing [08:27] anyone wants to take a look at #4313? it's already been approved by niemeyer and needs a second review and perhaps comments on the syntax [08:27] PR #4313: timeutil: refresh timer take 2 [08:29] mborzecki: I'll do it next, looking at error in 4426 [08:29] thanks [08:29] zyga, will review. is mvo off today? [08:30] pstolowski: I don't think he is but perhaps he feels worse than yesterday and is just not around yet [08:31] mborzecki: reviewing now [08:45] btw. any ide what's the status of fedora 27 in spread? [08:49] mborzecki: no, is it broken? [08:56] zyga: see #4336, there's a comment from niemeyer about rawhide, and it has been addressed already [08:56] PR #4336: spread.yaml: add fedora 27 [09:02] zyga, reviewed 4315, mostly a few questions [09:02] mvo: hey, feeling better today? [09:02] pstolowski: thanks, I'll check soon [09:03] mborzecki: hey, good morning! yeah, still a bit weak but better [09:03] and good morning pstolowski and zyga ! [09:03] hey mvo! how are you feeling today? [09:03] welcome back mvo! [09:04] mvo: o/ [09:04] hey kalikiana [09:05] * mvo makes a cup of tea and starts looking at open PRs after that [09:24] PR snapd#4432 closed: cmd/snap, tests/main/classic-confinement: fix snap-exec path when running under classic confinement [09:46] mborzecki: booted my arch system, wish we had the binary package for snapd :/ [09:48] zyga: pacaur and makepkg are your friends :) [09:48] PR snapd#4433 opened: interfaces: allow socket "shutdown" syscall in default profile [09:48] mborzecki: while that's probably very arch of it it's not very snapd of it :) [09:48] mborzecki: I wish we could fix the package in the archive === d_ed is now known as d__ed [09:58] one more classic confinement tests that can be enabled on fedora now [09:58] PR snapd#4434 opened: tests/main/confinement-classic: enable the test on Fedora [09:59] mborzecki: hmm [09:59] mborzecki: that test is special-ish [09:59] mborzecki: think about what happens [09:59] mborzecki: to really properly test that you need to use fedora base snap [09:59] mborzecki: NAK unless you want to take it to the store and enable a pure binary built test (execution) on fedora [10:02] mborzecki: sent more feedback in the PR [10:02] zyga: doesn't that apply to all distros? [10:02] and small break [10:02] mborzecki: tests don't build C programs (most of the time) [10:02] see my feedback and let's talk here [10:10] mvo: mborzecki: dunno if you saw my Q yesterday about #4394 [10:10] PR #4394: snap: give the snap.Container interface a Walk method [10:11] zyga: i'm looking at the makefile, looks like it's a least pain path without involving the store [10:12] Chipaca: hi, did you see my asking for reviews yesterday? :) [10:12] pedronis: i did not [10:12] pedronis: 'appropriate creds'? [10:12] yes [10:12] and #4389 (which is small) [10:12] PR #4389: overlord/snapstate: override Snapstate.UserID in refresh if the installing user is gone [10:17] oooh [10:17] shit [10:17] ^H [10:17] badbadbad [10:18] zyga, ? [10:18] one sec [10:18] Chipaca: oh, yes, I saw and forgot, I open the pR now [10:19] Chipaca: so that I don't forget again [10:21] uff [10:21] the bug is just in my branch [10:21] fire over [10:21] and now it should work :) [10:23] zyga: heh [10:23] * mvo hugs zyga [10:23] I fixed the base snap stale thing [10:24] zyga: I love bugs that are only in your branches :-D [10:25] zyga: neato! [10:27] * kalikiana coffee break [10:28] mvo: I was checking if I'm on classic on the inside of the mount ns :'-(( [10:29] woooooot [10:30] pushed, I'll let travis deal with it now [10:31] zyga: about that test, it tries very hard to make sure that the binary works with ld.so and libs from the core snap, not sure why it should not run on non-ubuntu (btw. it's already enabled for suse and debian) [10:34] mborzecki: it should be only built on ubuntu and should run everywhere [10:34] mborzecki: suse is a bug here, it's equally meaningless [10:35] mborzecki: the point is that it must match the core snap, not the distro [10:35] mborzecki: to illustrate that any distro with the core snap can run correctly built classic snaps [10:49] pstolowski: updated 4315 and responded to your feedback, thanks [10:49] zyga, thanks, looking [10:50] zyga: ok, i'll try to rework the test to have the snap installed from the store, probably will need some help in the process :) [10:50] mborzecki: thank you, I'll gladly help [10:56] PR snapd#4431 closed: snap: make `snap info invalid-snap` output more user friendly [11:12] PR snapd#4435 opened: snap: do not leak internal network errors to the user [11:16] mvo: +1 [11:17] zyga: heh, nice one! [11:20] Chipaca: thanks [11:47] mborzecki: yeah, no symlink is going into the real stuff [11:48] and the only way I'm accepting classic confinement for real is when you guys finally fix the /snap thing [11:48] so that /snap isn't the barrier to classic confinement [11:49] Son_Goku: that's impossible [11:49] no it isn't [11:49] Son_Goku: you know it, I know it [11:49] I've actually talked to niemeyer about it before [11:49] there is a way... it's just very difficult [11:49] Son_Goku: such as? [11:49] I'd have to dig out old chat logs for that [11:49] which I don't have on hand atm [11:50] Son_Goku: when you have a moment please share, I'm curiou [11:50] will do [11:50] * Chipaca -> lunchmaking [11:52] ogra_: ondra: are you both on holidays still? [11:53] Son_Goku: https://github.com/snapcore/snapd/commit/563795fd8d628c64da4019aee3f5c6a845eb0fe7 might be worth cherry picking to Fedora package as it addresses an issue that broke running classic snaps (should the user do a /snap symlink first of course) [11:53] mborzecki won't work [11:53] re-exec is disabled in Fedora [11:53] Son_Goku: that's unrelated [11:53] Son_Goku: it's not related to reexec [11:53] oh snapexec [11:53] Son_Goku: it's a correct bugfix [11:53] we were using the icnorrect path to snap-exec [11:53] yeah, I'll cherry pick it [11:54] Chipaca, back tomorrow [11:54] Son_Goku: great, thanks [11:54] PR snapd#4436 opened: snap: do not leak internal errors on install/refresh etc [11:54] Son_Goku: I updated my f27 yesterday [11:54] it's not in 2.30 either, so I'll pull it when I rebase to 2.30 [11:54] Son_Goku: oddly it picked the updates in gnome-software but not in dnf? maybe I was still sleepy [11:54] try "dnf --refresh upgrade" [11:55] Son_Goku: I'll try next time, it's up-to-date now [12:14] zyga, kalikiana: I just got DNF into OpenSUSE Leap 15.0 [12:15] Son_Goku: will it replace zypper? [12:15] no [12:15] Son_Goku: what's the use case? [12:15] python3-dnf [12:16] for snapcraft [12:16] aah [12:16] also, kiwi can produce images for Fedora/CentOS with it [12:16] Son_Goku: woot, awesome [12:16] the goal here is to have a single backend for rpm stuff [12:17] and pretty much all distributions that aren't SUSE are gradually converging on DNF [12:17] SUSE has Zypper, which for all practical purposes works identically to DNF [12:17] since they use the same resolver [12:20] fwiw, even yocto also integrated dnf some time ago [12:22] yeah [12:22] I helped out kanavin with that last year [12:25] mborzecki: https://github.com/snapcore/snapd/pull/4337/files [12:25] PR #4337: cmd/snap: use snap-exec from core with a classic snap when reexecing [12:26] mborzecki: ^_^ i forgot about this [12:28] mborzecki: maybe you want to review it [12:28] i've added a comment there [12:33] ohh [12:33] I have green :) [12:34] everyone: please review this and let's have it in 2.31 [12:34] https://github.com/snapcore/snapd/pull/4329 [12:34] PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) [12:34] PR snapd#4315 closed: cmd/snap-update-ns: add execWritableMimic [12:34] mvo: 2.29 and 2.30 milestones on GH have no due date and are open [12:34] mvo: (thank you for opening 2.31) [12:36] jdstrand: ^ [12:37] given that 2.30 is stable now we can close 2.29 [12:37] I agree [12:39] hmm i'm trying `snapcraft cleanbuild` with the test snap, but it fails both on arch (running from snaps) and on xenial (installed from repos) [12:40] on arch it's trying to push an assert file to the container, looks like it's confused about the path where the assert file is, maybe something with snap mount dir being different than /snap [12:40] PR snapd#4437 opened: tests: add test that ensures we never parse versions as numbers [12:40] mborzecki: just build it manually [12:40] mborzecki: upload to the store [12:40] Chipaca no back working [12:40] mborzecki: and share it with mvo [12:40] Chipaca what's up? [12:41] mborzecki: it's a special test IMO [12:41] on xenial, the container is started, i see it gets updated, but then i get `Temporary failure resolving 'archive.ubuntu.com'` when trying to install gcc as build-package [12:41] mborzecki: request: please use test-snapd- prefix [12:41] ondra: https://forum.snapcraft.io/t/best-practice-for-reporting-ubuntu-core-system-kernel-issues/3382 [12:41] mborzecki: the dns issue you see is interesting and probably worth looking into, could be lxd specific, could be general /etc mess bug [12:41] ondra: i thought maybe you had input there (otherwise ogra_ will get to it tomorrow i guess :-) ) [12:42] zyga: i added --debug to cleanbuld, it dropped me to the shell and i can apt-get install gcc just fine :/ [12:42] aha [12:42] good then [12:42] mborzecki: really just build it and push to the store [12:44] Chipaca let me check [12:49] "rainbow" (in the bug) sounds wrong all over ... [12:50] would be somethig to verify ... [12:50] regarding the bug filing i think using "Snappy" for image issues is fine as a catch all project [12:51] ogra_: agreed. now get out of here. [12:51] :) [12:51] :-) [12:55] PR snapcraft#1842 opened: lxd: Change "Terminating" message to debug level [13:01] zyga: just to be sure, snapcraft register test-snapd-hello-classic && snapcraft push --release=edge test-snapd-hello-classic_*.snap ? [13:02] mborzecki: looks right (I think) [13:05] mvo: pushed it to the store, the name is test-snapd-hello-classic [13:15] morning [13:16] sergiusens: good morning! [13:17] kalikiana hey, mind looking at what mborzecki is talking about? [13:17] zyga I m not sure, but it would be nice to have an API to retrieve the snap-declaration/revision assertion from snapd :-) [13:20] mborzecki: can you paste your log somewhere? [13:22] kalikiana: https://paste.ubuntu.com/26312927/ snapcraft from snaps, trying cleanbuild on arch, lxd seems to work just fine [13:26] mborzecki: I notice `error: open /var/lib/snapd/hostfs/` are you using the lxd snap from edge? [13:26] mvo: this is the PR I mentioned: #4392 [13:26] PR #4392: many: refresh with appropriate creds [13:26] mborzecki: the snap broke just before xmas [13:27] sergiusens: I think you can already, via the snap known API [13:27] sergiusens: or are you talking about getting them from the store for snaps snapd doesn't know about? [13:28] kalikiana: https://paste.ubuntu.com/26312943/ and this is snapcraft on xenial, from packages, when i get dropped to debug shell i can successfuly install required packages, not sure why it's hitting a timeout there :/ [13:29] pedronis: thanks [13:31] mvo: the PR with the snap is #4434 [13:31] PR #4434: tests/main/confinement-classic: enable the test on Fedora [13:31] mborzecki: Broken DNS would be my guess. It seems to work and then fails later on. Did you do `lxd init`and go through the terminal UX to set up the network? [13:32] kalikiana, mborzecki: look at /etc/nsswitch.conf please, see if it's fishy [13:32] we could use a DNS-test-snap (spread test) [13:32] that exercises glibc API and maybe systemd-specific new API [13:33] kalikiana: cleanbuild --debug drops me to the shell in the container right? [13:33] mborzecki: Yes [13:34] zyga for snaps installed, kalikiana are you using that? [13:34] mborzecki: please run "snapcraft release test-snapd-hello-classic 1 edge" [13:34] mborzecki: and your snap should be availabe, then we need to transfer your snap [13:35] kalikiana: when i'm dropped to the shell, i can install gcc just fine [13:36] mvo: done [13:37] sergiusens: zyga for locally installed snaps, we have code in snapcraft to get assertions via the snaps endpoint (https://github.com/snapcore/snapd/wiki/REST-API#get-v2snapsname) . If that's what you're looking for, checkout this code https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/lxd/_containerbuild.py#L236 [13:37] mborzecki: I can believe that. And unfortunately it doesn't contradict what I said [13:38] that's what broken DNS does [13:38] mborzecki: cool, now fire away, your test hopefully works now [13:38] my keyboard seems to have issues when I do backups over wifi :/ [13:39] sergiusens: I mean whatever fuels "snap known", not sure what that is [13:39] mvo: thx, started the test just now :) [13:39] zyga: tried switching the wifi to 5ghz band? [13:39] mborzecki: I am using it [13:39] mborzecki: (ah, no) [13:39] perhaps it's not [13:40] mborzecki: You can also check `ifconfig` and `/etc/resolv.conf` if there's a proper IP and ns respectively [13:40] my backup is to a "home" network that uses a mixture of 2.4 and 5 [13:41] kalikiana: fyi, it's also runnign in a vm :), so it's qemu -> xenial -> lxd in this case :) [13:43] mborzecki: that's generally fine. I'd try `sudo dpkg-reconfigure lxd` suspecting you didn't configure it before [13:44] in the xenial running in the vm [13:46] mborzecki: I'm heading out for lunch now. If that doesn't do the trick I'll try to think of what else to debug there [13:46] kalikiana: thanks, i've reconfigured lxd and trying a cleanbuild now [13:47] kalikiana: seems to work now :) thanks again [13:49] mborzecki: Sweet! Glad it worked! [13:49] * kalikiana now trying to leave the house without being blown away by the wind [14:15] still got some spread tests running, but i'm wrapping it up for today [14:33] mvo: seems we changed something about test-snapd-toosl release status, and now test snap-info failes [14:33] test-snapd-tools.channels.beta expected '↑', got '2.10 (7) 12kB -' [14:34] beta was closed and now it has a different release [14:35] pedronis: uh, I can fix this [14:36] pedronis: fixed, sorry for the trouble [14:37] mvo: is the new version needed for some work in progress? [14:39] pedronis: yes for my latest PR but I can use a different snap or adjust the tests in my PR, I don't want to break the world with that [14:39] ok, thank you [14:46] re [14:55] good morning! :D [15:05] hey elopio [15:08] elopio: whilst preparing snapcraft#1842 I noticed we seem to have no way to test if log messages use the expected level (debug, info). might be nice to consider what we could do about it in the future [15:08] PR snapcraft#1842: lxd: Change "Terminating" message to debug level [15:09] kalikiana: yeah, we have pending a complete redesign of logs, info messages and errors. Currently we have a mix of prints, logs and exceptions [15:10] elopio: I'm referring to existing uses of `logger`. There's no way to test that they use the correct level [15:12] kalikiana, you can make a fake logger that grabs a specific level [15:16] kyrofa: Hmmm do we have an example of this? [15:16] Yeah let me find one [15:17] Thanks! [15:21] kalikiana, look at test_yaml_missing_confinement_must_log in unit/project_loader/test_config.py [15:21] It's the FakeLogger fixture. It grabs whatever logging level you define as well as more critical levels [15:22] Perhaps that latter point makes it less useful for your case, I'm not sure [15:24] kyrofa: Hm... I think I need sort of the opposite. Assuming info would be 'more critical' I'd get the message, whether it's info or debug [15:25] kalikiana, are you trying to verify a message is debug, or info? [15:25] kyrofa: I'm changing the message from info to debug. I'd like to verify it's debug only. [15:28] kalikiana, you can change the log format in that fixture to include the log level [15:28] Kinda hacky, but then you could match the log level [15:33] Hmmm I'll give that a go. Thanks! [15:56] PR snapcraft#1843 opened: elf: warn if primed files will not work with the base's linker [15:59] kyrofa elopio ^ [16:00] * sergiusens is not a fan of checking for existence or lack of messages logged in tests [16:03] sergiusens: kyrofa: elopio This is what I came up with https://github.com/snapcore/snapcraft/pull/1842/commits/535cefbabbdb69481a4a6cc73ed3998e551d1f82 I'm not checking existence here, but rather that the level is correct [16:03] PR snapcraft#1842: lxd: Change "Terminating" message to debug level [16:13] sergiusens: checking... [16:17] kalikiana: I don't think that test is really necessary, mainly because as I said, we need to rethink our logger. I'm happy with tests that set the fake logger to debug, and check if the debug message is there [16:18] even if that will miss the specific level of the message. But your test looks correct too, I don't see a problem to land it. === Tribaal is now known as tribaal [16:24] elopio: A test that checks if the message is there won't fail without my change [16:26] I know, I'm saying I don't mind that that line is not fully covered. But it's ok if you care about it, of course. [16:35] PR snapcraft#1832 closed: cmake plugin: update plugin details [16:37] sergiusens: FYI I was certain there was a bug for this but couldn't find it... so I filed a new one in any case https://bugs.launchpad.net/snapcraft/+bug/1741082 This is for the permission issues with staged packages in conjunction with sshfs [16:37] Bug #1741082: sshfs breaks with serving user files to root in LXD [16:50] elopio: I can also back it out and we plan for a better solution. This was a pretty quick hack anyway. I just feel a bit... uneasy committing untested code [16:50] +1 [16:51] * kalikiana wrapping up for the day shortly - will have to push the sshfs PR in the morning since the tests aren't ready [16:59] PR snapcraft#1844 opened: Included fix for error messages [17:04] hi snappy-devs! I'm a bit green when it comes to Golang coding, but am trying to just run the tests before making any changes and am hitting https://paste.ubuntu.com/26313885/ [17:05] any clues? [17:06] sparkiegeek: your vet is newer or older than ours :-) [17:06] Chipaca: ⟫ go version [17:06] go version go1.8.3 linux/amd64 [17:06] Chipaca: which one do I want? [17:07] sparkiegeek: actually, i just checked and 1.6 and 1.9 are both happy with that file [17:07] Chipaca: it's interesting though that afaict Plug and Slot don't have a String [17:07] so that might be ok but not ideal [17:08] maybe pstolowski should look at that [17:08] PR snapd#4438 opened: snap: add new `snap advice-command` skeleton [17:09] ok, so in the meantime... should I just ignore it? or should i use a different go version? [17:09] I can't see anything in HACKING.md about what the supported Go version is [17:09] sparkiegeek: just ignore the bet errors while we investigate, just run ./run-checks --unit in the meantime [17:10] sparkiegeek: we support *all* (kidding, we should add go1.6+) [17:11] sparkiegeek: a PR with the fix for the HACKING.md would be welcome :-D go1.6+ is what we support [17:12] sparkiegeek, pedronis, will fix the code [17:13] Chipaca: afaict %s doesn't produce anything sane with a struct without String that doesn't have all fields that are strings [17:14] although [17:14] PlugInfo and SlotInfo do have String() [17:14] mvo: on it [17:14] re [17:14] * zyga is more awake now, sorry for being absent earlier [17:14] ah, it's Plug/Slot [17:14] I was writing (but not code) [17:14] about sanpd [17:14] snapd [17:15] sparkiegeek: \o/ [17:15] Chipaca: otoh golang.org at the moment doesn't let me share my example [17:15] :/ [17:17] mvo: https://github.com/snapcore/snapd/pull/4439 [17:17] PR #4439: Add documentation for supported Go versions [17:17] pedronis, is it possible vet got confused? i'm looking at these lines and they are dealing with PlugInfo and SlotInfo (and these have String()), not interfaces.Plug/Slot as indicated by vet [17:17] PR snapd#4439 opened: Add documentation for supported Go versions [17:17] pstolowski: ah [17:17] interesting or sparkiegeek doesn't have master ?? [17:18] or that... [17:19] pstolowski: I looked at that once and it looks like vet bug [17:19] pstolowski: it's meaningless (the error) [17:19] I'm running 55648cb8358825a18c6f926c38416703b48edd1f afaics [17:21] but I'd definitely suspect PEBKAC if it's not reproducible? I'm just using Go from Artful [17:21] sparkiegeek, ok, that's the latest [17:22] sparkiegeek, looks more like a vet bug as zyga says. the error mentions wrong type, it's not the one used in the code [17:22] pstolowski: I mean, I might well have screwed things up, I find myself battling $GOPATH quite often :) [17:55] PR snapd#4426 closed: snap: print friendly message if `snap keys` is empty