[01:25] PR snapd#5000 closed: errtracker: make TestJournalErrorSilentError work on gccgo === phoenix_firebrd is now known as phoenix_firebrd_ === phoenix_firebrd_ is now known as phoenix_firebrd [05:13] Caelum: yeah, I'll ask for that now [05:15] morning [05:16] zyga: ideally they'd have a nightly cron job or something [05:16] I just asked, not sure how it is set up [05:16] And we have another point release of snapd [05:16] nice [05:17] I will prepare the build [05:17] And maybe, just maybe, work on features again [05:17] This week was tough [05:18] Useful, fantastic bug fixes, but tough === phoenix_firebrd is now known as phoenix_firebrd_ === phoenix_firebrd_ is now known as phoenix_firebrd === phoenix_firebrd is now known as phoenix_firebrd_ === phoenix_firebrd_ is now known as phoenix_firebrd [06:21] I have updated https://github.com/snapcore/snapd/releases/tag/2.32.3 [06:22] Caelum: do you want to update the package to 2.32.3? === JanC_ is now known as JanC [07:14] good morning [07:22] zyga: sure I'll give it a go [07:22] thank you! [07:24] PR snapd#4998 closed: release: 2.32.3 === pstolowski|afk is now known as pstolowski [07:27] mornings [07:30] hey pawel [07:30] I figured out how to make my laptop not shutoff randomly so that should help [07:36] zyga: i left one comment in #4996 [07:36] PR #4996: overlord/ifacestate: store and use revision with security profiles set [07:36] thanks [07:36] otherwise looks sane to me [07:40] fixed [07:40] the formatting [07:40] is the error really a problem? [07:41] zyga: it is in if/then/else block, the thing is if Get() fails, the err will be swallowed up, don't know if that's intended (maybe it is?) [07:43] which err is swallowed? [07:43] the one from Get or the one from setup affected tasks [07:43] zyga: one in line 206 [07:43] the Get one is deliberate [07:43] yes [07:43] aah ok then [07:43] we don't want to err n that [07:44] ah [07:44] I misunderstood your comment then [07:45] all clear now [07:45] zyga: do you know if we still even need the libtool patch? [07:46] I suspect it is needed [07:46] because there's some build flags that get injected in some odd way I don't understand [07:46] we will simplify the C build system soon [07:46] drop auto mess [07:46] and remove more (all) conditionals [07:47] cool [08:10] popey: I reverted irccloud-desktop on my system as the latest revision is not working [08:10] revision 25 is ok [08:10] 41 doesn't start [08:12] This is because you reverted snapd [08:12] 2.31 breaks irccloud [08:12] 2.32 fixes it. [08:13] When will 2.32 come back to stable? (You could get core from beta to work around) [08:17] I see [08:17] I think next week [08:17] but I don't know for sure [08:17] we just released a new beta [08:22] i got core from beta due to the nvidia fixes, can confirm irccloud-desktop works [08:23] also the font issue I had in irccloud-desktop with twitter previews appears to have gone away, so thanks whoever fixed that! :) [08:24] zyga: it broke other applications too, ones we were waiting for 2.32 for. Quite frustrating as I'm now being pinged everywhere that my applications are all broken [08:25] do you know which feature missing in 2.31 is key? [08:25] I hope we can update to 2.32.3 [08:26] It's the new stuff from jd strand to turn kernel errors into warnings. [08:26] things that request process-control or try to chmod files break [08:26] so games break, nodejs applications break. we waited for 2.32 before releasing them and making a splash, now we have to go and clear up that mess [08:34] I'm struggling a bit with updating an older snap (mysql). Paths for various library files and binaries are no longer loaded by default. Do I need to manually specify every path to LD_LIBRARY_PATH? [08:34] (snapcraft 2.39.2) [08:36] Skuggen: you're updating _the_ mysql snap? [08:36] Skuggen: or a snap that uses mysql? [08:37] popey: 2.32 broke people doing snap install lxd though [08:37] Chipaca: The mysql snap [08:37] Skuggen: nice :-) [08:37] Sure. I understand there was an issue. But we got a "surprise, we broke your apps to fix someone elses" [08:37] I would like for there to be an incident report for this. Why was this not caught in QA? [08:38] because basically snap install lxd only exercise core once its in stable [08:38] we need to find a way to test that before [08:38] Chipaca: We were blocked by various missing features (privilege dropping, setting file ownership, etc.) so haven't looked at it for a while. I'm working on getting it updated so we can see what might still be missing for us to properly support it [08:39] zyga: any new data files in .32 I should know about? [08:39] Skuggen: daemons still only run as root, that hasn't changed [08:39] fwiw [08:39] popey: about an IR, that's fair, mvo should look into that [08:40] Thanks [08:44] Chipaca: Yeah, that is an issue. We could have some limited support of it even so, though. But first I need to actually get it working again :) [08:44] :) [08:44] Skuggen: just the other day somebody was asking about using mysql in a snap, fwiw (via embedding), and looked at the mysql snap as an example [08:45] (and then looked away in haste) [08:45] Skuggen: https://forum.snapcraft.io/t/mysql-server/4877 [08:45] just yesterday, in fact [08:45] Caelum: no, it's all the same [08:46] awesome [08:47] I need to redo it at some point to do a make install on data [08:47] Chipaca: Ah, can respond to that at least :) [08:48] Skuggen: do you know what version of snapcraft you used to build the snap before? [08:49] Hm, can you get that information from the snap itself? [08:50] Skuggen: I don't think you can [08:50] * Chipaca is not a snapcraft expert though [08:50] kalikiana: snapcraft doesn't record its version in the snap in any way, does it? [08:51] We used a xenial host, but don't know what version it had at the time [08:52] Submission date [08:52] 2017-01-27 08:18 - 1 year, 2 months ago [08:52] Oold [08:52] That's the one on the store [08:54] Skuggen: and the one in the 'latest' track is even older, 2016-12-19 [08:54] that's latest/beta [08:54] Caelum: and I heard the install instructions are now live [08:55] indeed they are, fantastic === sparkieg` is now known as sparkiegeek [08:57] popey: do you know if there's a guide or knowledge base or sth to update a snap that was created using snapcraft in the pleistocene? [09:00] zyga: /usr/lib/udev/snappy-app-dev is gone, do we drop it or add it as a source [09:00] Chipaca: wat [09:00] I think we want to copy snap-device-helper over as snappy-app-dev [09:00] Caelum: I think that's what we do for now, as there are still some transition complexities [09:01] Chipaca: Nope. Though you can use SNAPCRAFT_BUILD_INFO=1 to have it record manifest.yaml which contains Debian packages and snaps installed during the build. [09:01] And therefore indirectly Snapcraft's versions or revision [09:01] zyga: got it [09:01] kalikiana: popey: Skuggen here is tasked with updating the mysql snap, and the newest revision is over a year old, and the snapcraft.yaml no longer works, and they don't know what snapcraft it was built with [09:02] Might be simplest to start over; It's not super complicated, but contains extra binaries and libraries that are accessed by shell scripts (to replicate some of the install logic of the regular deb packages so users don't need to manually initialize databases and such) [09:02] Skuggen: possibly, snapcraft's changed a lot, although i'm surprised a snap stopped building entirely (i thought it had tests for that) [09:02] e.g. I got it to build, but it has issues finding things like the libaio1.so we include [09:02] Ah, understood. [09:03] Right. If the existing snap doesn't contain manifest.yaml I'm afraid that information won't be available. [09:03] Skuggen: so, that's one thing to do: for your future self, make sure SNAPCRAFT_BUILD_INFO=1 is set in the build environment [09:03] Skuggen: so you can answer 'what was this built with' [09:04] Skuggen: I'm a touch busy today, but I think if you pasted the yaml in the forum we could mobilise some people to look [09:05] kalikiana: wait, can you drop SNAPCRAFT_BUILD_INFO into the snapcraft.yaml itself? [09:05] popey: Can do that, sure. Thanks [09:06] Chipaca: No, it's an envrionment variable. [09:06] kalikiana: and the environment: section of snapcraft.yaml is passed through to the snap, not acted on? [09:06] i thought it influenced the build [09:08] Chipaca: Right, those don't actually affect what Snapcraft will look at [09:14] zyga: this test fails completely randomly on me, usually it passes but sometimes I get this: https://gist.github.com/rkitover/460ebe31c6bc3d7508ff584d505cdbce [09:14] hmmm [09:14] feels like a timing racy test [09:16] those tests use settle [09:16] so it's probably deeper [09:16] a bit hard to tell from that error though [09:22] Caelum: has that happened before? [09:22] I suspect it's not new to this release [09:38] zyga: question about your lab [09:38] yes sir? [09:38] zyga: do you have an nfs mount in there [09:38] no, I'm afraid I don't [09:38] but it could be arranged [09:38] the pi3-1 machine has a HDD and we could arrange for NFS export there [09:39] do you want one on the ppc box or somewhere else? (client side) [09:39] zyga: I don't mind the arch for this [09:40] just need nfs [09:40] sure, [09:40] zyga: but if it's not set up i can probably do something at home instead [09:40] Chipaca: I just installed nfs server on pi3-1 [09:40] can you ssh there? [09:40] i can [09:40] now it's just a matter of exporting something [09:41] zyga: I can't sudo there though [09:41] oh [09:41] let me fix that [09:41] zyga: because the password i have for the others doesn't work there [09:41] Chipaca: reset your password to your username and gave you sudo [09:42] feel free to export /home or something you want [09:42] I can stick another device if you want really networked NFS [09:42] I have a few more PIs and beagles [09:43] zyga: thanks [09:45] bash: line 3: cannot create temp file for here-document: No space left on device <--- 2018-04-06 11:42:41 Error preparing google:ubuntu-16.04-32:tests/main/ [09:45] who used all the space? :) [09:45] hue hue hue [09:45] * Chipaca laughs in brazilian [09:48] is resizing broken? [09:48] zyga: yes it happened with .31 too [09:49] PR snapd#4986 closed: snapstate: fix `snap refresh --amend` when the snap is not available in stable [09:49] zyga: blargh [09:49] what's wrong? [09:49] we don't want that fix [09:49] oh?! [09:49] because is going to conflict with the new code [09:49] sorry, I can revert taht [09:49] that just works [09:50] no worries, it's a revert away [09:50] I'm going to merge 4900 today, once it's green [09:50] it should have been marked blocked [09:50] but lots of stuff going on yesterday [09:51] https://github.com/snapcore/snapd/pull/5001 [09:51] PR #5001: Revert "snapstate: fix `snap refresh --amend` when the snap is not av… [09:52] PR snapd#5001 opened: Revert "snapstate: fix `snap refresh --amend` when the snap is not av… [09:53] pedronis: can you do a review of https://github.com/snapcore/snapd/pull/4996 [09:53] PR #4996: overlord/ifacestate: store and use revision with security profiles set [09:53] and I guess we want to add gustavo to review list [09:54] not sure I get to it today, more likely monday [10:02] zyga: request sent [10:02] thanks, looking [10:04] i forgot the details but fair that symlink must be a real cop [10:04] copy [10:05] otherwise +1 [10:16] sure, one moment [10:17] mborzecki: setre[ug]id works \o/ [10:17] Chipaca: yay :) [10:17] mborzecki: yes =) [10:18] PR snapcraft#2053 opened: meta: implement pass-through of properties to snap.yaml [10:18] Chipaca: nfs too? [10:18] mborzecki: that's what i was testing =) [10:20] Chipaca: great, so we can kill #4990 now [10:20] PR #4990: many: implement a poor man's privileges drop, use for auth.json [10:20] mborzecki: with extreme prejudice [10:20] haha :) [10:21] greyback: I reckon you might wanna take a peek at snapcraft#2053 as you expressed your interest in the forum [10:21] PR snapcraft#2053: meta: implement pass-through of properties to snap.yaml [10:21] mborzecki: I'll tweak the code to retry a couple of times on EAGAIN before panic'ing [10:21] mborzecki: as we've learned that EAGAIN happens =) [10:22] mborzecki: also might as well move Sete[ug]id to sys [10:22] mborzecki: thank you again for reminding me about this =) [10:24] PR snapd#4990 closed: many: implement a poor man's privileges drop, use for auth.json [10:24] PR snapd#4983 opened: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json [10:25] zyga: fixed [10:25] thank you, looking [10:26] and sorry I didn't mention this [10:26] you did say copy over [10:26] yes but I wasn't clear it is important :) [10:26] thank you for the work, it should be out soon :) [10:27] nice [10:29] zyga: i've updated the tests of #4968 ; that got me thinking a bit about the old code of ubuntu-core -> core migration that's executed on startup; I remove stale connections *after* all the renaming in initialize. that's ok isn't it? [10:29] PR #4968: RFC: ifacemgr: remove stale connections on startup [10:29] interesting [10:29] * zyga thinks [10:30] zyga: question is if the core snap is alrady under new name, or is there a risk of considering the renamed connections "stale" [10:31] it's hard to reason about this based on unit tests [10:32] the transition is a task [10:32] it's not instant [10:33] zyga: right. but the renaming of conns happens on snapmgr init [10:33] zyga: so it kicks inafter re-exec, so we have new snap at hand correct? [10:34] yes [10:34] well, remember the is a version of this code that runs on ubuntu-core [10:34] that's not as up-to-date [10:36] I think this is ok [10:36] but more than happy we didn't do it earlier [10:44] pedronis: can you please merge https://github.com/snapcore/snapd/pull/5001 [10:44] PR #5001: Revert "snapstate: fix `snap refresh --amend` when the snap is not av… === pstolowski is now known as pstolowski|lunch [10:46] I have reverted back to core stable and now I get this when launching snaps:- failed to create prefix path: /tmp/snap.rootfs_M8USmi/var/lib/snapd/lib/vulkan/icd.d: Permission denied [10:46] popey: that's fixed in beta [10:46] stable is stable but buggy [10:46] yeah, i am trying to use stable because that's what normal people use [10:47] I think this will be fixed once beta promotes [10:47] we're lining up snaps to promote on the social media, but I can't tell what will and won't work for users [10:47] it's a bad week [10:47] we have nothing better [10:47] ok [10:47] beta is most stable IMO [10:47] (today) [10:59] PR snapd#5001 closed: Revert "snapstate: fix `snap refresh --amend` when the snap is not av… [10:59] zyga: done, thanks [11:00] thank you [11:00] trying to get #4900 to green again and then will merge it [11:00] PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction

