[05:05] <mborzecki> morning
[05:20] <zyga> good morning
[05:20] <zyga> mborzecki: what a weird day, it's cold but forecast shows it will be 20+ in a few hours :)
[05:21] <zyga> mborzecki: how was your weekend?
[05:21] <mborzecki> zyga: hey, tiring
[05:22] <zyga> I was sleeping through most of Saturday and about a third of Sunday
[05:22] <mborzecki> zyga: allergy?
[05:22] <zyga> just not enough sleep :D
[05:35] <zyga> mborzecki: wanna read the next chunk: https://github.com/snapcore/snapd/pull/6788/files ?
[05:36] <mborzecki> zyga: will do next, looking at 6782 now
[05:36] <zyga> thanks!
[05:37] <mborzecki> heh, 6782 unit tests fail, i'm guessing it's because we're using 1.9 in travis, while go buildid is from 1.10+
[05:48] <zyga> mborzecki: hmmm
[05:48] <zyga> extra status 2?
[05:48] <zyga> no idea
[06:28] <mborzecki> mvo: morning
[06:29] <mborzecki> mvo: got a little for for 6782
[06:31] <mvo> mborzecki: hey, good morning
[06:33] <mvo> mborzecki: aha, yes, I figured that "file" is too old, a bit of a PITA, I need to figure out how to meaningful test this on older distros
[06:33] <mborzecki> mvo: i'll push a fix in a minute
[06:33] <mvo> mborzecki: oh? what will you do?
[06:33] <mborzecki> mvo: fwiw, i'm just forcing a specific build ID
[06:34] <mvo> mborzecki: neat! curious how you manage that given thats a composition of all inputs
[06:37] <mvo> mborzecki: will you push also update the comment? or should I do that?
[06:37] <mborzecki> mvo: i'll push it too
[06:38] <zyga> Hey mvo, good morning
[06:38] <zyga> おはよございます
[06:39] <mvo> mborzecki: \o/
[06:39] <zyga> One of the surprising things about learning Japanese is that it is completely natural to just read this now
[06:39] <mvo> zyga: hey, good morning
[06:39] <mvo> zyga: amazing!
[06:42] <mborzecki> mvo: pushed, waiting for travis unit test job to explode now :)
[06:47] <mvo> ta
[06:53] <mborzecki> mvo: hah, so go build ID test worked now, but --build-id=0x<hexstring> did not :P
[07:04] <pstolowski> mornings
[07:05] <mvo> hey pstolowski - good morning
[07:09] <mborzecki> pstolowski: hey
[07:39] <mborzecki> opensuse failing again?
[08:41] <Chipaca> https://github.com/snapcore/snapd/pull/6743 could use a second review
[08:42] <pstolowski> looking
[08:44] <Chipaca> thanks!
[09:03] <mborzecki> packages.ubuntu.com is quite confusing
[09:03] <mborzecki> https://packages.ubuntu.com/source/disco/desktop-file-utils leads to debian salsa as package source, but apparently that's not what is built
[09:21] <zyga> re
[09:21] <zyga> back from calls
[10:07] <mvo> we have a bunch of stuff targeted for 2.39 for review, would be great if we can focus on this to land this by tonight if possible
[10:39] <pstolowski> Chipaca: #4673 has 2 +1s
[10:39] <Chipaca> pstolowski: yes, thank you!
[10:50] <zyga> brb, coffee
[10:57] <Chipaca> mvo: what should we do with https://github.com/snapcore/snapd/pull/6404 ?
[10:57] <mvo> Chipaca: we need to ignore it for now, I will un-milestone it
[10:57] <pstolowski> mborzecki: gadget layouts +1
[10:57] <Chipaca> mvo: ok
[10:58] <Chipaca> mvo: there's two other blocked
[10:58] <mvo> Chipaca: at least the commandfromcore fix needs to land first
[10:58] <mvo> Chipaca: yeah, same for these, let me fix things
[10:58] <Chipaca> mvo: and user removal probably also needs demilestoning
[10:58] <mvo> Chipaca: 6404 has a (tiny) chance
[10:58] <mvo> Chipaca: but not until all the other bits are in
[10:58] <mvo> Chipaca: yeah, same for user removal
[10:59] <Chipaca> mvo: i think auto-install has two +1's now
[10:59] <mvo> Chipaca: I had hoped samuele could have a look tomorrow
[10:59] <Chipaca> he's back tomorrow? nice
[10:59] <mvo> Chipaca: its one of the features that are slightly in the danger-zone
[10:59] <Chipaca> yeh
[11:00] <mvo> Chipaca: yeah, unles I misremember we should have him back soon :)
[11:00] <mvo> Chipaca: please reload, list should be more sane now
[11:01] <Chipaca> noice
[11:03] <mborzecki> pstolowski: wow, really feel sorry for you with all error peeling cruft you had to go through
[11:03] <pstolowski> hehe
[11:04]  * zyga found a small bug in snapcraft
[11:22]  * zyga sighs 
[11:26] <Chipaca> mvo: in reviewing #6741 I had to make a change to get snapcraft to work (but it's still failing even after that0
[11:26] <Chipaca> mvo: not sure if there's a trick to it i'm missing :-/
[11:28] <mvo> Chipaca: what kind of error do you get?
[11:29] <Chipaca> mvo: maybe i should cleanbuild it? the unit tests are failing because it's getting a context somehow?
[11:29] <Chipaca> it's weird
[11:29] <mvo> Chipaca: this sounds like cleanbuild may help here, yes
[11:30] <zyga> mvo: is samuele back?
[11:30] <zyga> https://github.com/snapcore/snapd/pull/6791#issuecomment-487540857
[11:31] <zyga> I wanted to discuss this
[11:31] <mvo> zyga: he is back tomorrow
[11:31] <zyga> I s ee
[11:31] <mvo> zyga: so we should discuss this tomrrow early (ish) to ensure it does not block things
[11:32] <cmatsuoka>  /query cjwatson
[11:32] <cmatsuoka>  oops
[12:00] <Chipaca> mvo: even when I apply http://paste.ubuntu.com/p/g7NYVXdB7y/ I still see a -Zxz during the snapcraft, but not sure what's causing it. If you care to look, it's https://pastebin.ubuntu.com/p/bhq2vWtWVW/
[12:01] <mvo> Chipaca: hm, that is strange
[12:03] <Chipaca> mvo: anyway +1 to the fromCore pr
[12:03] <mvo> Chipaca: thank you, I like your suggestion to be more selective about picking the right binaries
[12:04] <mvo> Chipaca: I play with this now, its a bit of a PITA (as its slow to test). thank you!
[12:04] <Chipaca> mvo: all it takes is a stage section in the same part
[12:05] <Chipaca> maybe cmatsuoka knows how to remove all the snap/**.go files with a scriptlet or sth
[12:07] <mvo> Chipaca: yeah, I'm playing with it right now, I think I know what to do, the testing is a slightly annoying (cleanbuild etc)
[12:07]  * mvo lunches first though
[12:07] <Chipaca> mvo: buen provecho
[12:20] <dot-tobias> kyrofa: Read your article about stage-snaps (https://kyrofa.com/posts/speed-up-your-ros-snap-builds), thanks! I'm wondering if one could use the official ruby snap like this to speed up Ruby-based parts, or does its classic confinement prevent this?
[12:23] <cmatsuoka> Chipaca: I'll have a look
[12:55] <mborzecki> anyone up for a simple PR? https://github.com/snapcore/snapd/pull/6792 just renames and reshuffling some code
[13:24] <jdstrand> mvo: hi! do we have an eoan image in travis yet? libseccomp finally migrated
[13:24] <zyga> jdstrand: eoan?
[13:24] <zyga> is that the new name?
[13:24] <jdstrand> zyga: ubuntu 19.10
[13:24] <zyga> oh, nice
[13:25] <cmatsuoka> Chipaca: how was the snap dir problem handled until now?
[13:26] <jdstrand> mvo: also, I *think* I'm through the obstacles so will be focusing on adding tests and testing libseccomp 2.4.1 in all ubuntu releases. we should have a chat this week on what to do about 2.4.1 with core/core18/snapd snaps. maybe wednesday-ish?
[13:29] <mvo> jdstrand: we don't have this is travis yet, we tend to add it late, we should add it to spread.yaml in qemu though, should be a trviaial PR
[13:30] <mvo> jdstrand: wednesday is a public holiday here, but thu, fri sounds fine
[13:40] <jdstrand> mvo: it is already there for qemu (I'm using it)
[13:40] <jdstrand> mvo: ack on thursday
[13:41] <mvo> jdstrand: thanks!
[13:48]  * zyga lunch break
[13:55] <kyrofa> dot-tobias, great question! I believe you can use classic snaps as stage-snaps (sergiusens will know for sure), but if your snap isn't classic there's the possibility of issues. I haven't tried that particular case, but you should!
[14:05] <Chipaca> cmatsuoka: it's not handled; the snapd snap has .go files in snap/
[14:05] <cmatsuoka> oh I see
[14:22] <zyga> back from lunch
[14:35] <cachio> mvo, 2.38.1 in stable now
[14:35] <cachio> mvo, now promoting snpad
[14:39] <mvo> cachio: thank you!
[14:42] <cachio> snpad snap 2.38.1 already in stable
[14:42] <cachio> I'll monitor the snaps now
[14:46] <zyga> I have a simple CUDA app running, now let's see if I can snap it
[14:46] <zyga> mborzecki: let me add another GPU to see if that works too
[14:48] <zyga> mborzecki: I have an ancient quatro GPU as well
[14:48] <zyga> I got it for free once
[14:49] <zyga> heh, no X now :)
[14:49] <zyga> restarting gdm (it helped last time)
[14:50] <zyga> heh
[14:50] <zyga> yes it helped
[14:51] <zyga> let's install the 340 driver version
[14:51] <pstolowski> uh, one more timings PR coming from me, i was sure it landed already until i tried passing --ensure to snapd debug timings.. oh well :(
[14:59] <Pharaoh_Atem> zyga, mvo, mborzecki, kyrofa, sergiusens: so... how far are we from me being able to propose a talk at Flock this year about "creating your first Fedora-based snap"?
[15:00] <Pharaoh_Atem> the Flock 2019 CfP hasn't opened yet, but I want to think about this now, so that maybe we can figure out what we need to do to make that a thing
[15:00] <zyga> Pharaoh_Atem: hmm, no idea, I'm deep in CUDA, let me think and get back to you tomorrow
[15:02] <zyga> mborzecki: ^
[15:39]  * Chipaca goes to the gym before he starts breaking things
[15:41] <mvo> enjoy Chipaca
[15:41] <mvo> hrm, lots of red tests, does anyone looked what is breaking?
[15:44] <kyrofa> Chipaca, decided to start before going to the gym?
[15:45]  * cachio lunch
[15:45] <Chipaca> kyrofa: nope!
[15:45] <kyrofa> Stupid tab-complete adding that comma...
[15:45] <Chipaca> although i've seen the test-snapd-appstreamid test fail a lot
[15:45] <Chipaca> dunno why
[15:45] <Chipaca> now yes i go
[16:04]  * zyga EODs to stay sane and healthy :)
[16:32] <jdstrand> roadmr: hey, can you pull r1225? it isn't urgent
[16:36] <mvo> pstolowski|afk: for tomorrow - one idea that came up was to measure how long state loading (the json stuff) takes, i.e. adding this to the measurements taken
[16:44] <mvo> cachio: hey, I see some failures related to "google:ubuntu-16.04-32:tests/main/appstream-id" in recent PRs, would be great if you could check if its just a fluke or something with the store or snapd (but not rush, I get dinner now and mostly EOD)
[16:45] <cachio> mvo, hey, I saw the mame
[16:46] <cachio> the error is because the store is taking more than 1 second to answer
[16:46] <cachio> there is a PR fixing it
[16:46] <cachio> let me check i
[16:46] <cachio> t
[16:47] <cachio> mvo, I retriggered travis for #6789
[16:47] <cachio> It failed last time trying to download a golang dependecy
[16:52] <roadmr> cachio, mvo : fwiw it's probably taking a bit longer than expected due to the extra load from the recent core release :) should subside in a few hours
[16:53] <roadmr> jdstrand: just saw this! sure, r1225 pull coming up
[16:53] <cachio> roadmr, it is ok, I already fix that in a test, I added a longer timeout to support this kind of situations
[16:54] <roadmr> crap, I seem to have deleted my "bump-crt" script inadvertently :( jdstrand hehe no worries I'll figure it out
[17:27] <jdstrand> roadmr: thanks and whoops!
[17:30] <jdstrand> sergiusens[m], kyrofa: hey, if one of you are around, I'm curious about how to handle multiarch. I've read some of the docs but still not sure. I'd like on amd64 to build with gcc-multilib both amd64 and i386 (eg, -m32), but on i386 to only build its native arch. then I'd like to apply that process to arm64/armhf and I guess ppc64el/powerpc
[17:31] <jdstrand> sergiusens[m], kyrofa: is this possible with a single snapcraft.yaml such that I can have LP builds and end up with result I just described?
[18:00] <kyrofa> jdstrand, so you want the snap for amd64 to be built for both amd64 and i386, but also want one built for i386? I'm confused why you care about the amd64 one being compatible with i386 then
[18:00] <kyrofa> i.e. it will never be installed on i386. Wouldn't you want the same snap released to both architectures in that case?
[18:02] <jdstrand> kyrofa: let me rephrase. the end result should be a snap that contains its native architecture and any supported secondary architectures
[18:03] <jdstrand> kyrofa: so, on amd64, that is a snap that has both amd64 and i386 binaries (think wine), but on i386, just i386 binaries
[18:04] <kyrofa> Ah, the wine example makes this more clear
[18:04] <jdstrand> kyrofa: eg r1 is amd64 and has amd64 and i386 code. r2 is i386 so only has i386 code
[18:04] <jdstrand> r3 is amr64 with arm64 and armhf, r4 is armhf with only armhf
[18:04] <jdstrand> etc
[18:05] <kyrofa> jdstrand, in that case, it's all about the build system, and the `architectures` field doesn't matter (since the default uses the build arch). Correct?
[18:05] <jdstrand> I know how to generate an individulat snapcraft.yaml for each individual situation, but not one that works for all where the same snapcraft.yaml is used by LP to build all the archs with the secondary arch support as described
[18:06] <kyrofa> jdstrand, can you show me the difference between your amd64 and i386 yamls?
[18:06] <jdstrand> kyrofa: I figured I could adjust the Makefile to look at some things to decide when to build with -m32, but I need the gcc-multilib only sometimes, etc
[18:07] <kyrofa> That's doable
[18:07] <kyrofa> build-package, right?
[18:07] <jdstrand> kyrofa: between amd64 and i386, it's just about build-packages
[18:07] <kyrofa> Try this:
[18:10] <jdstrand> kyrofa: I guess I might conceivably need different stage-packages. I'm going to need the :i386 and the :amd64 packages in the amd64 build
[18:10] <kyrofa> jdstrand, https://paste.ubuntu.com/p/3z4VgPpcxg/
[18:10] <kyrofa> stage-packages should work the same way
[18:11] <jdstrand> ok, then I can use the equivalent gcc-... for arm64, etc
[18:11] <jdstrand> ok, that makes sense
[18:11] <kyrofa> Yeah you get the idea
[18:11] <jdstrand> kyrofa: thanks! I may have another question, but this is helpful :)
[18:12] <kyrofa> jdstrand, it's been a while since I did any of that, so let me know if you run into issues
[18:12] <kyrofa> Of course!
[18:12] <jdstrand> well, the paste helps me know what to focus on a lot
[18:32] <mvo> cachio: aha, thanks! I remember the PR now
[18:33] <cachio> mvo, I'll try to merge it today
[18:33] <mvo> cachio: yeah, once its green, go for it :)
[18:34] <cachio> mvo, sure, thanks
[18:35] <mvo> thank *you*
[18:37] <mvo> cachio: one more question - I see some failures in     - google:ubuntu-core-18-64:tests/core18/ and     - google:ubuntu-core-18-64:tests/main/ and its "rsync: write failed on "/mnt/user-data/gopath/src/github.com/snapcore/snapd/tests/main/interfaces-broadcom-asic-control/snapd-unpack/usr/lib/snapd/snap-repair": No space left on device (28)" - did anything change here recently (with the image or something else that you can think of?)
[18:37] <cachio> mvo, no, do you have a link?
[18:38] <mvo> cachio: this was in this pr https://github.com/snapcore/snapd/pull/6741
[18:39] <cachio> mvo, checkign
[18:41] <cachio> mvo, this is something new
[18:42] <mvo> cachio: maybe its a one-off, did not happen in the previous run (3h ago)
[18:42] <kyrofa> mvo, is `base: core` still not a thing? I'm getting "- Mount snap "foo" (unset) (cannot find required base "core")"
[18:42] <cachio> mvo, I am reviewing other logs to see if it is related to that PR or it is happening in others as well
[18:42] <kyrofa> sergiusens, I get that ^ when trying to install a snap I build using `base: core`
[18:43] <ijohnson> kyrofa: I thought that `base: core` only worked inside snapcraft.yaml and that when that's there snapcraft just generates a snap.yaml without a `base` spec
[18:44] <ijohnson> kyrofa: and AFAIK, the core16 snap isn't ready yet (it's not in stable at least)
[18:46]  * kyrofa sanity checks
[18:48] <sergiusens> kyrofa: are you using the snapcraft snap? It is valid in snapcraft.yaml but not snap.yaml
[18:49] <kyrofa> *sigh* please give me ten minutes while I try to figure out why multipass decided to stop working
[18:51] <kyrofa> "shutdown called while starting"...
[18:52] <ijohnson> kyrofa: `snap remove multipass && snap install multipass --beta --classic` always does the trick for me :-)
[18:52] <kyrofa> Hahahaha
[18:52] <ijohnson> I do that probably at least 2-3 times a week
[18:52]  * kyrofa does just that
[18:54] <kyrofa> Man... that's saving some sort of snapshot now that's taking forever. It snapd seriously backing up all the multipass VMs?
[18:54] <kyrofa> I just want to get back up and running!
[18:54] <ijohnson> :-( I don't see the snapshot behavior on stable snapd
[18:54] <kyrofa> Oh no
[18:55] <kyrofa> Crap, how did I end up on edge
[18:55] <kyrofa> This might explain a few things
[18:57] <ijohnson> good luck!
[19:03] <kyrofa> sergiusens, ah, it's the snapcraft .deb (issues from a customer)
[19:04] <kyrofa> sergiusens, that puts the base into the final YAML
[19:04] <kyrofa> You're right, the snap does the right thing
[19:04] <kyrofa> sergiusens, have you considered updating the deb to suggest the snap?
[19:19] <bdx> hello everyone
[19:20] <bdx> hitting a strange issue when building my snap https://paste.ubuntu.com/p/YV2vz6RMJF/
[19:21] <bdx> the plugin I'm using: https://gist.github.com/jamesbeedy/1f592f9beddf8f2973452d0dc742c09f
[19:22] <bdx> nothing has changed in my plugin/source since the last time I built the snap that uses ^ plugin
[19:23] <bdx> all of the sudden its barfing with ^^
[19:24] <bdx> I'm wondering if there is something that may have changed about how plugins are used to override steps?
[19:24] <cmatsuoka> bdx: did you install snapcraft using snap?
[19:24] <bdx> yes
[19:25] <bdx> I get that error both when using `snapcraft cleanbuild` and `snapcraft`, so both in the lxd build environment and on my local (both of which are 18.04)
[19:28] <cmatsuoka> bdx: could you paste your snapcraft.yaml file somewhere? (you may also want to join #snapcraft)
[19:30] <bdx> https://gist.github.com/jamesbeedy/c81decb3625999f75e04564d3b19b71e
[19:30] <bdx> cmatsuoka: want me to bring this over to #snapcraft ?
[19:34] <cmatsuoka> bdx: just a sec, I'm building it locally to see what happens
[19:42] <cmatsuoka> bdx: sent you some suggestions in #snapcraft
[20:13] <mvo> cachio: re 6741> I think I found the issue, sorry, the out-of-space thing was an error in this PR
[21:08] <om26er> Hi! It seems Ubuntu Core does not have the avahi-control interface, how do I make it available to my snap ?
[21:08] <om26er> ogra ^^
[21:08] <om26er> also, when did you lose that underscore in your nick ;-)
[21:39] <om26er> who takes care of those "human review required" failures while publishing snaps ?
[21:40] <om26er> I created a plug and it apparently needs an approval of some sort https://forum.snapcraft.io/t/human-review-required/11158
[21:45] <jdstrand> roadmr (cc msalvatore): hey, can you make that r1226 instead? this adds a 'system-users' check to support upcoming yaml)