[00:48] PR snapcraft#1961 closed: Sentry [00:51] PR snapcraft#1962 closed: store: stringify message for StoreDeltaApplicationError === nacc_ is now known as nacc [06:07] morning [06:08] Goood Morning! [07:08] mvo: morning [07:15] hey mborzecki ! [07:15] mborzecki: good morning [07:17] heh the timer services spread test is failing on 14.04, can't figure out why, cannot reproduce it in spread debug shell either even if i do `snap enable test-snapd-timer-service && snap disable test-snapd-timer-service` in a loop [07:19] and the error does not make any sense `start snap.test-snapd-timer-service.random-timer.timer] failed with exit status 6: Failed to issue method call: Unit snap.test-snapd-timer-service.random-timer.timer failed to load: No such file or directory` [07:21] hmm and we don't seem have any tests for enable/disable that touch services [07:26] mborzecki: hm, I have not seen this error before [07:27] mvo: this happens when i reenable the snap that has timer services, i'm adding a test right now to see if this happens also if there's just regular snap with services [07:30] mvo: also, the start happens after enabling the unit, so somehow systemctl enable worked, but systemctl start does not [07:31] hey mvo :) [07:31] zyga: hey [07:31] hey :-) [07:31] man, I overslept [07:32] mborzecki: hm, lets hope its not a general problem [07:32] zyga: hey, good morning [07:33] I got a failure of snap-service-refresh-mode [07:33] reinstall did stop a service that shouldn't [07:33] full log in https://api.travis-ci.org/v3/job/346989504/log.txt [07:34] * zyga notices the extended reply on https://forum.snapcraft.io/t/lxd-issue-due-to-snap-confine-apparmor-profile/4203/19 [07:40] Can anyone help in this? https://forum.snapcraft.io/t/cannot-upload-to-store/4250/9 [07:40] i.e. why am I getting this external libusb symlink when I built with Snapcraft? [07:40] kalikiana ^ [07:40] hi [07:41] pedronis: hey, morning [07:42] mvo: while trying to understand why the core transition tests failed with my new code, I found an interesting thing about them [07:43] pedronis: tell me more [07:44] mvo: since we have the base code we always install core when installing a new snap (if it's not there), even if ubuntu-core is there, so the two kind of test are the same now [07:44] pedronis: oh, indeed [07:45] I don't know if there is something to do [07:45] but I was confused for a bit [07:45] (I found the problem with my new code) [07:47] * mvo nods [07:48] mvo: we might want to remove of them, or merge them somehow [07:48] s/of them/one of them/ [07:49] I don't think at this point fixing the "bug" make sense [07:50] pedronis: indeed, I would love to get rid of all of them but not quite yet (its an expensive test) [07:55] and let them live there before they get removed [07:58] pedronis did you push the fix for the timestamp issue to 2.32? [07:58] no [07:58] only master [07:59] I just got this failure in a 2.32-based PR, perhaps it's worth doing so [08:05] mvo I wanted to update you on layouts [08:06] there is one PR that I asked you to co-review with jamie, that I would like to cherry-pick into 2.32 [08:06] there will be a follow-up today, building upon the concept, that will have a similar fate [08:06] both of those should be cherry-picked into 2.32 [08:06] the changes are non-trivial so I wanted you to be aware of that [08:10] zyga: what is the risk of breaking things there? i.e. is it a new feature (user mounts) or modifying exiting behaviour? [08:10] mornings [08:10] mvo a bit of both [08:11] mvo snap-update-ns will now use per-snap profile [08:12] mvo the follow-up PR will remove broadly open permissions and replace them with values that match the layout of a given snap [08:12] as well as inject $SNAP_NAME (expanded) into many places that currently use a glob [08:14] zyga: how critical is that? 2.32 already contains quite a bit of churn and its only 2 weeks away. I'm a bit concerned about adding things that might break [08:14] zyga: maybe we can discuss in more detail in the standup? [08:14] mvo pretty critical I'm afraid, jamie requested that to be in 2.32 [08:15] to avoid pretty-much unconfined snap-update-ns [08:15] ok [08:21] o/ [08:28] mo'in [08:29] mvo: I'm off to the dentist's first thing, should be back for a late start (my 11am) [08:31] Chipaca: hey, thanks [08:33] https://github.com/snapcore/snapd/blob/master/wrappers/services.go#L250 daemon-reload should probably happen when we add service files, regardless of those being enabled or not, shouldn't it? [08:35] mborzecki: yes, good catch [09:00] hmm [09:00] I'm seeing failres of snap-info [09:00] zyga: oh, featured list changed again? or the install date? [09:00] no, it is summary, it seems [09:01] + snap info basic_1.0_all.snap /home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/basic-desktop test-snapd-tools test-snapd-devmode core /etc/passwd test-snapd-python-webserver [09:01] + python3 check.py [09:01] in test-snapd-tools.summary expected 'Tools for testing the snapd application', got '' [09:01] starting local run now [09:02] I doubt this is something that is broken in my branch as it is entirely unrelated [09:03] btw. don't recall, do we do any testing with recentish nvidia cards? [09:03] mborzecki sergio ran some tests remotely recently [09:03] mborzecki not sure how recent the hardware was though [09:04] hmm, the user that had the stack smashing detected on manjaro with nvidia drivers got back to me, he's seeing the problem on arch too, nvidia drivers 390 [09:05] i'll suggest him to open a topic in the forum, maybe jdstrand will be able to suggest something [09:14] and indeed [09:14] I don't get a summary [09:14] https://pastebin.ubuntu.com/p/m5KQPxNSw4/ [09:14] any ideas anyone? [09:14] description is also empty [09:15] it's coming from the local snap.yaml i suppose [09:16] mvo, hi, I'm getting this error https://paste.ubuntu.com/p/gTrF3Z8yTS/ when trying to rebuild the maas snap with the custom base-18. did something change in bionic? [09:16] zyga: when it goes from the store there's both summary and description https://paste.ubuntu.com/p/3GZR5q5XJC/ [09:17] ackk: this looks like a snapcraft change, I wonder if it is not taking bases into account? it takes about core there [09:17] ackk: maybe kalikiana can help with the above error (cc https://paste.ubuntu.com/p/gTrF3Z8yTS/) [09:18] mvo, oh, I wonder if I'm usin an older version now (I used to use snapcraft from the snap) [09:18] hmm, test-snapd-tools doesn't have a summary [09:18] (or description) [09:19] checking master now [09:27] hmm [09:27] it passed on master [09:27] trying again [09:28] and now my branch passed [09:28] mvo there's something wonky going on, snap-info fails ~ 2/3 runs [09:36] zyga: woah, for snap info - that is astonishing [09:36] I don't understand it yet, running one test I saw a failure a moment ago [09:36] now no failures for 3 runs [09:36] zyga: only in tests? or also on a real system [09:36] zyga: is this coming from the store or from the local snap? [09:36] only in tests so far [09:37] main/snap-info [09:37] good question [09:37] from the store [09:37] maybe we hit different machine via load balancing [09:37] and one gives wonky answers [09:39] mvo: do you know anything about this error? https://pastebin.canonical.com/p/mdnpq6rM7T/ [09:39] mvo: it started happening recently (noticed it today), so i would suspect something changed in snapcraft [09:40] mvo: this is trying to build agains the base-18 on bionic [09:40] mvo so on my bionic machine I just installed test-snapd-tools [09:40] and it has a summary and desscription [09:40] mvo, BjornT's error is the same as mine [09:40] but just a moment ago inside a test I did the same and they were both empty (see the pastebin I sent earlier) [09:41] mvo, BjornT I'm trying to build with snapcraft from the snap (rather then the bionic one) and it now gets stuck on priming [09:43] zyga: was the test using a different channel? [09:44] no [09:44] same test in a loop [09:44] it doesn't fail now, maybe store got fixed now [09:45] BjornT: I talked about this with ackk some minutes ago, it looks like snapcraft is not taking "base" into account when it warns about the glibc incompatibilities [09:46] mvo: any chance of getting it fixed (or a workaround) quickly? it's blocking maas development [09:46] ah, the deb in bionic is newer than the snap stable version, I wonder if something broke there [09:47] BjornT: that is a question for sergiusens and/or kalikiana - I am not working on snapcraft myself, sorry. but lets hope they get back to you quickly [09:53] mvo, do you think #4762 could go o 2.31? [09:53] PR #4762: servicestate: use systemctl enable+start and disable+stop instead of --now flag [10:13] kalikiana, around? any suggestion on the issue above? ^ [10:23] I cannot reproduce snap-info error anymore [10:23] so maybe just a temporary fluke [10:23] pedronis is the store undergoing any updates now? [10:23] we reverted something I think [10:23] don't know if it was related [10:26] pstolowski: definitely 2.32, I think I will also cherry-pick to 2.31 just to be on the safe side [10:26] mvo 4760 is ready for your review now [10:28] zyga: must be later todday, I need to meet the feature freeze deadline for c-n-f [10:28] mvo understood [10:28] mvo curious, will you still tweak the output? [10:28] sorry! [10:28] I really didn't like the odd output I saw last night? [10:28] zyga: tweak the output of c-n-f ? [10:28] yes [10:29] https://bugs.launchpad.net/command-not-found/+bug/1749777 has the latest agreements as-i-understand-them [10:29] Bug #1749777: Syntax tweaks for snap-friendly output

