[05:09] morning [07:03] Good morning [07:04] mvo: no apparmor changes in that window would cause that. For now this is unknown, perhaps other parts of the kernel did change [07:07] zyga: hm, hm [07:08] zyga: thank you [07:09] zyga: mvo: hey [07:09] zyga: something fishy going on in #5566 [07:11] mborzecki: hey [07:16] I need to prepare breakfast for my daughter first [07:16] mvo: also the stop signal test had one more bug! [07:16] I sent a PR but perhaps not fully correct [07:17] zyga: ok [07:17] zyga: woah, yet another bug :( [07:22] in other news, people keep on using 'disable' and finding bugs [07:22] :-) [07:23] Chipaca: thanks for tackling them! [07:24] mvo: :-) [07:24] I fixed them and no tests broke [07:24] ok, ttyl, really need to make that bfast [07:24] so, er, need to write tests :-) [07:24] Chipaca: /o\ [07:24] * mvo hugs Chipaca [07:25] anyway, off to the gym before the day gets melty [07:25] ttfn [07:25] good plan! ttfn === chihchun_afk is now known as chihchun [08:12] Chipaca: reviewed the snapshotstate PR, looks good overall [08:15] pedronis: I updated 5563 to add more checks [08:18] mvo: so the bit of bad new is that so far we tried to not import snap into asserts [08:18] (because asserts is used in places that are not snapd) [08:22] pedronis: ok, I can revert that part and just parse manually [08:22] pedronis: its not that much its needed for [08:23] but we will have the problem going forward [08:23] zyga: OMG 5560 is green [08:24] pedronis: either way is fine with me, for this particular case its easy enough to do the checks without importing the channel parser [08:24] mvo: that would be easier, I think if we need the struct later we can make a subpackage of snap [08:25] pedronis: pushed some updates to #5452, switching between this and #5561 makes it a bit like brain surgery unfortunately [08:25] pedronis: ok, I will undo the import and just parse the relevant bits by hand [08:29] mborzecki: I'm a bit confused, 5561 is not based on 5452 ? [08:30] pedronis: no there are sort of in parallel [08:30] mborzecki: I'm not sure I'm up to that [08:30] it sounds confusing to me [08:30] pedronis: otherwise the diff would be much larger [08:32] pedronis: i suppose i can merge master into 5452 and rebase 5561 on top of it if it makes it easier to review [08:33] I don't know [08:33] I'm just getting confused by some of the last comments in 5452 [08:36] rere, bfast and housework done, let's hack [08:36] pedronis: this is updated now [08:37] mvo: see, the world is not on fire ;) [08:37] mvo: approved [08:37] mvo: I need to focus on image factory, I spoke with upstream developers about my plans and got some super useful advice [08:38] zyga: nice [08:38] pedronis: which ones? i'll clear it up [08:38] mvo: as for https://github.com/snapcore/snapd/pull/5564 [08:39] mvo: we need some before/after [08:39] zyga: what does before/after mean? [08:40] zyga: also what is the link the forum topic about the apparmor issue again? sorry, I misplaced it [08:41] zyga: found it, nevermind [08:41] no worries, it is [08:41] https://forum.snapcraft.io/t/apparmor-profile-caching/1268/17 [08:41] before / after as in "without this patch and with this patch" [08:42] jamie wanted to see the cost [08:42] TBH based on jamie's question I would say the boot performance is exactly identical [08:42] because without core refresh the system key is in sync [08:42] and that means that startup is totally identical [08:42] mborzecki: I answered, it seems you did the change in the follow up but it sounded like you didn't, but a bit unclear why you cannot do it here first [08:42] pedronis: i've merged master to 5452 and rebased #5561 on top (force pushed there too) [08:44] mborzecki: I'm talking about https://github.com/snapcore/snapd/pull/5561/files#diff-147f53d4ad040ca82e13d36e9fdd4e18R145 [08:45] mvo: so, I don't know, I think we should reboot the pi with stable kernel/core [08:45] use systemd's boot analyzer to just measure the tiem [08:46] do this 3-5 times and get some numbers out [08:46] then apply this patch [08:46] and do the same [08:47] but as I said, since the patch doesn't change anything in the case when system key is stable [08:47] I don't expect to see any difference [08:48] mborzecki: the best thing would be to get Chipaca to reivew #5452 today [08:48] pedronis: will ping him [08:49] pedronis: see your response now now, so you're saying f.snap() is like the store then? so with this instance key should be added in the caller rather than inside [08:49] yes [08:49] that's just my mental model [08:49] but that's where I'm coming from [08:50] also because snapSpec has a Name field atm [08:50] at least [08:50] pedronis: got slightly confused as there's snapSpec coming in but snap.Info coming out [08:50] mborzecki: we had store.SnapSpec at some point [08:50] mborzecki: actually we still do [08:50] that's why it would be good to keep it working similarly [08:51] mborzecki: fakeStore.snap corresponds to store.SnapInfo [08:51] to some extent [08:51] pedronis: i'm quite sure i replaced snapSpec with store.SnapSpec at some point and then dropped that change [08:51] we might change that at some point [08:51] but we haven't [08:51] it would be good to be somewhat consistent [08:51] it's all already all a bit confusing as it is :) [08:52] pedronis: makes sense now, thanks for clearing it up [08:52] mborzecki: also for clarity we had code in snapstate at some point that used SnapInfo and then snap was used to fake SnapInfo [08:53] we don't anymore, but we might later [08:53] (hopefully not) [08:53] anyway just to give more context [08:54] pedronis: thanks for the review! [08:54] hey Chipaca [08:54] how have you been? [08:54] zyga: 'sup [08:54] zyga: hot :-) [08:54] have the streets melted into canals of asphalt yet? [08:54] yes, it's hot [08:55] pedronis: i'll update 5452 then and leave 5561 hanging there for a while until we land the store part first [08:56] zyga: did it rain at your place yesterday? [08:56] mborzecki: not a drop of water [08:56] I really want some now [08:56] *except not when the moon thing happens [08:56] that would suck [08:56] zyga: it rained here during the night, but then the morning was south east asian style, you more twice and you're all sweaty [08:57] yummy [08:57] why take a shower when you can just get out of bed [08:58] brb (reboot) [08:59] mborzecki: btw this also means we should double check the places in api.go that use Store.SnapInfo they should always use a snap-name, if we start from an instance name we need to split it, might it's alright right [09:01] mborzecki: I'm switching to something else that needs a bit of wrapping up for a bit, I will get back to reviews in the afternoon [09:03] pedronis: sure, thanks for the help [09:15] mvo, did you consider to rename the pi kernel to just be pi-kernel instead of pi2-kernel with the switch to 4.15 ? (i think this is probably the best time to do it and the versioning in the na is completely pointless ) [09:15] *s/na/name/ [09:17] ogra: can you hop into #stable-kernel to see if that is much work for them? [09:17] on freenode ? [09:17] * zyga agrees with mvo and ogra [09:18] pi-kernel is so much better with tracks [09:18] it'd be only better if we could call it "IOT kernel" [09:18] with everything [09:18] and it would work on all the boards at once -) [09:18] haha, right [09:18] haha [09:19] ogra: we also need sign-off by niemeyer if we want to rename pi2-kernel to pi-kernel for core18. but I think this is pretty uncontroversial [09:19] yeah, it was pi2 only for probably 6 months since it exists [09:19] yeah, it's super nice [09:19] ogra: btw, I saw that pi3 has gotten much more aarch64 friendly? [09:20] ogra: is it the moment where pi could be either armv7 or aarch64 in our images? (that both arches work) [09:20] and toigether with a generalized gadget that runs on all pi'S you can then build an image (and model assertion) a lot easier [09:21] zyga, it cant "get more aarch64 freindly" until it has actual ram to make use of aarch64 :P [09:21] yeah but stuff and ponies and PRs [09:21] aarch64 on 1G is extremely wasteful [09:21] and you really dont benefit from anything 64bit on it [09:22] unless you do big math computations or some such ... [09:22] ... but for that you are lacking RAM again :) [09:23] currently all binaries allocate about 1.5x the RAM ... the same binarides, simply built for arm64 ... so even running the idle core image will bump the ram footprint from 40 to 60MB [09:24] ogra: yeah but it would mean people can use inexpensive pi to play with aarch64 on ubuntu [09:24] now they need to find something more exotic [09:24] or just use arch/fedora [09:25] well, i dont mind if they try out OOM on arch or fedora and we dont get bad press :P [09:25] zyga, mborzecki, pedronis there will be a snapd 2.34.3 to fix the apparmor cache problem - anything you want to have backported that is a) low-risk b) high-impact? [09:25] mvo: easter eggs that play yankie-doodle are not in that set [09:25] mvo: I think that's all for now [09:25] * ogra admits he is exaerating ... just a little :) [09:26] *exaggerating [09:26] brb [09:26] can I open a shell into a snap container? For debugging [09:27] mvo: nothing new, just the nvidia thing which is already 2.34 branch [09:27] mborzecki: ta [09:27] t1mp, snap run --shell . [09:27] ogra: great, thanks! I'll try it. [09:27] t1mp, for any installed snap [09:29] t1mp: note that this will drop you into a confined shell [09:29] t1mp: there's also a way to run an unconfined shell if you have sudo on your device [09:32] my device is my laptop :) I'm packaging a desktop app. [09:33] hmm, I'm a bit confused. The shell it gives me has the homedir in /home/tim/snap/qmenta-app/x37 but I don't have, for example, /bin/desktop-launch which I need [09:34] t1mp: the home directory is not as relevant perhaps, the big thing is that /bin/desktop-launch exists on your machine but not in the snap container [09:34] t1mp: what does desktop-launch do? [09:35] desktop-launch comes from a desktop helper [09:35] aha [09:35] then it is probably in $SNAP/bin/desktop-launch [09:35] your snapcraft.yaml needs to define some [after] statement to get it [09:35] since /bin is the /bin directory from the core snap, not from your application snap [09:35] it should be in your PATH by default [09:35] (if the snap includes it that is) [09:36] right. desktop-launch is indeed there, but $SNAP/... is not in my PATH [09:36] tim@tim-XPS-13-9350:~$ snap run --shell qmenta-app [09:36] To run a command as administrator (user "root"), use "sudo ". [09:36] See "man sudo_root" for details. [09:36] tim@tim-XPS-13-9350:/home/tim$ echo $SNAP [09:36] /snap/qmenta-app/x37 [09:36] tim@tim-XPS-13-9350:/home/tim$ echo $PATH [09:36] /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games [09:36] ogra: that's not exactly accurate [09:36] the PATH is changed by per-app wrappers for now [09:37] so if you run --shell you get a shell but not the wrapers [09:37] look at $SNAP/ and at the wrappers there [09:37] and see what they do [09:37] ah [09:37] this will be fixed with the incoming work around snapcraft templates and layers [09:37] sorry, not layers [09:37] there is some new term for that [09:37] layovers :P [09:38] but essentially snapd will know about the sandwiched helpers [09:38] so how do I change my / now to $SNAP inside the snap shell. I need that so that python will be able to find the python libs that are installed in the snap [09:39] t1mp: just 'cd $PYTHON' [09:39] er [09:39] zyga, btw, do we have an ETA foe layouts ? (i have a bunch of packages that would benefit from being able to provide /opt/vc on Rpi) [09:39] cd $SNAP [09:39] ogra: next cycle for sure, sorry about the lag [09:39] *for [09:39] python looks directly in /lib/python3.5/site-packages/ if there is no PYTHONPATH set [09:39] t1mp: yeah, you can set PYTHONPATH in environment: section in your snapcraft.yaml [09:40] zyga, well, its fine for me, its just awkward having to ask jamie for manual approval for each upload [09:40] I believe that is per-app so you can customize this [09:40] and it will be picked up by snap run --shell as well [09:40] in this case, I want to execute 'desktop-launch python3 -m my-lib.my-app', and it automatically reads the lib from /lib/python3.5/site-packages/my-lib (no need for PYTHONPATH if it is in that directory) [09:41] butu it wont be in that directory :) [09:41] *but [09:41] since that directory is in your core snap ... which is most likely not shipping "my-lib" :) [09:42] right, it is in $SNAP/lib/python3.5/... [09:42] so your PYTHONPATH needs to point to $SNAP/... [09:42] right [09:42] I did that now. [09:42] ImportError: libxcb-dri3.so.0: cannot open shared object file: No such file or directory [09:42] so there are a bunch of other env vars to set... I suspect a whole bunch, before it works from the shell. [09:43] (just running the snap works fine) [09:43] ... and your LD:LIBRARY_PATH needs to point to the right dirs too ... [09:43] typically done by the wrapper [09:43] somehow that is already working for me when I run the snap. Or does it chroot to $SNAP or something like that? [09:43] or in the environment section (more future proof, less shell to run) [09:43] t1mp: the snap uses a bunch of wrappers from snapcraft [09:43] those are not active in --shell [09:43] thats the bit that zyga referred top above ... if you use --shell, the wrappers arent executed [09:44] s/top/to/ [09:44] ah, right. command-qmenta-app.wrapper works [09:44] in $SNAP [10:06] which version of Ubuntu does the Snap use inside the images? (lsb_release is not installed in it) [10:07] it has python 3.5, and my app was tested as working with python 3.6 [10:08] xenial [10:09] which xenial? 16.04.1? I have 16.04.5 on my system and it has a newer python than the snap [10:16] how do I go about restricting the number of snaps saved in /var/lib/snapd/snaps? I probably only need the latest one +1. [10:17] no fun having three libreoffice snaps each 500meg [10:17] oh, right, the system has python35 (my py36 was in a virtualenv) [10:17] thresh: that's a feature that's in 2.34 [10:18] thresh: snap set system refresh.retain=2 [10:19] thresh: meanwhile, snap list --all thesnap, and snap remove --revision=revno thesnap [10:20] thresh: you can get it early by refreshing to another channel [10:21] Chipaca: the comment about "snapshots" name is not super constructive I know, maybe Gustavo will have input about that, it might just be fine and a matter of habit, they can be interpreted as collections or namespaces those top state entries [10:22] thanks Chipaca, zyga [10:22] trying candidate core now [10:22] :-) [10:22] pedronis: https://github.com/snapcore/snapd/pull/5187#discussion_r196223469 [10:22] * zyga is super happy about what snaps can do [10:22] ya [10:23] I guess the changes will kick in (as in actually removing the file) on the next snapped package update? [10:23] still wanting to add ‘snap remove --disabled’ [10:23] thresh: yeah [10:23] makes total sense, thanks! [10:24] thresh: you could hurry it along by doing a 'snap refresh --revision= thesnap' and then a 'snap refresh thesnap' [10:25] although at that point 'snap remove --revision' is probably quicker :-) but if you want to check it works, you can do the above [10:30] Chipaca: can you +1 and merge https://github.com/snapcore/snapd/pull/5566 please [10:30] one less flaky test [10:37] zyga: that was a tough review [10:37] I know [10:37] i think i need a break [10:37] haha [10:37] * zyga hugs Chipaca [10:37] maybe some ice cream [10:37] though a bit too hot for that [10:37] I was thinking [10:37] can we install a c-n-f handler [10:37] and fail tests if it fired [10:37] yeah, hug me but from a meter away dude [10:37] things are sticky [10:37] would catch things like tpyo || true [10:37] icky sticky [10:38] believe me, I don't know where to go to have less heat [10:38] zyga: Córdoba, Argentina [10:38] zyga: (cachio said it was <0C yesterday) [10:38] is there winter there? [10:38] hmm hmm [10:38] that's settled then [10:38] bye! [10:38] also winter is dry season [10:39] on the other hand, the president just authorized the army to intervene for "internal security" [10:39] so … maybe stay away for a bit [10:42] * zyga looks at an oldish python codebase [10:42] with iffy bits here and there [10:43] but docs make no sense [10:43] so deep dive required [10:43] zyga: you get all the fun [10:44] it depends if upstream is happy to take patches [10:44] it's the kind of code that makes you ask "python was about style?" questions [10:44] definitely written by a C coder [10:44] if(stuff): .. [10:45] also try: ... except: print "drat" [10:45] this enterprise vibe [10:46] also, no tests [10:46] zyga: “I'm sorry zyga the tests are in another castle^Wrepo” [10:46] hahaha [10:49] also no __future__ imports anywhere [10:49] la la la [10:49] python 2.6 required === mborzeck1 is now known as mborzecki [11:20] la la la [11:20] it's so hot I cannot think [11:28] zyga: find a fox in the woods, and use it as a hat [11:28] zyga: you will then no longer be worried about the heat [11:28] have I told you the story of the peeing bunny? [11:28] zyga: if you don't have foxes, a brace of ravens will do [11:29] anything that will try to gouge your eyes out really [11:29] zyga: … no [11:33] zyga: I'm going to have some lunch. No bunnies though. [11:37] 5555 needs a second review, easy win [11:37] (and a nice number!) [11:37] with a number like that [11:37] who can resist [11:49] Chipaca: bunnies for lunch? [11:50] 5562 is also an easy win [12:00] cachio: could you please test the latest pi2-kernel and dragonboard kernel on edge when you have a free slot? we have an initrd update there and once its good we can move it up to candidate/stable [12:03] mborzecki: I haven't sourced bunnies, no [12:05] mvo, is there any plan for beta today? [12:06] cachio: yes, probably after the standup [12:06] mvo, nice [12:27] back from lunch [12:27] and back to image factory [12:27] mvo: how is core18, are we green? [12:29] mvo, niemeyer I have to take my son to the doctor, I'll try to be for standup [12:29] cachio: ack [12:29] mvo: kernel is green, is stuff safe-ish for 1st? [12:30] mvo, tests runnign for db and pi2 with edge kernels [12:30] mvo: is the current release (.3) also the one that will enable c18? [12:31] mvo: or is that for 2.35? [12:37] zyga, hmm... would it be possible to have a layouts entry the re-maps $SNAP_USER_DATA to /home or is that too recursive to work ? [12:37] yes, but not yet [12:37] it's on the roadmap for this cycle [12:37] I'll get it done [12:38] (i'm wordering if i could make an openbox-session snap with a handfull of defult apps to run on top of mir-kiosk with XWayland to run a desktop on core [12:38] ) [12:38] let's sync in 3 weeks after my holidays and flock [12:39] you would indeed only e able to operate inside confinement so the re-mapping should make it possible to use dotfiles in home in that case [12:40] ... without having to tinker a lot with serach paths for configs etc in the binaries [12:45] heh, managed to break tmux by resizing gnome-terminal :( [12:50] tea? why yes [12:52] nah, coffee, 3rd one today and still sleepy [12:56] mborzecki: at this point I think sleep won [12:56] hmm [12:58] zyga: c18 is 2.35, 2.34.3 is just to unblock us [12:58] is it just me having issues with firefox? http://thre.sh/stuff/ff-crash.txt [12:58] kenvandine: ^ ? [12:59] mvo: ack === chihchun is now known as chihchun_afk [13:32] * Chipaca hugs mvo [13:33] * Chipaca sells mvo a universal random number generator [13:33] Chipaca: hahaha [13:33] * mvo hugs Chipaca [13:35] Chipaca: I have enough of random numbers for this week [13:35] mborzecki: are you going to merge #5452 and then update #5561 ? [13:35] mvo: but this one comes with a yellow duck, and a plane ticket for four to canarias [13:35] but ok, i'll throw it away [13:35] * Chipaca throwws it away [13:36] pedronis: merging right now [13:36] mvo: Here's a joke wishlist bug from debconf for you to amuse: https://bugs.launchpad.net/ubuntu/+source/vrms/+bug/1783986 [13:36] niemeyer: pedronis: so, about snapshots' state entry, currently it's {"snapshots": {"last-set-id": 42}} [13:37] juliank: clearly there needs to be a vrms snap [13:37] There were rumours about a flatpak snap [13:38] I'm also still waiting for the apt snap [13:38] Chipaca: what would vrms say when invoked form a snap? [13:38] juliank: was the flatpak snap distributed as an appimage [13:38] Chipaca: Hmm, could be [13:38] juliank: heh! I like that [13:39] a classic apt snap should actually be trivial :) [13:39] zyga: “starting microsoft office 2019...” [13:39] I'd do one on core18 [13:39] (wouldnt work on ubuntu core sadly) [13:39] current core needs to many backports [13:41] Chipaca: I guess the downside of that state entry is that if we ever decide to have a per-snapshot state, this would be the obvious key [13:42] niemeyer: that was my remark as well [13:42] niemeyer: I think that is pedronis's point [13:42] Ah, I didn't see that [13:42] niemeyer: pedronis: I could do the simplest thing, and have it be a toplevel "last-snapshot-set-id" [13:42] * cachio back [13:42] cachio: kid ok? [13:43] Chipaca, with fever [13:43] cachio: aw [13:43] 39° [13:43] Chipaca, as usual seek on weekends [13:44] it is a virus [13:44] cachio: uh, good luck [13:44] Chipaca: it would work for me, we do have toplevel ones from snapstate for example [13:44] Chipaca, pedronis: Conceptually okay.. it's just a mouthful.. let me grep a bit to see what else we've got [13:44] k [13:44] Chipaca, mvo I got a call from the kinder garden telling me he was with fever, so I took him the doc [13:44] we have last-refresh and last-refresh-hints [13:45] cachio: good luck [13:45] * niemeyer finds "ubuntu-core-transition-last-retry-time" :) [13:45] cachio: yeah, I read, all the best that he gets well quickly [13:45] Chipaca, mvo tx [13:46] mvo, db and pi2 so far so good [13:46] cachio: great, thanks [13:46] running about 60 tests without any error [13:46] using edge kernels [13:46] niemeyer: "once-upon-a-time-a-snapshot-set-id-decided-they-wanted-to-know-what-lay-beyond-the-dark-forest" [13:47] beavers ? [13:47] Chipaca: Cool, sounds fine [13:49] cachio: Aw.. sucks.. take your time if you need to take care of him [13:50] ogra: https://www.youtube.com/watch?v=ZqH4rc0E1fc [13:50] lol [13:51] pedronis: and 5561 is updated now [13:53] niemeyer, tx, he is sleeping now [13:54] Chipaca: LOL [13:54] mvo: the things you added in snap/channel.go in #5563 ar not used anymore/yet ? [13:56] pedronis: yeah, I can kill those off again, I left it mostly because we talked about that we might want to allow snap install foo=edge bar=stable but YAGNI and all that (easy enough to add again when needed) [13:56] mvo: that seems preferable [13:56] but yes keep the code around [13:56] pedronis: sure, let me do that [14:01] pedronis: I removed the relevant commit [14:10] zyga: did you see the latest comment from jamie about skipCache when loading snap-confine? [14:10] nope [14:10] looking [14:11] mvo: ah, nice [14:20] mvo: I think we do need the test you removed in some form, unless I'm confused [14:22] pedronis: let me double check which got removed [14:30]