[11:00] and prepare the backport, but the backport is probably to merge once .3 is in stable [11:00] and then we can do a .4 in beta [11:00] the backport will be for 2.32.4? [11:00] yes [11:01] thats' what I discussed with mvo [11:01] ack [11:39] are we doing standup at 14:00 or 15:00? [11:39] I need to leave in 40 minutes to go to school [11:40] 3pm i presume [11:42] heh, amazon linux 2 is 64bit only, they don't provide any *.i686 libs [11:43] this makes one of our unit tests to fail https://paste.ubuntu.com/p/JyqX9Wh9Rw/ [11:47] we should really add some sort of skip logic to that test [11:47] it also fails if you don't have the right deps [11:47] installed [11:50] it also fails if you try to run it on a banana [11:50] ¯\_(ツ)_/¯ [11:50] * Chipaca is full of ¯\_(ツ)_/¯ today [11:51] Chipaca: let put it this way, as written is not very friendly to porting to random other distro [11:54] pedronis: tbh i'm surprised multilib works at all [11:54] cross-distro i mean [11:54] but, yes, agreed [11:54] i'm being somewhat facetious [11:56] I need to go AFK [11:56] see you at the standup, from the phone [11:57] Bug #1761253 changed: Installing a network-bind snap along with core fails results in incorrect permissions [11:57] Caelum: approved, it's out :) [12:03] PR snapd#4900 closed: many: use the new install/refresh API by switching snapstate to use store.SnapAction

