[05:40] <PhoenixMage> Hi all
[05:40] <PhoenixMage> zyga-solus: Has your layout remapping stuff been released yet?
[05:46] <zyga-solus> PhoenixMage: no, but it's slowly taking shape
[05:46] <zyga-solus> PhoenixMage: I hope to land the first user visible thing today
[05:46] <zyga-solus> PhoenixMage: and then the most useful user visible thing (overlayfs)
[05:47] <PhoenixMage> zyga-solus: Nice, let me know if you need a guinea pig
[05:47] <PhoenixMage> Now I am back from vacation
[05:47] <PhoenixMage> Need to get some Olimex Lime2 boards I think
[06:43] <zyga-solus> PhoenixMage: I could use code review right away :)
[06:44] <zyga-solus> PhoenixMage: if you are interested in that I can show you the way
[06:47] <zyga-solus> ok, 50% sent to school, time for some work
[06:51] <PhoenixMage> zyga-solus: Code is not my strong suit :/
[06:55] <zyga-solus> PhoenixMage: I see, thank you for the offer still
[07:31] <zyga-solus> pstolowski: hello
[07:32] <zyga-solus> pstolowski: I was wondering how much work is needed to land https://github.com/snapcore/snapd/pull/3972 and let you iterate
[07:32] <mup> PR #3972: repo: sanitize plugs and slots early in ReadInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/3972>
[07:34] <pstolowski> zyga-solus, hey!
[07:36] <pstolowski> zyga-solus, 3972 itself is ready and captures item 1 of the plan I hope (https://forum.snapcraft.io/t/preparing-the-interfaces-logic-for-connection-hooks/2184)
[07:36] <pstolowski> zyga-solus, items 2 and 3 are ready and I'm about to push a PR for that
[07:37] <pstolowski> zyga-solus, item 4 ready too (will be part of same PR)
[07:37] <zyga-solus> pstolowski: I wonder if we can get a 2nd review for 3972 today
[07:37] <zyga-solus> pstolowski: maybe chipaca can help?
[07:37] <pstolowski> zyga-solus, I need the second review from Gustavo
[07:38] <pstolowski> zyga-solus, the sprint this week isn't going to help :/
[08:03] <PhoenixMage> zyga-solus: Configuration and troubleshooting is more my area
[08:27] <zyga-solus> ikey: hey, around?
[08:42] <seb128> https://errors.ubuntu.com/problem/65c0ce797c1e385496c43cb7d869f3e2c0bc55ab looks like it could be a snappy issue?
[08:42] <seb128> those reports have that error message
[08:42] <seb128>  hook configure in snap "core" failed: cannot change profile for the next exec call: No such file or directory
[08:51] <zyga-solus> seb128: looking
[08:51] <zyga-solus> seb128: typically that means ubuntu package reused on !ubuntu kernel
[08:52] <seb128> zyga-solus, thanks, I guess those reports don't have enough details to be useful then
[08:52] <zyga-solus>  4.11.1-041101-generic
[08:52] <zyga-solus> look at the kernel
[08:53] <zyga-solus> that looks like the mainline kernel
[08:53] <zyga-solus> I've been working on some patches that will let us work on mainline kernels soon, I may be able to put that into 2.29
[09:15] <mup> PR snapd#4011 opened: cmd: correctly name the "Ubuntu" and "Arch" NVIDIA methods <Created by zyga> <https://github.com/snapcore/snapd/pull/4011>
[09:22] <mup> PR snapd#4012 opened: cmd: add autoget case for solus <Created by zyga> <https://github.com/snapcore/snapd/pull/4012>
[09:41] <mup> PR snapd#4013 opened: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4013>
[10:26]  * __chip__ hugs mwhudson 
[10:27] <__chip__> mwhudson: just realised the two oldest PRs are yours
[11:21]  * zyga-solus -> food
[11:40] <c-lobrano> elopio: Hi, I'm on bug 1604815, but there might be a problem with the tests. The test_release_snap_to_invalid_channel triggers the same BAD RESPONSE reply of the bug, but the response payload doesn't seem the one expected (https://dashboard.snapcraft.io/docs/api/snap.html#id3) since the "errors" key is paired with a str and not with a list of dicts. Can you confirm, or am I missing something? Thanks!
[11:40] <mup> Bug #1604815: The error when trying to release a revision that's not a integer is ugly <bitesize> <Snapcraft:In Progress by c-lobrano> <https://launchpad.net/bugs/1604815>
[11:50] <zyga-solus>  re
[11:50] <zyga-solus> now back to work
[12:10] <mup> PR snapd#4012 closed: cmd: add autogen case for solus <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4012>
[12:12] <niemeyer> pstolowski: Let's see if I can look quickly before the plenary starts here
[12:12] <zyga-solus> niemeyer: hey
[12:12] <zyga-solus> niemeyer: how's the sprint?
[12:19] <pstolowski> niemeyer, o/, thanks
[12:31] <niemeyer> pstolowski: Sent a first review
[12:31] <niemeyer> pstolowski, zyga-solus: Let's please try to have sane code..
[12:31] <niemeyer> zyga-solus: Sprint starting just now
[12:35] <zyga-solus> niemeyer: ack
[12:38] <zyga-solus> pstolowski: I left a comment on the PR
[12:38] <zyga-solus> man, I should have read more kernel docs
[12:39] <zyga-solus> I found a good way to solve another problem
[12:39] <__chip__> zyga-solus: ...? :-)
[12:40] <zyga-solus> __chip__: notify_on_release is such a natural
[12:40] <__chip__> zyga-solus: sysctl -w kernel.global-warming=0 ?
[12:40] <zyga-solus> haha
[12:40] <zyga-solus> that'd be nice
[12:41] <__chip__> who's standup-able today?
[12:41] <zyga-solus> I am
[12:41] <__chip__> me too
[12:41] <zyga-solus> using notify_on_release I can solve an existing problem naturally
[12:43] <__chip__> zyga-solus: isn't the release-agent snapside?
[12:43] <wdouglass> when i snap runs, is it chrooted to the /snap/packagename/xx/ directory? i'm trying to figure out how paths work in a snap
[12:43] <wdouglass> like if i do 'snap run --shell packagename' it's not chrooted, but the environment is set up
[12:43] <__chip__> wdouglass: it's not chrooteed, no; what exactly are you trying to figure out?
[12:43] <wdouglass> __chip__: i'm trying to run a tkinter program, and it can't find 'init.tcl'
[12:44] <wdouglass> i'm trying to set the paths properly, and in a way that's portable.
[12:44] <__chip__> wdouglass: "snap run --shell" is the exact same environ
[12:44] <wdouglass> hmm ok
[12:44] <__chip__> oooh, that should be fun
[12:44] <__chip__> wdouglass: we haven't snapped a tcl thing before? strange
[12:44] <zyga-solus> __chip__: snapside? I mean it snapd could then do the cleanup properly
[12:44] <wdouglass> well I haven't
[12:44] <wdouglass> i'm very new at this
[12:45] <zyga-solus> wdouglass: it's not as simple as that
[12:45] <zyga-solus> wdouglass: when snap runs it gets a mount namespace with the designated base snap as the rootfs
[12:45] <zyga-solus> wdouglass: and a few things changed all around the place to make the world workable
[12:45] <zyga-solus> wdouglass: the shell advice is very useful, explore and look around
[12:45] <__chip__> wdouglass: https://stackoverflow.com/questions/39177158/tcl-cant-find-init-tcl-in-a-snap-package
[12:45] <zyga-solus> wdouglass: you may also look at how mounts are laid out
[12:46] <wdouglass> i saw that stackoverflow -- i'm trying to have as little impact on my upstream package as possible.
[12:46] <__chip__> ah
[12:46] <__chip__> wdouglass: but the answer there doesn't seem (at a quick read) to impact the upstream code at all?
[12:46] <pstolowski> niemeyer, thanks for the review
[12:47] <__chip__> zyga-solus: “the kernel runs the command specified by the contents
[12:47] <__chip__> of the "release_agent" file in that hierarchy's root directory”
[12:47] <wdouglass> hmmm...guess i didn't really understand the "glue" section. i'll look into that
[12:48] <__chip__> wdouglass: the "wrappers" are little scripts that set up the environ before calling the binaries
[12:48] <wdouglass> ok, so i can just put those wrappers next to my snapcraft.yaml, and then use the 'copy' plugin to put them in the right place?
[12:49] <__chip__> yes
[12:49] <wdouglass> awesome. Thanks for the clarification
[12:49] <zyga-solus> __chip__: right, that's what I need
[12:49] <__chip__> zyga-solus: but my point was that "that hierarchy" is snapside
[12:50] <zyga-solus> hmm, I don't follow
[12:50] <zyga-solus> snap-side as in ?
[12:50] <zyga-solus> where?
[12:51] <zyga-solus> __chip__: my intent is to have that run snap-discard-ns (indirectly0
[12:52] <zyga-solus> __chip__: this would allow us to simplify snap-confine
[12:52] <__chip__> zyga-solus: i mean it runs inside the namespace, doesn't it?
[12:52] <zyga-solus> __chip__: I don't think so
[12:53] <zyga-solus> but even if that's the case it's not a problem
[12:53] <__chip__> ok, fair enough
[12:54] <zyga-solus> __chip__: we can setns outside and unmount what we have to
[12:54] <zyga-solus> __chip__: setns, unmount, unlink, done
[12:54] <zyga-solus> that and the locking
[13:07] <wdouglass> hmmm....ok, the tcl wrapper thing worked. thanks for that. Now there's a new problem! i'm getting some fontconfig errors. "Unable to update the static FcBlanks"
[13:07] <wdouglass> is there a trick to getting fontconfig working?
[13:14] <zyga-solus> and now I notice that chipaca is *not* on irc
[13:20] <zyga-solus> __chip__: so does that give 4011 two +1s?
[13:20] <zyga-solus> I +1d the orinal
[13:20] <zyga-solus> original*
[13:20] <zyga-solus> note that I need to also update the packaging trees but nvidia is not tested much
[13:21] <zyga-solus> I shall better to that
[13:22] <zyga-solus> __chip__: are you using python ;)
[13:35] <__chip__> zyga-solus: in what sense?
[13:35] <__chip__> zyga-solus: this nick comes from my python days, yes
[13:35] <__chip__> for when i was feeling "special"
[13:35] <__chip__> or i wanted to pull __lucio__'s leg
[13:38] <zyga-solus> haha
[13:38] <zyga-solus> I was wondering the dunder semantics of chip(object)
[13:40]  * ikey blinks at the zyga-solus 
[13:42] <zyga-solus> o/
[13:42] <zyga-solus> ikey: I picked up one of your branches
[13:42] <zyga-solus> ikey: I pushed a new one up with conflict fixes, I'll do one more tweak to it and let's land it
[13:42] <ikey> oh thanks bud
[13:42] <ikey> ive been hammered with this gnome work the last few days -_-
[13:43] <ikey> (3.26 stack update + systemd + llvm + ....)
[13:43] <zyga-solus> ikey: thank you for putting it up, I'll try to land the other branches soon too
[13:43] <ikey> you are too good. ^_^
[13:46] <zyga-solus> does anyone know when v2 cgroups will be around?
[13:46] <zyga-solus> jdstrand, tyhicks ^ you maybe?
[13:51] <cachio> niemeyer, I saw this error: 2017-10-09 13:08:29 Discarding linode:ubuntu-14.04-64 (Spread-78), cannot connect: cannot connect to linode:ubuntu-14.04-64 (Spread-78): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain
[13:51] <cachio> niemeyer, https://travis-ci.org/snapcore/spread-cron/builds/285355223
[13:52] <cachio> I'll check if there are more like this
[13:54] <cachio> Son_Goku, hey, I saw some test errors setting up fedora
[13:54] <cachio> ++ dnf -q -y --refresh install expect
[13:54] <cachio> Error: Failed to synchronize cache for repo 'updates'
[13:54] <Son_Goku> linode *grumbles*
[13:54] <cachio> Son_Goku, any idea what could be causing that?
[13:55] <Son_Goku> I think Linode has a registered mirror for their IP block with Fedora MirrorManager
[13:55] <Son_Goku> so all requests to the metalink and mirrorlist return Linode's mirror
[13:55] <Son_Goku> but when it's mid metadata sync, the repomd.xml file doesn't exist, so that happens
[13:56] <zyga-solus>  ahh
[13:56] <cachio> Son_Goku, ah, ok, any workaroud at least to manage that error?
[13:56] <zyga-solus> Son_Goku: nice work
[13:57] <Son_Goku> cachio: force a different mirror or try again later?
[13:57] <Son_Goku> really, someone needs to talk to Linode about how they rsync from tier 1 mirrors
[13:58] <Son_Goku> they probably are using the wrong rsync options to keep things sane during update
[13:58] <zyga-solus> Son_Goku: can you jump into #linode and ask them, all the linode staff seems to be lurking there
[13:59] <zyga-solus> Son_Goku: and I think you are the best qualified to explain how to do that properly
[13:59] <Son_Goku> I guess
[13:59] <cachio> Son_Goku, agree
[13:59] <cachio> with zyga
[14:15] <__chip__> cachio: are you ok with https://github.com/snapcore/snapd/pull/3951/commits/a803b5a0af7f86e461f2a5d21c0b9d4aa0935511 ?
[14:15] <mup> PR #3951:  snap: add new `snap pack` and use in tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3951>
[14:15] <cachio> __chip__, checking
[14:16] <cachio> __chip__, yes, lgtm
[14:17] <__chip__> ok, i'll merge when green then
[14:17] <mup> PR snapd#4011 closed: cmd: correctly name the "Ubuntu" and "Arch" NVIDIA methods <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4011>
[14:18] <mup> PR snapd#3978 closed: cmd: Correctly name the "Ubuntu" and "Arch" NVIDIA methods <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3978>
[14:20] <mup> PR snapd#4014 opened: packaging: update nvidia configure options <Created by zyga> <https://github.com/snapcore/snapd/pull/4014>
[14:43] <wdouglass> hmmm..ok so it looks like the fcblanks thing is a red herring. i'm getting a segfault somewhere in TCL
[14:47] <zyga-solus> wdouglass: you probably are missing fonts, core has no fonts
[14:47] <wdouglass> that make sense, thanks
[14:47] <zyga-solus> wdouglass: it's a work in progress from our end, for now you can use one of the workarounds people use that inject fonts and some fontconfig env variables
[14:47] <ogra_> use the desktop launcher and the snapcraft desktop part
[14:49] <ogra_> alternatively here is an example with a wrapper script https://github.com/ogra1/jtiledownloader (make sure to have something in your stage-packages that pulls in fontconfig and some fonts ... i.e. a theme package)
[14:50] <wdouglass> so i just stage-package a theme and it should work. Cool! trying this now.
[14:50] <ogra_> well, you need the env variables the wrapper sets as well
[14:50] <zyga-solus> wdouglass: i don't know - I suspect you need a bit more but I really don't know
[14:50] <wdouglass> ogra_: alright cool, i'm already using a wrapper for tcl (meantioned above) so i'll just add more variables there
[14:51] <ogra_> right, even though jtiledownloader is java, the font stuff should work for tcl too
[14:55] <wdouglass> ok, so that got rid of my fcblanks problem, but i'm still getting a segfault as soon as I create my first Tk widget
[14:55] <wdouglass> oh wait, i may have missed a variable...
[14:57] <zyga-solus> __chip__: let's land this one please https://github.com/snapcore/snapd/pull/4014
[14:57] <mup> PR #4014: packaging: update nvidia configure options <Created by zyga> <https://github.com/snapcore/snapd/pull/4014>
[14:57] <__chip__> zyga-solus: this is the other half of the previous one?
[14:58] <wdouglass> it works! thanks so much guys!
[14:58] <__chip__> wdouglass: huzzah!
[14:59] <zyga-solus> yep
[15:03] <elopio> good morning
[15:06] <__chip__> hah, i approved twice
[15:06] <__chip__> not that it's a day i'm easily distracted or anything
[15:07] <elopio> clobrano: hello! The unit tests use a fake server with hardcoded replies.
[15:07] <c-lobrano> elopio: hi! Yes, I saw it. I'd like to have a double check, before changing this test
[15:12] <elopio> c-lobrano: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/fake_servers/api.py#L382 That line is wrong. We should put the message in a list.
[15:12] <elopio> that's why we are not very happy with the fake servers.
[15:12] <c-lobrano> :)
[15:12] <c-lobrano> elopio: is that just a list or a list of dictionaries?
[15:13] <c-lobrano> elopio: the format seems to be {"name": ["reason"]}
[15:14] <c-lobrano> I meant, errors :[ {"name": ["reason"]}] (quite complicated)
[15:14] <elopio> yeah, a list of dictionaries, with the field as the key, and a list of strings as the value.
[15:15] <elopio> let me try to release to an invalid channel, to get the exact reply from the store.
[15:15] <c-lobrano> ook, so I could expect more that one "reason" per key?
[15:15] <c-lobrano> alright, thanks a lot
[15:17] <elopio> c-lobrano: ahh, this one is different: {'success': False, 'errors': 'Track does not exist: invalid', 'error_list': [{'code': 'invalid-field', 'message': 'Track does not exist: invalid'}]}
[15:18] <elopio> let me now try to release to not a number and see if it's the same.
[15:19] <elopio> c-lobrano: {'success': False, 'error_list': [{'code': 'invalid-field', 'message': "The 'revision' field must be an integer"}], 'errors': {'revision': ['This field must be an integer.']}}
[15:28] <c-lobrano> elopio: uhm, ok. The problem is that StoreReleaseError is at the edge of "too complex" :D
[15:28] <c-lobrano> elopio: I need to find a simple solution
[15:29] <c-lobrano> error_list is actually quite nice
[15:40] <jdstrand> zyga-solus: note we are both sprinting (cc tyhicks), but my understanding is that practically speaking, v2 cgroups won't be around by default until the issues surrounding them not being able to be used at the same time are resolved
[15:40] <jdstrand> (same time as v1)
[15:41] <ikey> so then does snapd mandate legacy cgroup hierarchy in systemd?
[15:41] <jdstrand> iirc, there were a lot of discussions about how to make that happen, but no concrete plan that people are working on. stgraber would also be able to orrect me
[15:42] <jdstrand> ikey: I think that what we would want to support is that when systems are using only v2 cgroups, snappy shuld be able to detect that nand use them
[15:42] <ikey> yea
[15:42] <ikey> good job my systemd is set to legacy then i guess xD
[15:42] <jdstrand> my point was that I don't really know when a system can reasonably be v2
[15:42]  * ikey encountered that issue in the past with docker already
[15:43] <jdstrand> there are a lot of technical challenges with mixing the two that need to be reasonably resolved
[15:45] <zyga-solus> jdstrand: thank you for the note
[15:45] <zyga-solus> jdstrand: I'm making progress, I think we are in a good position
[15:46] <mup> PR snapd#3951 closed:  snap: add new `snap pack` and use in tests  <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3951>
[15:47] <__chip__> zyga-solus: what's missing for snapd#3958?
[15:47] <mup> PR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>
[15:47] <zyga-solus> __chip__: niemeyer asked for a wait for review
[15:47] <zyga-solus> I'm happy as is
[15:54] <elopio> c-lobrano: you can split the big function in subfunctions. There can be one like _get_text_for_store_release_errors_401_and_403.
[15:55] <c-lobrano> elopio: right, that would be a good idea
[15:55] <c-lobrano> elopio: but with error_list I should be able to format a nice message passing only the dictionary
[15:55] <c-lobrano> and runtest.sh isn't complaining so far :)
[17:37] <mup> PR snapd#4014 closed: packaging: update nvidia configure options <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4014>
[17:37] <__chip__> zyga-solus: i suspect master is broken (but it might be just this PR)
[17:37] <__chip__> let me push this out and check master before frightening you, better
[17:38] <__chip__> zyga-solus: phew. looks like just this PR. sorry for the scare.
[17:39] <__chip__> in my defense it's not _my_ pr :-)
[17:51] <zyga-solus> __chip__: ouch, is that my doing?
[17:51] <zyga-solus> __chip__: let me see how I can help
[17:51] <__chip__> zyga-solus: no, it's mvo's doing, in mvo's branch
[17:51] <zyga-solus> __chip__: which branch is that?
[17:51] <__chip__> zyga-solus: master is fine
[17:51] <zyga-solus> ah, uff
[17:51] <zyga-solus> good
[17:51] <zyga-solus> I'm deep in systemd and cgroups
[17:51] <__chip__> zyga-solus: https://github.com/snapcore/snapd/pull/3995/commits/d1dab9d03903efa3d10e39d3d0ce44683ebf23fa
[17:51] <mup> PR #3995: snap: support "command: foo $ENV_STRING" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3995>
[17:51] <zyga-solus> going from "aha, eureka" to "darn s***"
[17:51] <zyga-solus> and back
[17:52] <zyga-solus> hmm
[17:52] <zyga-solus> didn't I like push to that branch?
[17:52] <__chip__> zyga-solus: systemd <4-dimensional emoji that turns mazlow's pyramid on end and breaks several international conventions on human rights> cgroups ?
[17:53] <__chip__> zyga-solus: github says no
[17:53] <zyga-solus> __chip__: I just feel it's a bit complex and not working
[17:53] <zyga-solus> __chip__: odd
[17:54] <zyga-solus> ah that was https://github.com/snapcore/snapd/pull/4006
[17:54] <mup> PR #4006:  snap-exec: update tests to follow main_test pattern  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4006>
[17:54] <zyga-solus> I just found this odd because I also made a chmod +x patch
[17:55] <__chip__> heh
[17:55] <__chip__> zyga-solus: i didn't --force, promise
[17:55] <zyga-solus> """
[17:55] <zyga-solus> cgroup empty notification is seriously broken unfortunately in the
[17:55] <zyga-solus> kernel the way it is currently implemented. And we'll miss the
[17:55] <zyga-solus> callouts in a number of cases (for example, if somebody has any dir in
[17:55] <zyga-solus> a cgroup still we get no events for it. It's also not available at all
[17:55] <zyga-solus> inside of containers, since the callouts take place on the main pid
[17:55] <zyga-solus> namespace, and nowhere else)."""
[17:55] <zyga-solus> ^- I should get a drnk
[17:55] <zyga-solus> *drink
[17:55] <__chip__> drnk snds rght
[18:05] <ogra_> jdstrand, zyga-solus ... http://paste.ubuntu.com/25708869/ note that i uninstalled the ubports-instller snap before i plugged in the SD card reader in that log
[18:05] <ogra_> this mess goes on and on ...
[18:06] <ogra_> looks like uninstalling the snap left some udev stuff around
[18:08] <zyga-solus> ogra_: looking
[18:09] <zyga-solus> ogra_: is pid 29417 still alive?
[18:09] <ogra_> ogra@styx:~/Devel/model-creator$ ps ax|grep 29417
[18:09] <ogra_>  9179 pts/5    S+     0:00 grep --color=auto 29417
[18:09] <ogra_> nope
[18:09] <zyga-solus> the comm name is interesting
[18:10] <zyga-solus> ogra_: are you still seeing those messages
[18:10] <ogra_> yes, every time i plug or remove the SD card reader
[18:11] <zyga-solus> ogra_: interesting
[18:12] <zyga-solus> jdstrand: I'm lost, it looks like a bug
[18:14] <ogra_> it definitely does
[18:15] <ogra_> note the snap uses devmode by default https://github.com/ubports/ubports-installer/blob/master/snapcraft/snapcraft.yaml
[18:16] <ogra_> (though that should be obviousl from the "ALLOWED" messages)
[18:16] <zyga-solus> right, I'm trying to see what's going on here
[18:20]  * zyga-solus puts this laptop back on the charger and gets to do something on the othe rone
[18:41] <mup> PR snapcraft#1596 closed: tests: move ruby demo test to snapd integration suite <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1596>
[18:50] <mup> PR snapcraft#1348 closed: repo: setup a foreign arch and sources <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1348>
[18:50] <mup> PR snapcraft#1382 closed: rust plugin: make libc configurable <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1382>
[18:50] <mup> PR snapcraft#1387 closed: [WIP] tests: reenable the cleanbuild integration test <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1387>
[20:05] <mwhudson> __chip__: two oldest?? hah
[20:06] <mwhudson> i guess i'm glad random contributors from outside the company have a better time
[20:51] <mup> PR snapd#3995 closed: snap: support "command: foo $ENV_STRING" <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3995>
[23:47] <__chip__> facubatista: o/