=== LtWorf_ is now known as LtWorf [10:29] zyga: there is a bit of controversy still but its difficult to find a solution that makes everyone happy, we discussed that quite a bit [10:30] what bugs me the most is that the mixed advice there doesn't give instructions on how to do anything about installing it [10:33] zyga: indeed, I think we did a pad with some clever ideas, just need to find it [10:34] mvo I made a trivial suggestion [10:34] https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1752185/comments/3 [10:34] Bug #1752185: Formatting of command-not-found with snap addition could use cleanup [10:34] zyga: https://pad.ubuntu.com/1C0cSZX9oB [10:34] zyga: sure, that is welcome [10:35] mvo is "this is what we will do" part true? [10:35] as in, that's the thing you will code [10:37] mvo, ack [10:38] PR snapd#4762 closed: servicestate: use systemctl enable+start and disable+stop instead of --now flag [10:38] zyga: it was true [10:39] zyga: and then this bugreport with another version of the syntax came along [10:39] zyga: that was the outcome of a long(ish) meeting with john and gustavo, I think the result is good but its also noisy, the idea from mark has the advantage that its very compact [10:39] I think it just hast to be useful and feel good [10:39] good luck on that [10:51] ackk: Sorry, I was in a call. Looking in a moment [10:51] kalikiana, thanks [11:03] BjornT: What Snapcraft are you building with? Edge? There've been some recent fixes on master although base support is still a work in progress. I'd defer to sergiusens here since he's working on that. [11:07] kalikiana, I've been using stable, I'm building with edge now [11:07] kalikiana, priming now seems to take a very long time [11:08] kalikiana, it fails with edge as well [11:08] kalikiana, so, stable does seem to take into account bases, edge (or bionic package) doesn't [11:09] BjornT, kalikiana even no-system-libraries fails for me [11:14] kalikiana: i'm using git master to build the snap. using no-system-libraries takes me further. it still prints out warnings and i get a snap. but now i get python import errors when trying to run the snap. it seems that /usr/bin/python3 is used, which doesn't have my python modules [11:32] pedronis, hey, running again the tests against stagin [11:32] g [11:32] cachio_: no, need, I did this morning [11:32] also there's a problem with staging [11:32] we are trying to fix [11:33] pedronis, ok, so many errors? [11:33] yes, not a lot [11:33] but more that there should be [11:37] pedronis, ok, I am making a run now [11:38] pedronis, I already started it [11:38] ok [11:54] Is it possible to have multiple versions of a snap installed simultaneously? [11:54] mpt not yet but Chipaca is working on that [11:54] ah, cool [11:54] no i'm not [11:54] :) [11:55] but i will be, next [11:55] or, rather, that's the next big thing i'll be working on [11:57] PR snapd#4765 opened: interfaces/apparmor: use snap name instead of wildcards [11:57] PR snapcraft#1964 opened: Fix Store integration tests with updated snap name registration error messages (take 2) [11:57] I need some reviews [11:57] for this (last patch only) [11:57] and the one before [11:57] anyone interested [11:57] this one is actually trivial [11:57] https://github.com/snapcore/snapd/pull/4765/commits/caafe76f4c3040426573b81def2a645119c68451 [11:57] PR #4765: interfaces/apparmor: use snap name instead of wildcards [11:59] Chipaca, ok. When you do have multiple versions installed, will they always have access to the same interfaces? Or will it be possible to differentiate? (for example one version has access to the camera while the other doesn’t) [12:00] mpt: as I understand it they'll be separate entities as far as that aspect of things [12:01] mpt: but there isn't even a forum topic about it yet, so it's rather green [12:01] Chipaca, thanks. (Reason I’m asking is, that means they’ll need to be listed separately — and disambiguated — in GUIs for seeing/changing what permissions they currently have.) [12:01] mpt: (if you feel strongly one way or the other now'd be an ideal time to bring it up :-) ) [12:06] pedronis, I uploaded 3 snaps to staging [12:06] pedronis, it should fix the 3 failing tests that I swaw [12:06] I0ll re run to see we have 100% passing [12:11] kalikiana: fwiw, i tried this patch: https://paste.ubuntu.com/p/s2t3wct5J3/ [12:12] kalikiana: the maas snap builds then, but then the configure hook complains: https://paste.ubuntu.com/p/G3dsTh33Fg/ [12:12] kalikiana: libssl.so.1.1 is in the snap, though [12:17] kalikiana: btw, LD_LIBRARY_PATH doesn't seem to be set [12:21] PR snapd#4766 opened: userd: add an OpenFile method for launching local files with xdg-open [12:22] Chipaca have a look at 4755 please [12:40] mvo, still working with sru [12:40] I see some denials [12:41] https://paste.ubuntu.com/p/6WJfXd952Q/ [12:48] zyga, I am tesintg on google and I see bionic has not SElinux enabled [12:48] cachio_ why would it be enabled? [12:49] zyga, well, hte problem is that we are trying to uninstall snapd_selinux package [12:49] and it is failing [12:49] that package only exists for fedora [12:49] the package is not installed [12:49] why would we do that? [12:49] we do that in the upgrade test [12:51] ok, in that case something else is wrong [12:51] zyga, after remove and reinstall snapd [12:51] there's no such package in ubuntu or anywhere else but fedora [12:51] zyga, I see all the snaps broken [12:51] so probably some wrong pattern somewhere [12:52] zyga, ok, thanks!! [12:52] zyga: you sure you meant to ask me to look at my own pr? [12:53] yes :) meant to look at the feedback [12:54] zyga: I think I'll just replace it with a MatchCounter [12:54] the gist of this pr predates that :-) [12:57] PR snapd#4767 opened: interfaces: disconnect hooks [13:01] PR snapd#4763 closed: osutil: handle file being matched by multiple patterns (2.32) [13:03] zyga: hey, I approved PR 4745 [13:03] PR #4745: osutil: allow creating strings out of MountInfoEntry [13:03] jdstrand hey, thank you! [13:03] zyga: I looked at PR 4765, but I think the rules need tuning. lots of apparmor denieds [13:03] PR #4765: interfaces/apparmor: use snap name instead of wildcards [13:03] jdstrand I'm going through hardening, got slowed down by store issue in the morning but now I'm iterating quickly [13:04] yes, I'm fixing that now [13:04] ok [13:04] I've added it to my list. when it passes automated tests, I'll look at it [13:05] thanks! [13:06] PR snapd#4745 closed: osutil: allow creating strings out of MountInfoEntry [13:12] cachio_: hm, wonder if snapd-app-helper in our installed profile [13:16] PR snapd#4768 opened: [RFC] snap userd autostart v2 === ondra_ is now known as ondra [13:32] * kalikiana lunch time [13:35] sergiusens: kyrofa: snapcraft#1964 fixes your integration tests vis-a-vis new validation failure messages [13:35] PR snapcraft#1964: Fix Store integration tests with updated snap name registration error messages (take 2) [13:37] mvo: BjornT no, becuase I asked what the official bases would be named (you are CCed in that email mvo) to actually work on this ;-) [13:48] Chipaca: maxiberta is the integration store server updated to follow these strings? Once this is updated, all the store triggers will fail until updated, are you aware of that? [13:49] sergiusens: what's the 'integration store server'? [13:49] sergiusens: and what are 'store triggers'? [13:54] PR snapcraft#1963 closed: Fix Store integration tests with updated snap name registration error messages [13:56] Chipaca: OLS triggers pre-deployment tests using our test suite against the integration/staging store [13:57] sergiusens: ah! that's why maxiberta wrote the first PR (which didn't address the whole issue) [13:58] Chipaca: yeah, but this is chicken and egg problem unless we allow dual results in the tests :-) [13:58] sergiusens: core18 [13:58] sergiusens: will be the name [13:58] sergiusens: but there might be more [13:58] sergiusens: … the code with the new errors is on staging [13:59] sergiusens: maybe I'm not understanding something [13:59] Chipaca: oh, I am asking, I am not stating :-) [13:59] Chipaca: let's make this simple, cprov can you +1 https://github.com/snapcore/snapcraft/pull/1964 :-) [13:59] PR snapcraft#1964: Fix Store integration tests with updated snap name registration error messages (take 2) [13:59] sergiusens: maxiberta is probably the person to answer, then [13:59] I am far from understanding all the links, I just dived in there and broke stuff [13:59] :) [14:00] the new strings are already deployed on staging Store [14:00] sergiusens: production rollout is in progress, the changes matches what we have in production [14:00] mvo: is there a forum post or something where everyone +1s? I thought that was the process for bases. I would really like to see general agreement for this as it would be really hard for us to change this (wrt SRUing) if this changes [14:00] *will* have in production in a few minutes [14:00] cprov: great, then in it goes [14:01] thank you [14:01] pstolowski, niemeyer: when you talk about "snap connections", I'd love to participate [14:01] thanks Chipaca, sergiusens [14:03] zyga, sure. but i think i'll go with something straighforward as outlined by nimeyer during the standup, not sure we will discuss it more [14:03] * pstolowski lunch [14:07] PR snapcraft#1964 closed: Fix Store integration tests with updated snap name registration error messages (take 2) [14:07] sergiusens: what is the 'assigned' thing github tells me when you merge stuff? [14:08] I'm getting error when uploading a snap to the store [14:08] package contains external symlinks: usr/lib/x86_64-linux-gnu/libusb-1.0.so lint-snap-v2_external_symlinks [14:08] Chipaca: just my internal way of making sure later who worked on what to backtrack and provide a thank you drink ;-) [14:08] But the package was built with snapcraft, isn't suppose to take care of such links? [14:09] Jasem[m]: some snaps are allowed some symlinks, so we cannot remove them "magically" or part of the building populus might be unable to create snaps in the first place [14:11] Chipaca: well, any idea how to resolve this problem then? [14:11] you can use `stage` or `prime` keywords to filter it out, but somehow I think the actual package from the archive in this case might be problematic as .so files are usually linked directly to a .so. in the same directory (and this one seems to be using an absolute path) [14:13] mvo, did you see the denial on the sru? [14:15] mvo, I have a debug open [14:20] zyga, pstolowski: We should definitely have talk about it before spending much time on one direction [14:20] Forum is great for that [14:20] Chipaca: Just responded on that thread [14:21] niemeyer: appreciated [14:22] PR snapd#4769 opened: wrappers: detect whether systemd-analyze can be used in unit tests [14:22] niemeyer: can we line up the 'days' to make scanning easier? [14:23] Chipaca: think it'll look awkward in the general context [14:23] Chipaca: Similar issue we had with "installed" (the version) [14:23] Chipaca: Also, "today" and "yesterday" won't align either [14:24] true dat [14:24] the former is less a concern now that the first indent isn't all uniform [14:24] (for the best i think) [14:24] but, it's not like we're oging to have 10 of these lines :-) so i'm just being a nit [14:24] niemeyer: thanks [14:25] Chipaca: np, thanks for calling it out [14:31] mmmm [14:31] pierogi :-) [14:31] I missed that [14:32] jdstrand 4765 is green now [14:32] if you look at the 2nd patch there the review is easier [14:34] cachio_: yeah, so about the denial> what do you see with " grep device-helper /etc/apparmor.d/usr.lib.snapd.snap-confine.real " [14:36] mvo, empty [14:39] cachio_: hm, that sucks [14:39] cachio_: if you grep for udev in there, what do you get? [14:39] cachio_: and please also grep for usr.lib.snapd [14:41] zyga: ack [14:42] * cachio_ afk [14:47] mvo that's weird [14:47] what's on bionic? [14:47] * zyga finished with pierogi and gets back to hardening [14:52] zyga: it looks like something is wrong with the apprmor profile, but its strange [14:52] hmm, didn't we have something like that a moment ago [14:52] zyga: oh, actually - 2.31 still have udev/snappy-app-dev [14:52] the device-helper rules went away [14:54] hmmmm [14:54] what was that [14:54] ah [14:54] I remember now [14:54] but that was for a re-exec rule [14:54] and just for testing scenarios [14:54] not for real-life issues [14:55] and in either case, we fixed that one [14:55] so ... [14:55] no idea, I'll go back to hardening [15:08] cachio_: do you have more context about the sru error? I see the denial but in what test is that happening? what is odd is that on 2.31 we have /lib/udev/snappy-app-dev - we moved to snap-device-helper only in 2.32 [15:10] cachio_: just let me know when you are back, happy to look at this then [15:13] niemeyer, zyga ok! [15:30] ok jdstrand whats a good non-conflict definition to copy for an interface? [15:30] to copy for an interface? [15:31] what does that mean? [15:31] like for making a new interface [15:31] ah [15:31] you wanna start with something and iterate [15:31] whatever it is i went with last time was wonky [15:31] start with common [15:31] then see what you miss [15:31] most things are fine with common [15:31] my actual definitions were fine for apparmor and seccomp [15:31] its the actual interface struct that was wonky [15:32] which seems woefully undocumented [15:32]