[12:18] sweet! [12:20] * cachio afk [12:22] PR snapd#5002 opened: many: use the new install/refresh API by switching snapstate to use store.SnapAction === pstolowski|lunch is now known as pstolowski [12:38] mborzecki: #4983 is green and happy as a bean [12:38] PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json [12:39] * kalikiana lunch [13:02] Chipaca: standup? [13:03] pstolowski: yeah, was jiggering my camera [13:04] PR snapd#5003 opened: cmd/snap-seccomp: graceful handling of non-multilib host [13:11] Hey guys! are snaps able to work with USB and serial devices well? [13:12] eraserpencil: yes :) [13:12] thanks! [13:12] eraserpencil: only issue might be if it's a new flavour of serial, as they're whitelisted [13:12] ie if you start having /dev/ttyFunky0, it'll need a patch [13:13] (although that one in particular might not =) ) [13:13] nice [13:14] like erm communicate with multiple USB ports and one serial connection whilst having web servers and processing algorithms? [13:14] I'm looking at the ROS-Snap tutorial, not sure what the limits of snaps are [13:23] eraserpencil: probably a kyrofa question [13:30] cachio: now I see, the issue is that secrets are encrypted per repository, you cannot reuse a snapd secret for snapd-cron [13:31] ahh [13:31] pedronis, that makes sense [13:31] cachio: I'm not sure how gustavo created the key for snapd, but we need to rencrypt it for snapd-cron, or create a new one and encrypt [13:32] cachio: probably need to discuss with him [13:32] pedronis, yes, I'll wait until next week [13:34] pedronis, cachio: yes, I bumped into that as well [13:34] re [13:34] this prevents people from copy-pasting secrets around [13:34] but if you know the decrypted secret you can easily re-encrypt it and add it via travis [13:35] yea, but we don't [13:51] Chipaca: whats a kyrofa question [13:52] eraserpencil: 'multiple USB ports and one serial connection', in the context of ROS [13:52] eraserpencil: I see ROS, I defer to the kyrofa [13:52] :-) [13:53] off to pick up the kids [13:59] roadmr: hi! can you pull in r1018? (just a few more overrides) [13:59] jdstrand: absolutely. Here I go! [14:00] roadmr: thanks! :) [14:03] jdstrand: hey [14:08] zyga: hi! [14:09] roadmr: fyi, snapcraft 2.40 is now in stable and -updates everwhere. this is what we were waiting on for the resquash tests. in the coming weeks I'm going to request an isolated pull to turn on enforcement [14:10] roadmr: we'll want to keep an eye on it though in case we want to back it out [14:10] jdstrand: ok. How do we turn it on? set an env var? [14:10] roadmr: today, that is how. I'm going to flip the logic for that [14:11] and request a pull [14:11] jdstrand: oh understood. Think we should put that behind a feature flag so we can have a panic switch in case it all goes awry? [14:12] roadmr: how do you envision implementing that? I figured that was what the env var would do [14:15] jdstrand: I'd like to deconflict and merge https://github.com/snapcore/snapd/pull/4868 [14:15] PR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts [14:15] it's already reviewed just FYI [14:15] I picked up user mounts [14:15] expect useful stuff on ~Tuesday [14:15] zyga: well, it needs an additional comment [14:16] * zyga -> cooking [14:16] 4868 [14:16] I owe the PR a response. I plan to do that today [14:16] aha [14:16] I will look for your response then [14:16] codewise it is fine. james and I disagreed on the phrasing of a comment [14:17] (a comment I suggested, so it wasn't added) [14:17] jdstrand: yes but how do we set/unset the env var in the store? a feature switch is a thingy we can flip on/off in the django admin and that controls stuff in the code [14:18] jdstrand: so something like if is_set('the_flag'): os.environ['RESQUASH_CHECK'] = "true" [14:18] jdstrand: because otherwise, if we need to switch this on quickly, we'd need a redeploy or something [14:18] s/on/off/ [14:18] roadmr: ok, I wasn't sure where you wanted the feature [14:18] jdstrand: well no matter, let me ponder and we'll implement this if needed [14:19] jdstrand: I mean - it's fine that the tools themselves have a way to control this, but remember this lives on a production server where I have no direct access [14:19] roadmr: I think it sounds like a nice idea. the worst that can happen is things end up in manual review. but, that could be a big number so being able to stop the bleeding quickly would be good [14:19] so I can't easily e.g. ssh in and set/unset that variable in /etc/environment [14:19] jdstrand: ok so I'll look into doing that then [14:20] obviously tyhicks and I believe that things are all worked out, but, you never know :) [14:22] zyga: I was confused. the comment I owe is in pr 4957 [14:22] PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation