[05:03] <mborzecki> morning
[05:08] <mborzecki> mvo: hey
[05:08] <mvo> mborzecki: good morning
[05:08] <mvo> mborzecki: how are things? anything important I missed last week?
[05:09] <mborzecki> mvo: no, don't think so, no fires or anything
[05:11] <mvo> mborzecki: great
[05:11]  * mvo dives into core18 and reviews then
[05:11] <mvo> mborzecki: anything exciting happened? how are parallel installs coming along, I'm quite excited about this one
[05:13] <mborzecki> mvo: i've bastardized snap-confine and snap-update-ns to accept the _ in snap names, then on friday i was looking into mounting foo_bar as foo
[05:13] <mborzecki> mvo: i should be opening some PRs today with some introductory changes in structs
[05:13] <mvo> mborzecki: sweet!
[05:13] <mvo> mborzecki: I was wondering how the internal changes will look like, was it a lot of fiddling?
[05:14] <mborzecki> let me show you a patch
[05:15] <mborzecki> mvo: https://paste.ubuntu.com/p/xNBgYhWcMp/ that's a work in progress version
[05:17] <mvo> mborzecki: aha, nice. StoreName() is a good helper
[05:18] <mvo> mborzecki: that is surprisingly short, nice
[05:18] <mborzecki> mvo: tried to make it least invasive :P
[05:18] <mvo> mborzecki: heh :) looks like a success to me
[05:22] <mborzecki> mvo: s-c bits are a bit fiddly, the mounts, i'm trying tmpfs over $SNAP_MOUNT_DIR, oh an the store part, you can't really install foo and foo_bar right now, because the store complains that you have the same snap appearing twice in the request
[05:23]  * mvo nods
[05:33] <mborzecki> https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github wat?
[05:35] <mvo> mborzecki: I heard rumors about this on the weekend
[05:35] <mvo> mborzecki: definitely in the waaat catgeory
[05:35] <mvo> mborzecki: source-safe-2018
[05:35] <mvo> 5251 is an easy win if someone wants to review
[05:35] <mborzecki> hahah, well, at leas this one  is usable :)
[05:36] <mvo> mborzecki: yeah :)
[05:39] <mup> PR snapd#5251 closed: tests: reprioritise a few tests that are known to be slow <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5251>
[05:39] <zyga> good morning!
[05:39] <mvo> zyga: hey, good morning
[05:39] <zyga> hey hey, how are things
[05:39] <mborzecki> zyga: hey
[05:40] <zyga> so Microsoft keeps snapd source safe ;)
[05:40] <mup> PR snapd#5249 closed: interfaces/home: remove redundant common interface assignment <Simple> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5249>
[05:44] <zyga> I will be here shortly, need to set the little one for a school trip
[05:46] <mvo> mborzecki: there is one open question by zyga in 5244 otherwise it looks good afaict
[05:50] <mborzecki> mvo: just pushed a fix
[05:51] <mvo> mborzecki: ta
[05:51] <mup> PR snapd#5238 closed: tests: skip appstream-id test for core systems 32 bits <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5238>
[05:53] <mup> PR snapd#5232 closed: interfaces/tpm: Allow access to the kernel resource manager <Created by yphus> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5232>
[05:53] <mborzecki> https://www.youtube.com/watch?v=VYOXuOg9tQI haha look at the publish date
[06:17] <mvo> mborzecki: hahaha
[06:32] <zyga> tests are not happy :/
[06:34] <zyga> unattended upgrades?  https://www.irccloud.com/pastebin/Txy5hEt3/
[06:43] <mvo> zyga: possible, yes
[06:56] <pstolowski> morning
[06:58] <zyga> ok
[06:58]  * zyga got stressed because of sudden call that the school trip rule sheet must be brought by all children
[06:58] <zyga> school is so poorly organised
[06:59] <zyga> I signed that paper last week
[06:59] <zyga> and suddenly they tell me I need to keep it (I got a blank copy) and -bring it-, as if they couldn't find their own copy
[06:59] <zyga> sigh
[06:59] <zyga> but all is good now
[06:59]  * zyga tries to forget about non coding stuff
[07:14] <zyga> could anyone please review https://github.com/snapcore/snapd/pull/5245
[07:14] <mup> PR #5245: cmd/snap-update-ns: add PathIterator <Created by zyga> <https://github.com/snapcore/snapd/pull/5245>
[07:17] <mborzecki> zyga: i'll do it in a while
[07:17] <zyga> thanks
[07:59] <mborzecki> any clues what happened to lxd? restoring google:ubuntu-16.04-32:tests/main/lxd seems to consistently fail across a number of jobs
[08:00] <mborzecki> the job hits a kill-timeout when issuing `lxd.lxc stop my-ubuntu`
[08:00] <mvo> mborzecki: I saw this as well, I have not looked yet but probably worthwhile to do a local spread run with -debug
[08:01] <mborzecki> Chipaca: hey, thanks for pushing the fixes for shellchecks :)
[08:03] <Chipaca> mborzecki: I was very bored :-)
[08:20] <mup> PR snapd#5252 opened: store, jsonutil: move store.getStructFields to jsonutil.StructFields <Created by chipaca> <https://github.com/snapcore/snapd/pull/5252>
[08:24] <mborzecki> damn, that lxc issue does not reproduce when running locally :/
[08:26] <Chipaca> mborzecki: the one where it doesn't stop?
[08:26] <mborzecki> Chipaca: yes
[08:26] <Chipaca> mborzecki: it's not 100% on spread either
[08:26] <Chipaca> that is, it's racy
[08:27] <mborzecki> heh, i must be super lucky then :)
[08:27] <Chipaca> i've seen it sporadically since friday
[08:27] <Chipaca> (while iterating on those shellcheck tests)
[08:28] <Chipaca> mvo: extra bonus idea for --format=help: use tags to add brief explanation to fields
[08:28] <Chipaca> mvo: I can push a tweaked helper to grab you that if we agree on a format for 'em
[08:29] <Chipaca> (or, you can, it's not brain rocketry)
[08:34] <pstolowski> 2018-06-04 08:29:45 Failed task restore: 1
[08:34] <pstolowski>     - google:ubuntu-16.04-32:tests/main/lxd
[08:34] <pstolowski> i saw that over the weekend too
[08:35] <pstolowski> mborzecki: ah, it seems like what you mentoned above
[08:40] <mvo> Chipaca: feel free to do that, I'm wrestling firstboot to skip looking for core
[08:41] <Chipaca> mvo: aw
[08:41] <Chipaca> mvo: wrestl wrestl
[08:58]  * zyga -> tea
[09:03] <mup> PR snapd#5253 opened: snap: introduce new fields for parallel snap installation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5253>
[09:17] <pstolowski> and now i got a failure on journal cursor in the google:ubuntu-14.04-64:tests/main/snap-confine-from-core test
[09:22] <pedronis> mborzecki: hi, could you write in a forum topic how you plan to refactor things on the way to parallel installs, small PRs are good but is hard to guess the full picture.
[09:22] <mborzecki> pedronis: sure
[09:23] <mborzecki> pedronis: btw. https://paste.ubuntu.com/p/xNBgYhWcMp/ if you'd like a quick peek at the current changes
[09:25] <mborzecki> pedronis: as you commented in the PR, SnapSetup.Name() has been updated too, just that it's not included int the patchset
[09:25] <pedronis> mborzecki: there are no changes to tests there, bit hard to judge if those changes are sufficient, also the change in store is a bit strange
[09:26] <pedronis> mborzecki: any place dealing with info.Name needs a new test
[09:27] <pedronis> in theory not, but in practice it sort of does
[09:29] <mborzecki> pedronis: hmm i think i'm more afraid of the places that poke the struct directly rather than calling its methods, iirc there was one place where SuggestedName was accessed this way (store?)
[09:29] <pedronis> mborzecki: wrappers I think
[09:29] <zyga> pstolowski: I think the journal change is racy and it somehow doesn't always work
[09:30] <pedronis> mborzecki: anyway new tests in managers_test and spread are probably welcome
[09:30] <pstolowski> zyga: yes.. and somehow it's only on 14.04 (afair)
[09:30] <mborzecki> pedronis: sure, will be adding those
[09:30] <zyga> I don't know,  think I saw that across the board
[09:31] <pstolowski> hmm ack
[09:31] <zyga> offtopic, so the GitHub news seems true,
[09:31] <zyga> I wonder what this means for us
[09:32] <pstolowski> zyga: what is it about github?
[09:32] <zyga> pstolowski: ms bought it
[09:33] <pstolowski> woot
[09:35] <ogra_> zyga, they did ? i thought they only think aloud about it yet ... was there an official statement ?
[09:36] <ogra_> (they also said they might only invest in shares and not buy the whole company afaik)
[09:37] <pedronis> mborzecki: also store changes are a bit buggy ,  that code was sometimes  assuming that instanceKey == snapID which is not true anymore and doesn't seem fully updated
[09:41] <zyga> ogra_: I don't know for sure, there's plenty of news but also rumour around this topic
[09:41] <zyga> I think we'll just wait and see
[09:41] <ogra_> yeah
[09:42] <ogra_> afaik most is speculation atm
[09:44] <ogra_> (what is clear is that MS has "some interest" in GH ... but perhaps thats only to the level like they had interest in imagination tech. where they hold a third to have influence on the graphics driver development)
[09:44] <zyga> http://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github
[09:45] <mborzecki> ogra_: heh, how imagination tech. handled being up for sale was a fiasco :) at least for imagination...
[09:46] <ogra_> yeah, totally
[09:46] <ogra_> haha "Bill Gates and Paul Allen co-founded the company to give hobbyists a way to program a new micro-computer kit, the MITS Altair."
[09:46] <ogra_> thats soo ... LOL ...
[09:47] <ogra_> s/to give hobbyists a way/to lock in hobbyists that already had ways to/
[09:49] <ogra_> heh, this one is also great:
[09:49] <ogra_> "GitHub preferred selling the company to going public and chose Microsoft partially because it was impressed by Nadella ..."
[09:50] <ogra_> ... "he looks so good" ... :P
[09:50] <zyga> <trump voice>you look good, are you exercising?</trump voice>
[09:50] <ogra_> haha
[10:00] <mvo> pedronis: good morning! I updated 5217 based on your feedback
[10:02] <pedronis> mvo: hi, looking
[10:03] <mvo> pedronis: thank you. I'm looking at the firstboot changes right now, I think I will need to reuse bits from 5217 here :)
[10:05] <mup> PR snapd#5162 closed: overlord/hookstate: support undo for hooks <Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5162>
[10:10] <pedronis> mvo: I think snapd should come first in the snaps installed sequence
[10:11] <mvo> pedronis: ok, let me fix this
[10:11] <pedronis> we then take care again of that in first boot
[10:11] <pedronis> but we should keep being consistent I think
[10:12] <mvo> pedronis: yeah, makes sense
[10:15] <mvo> pedronis: updated
[11:00] <pedronis> pstolowski: is your -1 because of the last comment, it wasn't super clear (the other one is wondering and one is a nitpick so I suppose so)
[11:02] <pstolowski> pedronis: yes just about Empty(); and i prefer to call it "requesting a change", not -1 because I'm +1 for you change overall :)
[11:02] <pedronis> pstolowski: well, it really means "requesting a change and wanting to look again"
[11:07] <pstolowski> fair enough, it's just a minor thing, that's all i'm saying
[11:16] <rbasak> I'm under the impression that I can download any revision of a previously published store if I have the right developer access. Is that correct, or is there some kind of retention/expiry policy?
[11:16] <rbasak> I'm trying to download r429 of git-ubuntu from the store, since r430 in edge broke what previously worked.
[11:16] <rbasak> snap download --revision=430 git-ubuntu
[11:16] <rbasak> worked
[11:16] <rbasak> snap download --revision=429 git-ubuntu
[11:16] <rbasak> says: error: cannot find snap "git-ubuntu": snap not found
[11:17] <rbasak> I tried logging in with snap login, but after credentials that failed and suggested sudo
[11:17]  * cachio afk
[11:17] <rbasak> sudo snap login works, with both credentials and a further prompt for 2fa
[11:17] <rbasak> But even then, both snap download and sudo snap download still fail
[11:20] <thresh> hello
[11:21] <thresh> is there a "install" button widget or something I could add on my website to point to snapcraft.io/vlc ?
[11:31] <rbasak> I found https://dashboard.snapcraft.io/snaps/git-ubuntu/revisions/429/ which has a download link which works. But that gives me only the snap, not the assertion.
[11:33] <pedronis> rbasak: that's correct, it should be possible if you have developer access
[11:34] <pedronis> rbasak: can you open a bug https://launchpad.net/snapstore/+bugs
[11:38] <rbasak> pedronis: thanks. The dashboard link shows me "
[11:38] <rbasak> Submitted by
[11:38] <rbasak> nacc (nish.aravamudan@gmail.com)
[11:38] <rbasak> "
[11:39] <rbasak> Which isn't me.
[11:39] <rbasak> Could that be the reason?
[11:39] <rbasak> Some kind of team/individual confusion.
[11:39] <rbasak> It should all be handed over to me, and this was done before that revision was pushed.
[11:39] <rbasak> I remember having to re-auth Launchpad to the store.
[11:39] <pedronis> rbasak: if you can push to it it shouldn't matter
[11:42] <mup> PR snapd#5244 closed: tests: shellchecks part 3 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5244>
[11:43] <Chipaca> rbasak: what architecutre is the snap?
[11:43] <Chipaca> rbasak: if you are logged in, you can ask for any published revision, as long as it's for the current architecture
[11:43] <rbasak> All amd64
[11:44] <Chipaca> rbasak: 'snapcraft revisions git-ubuntu' agrees?
[11:44] <Chipaca> oh
[11:44] <Chipaca> wait
[11:44] <Chipaca> *snap download*
[11:44] <pedronis> ah, download
[11:45] <pedronis> me missed that
[11:45] <rbasak> As opposed to what - publish?
[11:45] <Chipaca> rbasak: install
[11:45] <rbasak> Ah
[11:45] <Chipaca> rbasak: download doesn't talk to snapd to get your tokens
[11:46] <rbasak> Let me explain a little more what's going on
[11:46] <rbasak> edge was working
[11:46] <rbasak> I made an innocuous push to master in our codebase, which triggered a Launchpad build recipe to push to edge
[11:47] <rbasak> That tripped some kind of non-determinism in snapcraft and pushed a broken snap to edge
[11:47] <Chipaca> rbasak: QOTM right there
[11:47] <rbasak> I'd like to do two things: 1) restore edge; 2) examine the snap that Launchpad produced, which is broken, since that isn't what our CI did, which was OK
[11:47] <Chipaca> “I made an innocuous push to master in our codebase” :')
[11:48] <rbasak> :)
[11:48] <Chipaca> rbasak: ok, so if edge is currently broken and that's the one you want to download, why not snap download it right now?
[11:48] <Chipaca> there's a bit of a dance to be done to get it to use the right tokens otherwise
[11:48] <rbasak> https://forum.snapcraft.io/t/launchpad-post-build-pre-upload-testing/5545 has some broken
[11:48] <rbasak> Chipaca: I've downloaded the broken one no problem.
[11:48] <Chipaca> ah ok
[11:48] <rbasak> Chipaca: I'd like to download the previous good one too
[11:49] <rbasak> I have managed to get the snap from the dashboard UI
[11:49] <Chipaca> rbasak: once you have the bad one, use snapcraft to re-pubish the good one, and download that one
[11:49] <rbasak> But I was confused as to why "snap download" didn't work since I was under the impression that it would
[11:49] <rbasak> Also that the dashboard web UI didn't give me the assertion file, but I presume I will just get a new one when I re-publish the good one?
[11:50] <pedronis> sorry, I misunderstooed,  download doesn't work in that case (unless you pass it tokens manually)
[11:50] <pedronis> but that's known bug,  not prioritized for a fix yet though
[11:51] <rbasak> https://dashboard.snapcraft.io/snaps/git-ubuntu/revisions/429/ has a Release button
[11:51] <pedronis> https://forum.snapcraft.io/t/improvements-in-snap-download/1422/8
[11:51] <rbasak> Can I stick it back in edge through there?
[11:51] <Chipaca> rbasak: yes
[11:52] <rbasak> Great! I think I know how to do everything I need then.
[11:52] <rbasak> Thank you for your help - it's much clearer to me now what is going on.
[12:00] <zyga> pstolowski|lunch, mborzecki: updated 5245
[12:00] <zyga> and I have a working follow-up that uses it extensively
[12:01] <zyga> and drops all segments from the code
[12:01] <mborzecki> zyga: ok, looking
[12:10] <jdstrand> skomorokh: it isn't currently possible to do what you want. I suggest creating a forum topic at https://forum.snapcraft.io
[12:13] <zyga> pstolowski|lunch, mborzecki: I pushed the other PR to https://github.com/snapcore/snapd/pull/5254
[12:13] <mup> PR #5254: cmd/snap-update-ns: discard the concept of segments <Created by zyga> <https://github.com/snapcore/snapd/pull/5254>
[12:13] <mup> PR snapd#5254 opened: cmd/snap-update-ns: discard the concept of segments <Created by zyga> <https://github.com/snapcore/snapd/pull/5254>
[12:13] <zyga> jdstrand: hey, good morning :)
[12:14] <jdstrand> hey zyga :)
[12:14] <zyga> jdstrand: I'm working on trespassing, went on a small tangent to clean up validation interface, ended up killing segments
[12:16] <jdstrand> cool
[12:16] <zyga> I have one last cleanup on top, to make error messages less duplicated, shorter and to the point
[12:16] <zyga> then the stack unwinds and validation is back, also with fuse validation
[12:16] <zyga> I didn't see fuse as a problem but now I do :/
[12:17] <zyga> anything fuse has one filesystem type number
[12:17] <zyga> so we no longer know read-only squashfs from writable fuse-exfat or whatever
[12:17] <zyga> I'd love if there was a way to see if a filesystem is read-only without trying to write to it
[12:29] <Chipaca> zyga: doesn't statfs's ST_RDONLY work?
[12:30] <zyga> mmmm :D
[12:30] <zyga> maybe, I didn't think about that !
[12:30] <zyga> Thank you John, I'll check that
[12:30] <Chipaca> wouldn't be surprised if it didn't,  because it being fuse means somebody would have to care :-)
[12:34] <mup> PR snapd#5255 opened: cmd/snap-confine: applied make fmt <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5255>
[12:36] <mup> PR snapd#5256 opened: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256>
[12:45] <zyga> mborzecki: can we not use the word base there
[12:45] <zyga> it's not about the code but the word would become overloaded and confusing
[12:45] <zyga> what's the terminology for the instances/parallel installation etc
[12:46] <mborzecki> haha ok ;)
[12:47] <mborzecki> if we had a list of forbidden words, i'd nominate classic
[12:48]  * zyga should take the dog for a walk
[12:52] <Chipaca> mborzecki: you should call it 'root', that way it's unambiguous
[13:07] <mborzecki> Chipaca: sc_snap_root_name sounds good
[13:08] <Chipaca> mborzecki: I was being facetious
[13:09] <mborzecki> Chipaca: heh, given the limited possibilities root actually make sense :)
[13:27] <Chipaca> mborzecki: sc_snap_uninstanciate_name
[13:27] <Chipaca> mborzecki: sc_snap_deinstance_name
[13:28] <Chipaca> mborzecki: sc_snap_get_rid_of_this_instance_nonsense_in_the_name
[13:28] <mborzecki> sc_snap_drop_instance_name
[13:28] <Chipaca> mborzecki: sc_snap_what_is_this_instance_stuff_just_i_dont_even
[13:28] <mborzecki> sc_snap_why_u_name
[13:29] <Chipaca> mborzecki: sc_snap_wat
[13:29] <Chipaca> mborzecki: putting my serious hat on for a moment, sc_snap_drop_instance_name might be the best one so far
[13:31] <zyga> pstolowski: can you look at the iterator PR again please
[13:31] <pstolowski> zyga: will do
[13:31] <zyga> feel free to open more points there, I changed the code much after really using it
[13:33] <zyga> niemeyer: $7.5B in stock
[13:33] <pedronis> niemeyer: the PR I mentioned is here:  https://github.com/snapcore/snapd/pull/5221
[13:33] <mup> PR #5221: [RFC] snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221>
[13:33] <niemeyer> zyga: How much is that divided by the number of developers?
[13:33] <niemeyer> Just trying to figure how much I'm worth :P
[13:34] <zyga> niemeyer: ~100 AFAIK
[13:34] <zyga> ah sorry
[13:34] <zyga> 745 exactly
[13:34] <zyga> man, that's even nice to divide :P
[13:35] <zyga> 10M each, even for the guy mending the coffee machine
[13:41] <niemeyer> pedronis: Looking
[13:46] <mborzecki> cachio: is gce cleaner using timer services?
[13:46] <cachio> mborzecki, yes
[13:46] <mborzecki> nice
[13:46] <cachio> mborzecki, :)
[13:47] <cachio> working very well so far
[13:57] <mborzecki> noticed the banner at the top of the github page?
[14:02] <cachio> mborzecki, yes
[14:04] <niemeyer> pedronis: Reviewed.. probably needs a quick sync, on that last question.. going into a call now, and we can sync after it
[14:16] <mup> PR snapd#5257 opened: snapstate: ensure fakestore returns TypeOS for the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/5257>
[14:16] <zyga> back from the walk
[14:16] <zyga> so so so hot
[14:22]  * zyga made some ice coffee and gets back to work
[14:25] <zyga> @niemeyer eh
[14:25] <zyga> https://gitlab.com/Zyga
[14:25] <zyga> :-(
[14:25] <zyga> who is pawel z?
[14:29] <pstolowski> zyga: uh...new face of cybersquatting
[14:38]  * zyga enjoys some brief breeze of wind
[14:52] <pedronis> niemeyer: oops, I got confused and thought your meeting was 1h
[14:53] <niemeyer> pedronis: It wasn't too far from it :)
[14:54] <mup> PR snapd#5258 opened: tests: fix lxd test which hangs on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5258>
[15:00] <mup> PR snapd#5217 closed: asserts,image: add support for models with bases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5217>
[15:03] <Chipaca> robert_ancell: o/
[15:23] <zyga> pstolowski: updated
[15:24] <zyga> pstolowski: the error from the constructor fits the rest very nicely, I will now update the remaining PR
[15:27] <jdstrand> cachio: hey, can you take a look at https://github.com/snapcore/snapd/pull/5248? The only issue with travis is that the lxd fix hasn't made it to 2.33
[15:27] <mup> PR #5248: tests: add test to ensure /dev/input/event* for non-joysticks is denied - 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5248>
[15:27] <cachio> }jdsure
[15:27] <pstolowski> zyga: great, thanks
[15:27] <jdstrand> at least I think I'm remembering that right
[15:27] <jdstrand> cachio: thanks
[15:47] <Chipaca> mvo: let me know if I'm bikeshedding too much on your RFC PR
[15:49] <Chipaca> oops
[15:50] <mup> PR snapd#5259 opened:  devicestate: support seeding from a base snap instead of core  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5259>
[15:53] <mvo> Chipaca: just read it, its great
[15:53] <mvo> Chipaca: thank you!
[15:59] <zyga> pstolowski: can you re-review that PR please, it would get me unblocked
[16:04] <pedronis> niemeyer: I'm available for the next hour for that chat, otherwise tomorrow
[16:10] <pstolowski> zyga: doing
[16:10] <zyga> Thanks :)
[16:12] <pstolowski> zyga: looks good, although you made it strict in all cases now, that's intended? i thought you would have to variants?
[16:12] <pstolowski> *two
[16:12] <pstolowski> ah, cleanpath should succeed generally
[16:14] <zyga> pstolowski: no, I thought so too but the usage down the line is fine as-is
[16:17] <pstolowski> +1
[16:17] <zyga> \o/ thanks!
[16:18] <zyga> let's hope tests are lucky now
[16:26] <mup> PR snapcraft#2153 opened: project_loader: allow loading null parts <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2153>
[16:32] <niemeyer> pedronis: Hey, give me a couple and will be with you
[16:33] <mup> PR snapd#5245 closed: cmd/snap-update-ns: add PathIterator <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5245>
[16:36] <niemeyer> pedronis: https://meet.google.com/ftn-sqmv-kwy
[16:37] <zyga> pstolowski: follow-up in #5254
[16:37] <mup> PR #5254: cmd/snap-update-ns: discard the concept of segments <Created by zyga> <https://github.com/snapcore/snapd/pull/5254>
[16:37] <zyga> now shorter and just to the point
[16:38] <mup> PR snapcraft#2151 closed: Debian <Created by transdigiware> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2151>
[16:39] <pstolowski> zyga: i'll take a look tomorrow morning
[16:39] <zyga> pstolowski: sure
[16:41] <cachio> pedronis, hey, any idea why it could be happening? https://paste.ubuntu.com/p/F8fwwrYHVt/
[16:41] <cachio> it is not retrying the assertions
[16:44] <Trel> I'm having some problems understanding how to create a snap.  I have a binary, a few depencencies, and a wrapper script.  Nothing is being compiled.  I'm not sure how to go about doing this.  I'm looking at the site, but not having much luck understanding it.
[16:44] <zyga> jdstrand: hey, do you have some time for a small refactor review?
[16:45] <jdstrand> zyga: which PR?
[16:45] <zyga> Trel: see what snapcraft does, it allows you to bundle your binary (using the copy plugin AFAIK but kalikiana can correct me), you can also define your dependencies which will be added to your snap
[16:45] <zyga> Trel: with some iteration you should get it going
[16:45] <zyga> jdstrand: #5254 please
[16:45] <mup> PR #5254: cmd/snap-update-ns: discard the concept of segments <Created by zyga> <https://github.com/snapcore/snapd/pull/5254>
[16:45] <zyga> jdstrand: this is related to trespassing, the segment verification was unable to verify rootfs and was super confusing with off-by-ones
[16:45] <Trel> zyga: I've been trying to use snapcraft the entire time.  I'm not getting it
[16:46] <zyga> Trel: snapcraft defines how various parts should be combined (perhaps built, perhaps not) into a snap and what the snap itself should export
[16:46] <zyga> Trel: I'd suggest installing hello-world
[16:46] <zyga> looking at what the snap actually contains (in /snap/hello-world/current)
[16:47] <zyga> specifically focus on meta/snap.yaml
[16:47] <zyga> Trel: then run snap run --shell hello-world
[16:47] <zyga> and explore how the filesystem looks like, it's not the same as before
[16:47] <zyga> this should give you some feeling of how snaps execute
[16:47] <zyga> after that the question is "how to build one for myself"
[16:47] <zyga> there are many paths, snapcraft is the most complete and automated one
[16:47] <zyga> but for experimentation and learning you can hand-make one with a few commands
[16:48] <zyga> all you need is meta/snap.yaml
[16:48] <zyga> some files you want to have in your snap
[16:48] <zyga> then you can "snap try" from the directory containing the "meta" directory (this becomes the top level directory in your snap)
[16:48] <zyga> and see what happens
[16:48] <zyga> "snap try" is fantastic for iteration IMO
[16:48] <zyga> you can even get started by copying hello-world snap into a directory of your own
[16:48] <zyga> and tweaking some things
[16:49] <zyga> and "snap try" that
[16:49] <zyga> once you are more comfortable research snapcraft and see how you can take your binary and ship it as a snap
[16:49] <zyga> and people here will no doubt help you out with specific questions
[16:49] <Trel> See, I'm not following any of what you said.
[16:49] <zyga> Trel: ok, start from the top,
[16:49] <zyga> run "snap install hello-world"
[16:49] <zyga> then see that you can run it
[16:50] <Trel> would it be possible to not base it off another?
[16:50] <zyga> then look at how it is defined by looking at various files present in /snap/hello-world/current/
[16:50] <zyga> Trel: sure but I'm trying to show you how snaps look like
[16:50] <cachio> Chipaca, do you have any idea why it could be happening? https://paste.ubuntu.com/p/F8fwwrYHVt/
[16:50] <zyga> you don't have to start from hello-world, this was just a working example you can tweak
[16:50] <Trel> I'll try that but without understanding what I'm looking at, I'm not sure what I'll get out of it that I'm not getting from the docs
[16:51] <cachio> Chipaca, it is not retrying the assertions
[16:51] <zyga> Trel: do you have some basic understanding of how snaps operate?
[16:51] <zyga> Trel: I think snapcraft docs _may_ explain that but I'm not the best person to judge that given I develop snapd
[16:51] <zyga> Trel: having this basic feeling of what snaps do will let you build an understanding of what it takes to build one
[16:51] <zyga> Trel: and finally how to use snapcraft to accomplish your goals
[16:51] <Trel> depends on what you mean, I get the general concept, but not the operation.
[16:52] <Trel> But I'm not understanding what I'm doing to try and add this at all
[16:52] <zyga> Trel: ok, then exploring hello-world will be useful IMO
[16:52] <zyga> Trel: you should learn about what meta/snap.yaml does, looking at hello-world is a good quick idea
[16:52] <Trel> I installed hello-world, I'll look, but I get the feeling it's not going to help me understand because I'm not understanding the examples that use it in the docs either
[16:52] <zyga> Trel: you should also understand how snaps execute, running a command is nice but running "snap run hello-world --shell" is eye-opening
[16:53] <zyga> hint: it's not like your regular system, this is what makes snaps so portable
[16:53] <zyga> Trel: e.g. go to / and run "ls" in that shell, it's not your root filesystem
[16:54] <Trel> Also when I do snapcraft init, I don't get a meta directory at all
[16:54] <zyga> Trel: in the end snap really just ship arbitrary binaries and have a meta-data file describing what those are, snapcraft will let you build snaps ranging from most trivial to most complex but the documentation may use concepts that are unfamiliar at first
[16:54] <zyga> Trel: the source layout is not the same as binary layout, if you follow the snapcraft tutorial and build the first snap there, look at the contents of the prime/ directory
[16:54] <zyga> that is what is inside a built binary snap
[16:54] <zyga> Trel: most of what is in snapcraft.yaml ends up in meta/snap.yaml
[16:55] <zyga> (except for the parts that define how to build it)
[16:55] <zyga> Trel: did you follow this, for example? https://docs.snapcraft.io/build-snaps/your-first-snap
[16:56] <Trel> That's what I'm looking at and not getting.  It's talkign about parts, and snapcraft says parts is required, but hello-world has none
[16:56] <zyga> Trel: parts only exist at build time
[16:56] <zyga> after your snap is built parts play no role
[16:56] <Trel> yes....that's the whole portion I'm not getting
[16:56] <zyga> compare snapcraft.yaml with prime/meta/snap.yaml
[16:56] <zyga> well, now you do :)
[16:56] <zyga> parts only exist at build time
[16:56] <zyga> at runtime you only have a snap
[16:57] <Trel> I honestly am not getting it
[16:57] <Trel> hold on a sec
[16:58] <zyga> Trel: are you familiar with any classic packages (like deb/rpm?)
[16:58] <zyga> Trel: maybe I can make an analogy if you are
[16:58] <Chipaca> cachio: not sure why i didn't see the notification for your question, sorry
[16:58] <Chipaca> cachio: what command are you running, there?
[16:59] <Trel> I'm not, no.
[16:59] <Trel> https://pastebin.ca/4037224  here's what I put in snap.yaml
[16:59] <zyga> that's what you would put in a snapcraft.yaml
[16:59] <Trel> that's what I meant
[16:59] <Trel> sorry
[17:00] <zyga> snapcraft uses snapcraft.yaml to build a snap and generate an appropriate snap.yaml file
[17:00] <zyga> ah, perfect then
[17:00] <cachio> Chipaca, we run
[17:00] <cachio> su -c "/usr/bin/env SNAPD_DEBUG=1 snap download --edge test-snapd-huge 2>snap-download.log" test &
[17:00] <Chipaca> cachio: if it's the same 'snap download' from econnreset/task.yaml, .... i don't know
[17:00] <zyga> Trel: the plugin on line 17 is what tells snapcraft how to build a given part
[17:00] <zyga> Trel: you used nil which literally does nothing at all
[17:00] <cachio> Chipaca, yes, it is the same
[17:00] <Chipaca> cachio: but
[17:00] <zyga> Trel: you probably want one that builds the program or one that copies a pre-made binary from somewhere else
[17:01] <Chipaca> cachio: the assert is downloaded after the snap
[17:01] <zyga> https://docs.snapcraft.io/build-snaps/plugins has more info about plugins
[17:01] <Chipaca> cachio: but we only wait for the snap
[17:01] <Trel> zyga: pre-made, and I thought that's what I'm doing there
[17:01] <zyga> Trel: almost, the nil plugin is not the right one
[17:01] <zyga> kalikiana: around?
[17:01] <zyga> kalikiana: can you please help Trel ^
[17:02] <cachio> Chipaca, so, in this case it is ok the assert is not retried
[17:02] <cachio> because in the error, it is not starting the download
[17:02] <Chipaca> cachio: which is the failure?
[17:02] <cachio> it is creation el partial file
[17:02] <zyga> Trel: AFAIR you want to use "dump" plugin
[17:02] <zyga> https://docs.snapcraft.io/reference/plugins/dump
[17:02] <cachio> but emprty
[17:02] <zyga> https://docs.snapcraft.io/reference/plugins/ is also useful
[17:02] <Chipaca> cachio: ah!
[17:03] <Trel> I looked there and googled around, from what I read if I was supplying the binary, I should've been using nil
[17:03] <Trel> let me switch it to dump and try
[17:03] <zyga> Trel: you want to switch nil to dump and add a source line that defines where to get the pre-build binary
[17:03] <cachio> Chipaca, the problem is that the snap does not start to be downloaded
[17:03] <zyga> I think nil would work iff you'd keep the binary in the same place as snapcraft.yaml
[17:04] <Chipaca> cachio: maybe 20 seconds is too short a time, and we should wait more?
[17:04] <zyga> but I'm a snapd person not a snapcraft person so I may not be fully used to how things are done on the build side
[17:04] <zyga> Trel: please ask kyrofa_, sergiusens or kalikiana as they know this code inside out
[17:04] <cachio> Chipaca, I don't know if it is the problem
[17:04] <cachio> Chipaca, we could try
[17:05] <Trel> Can I run the snap it generates without installing it to see what it does?
[17:05] <cachio> wait more time and see if the problem is this one
[17:05] <zyga> Trel: yes, (well), "snap try" does that
[17:05] <zyga> it is like "snapcraft && snap install *.snap" but much faster
[17:05] <kyrofa_> Hey there Trel
[17:05] <zyga> as long as you don't change snapcraft.yaml (or meta/snap.yaml) you can also change the snap in your source tree live
[17:06] <Trel> needs sudo to try?
[17:06] <zyga> yes
[17:06] <zyga> or sudo snap login
[17:06] <zyga> then snap works without sudo
[17:07] <kyrofa_> Trel, indeed, as zyga was saying the nil plugin literally does nothing. You can still use it, but you'd have to do all the copying yourself, whereas the dump plugin sounds more like what you want
[17:07] <kyrofa_> ("take this tarball and dump it all into the snap")
[17:07]  * zyga hugs kyrofa_ 
[17:08] <Trel> kyrofa_: I thought I DID do all the copying, which is what I'm really not getting here
[17:09] <kyrofa_> Trel, let me take a look at the pastebin
[17:09] <kyrofa_> It's taking quite some time to load for me
[17:09] <Trel> and hold on I'll also pastebin a recursive ls
[17:09] <Trel> there a better pastebin site?
[17:10] <kyrofa_> Trel, mind using pastebin.ubuntu.com?
[17:10] <kyrofa_> About as simple as it gets
[17:12] <zyga> Trel: there's a pastebinit command that helps :)
[17:12] <Trel> Dir listing: https://pastebin.ubuntu.com/p/Dx7G84c7V4/, snapcraft: https://pastebin.ubuntu.com/p/Y22k9QpD7V/
[17:12] <zyga> I think the "filesets" is confusing there
[17:13] <zyga> its meant to help organise how a given part contributes to the snap
[17:13] <zyga> not how to install files in general
[17:13] <zyga> jdstrand: is that code sensible?
[17:13] <zyga> jdstrand: I have some cleanups on top of that
[17:14] <zyga> mainly error handling that's nicer
[17:14] <jdstrand> zyga: I haven't had a chance to look at it yet
[17:14] <jdstrand> hopefully in a bit
[17:14] <zyga> ack
[17:14] <zyga> thank you :)
[17:14] <Trel> but what is the RIGHT way to do it, I've found a lot of ways that aren't working ><
[17:14] <kyrofa_> Trel, yeah, so you have a good start here, but you're using some more advanced features (filesets) without actually doing the basics. So let's start simpler
[17:15] <kyrofa_> Trel, you have a bin directory that you want in the snap, right?
[17:15] <Trel> yes
[17:15] <kyrofa_> You can do that in two easy ways
[17:15] <Trel> And if it's doing it virtually, I'd prefer that it considers it /usr/bin but that's not necessary, thought it would be good in the case of libraries that I can't reloacte
[17:16] <Trel> *relocate
[17:16] <kyrofa_> One is using the dump plugin like this: https://pastebin.ubuntu.com/p/zhDMDmDBBS/
[17:17] <kyrofa_> Saying "copy the root of my project (which only contains the bin directory) into the snap"
[17:18] <Trel> What about with nil?
[17:18] <kyrofa_> The other one, which I don't recommend but illustrates that the nil plugin isn't doing anything for you, looks like this: https://pastebin.ubuntu.com/p/GnDjR9Fb8T/
[17:19] <Trel> But where should I be putting the binary directory in that case
[17:19] <kyrofa_> Both accomplish the same thing with the bin directory in the place you have it now
[17:20] <kyrofa_> And both place it into the root of the snap
[17:20] <kyrofa_> If you want to reorganize it, you can copy it to a different place using the nil plugin, or you can use the `organize` keyword with the dump plugin
[17:22] <Trel> kyrofa_: except where I have it now, with nil, doesn't work
[17:23] <kyrofa_> Trel, even using the code I gave you?
[17:24] <Trel> Wait, I'm confused, does nil do nothing or does it execute that line?
[17:28] <Trel> I tried both ways, I get a snap, but it doesn't run
[17:28] <zyga> mborzecki: hey
[17:28] <zyga> mborzecki: small review on #5256
[17:28] <mup> PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256>
[17:28] <zyga> Trel: does it contain the files you expected?
[17:29] <Trel> I think so, and running them from /snap/qrencode/x1/bin/ works
[17:29] <zyga> excellent
[17:29] <Trel> nope
[17:29] <zyga> what does your binary link with?
[17:30] <zyga> you need to bring those dependencies into your snap
[17:30] <Trel> should just be libpng was the only non-static part
[17:30] <Trel> cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
[17:30] <Trel> that's what I get when I try to run it normally
[17:30] <zyga> Trel: hmm, what is your "snap version"?
[17:30] <zyga> and can you paste "dmesg | grep DENIED"
[17:30] <Trel> 2.32.8
[17:31] <zyga> Trel: please provide the rest of the version output, it's useful
[17:32] <Trel> dmesg: https://pastebin.ubuntu.com/p/FcwChNF28V/ version: https://pastebin.ubuntu.com/p/HHzBvMWBQN/
[17:33] <zyga> kernel  3.13.0-35-generic this is unusual
[17:33] <zyga> or maybe I'm forgetting what's in xenial
[17:34] <zyga> is this a cloud machine?
[17:34] <zyga> you should be on a 4.4 kernel
[17:34] <zyga> not on a 3.13 one
[17:34] <Trel> nope, machine I built a while back
[17:34] <zyga> 3.13 won't work AFAIR
[17:35] <Trel> but snapcraft does
[17:35] <zyga> xenial ships with a 4.4 kernel, did you update from 14.04?
[17:35] <zyga> (aka trusty)
[17:35] <Trel> I may have
[17:35] <Trel> it's been a while
[17:35] <Trel> Is there a way to check that?
[17:35] <zyga> can you update all of your packages, including the kernel and then reboot
[17:36] <zyga> you should see a boot selection if you have multiple kernels
[17:36] <zyga> but the most recent one should be default
[17:36] <zyga> unless you changed that
[17:37] <zyga> mvo: should we add minimum kernel detection to self-tests?
[17:38] <zyga> mvo: I think this could be perhaps, somewhat disruptive
[17:38] <zyga> but I think it would be worth it
[17:38] <Trel> The server is remote to where I am.  I won't see the boot screen.  I can do all but that part (in that way). I'm looking right now at grub.cfg and don't see any entries referencing 4.x?
[17:39] <Trel> BTW, apt doesn't seem to be offering a kernal update
[17:39] <zyga> Trel: you can install linux-image-generic, that should pull in the right kernel
[17:40] <Trel> yeah, I'm about to try that, that will boot me from IRC though when I reboot, I'm going to quit now gracefully prior to doing this, be back in a bit
[17:41] <mup> PR snapcraft#2154 opened: tests: disable sentry <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2154>
[17:48] <mvo> zyga: can we detect this reliable?
[17:49] <zyga> mvo: well, we can do some things that are smart, e.g. recommend a reboot when using ubuntu 14.04 and 3.13 kernel, say that 2.x kernels are not supported and a few others
[17:49] <zyga> I'm looking at your self-test PR as base, let me post some RFC ideas
[17:54] <Trel> I think the kernel bit worked
[17:54] <Trel> I need to try the build again
[17:54] <zyga> Trel: excellent
[18:02] <Trel> Ok, one thing to ask before I try testing, if I have a script, that refers to a binary in the snap, how does the path relate inside?
[18:09] <zyga> Trel: you can use the $SNAP variable
[18:09] <zyga> it refers to the top-level directory in your snap
[18:09] <zyga> so if your snap has bin/someniceapp to run
[18:09] <zyga> you can have your wrapper script run $SNAP/bin/someniceapp
[18:11] <zyga> mvo: this is what I was thinking about https://github.com/snapcore/snapd/pull/5260/commits/50119c96a87952b4af92a8d224cece1bc90e292a
[18:11] <mup> PR #5260: sefltest: advise reboot into 4.4 on trusty running 3.13 <Created by zyga> <https://github.com/snapcore/snapd/pull/5260>
[18:11] <zyga> mvo: but the concept can be extended into new areas
[18:11] <mup> PR snapd#5260 opened: sefltest: advise reboot into 4.4 on trusty running 3.13 <Created by zyga> <https://github.com/snapcore/snapd/pull/5260>
[18:11] <zyga> like flagging ancient openvz kernels that don't work
[18:12] <zyga> since it is restricted to classic it should not harm any product kernels that may have kept old version id but have all the extra patches that make snaps work
[18:12] <Trel> ok, let me try that, if it works, is there anywhere I can the resulting snap file assuming it works on my machine?
[18:13] <zyga> Trel: just ensure that you run your snap as "snap run yoursnapname"
[18:13] <zyga> as running the binary from /snap/yoursnapname/bin/whatever doesn't really use snaps
[18:13] <zyga> once your snap works you can share it with a friend for quick testing
[18:13] <zyga> or register the name on the store and upload it there
[18:13] <zyga> (the binary that is)
[18:13] <zyga> snapcraft has commands for all of that
[18:15] <Trel> I added /snap/bin to my path, is that the same as snap run?
[18:15] <zyga> Trel: yex
[18:15] <zyga> yes, exactly the same
[18:15] <zyga> if you look at what is in /snap/bin
[18:15] <Trel> I THINK it's working
[18:16] <zyga> you will find symbolic links to /usr/bin/snap
[18:16] <zyga> which detects this and behaves as if you ran "snap run"
[18:17] <Trel> ah, so I should now try it with strict mode I'm guessing
[18:17] <zyga> for strict mode you will need to start using some interfaces,
[18:17] <zyga> switch your snap to strict mode (confinement: strict)
[18:17] <zyga> re-build it
[18:17] <zyga> install it
[18:17] <zyga> and see what happens when you run your app
[18:17] <zyga> but congratulations, in development mode your application is already a snap :D
[18:19] <Trel> What do you mean by interfaces in this case?
[18:20] <zyga> Trel: snapd interfaces are a system that allows to change the set of things that snaps can run and to allow snaps to work together
[18:20] <zyga> https://docs.snapcraft.io/core/interfaces
[18:20] <zyga> https://docs.snapcraft.io/reference/interfaces is also useful
[18:21] <Trel> I'll give them a look, though I'm not sure how necessary they'll be for this one
[18:21] <zyga> Trel: it depends on what your snap does
[18:21] <mup> PR snapd#5261 opened: tests: wait more time until snap start to be downloaded <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5261>
[18:22] <Trel> In my case, it uses a pre-compiled binary, with a wrapper script.  I will try later to have it compile it rather than use a pre-compiled one
[18:22] <Trel> it's wrapping this specifically: https://github.com/fukuchi/libqrencode
[18:24] <zyga> Trel: it's not about the binary being precompiled or not
[18:24] <zyga> it's about what the resulting process tries to do
[18:25] <zyga> which system calls it wants to access, which files it wants to access, which IPC system it wants to access
[18:25] <zyga> it is all about runtime
[18:25] <Trel> I'm not sure how'd I'd even determine that let alone work with it
[18:25] <zyga> Trel: you run your app and see what happens
[18:25] <zyga> we have tools and people that can help
[18:26] <Trel> it ran
[18:31] <Trel> which is to say, I have no clue if that means I'm done or there's something else I'd need with what you're saying about interfaces?
[18:32] <zyga> Trel: interfaces allow snaps to do things, at runtime, that are not allowed by default; if your application was never confined it could do anything it wanted.
[18:33] <zyga> the App Store model is built on confinement so untrusted applications can be used without code review
[18:33] <zyga> as long as the set of permissions they have is understood and managed
[18:33] <zyga> that's what interfaces allow
[18:34] <zyga> if the confinement system gets in the way from accessing some critical resource then you will need to look at interfaces for solutions
[18:35] <Trel> Since my wrapper script passes text either as a parameter or piped in, and the result is just spit to the terminal, I'm guessing it doesn't apply for this usage?
[18:35] <zyga> almost
[18:35] <zyga> piping things means the process inherits a file descriptor
[18:35] <zyga> it depends on where it is coming from
[18:36] <zyga> but just try it and see
[18:39] <zyga> jdstrand: will you have time for that review today?
[18:39] <jdstrand> zyga: my today, yes
[18:39] <zyga> jdstrand: thank you, perfect, I will iterate with cleanups on top
[18:40] <mborzecki> zyga: jdstrand: thanks for the reviews on #5256, pff silly me :/, i've pushed fixes just now
[18:41] <mup> PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256>
[18:42] <zyga> mborzecki: can you patch tests to ensure that things are correct
[18:42] <zyga> like with the off by one
[18:48] <Trel> zyga: I'm a bit lost there, I've tried it both ways and it works
[18:48] <Trel> without anything else so far
[18:48] <zyga> Trel: that's fine then
[18:48] <zyga> Trel: I'm not sure what your app is doing
[18:48] <zyga> Trel: but if it works, that's what you want :)
[18:48] <zyga> it works, ship it
[18:51] <Trel> taking text as a parameter or piped and generating a QRCode using unicode characters, and outputting it to the terminal  (the actual libqrencode can make files as well) but my wrapper is what resticts it ot just doing text
[18:53] <zyga> that should be fine
[18:53] <zyga> it might be more complex if you want to redirect to/from a file in ~/.ssh/secret for example
[18:53] <zyga> but for normal usage it should work just fine
[18:54]  * cachio afk
[18:57] <Trel> There any way to avoid "Copying needed target link from the system", I'm guessing I'd need to add the package somewhere, but I'm not sure where.
[18:58] <zyga> can you please be more specific, which command gave you that error?
[18:59] <mborzecki> zyga: i've added more tests, also the temp buffer is filled with some known pattern to check for the code doing proper termination with \0
[18:59] <zyga> thanks!
[19:00] <Trel> This is if I try to compile it rather than copy the binary directly
[19:00] <Trel> full line is: Copying needed target link from the system /lib/x86_64-linux-gnu/libz.so.1.2.8
[19:01] <zyga> that's something for kyrofa_ I think
[19:02] <Trel> I thought it was just adding it to build-packages or similar but I can't seem to reference it anywhere that stops that line
[19:03] <zyga> build packages are the packages you need to build
[19:03] <zyga> stage packages are the packages you need to run
[19:03] <Trel> yes, that's to build, not run
[19:03] <Trel> precompiled doesn't seem to need it
[19:03] <zyga> but does your binary link to libz in the end?
[19:03] <zyga> what does ldd say?
[19:04] <Trel> not sure, that I can check when I'm back on the pc
[19:05] <zyga> just run ldd /path/to/your/binary
[19:06] <Trel> Can't run it on my phone ><
[19:06] <zyga> :-)
[19:07] <Trel> (weechat relay, not actually at the machine)
[19:08] <mup> PR snapcraft#2155 opened: build_providers: support for communicating with a qemu VM <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2155>
[19:18] <kyrofa_> Trel, that means whatever you're building depends on libz.so, but you're not staging it
[19:19] <kyrofa_> So it takes it from the system instead. You can disable this behavior by adding `build-attributes: [no-system-libraries]` to the part definition
[19:19] <kyrofa_> But then that part will be broken, so I suggest you stage that lib
[19:24] <kyrofa_> jdstrand, what does this review error mean?
[19:24] <kyrofa_> The store was unable to accept this snap.
[19:24] <kyrofa_>   - found binaries for architecture 'all'
[19:26] <kyrofa_> (and then it gives a list of stuff)
[19:35] <kyrofa_> This is an `architectures: [all]` snap, does that have something to do with it?
[19:35] <kyrofa_> The error message is very opaque
[19:35] <kyrofa_> roadmr, do you know what that ^ means?
[19:43] <roadmr> kyrofa_: let me see
[19:45] <Trel> kyrofa_: testing that out now
[19:46] <roadmr> kyrofa_: non-gadget snaps with architectures: all can't have compiled binaries inside, because a single binary to rule all architectures is not possible
[19:46] <roadmr> kyrofa_: it should either be arch-specific or not have anything compiled inside (i.e. should contain only interpreted code, .py, .sh, and so on)
[19:48] <Luke> hey guys, i'm trying to build my first snap of mastodon which has a ruby, nodejs, and nginx component. my question is first: can i use a nodejs AND ruby plugin in the same part?
[19:49] <Luke> my second question is, for building ruby packages, I need some extra apt repos for the build-packages. what's the right way to add those?
[19:50] <kyrofa_> roadmr, so it's impossible to ship multiple binaries along with a shell script to decide which to run?
[19:50] <kyrofa_> I thought that was the definition of "fat" snap
[19:51] <Trel> kyrofa_: I see what happened, I forgot I got the pre-compiled one mostly static, that's why it didn't need that lib.  Looks like it may be good now
[19:52] <kyrofa_> Trel, well, it looks like it _think_ it needs that lib ;)
[19:52] <kyrofa_> (ldd)
[19:55] <Luke> what's the relation between snappy and snapcraft?
[19:55] <Luke> is snappy a deprecated name?
[19:59] <diddledan> snapcraft is the command line tooling that builds snap packages to run via snapd
[19:59] <diddledan> snappy ubuntu core is a distribution of Ubuntu that relies entirely on snaps
[19:59] <roadmr> kyrofa_: I think so, that's at least the logic in the reviewer tools, jdstrand might definitely know more
[20:01] <kyrofa_> Luke, more and more the entire system is referred to as "Snapcraft" with the CLI tool being known as "the snapcraft CLI"
[20:01] <kyrofa_> Alright, thanks roadmr. jdstrand curious to get your thoughts on that
[20:02] <Luke> cool thanks
[20:04] <Luke> is there a snapcraft specific channel?
[20:08] <mup> PR snapcraft#2146 closed: project_loader: process parts in consistent order <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2146>
[20:08] <kyrofa_> Luke, nah, we're all together here! Do you have snapcraft-specific questions?
[20:09] <Luke> yeah 1) can I use multiple plugins for a single part and 2) what's the right way to apt-add-repository for build-packages?
[20:09] <Luke> thanks btw!
[20:10] <kyrofa_> (1) yes, just use the same `source` for multiple parts, (2) this is not recommended
[20:11] <Luke> ok cool on #1. the source is a tar to be downloaded. I'm assuming it will be cached?
[20:11] <Luke> kyrofa_: for #2, it's because I'm trying to build ruby stuff. It needs all these rbenv things (I don't know much about building ruby packages)
[20:11] <kyrofa_> Luke, use the ruby plugin, it'll build a specific version from source
[20:12] <Luke> and the #3 question is actually: I need to run pgsql and nginx as a part of this app, should I just jam that into it's own part?
[20:12] <kyrofa_> Luke, that's up to you, you can ship them on their own, but then they need to communicate with each other somehow. Depending on your requirements, it may be easiest to just bundle everything together
[20:13] <kyrofa_> That way you can update them all in one go as well
[20:13] <Luke> yes I want to bundle all together for sure
[20:13] <kyrofa_> So yeah, just new parts
[20:13] <Luke> just not sure the right way to represent bundling in one snap
[20:13] <Luke> ok thanks
[20:13] <kyrofa_> yeah you're spot on: anything that's supposed to be in the snap is a part
[20:13] <Luke> great
[20:14] <Luke> you've saved me like 3-5 days of experimenting and forum questions :)
[20:14] <Luke> is there any ruby-specific snaps you recommend looking at? it seems the least well-represented in snapcraft given the ruby plugin is in beta?
[20:15] <Luke> is the concept that anyone should be able to run the build part of the snap on any box or is the portability just for the snap once it's packaged?
[20:16] <kyrofa_> I don't know of any off the top of my head, but the idea is that the build process should be able to run in CI, a clean xenial image
[20:17] <Luke> ok thought so. that was my goal
[20:17] <Luke> i just dont know what I'll do about these build deps for ruby then
[20:17] <Luke> rbenv and ruby-build
[20:17] <Luke> https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md here's the build guide i'm following btw if you're interested
[20:22] <Trel> kyrofa_: what file would I be using ldd on in that case?
[20:25] <kyrofa_> Trel, well, you can start with the one in bin
[20:25] <Trel> you're talking about AFTER it builds right?  My pre-compiled one is what I'm saying doesn't link to the external version of that file
[20:27] <Trel> One other question, which command for would display the 'description' field.  Info (even with verbose) is only showing the summary.
[20:47] <mup> PR snapcraft#2153 closed: project_loader: allow loading null parts <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2153>
[20:47] <mup> PR snapcraft#2154 closed: tests: disable sentry <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2154>
[20:51] <jdstrand> roadmr: hi! hey, can you pull r1086? when that is live, we can turn on resquash
[20:57] <roadmr> jdstrand: hehe sure! tomorrow, most likely; I've just deployed r1082
[20:58] <jdstrand> roadmr: thanks! tomorrow sounds good
[22:02] <mup> PR snapcraft#2156 opened: snap: use apt from the archive instead of compiling <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2156>