[00:04] <niemeyer> jdstrand: Replied, sorry for the delay there
[00:18] <diddledan> is my system messed up somehow? https://www.irccloud.com/pastebin/zgh6Nf9E/
[04:59] <mborzecki> morning
[05:41] <zyga> Good morning
[05:41] <zyga> I need to take the dog out and I will be back here shortly
[06:25]  * zyga reviews 5316
[06:51] <mup> PR snapd#5316 closed: store, et al: kill dead code that uses the bulk endpoint <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5316>
[06:52] <zyga> whaa
[06:52] <zyga> I was reading it :
[06:52] <zyga> :-)
[06:52] <zyga> but that's fine
[06:52] <zyga> I guess I should make some coffee and meet with mvo then
[06:53] <mvo> zyga: yeah, but rush
[06:54] <zyga> rush or no rush? :D
[06:54] <mvo> zyga: no rush
[06:54] <mvo> zyga: sorry
[06:54] <mvo> zyga: I guess that is a sign that I need more tea
[06:58] <mborzecki> i think we're not picking up enough nvidia/cuda libraries
[06:59] <mborzecki> CUDA 9.1 runtime ships libcudart.so* which is not included in our globs
[07:01] <pstolowski> morning
[07:01] <zyga> mborzecki: I would love a proof of concept nvidia snap
[07:02] <mborzecki> zyga: this and the 'mesa' snap
[07:02] <zyga> mesa is slightly different
[07:02] <zyga> I don't know where it fits
[07:02] <zyga> is it all a bunch of .so files
[07:02] <zyga> or does it need to be in some weird specific spot
[07:19] <mborzecki> cuda sdk - merge 1.2GB download :/
[07:36] <mup> Bug #1639746 changed: Snap launching other snaps <snapd-interface> <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1639746>
[07:54] <Saviq> hey all, where do I file bugs about emails from snapcraft.io? Thunderbird flags them as spoofing because of links pointing to a different place than they display. And then when viewing the online version, Firefox warns about it not being a fully safe connection (assets loaded via http)
[07:55] <zyga> Saviq: good question, I don't know honestly, perhaps popey or JamieBennett knows?
[07:57] <JamieBennett> https://github.com/canonical-websites/snapcraft.io
[07:57] <davidcalle> Saviq: https://github.com/canonical-websites/snapcraft.io/ is a good place for it, make sure you tag @evandandrea and @lewciie
[07:57] <zyga> Thank you
[07:58]  * zyga thinks that it would be good to add a small piece of text to the page footer for this
[07:58] <zyga> maybe worth a small PR
[07:58] <Saviq> thanks!
[08:01] <mborzecki> github is down or sth?
[08:02] <mup> PR snapd#5322 opened: cmd/snap-confine: include CUDA runtime libraries <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5322>
[08:10] <Chipaca> moin moin
[08:10] <pstolowski> mvo, mborzecki, zyga : do you want to take another look at https://github.com/snapcore/snapd/pull/5288 ? i'd like to land it and see if it improves situation; i've added a little more debug and also added rm -rf cleanup step before the test starts, in case we're reusing the machine and previous cleanup didn't work for whatever reason (i suspect this could explain our issues as I think in such case our caching kicks in and
[08:10] <pstolowski> we don't see retry on download, only on assertion fetch)
[08:10] <mup> PR #5288: tests: econnreset/retry tweaks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5288>
[08:11] <zyga> looking
[08:24] <mborzecki> wanted to check cuda with snaps on arch, but the cuda package is installed under /opt/cuda, so our carefully crafter s-c globs basically went out the window
[08:30] <Chipaca> mvo: you around?
[08:30] <mvo> Chipaca: yes
[08:31] <Chipaca> mvo: you have dev access to the hello-world snap, yes?
[08:31] <mvo> Chipaca: let me check, yes
[08:31] <mvo> Chipaca: you have as well
[08:31] <Chipaca> I do?
[08:31] <mvo> Chipaca: sure, check your mail
[08:31] <Chipaca> ah
[08:32] <Chipaca> I've been invited to perhaps :-)
[08:32] <mvo> Chipaca: ;)
[08:38] <mup> PR snapd#5323 opened: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/5323>
[08:41] <Chipaca> hrmph, the hello-world data in the store tests has been edited in undocumented ways :-(
[08:42] <Chipaca> it's testing for content plugs that aren't there for ex
[08:42] <pedronis> mborzecki: zyga had a suggestion for the InstanceName doc comment, you +1 it, are you applying it in the PR or when you actually implement the logic in a follow up?
[08:43] <mborzecki> pedronis: must have missed it, let me push a quick patch
[08:43] <pedronis> Chipaca: I think we have grown more features that is fair to stick on hello-world :/
[08:43] <mborzecki> pedronis: pff yeah, didn't stage it :(
[08:44] <Chipaca> pedronis: I know, and it's fine, but that's why there's a "download the json, and then <do this to it>" comment in the tests
[08:44] <Chipaca> grmbl, grmbl, *AND* grmbl.
[08:45] <pedronis> I don't think I ever noticed that
[08:45] <pedronis> it's probably/likely partly my fault, sorry
[08:46] <zyga> pstolowski: yeah, let's merge 5288 .
[08:46] <pstolowski> k, thanks
[08:47] <mup> PR snapd#5288 closed: tests: econnreset/retry tweaks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5288>
[08:48] <pedronis> mborzecki: np
[08:54] <zyga> mborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/5315/files
[08:54] <mup> PR #5315: cmd/snap-update-ns: introduce MimicRequiredError, make ReadOnlyFsErro… <Created by zyga> <https://github.com/snapcore/snapd/pull/5315>
[08:54] <zyga> I applied your suggestion now
[08:55] <popey> Saviq: yeah, a github issue about the mails is best, thanks.
[09:05] <Saviq> popey: https://github.com/canonical-websites/snapcraft.io/issues/729 https://github.com/canonical-websites/snapcraft.io/issues/730
[09:06] <popey> thanks Saviq
[09:07] <mup> PR snapd#5324 opened: snap: run snap-confine from the re-exec location <Created by mvo5> <https://github.com/snapcore/snapd/pull/5324>
[09:33] <pstolowski> life-changing: travis-ci.org##.ansi filter in ublock kills the cpu hungry log window and only leaves 'raw log' button
[09:33] <zyga> mvo: I saw that, I'm making progress on the system interfaces now
[09:36] <mvo> zyga: nice
[09:37] <zyga> mvo: there's one more special case to handle
[09:37] <Wimpress> Morning mvo zyga
[09:38] <zyga> but we can do the smart thing as well (not touch it)
[09:38] <zyga> base policy
[09:38] <zyga> we should translate system back to core there
[09:38] <Wimpress> I've been asked by an ISV if it is possible to run snapd in Docker.
[09:38] <zyga> Wimpress: hello, how are you doing sir?
[09:38] <Wimpress> My frst thought is no, but I "think" I saw someone show me snapd working in Docker.
[09:38] <zyga> Wimpress: from what I know it is maybe possible but we don't test that today. It depends on how docker confines the container
[09:39] <pedronis> and also what kind of distro is inside I suppose
[09:39] <zyga> yes, that's also a factor
[09:39] <Wimpress> So technically possible but not an "out of box" experience?
[09:40] <jamesh> zyga: I had a few more thoughts about the "old portals" issue, which I've added to the PR: https://github.com/snapcore/snapd/pull/5271#issuecomment-397235058
[09:40] <mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
[09:41] <jamesh> zyga: in short, I agree that it is a problem but think we might have been overestimating how prevalent it is
[09:43] <zyga> jamesh: thank you for the write up and analysis, I think I tend to agree
[09:43] <zyga> let me think about this today and try to catch jdstrand later to discuss, we will reply there
[09:52] <pedronis> pstolowski: couple small comments on the disconnect hooks one
[09:58] <mup> PR snapd#5325 opened: interfaces: add Repository.AllInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/5325>
[09:59] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/5325
[09:59] <zyga> small helper for upcoming branch
[09:59] <mup> PR #5325: interfaces: add Repository.AllInterfaces <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5325>
[10:00] <Chipaca> jamesh: question out of the blue: do you know how to tell gnome what 'app' a window is from?
[10:00] <Chipaca> jamesh: or how it does that for non-gnome apps?
[10:00] <Chipaca> jamesh: snapped apps don't have an 'app' in looking glass, and they don't have an icon, and I suspect it's the same thing
[10:01] <zyga> Chipaca: knowing gnome I'd not be surprised if it used google to search each time you open the activities screen
[10:01] <Chipaca> zyga: :)
[10:01] <jamesh> Chipaca: I'm not sure exactly how gnome-shell links the windows to apps off the top of my head (or if it differs for Wayland vs. X11 apps), sorry.
[10:01] <zyga> The comment said /* Faster than scanning desktop files */
[10:02] <Chipaca> jamesh: no problem
[10:02] <Chipaca> jamesh: I'll continue to ask random people in the street then
[10:02] <Chipaca> :)
[10:02] <jamesh> I know the code in unity7 had some nasty hacks
[10:03]  * zyga thinks http://blog.lenovo.com/en/blog/the-new-thinkpad-p52/ is crazy cool
[10:03] <jamesh> some of which persists in snapd with  the BAMF_DESKTOP_FILE_HINT stuff
[10:05] <Chipaca> jamesh: the BAMF_ thing was to tie it into bamfdaemon,  and some older apps also needed to set WMClass
[10:05] <Chipaca> jamesh: but gnome shell indeed seems to ignore both these things :-)
[10:06] <zyga> Chipaca: can we run gedit and see what it does
[10:06] <Chipaca> (bamfdaemon, i'm not surprised)
[10:06] <zyga> Chipaca: I suspect the best way to learn is just to observe a real app
[10:06] <Chipaca> I'd be completely unsurprised if it were something like "the desktop file needs to be named exactly like the binary"
[10:06] <Chipaca> also saddened
[10:06] <popey> that is in fact the case AIUI
[10:06] <jamesh> right.  IIRC, bamfdaemon would read the environment of the process via /proc to look for that variable to make the link
[10:07] <zyga> Chipaca: all bugs are shallow ... eyes... sad... (pours more alcohol)
[10:08] <Chipaca> popey: do you know if there's a way to override that?
[10:08] <popey> i do not, I comply
[10:08] <Chipaca> popey: how?
[10:08] <popey> maybe the desktop: entry in snapcraft.yaml
[10:08] <zyga> Chipaca: only 20 separate implementations to check :-(
[10:08] <popey> i always put the .desktop file in snap/gui
[10:09] <popey> e.g. https://github.com/snapcrafters/opentoonz/tree/master/snap/gui
[10:10] <mup> PR snapd#5324 closed: snap: run snap-confine from the re-exec location <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5324>
[10:10] <Chipaca> popey: let me test that then
[10:10] <popey> ok, thanks
[10:10] <popey> would be nice not to have to do it
[10:10] <popey> (but we always do)
[10:13] <Chipaca> huh
[10:13] <Chipaca> well i'll be jiggered
[10:13] <Chipaca> renaming the desktoop file to kiosceditor_kiosceditor did the trick
[10:14] <mborzecki> zyga: can you take another look at #5306?
[10:14] <mup> PR #5306: cmd/libsnap-confine-private: introduce a helper for splitting snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5306>
[10:15] <Chipaca> popey: https://forum.snapcraft.io/t/ubuntu-18-04-and-snap-issues/5832/8?u=chipaca
[10:15] <popey> <3
[10:17] <Chipaca> pedronis: in overlord/snapstate's fakeStore there's a bunch of code that uses a snap's channel to decide what to do
[10:17] <Chipaca> pedronis: but I'm killing channel (and anychannel) as arguments to snapinfo -- they're not used anywhere in non-test code
[10:18] <Chipaca> pedronis: do you think it'd be reasonable to give fakeStore an out-of-band way of knowing what's wanted of it?
[10:18] <zyga> mborzecki: sure
[10:20] <Chipaca> pedronis: (i think i might add channel back just for these tests, and kill it in a followup, as it'll get gnarly)
[10:21] <mup> PR snapd#5326 opened: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
[10:23] <zyga> mborzecki: is instance name and instance key the same thing, can they be used interchangeably?
[10:24] <Chipaca> zyga: AIUI instance name == name + "_" + key
[10:24] <mborzecki> zyga: foo_bar, foo_bar [10:25] <zyga> thanks
[10:27] <mborzecki> pedronis: #5314 was updated, please take another look
[10:27] <mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
[10:33] <zyga> mborzecki: done
[10:35] <zyga> another instance of
[10:36] <zyga> Jun 14 09:24:29 arch snapd[28173]: Jun 14 09:24:27 arch systemd[1]: var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount: Mount process finished, but there is no mount.
[10:36] <zyga> Jun 14 09:24:29 arch snapd[28173]: Jun 14 09:24:27 arch systemd[1]: var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount: Failed with result 'protocol'.
[10:36] <zyga> in mvo's branch
[10:55] <mup> PR snapd#5324 opened: [RFC] snap: run snap-confine from the re-exec location <Created by mvo5> <https://github.com/snapcore/snapd/pull/5324>
[11:01] <mvo> zyga: the snap-confine on core18 is a bit thorny, I wrote some options down in 5324 maybe we can chat after lunch about the pros/cons, nothing seems perfect but maybe the alternative plan in 5324 is worth persuing
[11:01] <zyga> ok, I'm reading your PR now
[11:01] <zyga> the system interfaces approach is clean so far
[11:01] <zyga> not finished yet but very simple what's going on (for now)
[11:02] <ondra> mvo ping
[11:03] <mvo> ondra: pong (but almost at lunch)
[11:03] <ondra> mvo sure, will try to be quick :)
[11:03] <pedronis> mborzecki: thanks will look in a little bit
[11:03] <ondra> mvo have I missed something about pi3 kernel and dtb?
[11:03] <mvo> zyga: yeah, its not hard, just feels a bit "uneven" that we need to use different dirs for the profiles on classic and core and to reuse the snap profile dir
[11:04] <mvo> ondra: missed in what sense? I haven't looked at this in a while
[11:04] <ondra> mvo I'm getting a bit confused, so are we free to update kernel as much as we like and dtbs update correctly?
[11:04] <mvo> ondra: well, we unblocked the kernel updates a while ago because the dtb diff was just a single line in a serial port uart freq
[11:04] <ondra> mvo I thought we are not updating dtbs from kernel snap to system-boot at all
[11:04] <mvo> ondra: but of course if this changes and the diff becomes bigger we need to halt things again
[11:05] <mvo> ondra: we are not doing it in snapd, that is correct
[11:05] <mvo> ondra: I mean, we don't copy stuff around into /boot at this point
[11:05] <mvo> ondra: we have no code for this
[11:05] <ondra> mvo so we are not updating dtbs, but rather relying that kernel does not really change there
[11:05] <mvo> ondra: correct
[11:06] <mvo> ondra: yeah, its just so that people get kernel updates but we still have not tackled the dtb update problem
[11:06] <ondra> mvo can you please comment on that forum post? as Gustavo thinks there is no problem to solve, and I do not think this is correct assumption
[11:07] <niemeyer> ondra: That's not what was written there
[11:07] <mvo> ondra: do you have a link for me?
[11:07] <niemeyer> mvo: https://forum.snapcraft.io/t/proposal-to-enable-pi2-3-major-kernel-updates/5842/8
[11:07] <mvo> niemeyer: ta
[11:08] <niemeyer> mvo: np
[11:08] <ondra> niemeyer you are claiming that we have updates flowing and there is no problem, but clearly we do not have dtb updates flowing
[11:09] <ondra> niemeyer so to me there seems to be mismatch in understanding what is actually updating
[11:10] <niemeyer> ondra: I specifically said:
[11:10] <niemeyer> a) The pi2 kernel had a major update just weeks ago, which disagrees with what was presented in the first few sentences
[11:10] <niemeyer> b) We have a design for dtb updates in place
[11:10] <niemeyer> c) If your needs are different, they need to be put into that design instead of besides it
[11:11] <mup> PR snapd#5327 opened: store: switch store.SnapInfo to use the new v2/info endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/5327>
[11:11] <Chipaca> pedronis: ^
[11:11] <niemeyer> d) If you do critical updates like this in hooks it will likely destroy systems in the future
[11:11] <niemeyer> e) We should have a meeting to discuss this
[11:11] <pedronis> Chipaca: thx, will look
[11:11] <niemeyer> ondra: Which of these points is incorrect or unreasonable?
[11:12] <ondra> niemeyer I have been talking about this very problem with mvo in Berlin and he told we are still not updating dtbs when we update kernel,
[11:12] <ondra> niemeyer so you are telling we are updating dtbs?
[11:12] <zyga> mvo: is /etc/apparmor.d really read-only on core?
[11:12] <niemeyer> ondra: I said the pi2 kernel had a major update. Is that true or not?
[11:12] <mvo> zyga: yes
[11:13] <zyga> mvo: I see, well, that's okay
[11:13] <niemeyer> ondra: You're arguing with things I did not say
[11:13] <zyga> I mean, it's harder but we can manage
[11:13] <mvo> zyga: the trouble is that it has a bunch of subdirs
[11:13] <mvo> zyga: otherwise I would say we just make it writable
[11:13] <ondra> niemeyer was that update carefully crafted in a way it does not require dtb changes and can use old dtbs?
[11:14] <zyga> mvo: if we can move s-c profiles in all the cases to a new place I'm okay with that
[11:14] <mvo> ondra: we checked carefully that the new kernel would work fine with the old dtbs
[11:14] <ondra> niemeyer proposal is targeting issue when dtbs are not updated with kernel updates, you claim there is no such a problem
[11:14] <zyga> mvo: and we can consider deploying snapd.apparmor.service to core too, to be 100% sure that we have freedom here
[11:14] <ondra> niemeyer I do not agree with that
[11:14] <niemeyer> ondra: Which of the points above says that?
[11:15] <niemeyer> ondra: In other words, you're saying that yourself.. not me
[11:15] <mvo> zyga: interessting
[11:15] <zyga> mvo: this would allow us to use a directory such as /var/lib/snapd/apparmor/internal or whatever we want
[11:15] <zyga> mvo: and not clash in any wy
[11:15] <zyga> *way
[11:15] <ondra> niemeyer from forum "@ondra My understanding is that we have updates to pi2 boards flowing, and that the dtb problem in that specific case was a red-herring. "
[11:15] <mvo> zyga: I like internal/
[11:15] <zyga> mvo: or ...
[11:15] <niemeyer> ondra: Exactly.. we had a pi2 kernel update just weeks ago
[11:15] <zyga> system ;)
[11:15] <ondra> niemeyer so you are saying there is problem
[11:15] <mvo> zyga: heh
[11:15] <zyga> mvo: but anyway, that's besides the point, let me read your branch carefully
[11:15] <niemeyer> ondra: I said we *DID UPDATE IT*
[11:15] <ondra> niemeyer and I can update kernel freely?
[11:16] <mvo> zyga: I think that is great input, we can probably move it all
[11:16] <niemeyer> ondra: THis is not theoretical
[11:16] <zyga> mvo: the service is already in place, we should see if we can just enable it (it's harmless)
[11:16] <ondra> niemeyer so you don't see problem that we cannot update dtbs?
[11:16] <zyga> mvo: that is, ship it and enable via the snapd.run-from-snapd-snap service
[11:16] <niemeyer> ondra: Why are you still making stuff up?
[11:16] <mvo> zyga: we need to extend it to cover system/ as well, right?
[11:16] <zyga> mvo: yes but it is our service
[11:16] <zyga> it's simple to extend
[11:17] <mvo> zyga: cool
[11:17] <zyga> and we can ship it in snapd snap
[11:17] <ondra> niemeyer because you are telling me there is no problem to solve
[11:17] <niemeyer> ondra: So you hate the blue color?
[11:17] <zyga> and it's a blessed shell script instead of one liner for the purpose of being shellchecked
[11:17] <mvo> zyga: I need to run for lunch, lets catchup afterwards (and/or feel free to write your thoughts into the open PR)
[11:17] <zyga> mvo: sure, go ahead
[11:17] <ondra> niemeyer OK whatever, clearly impossible to talk to you
[11:18] <niemeyer> ondra: Honestly, this is nuts.. I'm literally saying "let's please have a meeting to discuss your needs" and "if your needs are different let's integrate in the design"
[11:18] <zyga> ondra, niemeyer: I'm sure we are perfectly capable of solving the problem if we talk together, I really recommend that we have a call later today/tomorrow
[11:18] <niemeyer> zyga: That's literally the first thing I said :)
[11:19] <zyga> perhaps ondra is not aware of the existing plans or there is a technical detail that we are missing
[11:19] <niemeyer> Quoting:
[11:19] <niemeyer> """
[11:19] <niemeyer> Nevertheless, we already have a design for the proper representation of dtbs that can be updated. Let’s please not cook a different solution without looking at that design first. Even if it’s incomplete for your needs, we should improve on it instead of besides it. Happy to discuss this in our next meeting.
[11:19] <niemeyer> """
[11:19]  * zyga hugs niemeyer and ondra *together* 
[11:20] <pstolowski> anyone looking at interfaces-calendar-service test flakiness? if not, i'll coz it's driving me crazy
[11:20] <zyga> pstolowski: there's a PR from cachio but I don't quite understand how that helps or what the problem is
[11:20] <zyga> pstolowski: I'd recommend diving into it , yeah
[11:20] <zyga> and it seems to happen on all kinds of systems so a small loop with debug would be good
[11:20] <pstolowski> oh ok, let me first check what did he do
[11:20] <zyga> thank you!
[11:22] <pstolowski> right.. it seems that retry didn't help, the PR failed on this test again
[11:22] <pstolowski> interesting
[11:23] <mborzecki> zyga: i think it's related to gvfs which does fuse internally
[11:23] <zyga> mmm
[11:23] <zyga> mborzecki: yeah, it feels like something is mounted there
[11:23] <zyga> otherwise rm would not fail
[11:23] <mborzecki> maybe worth trying is to kill gvfsd* in restore
[11:23] <mborzecki> but that's a long shot anyway :P
[11:25] <zyga> I think we need to reproduce and see what's there
[11:26] <cachio> pstolowski, the retry didn't work?
[11:26] <pstolowski> cachio: it seems to, your PR failed on travis
[11:26] <pstolowski> *so
[11:29] <cachio> but failed on a different test
[11:29] <cachio> there are 2 tests failing for the same reason
[11:29] <cachio> calendar and contacts
[11:30] <cachio> pstolowski, I was trying to see what it is locking the files inside
[11:31] <cachio> but when I debug it, it is already unlocked
[11:31] <mborzecki> cachio: when it fails, can you check if there's anything in that directory (gvfs-metadata) and if there are any gvfs processes alive, if so, kill them
[11:37] <cachio> mborzecki, running again to see
[11:38] <mborzecki> ok, i'm off to the kindergarten, bbl
[11:40] <mup> PR core18#26 closed: hooks: add path <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/26>
[11:41] <pedronis> Chipaca: did a first pass,  main point is that I think the helpers merit unit tests (also because the current shape of responses doesn't exercize all corners of them)
[11:42] <pedronis> looks good though otherwise
[11:53]  * Chipaca ~> lunch
[11:57] <jdstrand> zyga: what did you want to talk about? a snapd-apparmor.service for core?
[11:58] <zyga> jdstrand: I'm not sure, yesterday or today/
[11:58] <zyga> yesterday I only wanted to ask for a re-review of chopTree PR
[11:59] <zyga> there are some interface PRs in flight but I think those are handled well on elsewhere already
[11:59] <zyga> I'm sorry, I think the answer is "I'm not sure"
[11:59] <jdstrand> zyga: it seems https://github.com/snapcore/snapd/pull/5271#issuecomment-397235058
[11:59] <mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
[11:59] <zyga> ah
[11:59] <zyga> yes, that's that!
[12:00] <zyga> so here I tend to agree with James, please think about it and let's discuss in the PR (since James is far away in terms of timezones)
[12:00] <jdstrand> zyga: but I would caution you on moving snap-confine to internal/. I mean, the idea of that is not bad in and of itself, but understanding why the profiles aren't being loaded in /etc/apparmor.d is important before suggesting a solution
[12:00] <jdstrand> zyga: do we understand the race/problem there?
[12:01] <jdstrand> zyga: as in, are we just kicking the can and going to see it happen with internal/ too?
[12:01] <zyga> jdstrand: this is a more subtle question, it is specific to core systems only
[12:02] <zyga> where we cannot write to /etc/apparmor.d
[12:02] <zyga> but need a place to store snap-confine profiles for snapd reexec
[12:02] <zyga> and using /var/lib/snapd/apparmor/profiles was undesired as it would need a new prefix not to clash with snap profiles
[12:02] <zyga> (but we could do that)
[12:02] <jdstrand> why are we reexecing on core?
[12:02] <zyga> this is the new work on a standalone snapd snap
[12:02] <zyga> where core18 or core16 is used for booting
[12:03] <zyga> but snapd is in a separate snap
[12:03] <zyga> (snapd.snap)
[12:03] <zyga> there's a new protocol for running that
[12:03] <zyga> but it involves writing a profile for snap-confine for a given snapd snap revision
[12:03] <zyga> mvo: I just realised there is a complication
[12:03] <jdstrand> it still isn't clear. why are we reexecing on core?
[12:03] <zyga> jdstrand: because core18 and core16 don't ship a snapd snap
[12:03] <zyga> er
[12:03] <zyga> snapd itseslf
[12:04] <jdstrand> I mean, core16 and core18 won't have snapd, so there is nothing to reexec
[12:04] <zyga> this isn't really reexecing, it needs a new name
[12:04] <jdstrand> so?
[12:04] <jdstrand> ok
[12:04] <zyga> so we will exec snap-confine from /snap/snapd/123/usr/lib/snapd/snap-confine
[12:04] <zyga> we need to generate a profile for that in snapd
[12:04] <zyga> and we need to store it persistently
[12:04] <jdstrand> but regardless of what it is called, snapd needs to put a snap-confine profile somewhere
[12:04] <zyga> and load it on boot
[12:04] <zyga> the question is where do we store it
[12:04] <zyga> and /etc/apparmor.d is read only
[12:05] <zyga> and has a host of other things inside that makes it harder for us to use as a sync directory
[12:05] <jdstrand> this is getting into the territory of why I thought the snapd snap should not be a normal app snap
[12:05] <zyga> it is not a normal app snap
[12:05] <jdstrand> but a new 'type: snapd'
[12:06] <jdstrand> ok, then that has evolved. last I heard it was
[12:06] <zyga> (new type is an interesting idea but it's orthogonal, it has special handling already)
[12:06] <zyga> it is not a normal app snap in the sense that it doesn't expose itself as a service
[12:06] <zyga> or snap as an app
[12:06] <zyga> it's all handled externally with snapd.run-from-snapd-snap.service
[12:06] <Chipaca> popey: remember that xps? something was burnt out getting power to the ram; £65 later i've got an xps
[12:07] <jdstrand> it is 'type: app' with special-casing. more and more as we go. that is orthogonal, but the more special casing, the more it shouldn't be 'type: app'. it isn't an app. it is a snap from managing and running apps
[12:07] <jdstrand> s/from/for/
[12:07] <jdstrand> anyway
[12:07] <jdstrand> sure, put it in apparmor/internal, leave cache the same
[12:07] <zyga> jdstrand: ack, thank you
[12:08] <zyga> jdstrand: I agree about making it explicitly special and I think we will over time, this is just a way to hit core18 work on time
[12:08] <jdstrand> you will then need snapd-apparmor.service
[12:09] <zyga> jdstrand: yes, but as I said, it is just a proposal at this stage
[12:09] <jdstrand> note, I still consider /etc/apparmor.d as read-only a good property on core
[12:09] <zyga> mvo and I will talk about what the options are and then decide what to pursue
[12:09] <jdstrand> because it makes it impossible to mess with system policy, tunables and abstractions
[12:09] <zyga> jdstrand: yeah, I think that's fine too, it's just something we were not aware of a short while ago :)
[12:10] <jdstrand> we actively chose to have /etc/apparmor.d/cache read/write but /etc/apparmor.d read-only
[12:10] <mup> PR snapd#5328 opened: snapstate: stop using evolving SnapSpec internally, use an internal-only snapSpec instead <Simple> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5328>
[12:37] <jdstrand> zyga: I was surprised to see that the 'profile not found' issue was not on your list. it seems I see at least once a day an issue where someone is hitting it
[12:38] <zyga> hmm, indeed, I should look into it
[12:39] <jdstrand> zyga: thanks
[12:39] <zyga> I need to scan the forum for existing reports
[12:39] <mvo> jdstrand: has apparmor upstream ever considered /var/lib/apparor.d in addition to /etc/apparmor.d ?
[12:40] <mvo> jdstrand: having that as an official place would make some things on core18 easier for me, i.e. the snap-confine dynamic profile generation
[12:41] <mvo> zyga: I was thinking about snapd.apparmor.service, the downside of using it is robustness, having something on core18 itself load profiles (like the current apparmor service) would mean things work even if snapd.run-from-snap does not work for whatever reason
[12:41] <mvo> zyga: the snapd.* services are all generated only in /run/ at this point
[12:41] <mvo> zyga: wdyt?
[12:42] <mvo> zyga: I wonder if I should write a forum post about this, it has more edges than I expected it to have
[12:43] <zyga> jdstrand: I see what you are saying but once run-from-snapd-snap stops working we are toast anyway
[12:43] <zyga> no "snap", no "snap revert"
[12:43] <zyga> nothing works at that time
[12:44] <mvo> zyga: well, yes. however if in such an even at least the snaps themself keep running that would be preferable it seems
[12:44] <mvo> zyga: different levels of de-generation :)
[12:51] <jdstrand> mvo: apparmor upstream has not dictated how downstreams load policy
[12:52] <jdstrand> mvo: apparmor upstream is interested in making a systemd unit that can be used across distros. this will allow adding additional directories, etc
[12:52] <mvo> jdstrand: ok
[12:53] <jdstrand> mvo: today, it is an Ubuntu-ism to load /var/lib/snapd/apparmor/profiles
[12:53] <jdstrand> mvo: it would be possible for the apparmor init to add /var/lib/snapd/apparmor/internal
[12:53] <jdstrand> mvo: it is also possible to ship /var/lib/snapd/apparmor/snap-confine....
[12:54] <jdstrand> err
[12:54] <jdstrand> /var/lib/snapd/apparmor/profiles/snap-confine....
[12:54] <zyga> that is a directory
[12:54] <zyga> ah
[12:54] <zyga> yes
[12:54] <jdstrand> then the init doesn't have to change anything
[12:55] <jdstrand> we already have snap-update-ns. in there, it isn't impossible to think about snap-confine.something too
[12:55] <jdstrand> ensure dir could ignore stuff that was prefixed with snap-confine.
[12:55] <jdstrand> etc
[12:56] <mvo> jdstrand: you mean to use the "snap-confine." prefix?
[12:56] <mvo> jdstrand: just like we use the snap-update-ns. prefix?
[12:56] <zyga> yes, that would work
[12:56] <mvo> jdstrand: if we go with a unique prefix we could use "system." as this is already not availalbe as a snap
[12:56] <mvo> zyga: (cc) -^
[12:57] <mvo> and then we just write it in both core and classic into the same location - that will be nicer than the current mess^Wapproach
[12:57] <zyga> mvo: system could even be a snap as snap profiles are snap.*
[12:57] <jdstrand> mvo: yes, that is a possibility, then you are working within the current Ubuntu-ism
[12:57] <zyga> (so snap.system.foo)
[12:57] <zyga> vs system.whatever
[12:57] <mvo> zyga: good point
[12:57] <jdstrand> system. obviously works too
[12:58] <mvo> jdstrand: yeah, I think I will go with this, thank you and zyga  for your input!
[12:58] <jdstrand> np
[12:58] <ogra_> niemeyer, seriously, i'm not attemprting to discuss anything with you, i was asking for a link to the design you referred to and you shut the topic down ... and you call *me* "passive aggressive" ?!?!
[12:59] <niemeyer> ogra_: I won't discuss it here either. That's not passive aggressive, that's not having an argument at all. I'll talk to ondra in a place we can understand each other more easily.
[13:00] <ogra_> niemeyer, pretty please do you have a link or dont you have a link, i do *not* want to discuss anything but you refer to a design that i'd like to be aware of
[13:00] <ogra_> without any intend to discuss anything with you i just want to know about it since i will likely have to use it
[13:02]  * zyga -> standup
[13:04] <ondra> niemeyer random question, are we planning to support upgrade from UC16 to UC18?
[13:04] <niemeyer> ondra: Yeah, definitely.. we need some good work there
[13:04] <jdstrand> roadmr: hi! totally not urgent request for pulling r1091
[13:05] <jdstrand> lool: that has what we talked about ^
[13:05] <roadmr> jdstrand: sure thing, I'll put it in the queue and roll the ball from there
[13:06] <jdstrand> roadmr: thanks
[13:06] <lool> jdstrand: cool
[13:12] <ondra> niemeyer then I'm gently pointing out, dtbs are not compatible between 4.4 and 4.15 kernels on pi
[13:13] <niemeyer> ondra: Let's discuss the topic in our next call.
[13:14] <ondra> niemeyer sure, more than happy to do so
[13:14] <niemeyer> ondra: Thanks
[13:16] <snappy_> Hi guys..   How can we delete/de-register the snap from the snap store?  Please someone guide me to de-register the snap in the store...
[13:25] <popey> ^ sparkiegeek
[13:30] <diddledan> something's wonky with the newly rolled-out buildd:
[13:30] <diddledan> https://www.irccloud.com/pastebin/zDAQYaLN/
[13:31] <diddledan> specifically it's failing to run my wget command in override-build
[13:35] <sergiusens> diddledan: newly rolled out buildd?
[13:36] <diddledan> sergiusens: https://forum.snapcraft.io/t/released-launchpad-buildd-163/5925
[13:36] <sergiusens> diddledan: btw, had you tried corebird (the snap) with the communitheme ?
[13:36] <diddledan> no, I haven't
[13:36] <sergiusens> get transparent backgrounds
[13:36] <sergiusens> might be a comunitheme issue (ah, that thing is so hard to spell)
[13:37] <sergiusens> ooh, transparent proxy, that removes a lot of pain from some of the plugins
[13:40] <diddledan> it might fix some plugins, but it's preventing wget from working in my build
[13:41] <sergiusens> diddledan: so wget is not found or the network setup is getting in the way?
[13:41] <diddledan> it's refusing to download the url - wget says no
[13:42] <diddledan> see my paste above
[13:43] <diddledan> the code that drives that is
[13:43] <diddledan> https://www.irccloud.com/pastebin/vFsm4jzb/
[13:46] <Chipaca> mvo: La Pampa, https://goo.gl/maps/ugAEKg51sjq, vs the Pampas, https://en.wikipedia.org/wiki/Pampas#/media/File:Pampas_Range.png
[13:46] <Chipaca> mvo: not to confuse with the Pampa, an indigenous people
[13:46]  * Chipaca really off now
[13:47] <sparkiegeek> cjwatson: ^^
[13:48] <pedronis> mvo: as I said, I think I'm going to pick up this, tomorrow tough likely:  https://github.com/snapcore/snapd/pull/5270
[13:48] <mup> PR #5270: snap,client: show "publisher" in `snap list` and expose in client API <Created by mvo5> <https://github.com/snapcore/snapd/pull/5270>
[13:49] <mvo> Chipaca: heh, thank you!
[13:49] <mvo> pedronis: great, thank you
[13:49] <mvo> pedronis: I will try to tame snap-confine on core18 now
[13:49] <pedronis> mvo: we should probably block the --format one tough,  until that one is done, if that's ok
[13:49] <mvo> pedronis: sure, just add "blocked" there
[13:50] <pedronis> ok, thx
[13:50] <mup> PR snapcraft#2155 closed: build_providers: support for communicating with a qemu VM <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2155>
[13:53] <jdstrand> zyga: fyi, I added the small changes you requested in PR 5250
[13:53] <mup> PR #5250:  interfaces/udev,misc: only trigger udev events on input subsystem as needed <Reviewed> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5250>
[13:54] <zyga> Ack, I will look shortly. Taking the dog out now
[13:54] <jdstrand> mvo: fyi, that ^ is going to really help people like popey who are seeing desktop environment hangs and crashes upon interface connection
[13:55] <jdstrand> mvo: I was hoping this would make 2.33, but it didn't. if you are respinning a 2.33, feel free to consider it (and to say 'no' if you want it to bake. if its in trunk, people like popey can use the edge snap)
[13:55] <popey> I'm still using your shonky build of snapd
[13:56] <popey> and not had any desktop explosions yet
[13:56] <jdstrand> popey: I'm so glad it has helped you
[13:56]  * diddledan hides the c4
[13:56] <jdstrand> popey: keep an eye on that PR and you can start using the edge one
[13:57] <popey> jdstrand: unrelated. firefox specifies removable media but doesn't autoconnect. Do *they* need to request that?
[13:57] <mvo> jdstrand: it seems risky for 2.33.1
[13:57] <popey> Because I wanted to upload a photo from a CD (yes, a CD) and had to connect it to get access
[13:58] <mvo> jdstrand: but if you and $more people assure me it solves more problems than it creates I'm open to this
[13:58] <jdstrand> popey: well, somebody does, yes
[13:58] <popey> would it be okay if I requested it? :D
[13:58] <popey> or do you need the upstream to do it
[13:59] <jdstrand> mvo: at its heart, it is a simple change. run udevadm trigger with --subsystem-nomatch=input
[13:59] <jdstrand> by default
[13:59] <jdstrand> and add in other stuff as needed
[13:59] <jdstrand> I will be on holiday tomorrow and next week
[14:00] <mvo> jdstrand: oh, that evolved since I looked at last then I think. that sounds more innocent now
[14:00] <jdstrand> mvo: I think it's safe (which is why I mentioned it at all), but I also won't be around if it gets pushed out. I'm also fine for 2.34
[14:00] <mvo> jdstrand: I have a look, given that its (mostly aiui) nomatch that makes it much more appealing
[14:01] <cjwatson> diddledan: Could I have the full build link, please?
[14:01] <mvo> jdstrand: I will ask for it to get squash merged, I assume this is ok with you?
[14:01] <mvo> jdstrand: to make the cherry-pick to 2.33 easier
[14:01] <jdstrand> mvo: yeah, it needs a second review so if you did that it could double as a review for 2.33.1
[14:01] <jdstrand> mvo: yes
[14:01] <diddledan> cjwatson: this it? https://build.snapcraft.io/user/diddledan/gog-galaxy-wine-snap/249050
[14:02] <mvo> jdstrand: great, thank you. once I finished my current task I will look at it
[14:02] <jdstrand> mvo: thanks for your review and consideration :)
[14:02] <mup> PR snapd#5321 closed: tests: fix interfaces-contacts-service test retrying to remove share dir <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5321>
[14:03] <jdstrand> popey: you can request it
[14:03] <cjwatson> diddledan: mm, somebody's broken BSI's ability to show other users' builds, but I can work it out from that ...
[14:03] <diddledan> cjwatson: that's the amd64 build, this is the i386 variant - both fail the same way: https://build.snapcraft.io/user/diddledan/gog-galaxy-wine-snap/249053
[14:04] <cjwatson> diddledan: Is it clear that this is a regression?  That snap has never had any successful builds
[14:04] <diddledan> it's a brand new snap. it builds fine locally in cleanbuild
[14:05] <cjwatson> Right, which says nothing about whether it's a regression in launchpad-buildd :)
[14:06] <cjwatson> I can certainly look, it's just less of a panic if it's not obviously a regression.
[14:08] <diddledan> @Wimpress can you trigger a build on tmnationsforever to test whether it's a regression as you're using a similar build?
[14:09] <cjwatson> I'm setting it up locally
[14:11] <cjwatson> It *could* be something wrong with the extra layer of proxying, although you can see the access log there reporting 200
[14:11] <popey> diddledan: actually tmn wasn't hooked up to build yet. I have just done so. (which will trigger a build)
[14:11] <cjwatson> And much more complicated things have worked
[14:11] <cjwatson> So let's see if it reproduces in my local setup
[14:12] <diddledan> thanks :-)
[14:12] <popey> https://build.snapcraft.io/user/snapcrafters/tmnationsforever
[14:13] <diddledan> looks like the `build-on:` isn't respected by the builders yet (but that's completely orthogonal. I'm just observing.. :-)
[14:14] <cjwatson> diddledan: I know, I've been working on that for the last couple of weeks
[14:14] <diddledan> I'm betting it's a pain to get working
[14:14] <cjwatson> It is very definitely in progress
[14:14] <cjwatson> Most of the pain has been in sorting out APIs for Bazaar-backed things
[14:15] <diddledan> you need to download the project (into a builder?) before you have the required bits to tell you where to build.. glad I'm not working on that :-p
[14:15] <cjwatson> The actual mechanics of build-on are relatively straightforward, just code that kyrofa supplied for me and plumbing
[14:15] <cjwatson> Nah
[14:15] <cjwatson> We have internal APIs to fetch files from Git repositories
[14:15] <diddledan> aha
[14:15] <cjwatson> And I've put the same thing together for Bazaar
[14:15] <diddledan> sneaky backroom dealings!
[14:16] <cjwatson> Although now that you mention it I'm going to have to work out how that works for stuff hosted on GH, argh
[14:16] <cjwatson> sudden non-triviality realisation!
[14:16] <diddledan> oops, sorry :-(
[14:17]  * diddledan cuddles everyone who needs it
[14:18] <cjwatson> might need to start doing internal imports or something
[14:23] <zyga> re
[14:23] <cpaelzer> hi, I assume I was lazy not paying attention to some mails - but it seems my small snap was sorted out in the snapstore
[14:24] <cpaelzer> I still have it installed
[14:24] <cpaelzer> virt-machine-type      0.0.2                   3     edge      paelzer       -
[14:24] <cpaelzer> but can't find it on the store
[14:24] <cpaelzer> maybe I violated some new check/rule
[14:24] <cpaelzer> how would I debug that other than digging through the pile that is my mail inbox?
[14:24] <sparkiegeek> cpaelzer: define "can't find it on the store" ?
[14:25] <cpaelzer> like search on https://snapcraft.io/store
[14:25] <cpaelzer> aren't all snaps there?
[14:25] <sparkiegeek> cpaelzer: you haven't released it to stable, the search APIs don't (yet) return snaps that haven't been pushed to stable
[14:25] <cpaelzer> oh, that explains why snap find doesn't find it either
[14:26] <cpaelzer> thanks sparkiegeek
[14:26] <cpaelzer> I thought it was shown on find in the (very) early days
[14:26] <cpaelzer> but that is fine
[14:26] <cpaelzer> yeah I can install from edge
[14:27] <cpaelzer> thanks sparkiegeek
[14:28] <zyga> jdstrand: will you have time to review https://github.com/snapcore/snapd/pull/5081 before your holidays?
[14:28] <mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
[14:29] <popey> diddledan: huh, tmn fails too. https://launchpadlibrarian.net/374512942/buildlog_snap_ubuntu_xenial_amd64_7d2139885b31f8fd1187b9d3482243b9-xenial_BUILDING.txt.gz
[14:30] <sparkiegeek> popey: looks different? is wget in the build-packages stanza?
[14:30] <popey> No, it's in stage-packages.
[14:31] <popey> works in cleanbuild though *shrug emoji*
[14:31] <cjwatson> Yeah that looks like an obvious bug
[14:31] <diddledan> yeah, I had to add wget to build-packages. that's a different issue :-)
[14:31] <cjwatson> cleanbuild uses a slightly fatter base image
[14:31] <sparkiegeek> popey: 🤷
[14:31] <popey> ok, thanks will fix that
[14:31] <cjwatson> diddledan: speaking of which you need "build-packages: curl" in the gog-galaxy-version part
[14:31] <popey> doing gods work sparkiegeek thanks
[14:31] <cjwatson> I don't think that's the bug here, but noticed in passing
[14:32] <diddledan> I do?
[14:32] <sparkiegeek> popey: I had to leave people hanging :)
[14:32] <diddledan> I'm not using curl anywhere
[14:32] <cjwatson> Yeah you are
[14:32] <cjwatson> Last line of your snapcraft.yaml
[14:32] <diddledan> oh yeah, I see it, thanks
[14:32] <diddledan> I should swap that for wget
[14:32] <anarcat> grml... so more firefox problems! :) since 60.0.2 (or 60.0.1? not sure) u2f authentication is failing
[14:33] <cjwatson> Eh, curl is more convenient for piping to stuff, so *shrug*
[14:33] <anarcat> it works well in firefox-esr from the debian packages and used to work in earlier snap versions, so i'm not sure what's going on
[14:33] <anarcat> the u2f token is a Yubikey NEO and it still works with chromium as well
[14:33] <anarcat> i'm wondering how/if i can rollback to an earlier snap version
[14:33] <cjwatson> diddledan: reproduced locally; trying under strace to get a better idea of what's failing
[14:37] <popey> Chipaca: nice on the xps! The chromebook I got is all up to date (as far as it will go) and will probably live on a dusty shelf now :)
[14:38] <pedronis> niemeyer: https://forum.snapcraft.io/t/possible-evolution-path-for-snap-store-endpoints-regarding-epoch/5871
[14:39] <jdstrand> zyga: yes, see your inbox :)
[14:39] <jdstrand> that's one for today
[14:39] <anarcat> should i send my question on the forum instead?
[14:40] <zyga> oh, thanks
[14:40] <sparkiegeek> anarcat: snap help revert in general, 'snap revert firefox'  in particular?
[14:40] <zyga> jdstrand: about readlinkat, I suspect it's an older conffile
[14:41] <zyga> jdstrand: so one thing about todays discussion, I'd love to get snap-confine profile out of /etc
[14:41] <zyga> and out of conf-file hell
[14:42] <anarcat> sparkiegeek: thanks, i somewhat missed that
[14:42] <jdstrand> I know you would and it makes some sense, especially with the core snap discussion from earlier
[14:42] <jdstrand> I've said that elsewhere
[14:42] <anarcat> sparkiegeek: what if i confirm the regression? should i file this as a bug somewhere?
[14:43] <mvo> zyga: I updated 5324
[14:43] <zyga> thanks
[14:43] <anarcat> sigh... reverting to 60.0.1 doesn't fix the issue :/
[14:43] <mvo> zyga: it uses most of the ideas you suggested, I think its nice now, no more special cases, profiles get loaded on boot etc
[14:44] <mup> PR snapd#5306 closed: cmd/libsnap-confine-private: introduce a helper for splitting snap name <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5306>
[14:44] <popey> jdstrand: we're getting a failure in the store where we're using build, so surprised it's failing... https://dashboard.snapcraft.io/snaps/tmnationsforever/revisions/6/
[14:44] <popey> it says checksums don't match
[14:44] <sparkiegeek> anarcat: I'm not familiar with the details of U2F, could it be https://forum.snapcraft.io/t/snapped-firefox-unable-to-use-smart-card/5719 ?
[14:45] <anarcat> sparkiegeek: probably related, yes. it's strange because it used to work...
[14:45] <anarcat> sparkiegeek: is there a way to revert further back?
[14:46] <jdstrand> popey: it figures that as soon as I see my email that there was nothing reported, something was reported
[14:46] <popey> You're welcome. :)
[14:47] <jdstrand> popey: I really don't know anything about build. is it using a new enough snapcraft?
[14:47] <zyga> jdstrand: ack, thank you for the mail
[14:48] <jdstrand> popey: are you doing anything weird like an unsquash/fix something/mksquash?
[14:48] <sparkiegeek> anarcat: look at the --revision flag
[14:49] <cjwatson> jdstrand: hey the snapcraft version is right there in the build log
[14:49] <cjwatson> (though may not be readily linked to from the store I suppose)
[14:49]  * jdstrand doesn't have the build log url
[14:49] <jdstrand> yeah, it isn't yet (that would be great! :)
[14:49] <jdstrand> popey: is this electron-builder?
[14:49] <cjwatson> jdstrand: you can start from https://launchpad.net/~build.snapcraft.io/+snap/7d2139885b31f8fd1187b9d3482243b9-xenial to find this one
[14:50] <popey> jdstrand: no, we dont do anything shonky
[14:50] <cjwatson> jdstrand: but in general, BSI uses whatever's latest in xenial-updates
[14:50] <popey> jdstrand: it's just wine (dumped deb) and another couple of scripts dumped in
[14:51] <anarcat> sparkiegeek: how do i find which revisions are available? info does not say much
[14:51] <zyga> anarcat: you can only refresh to a revision you already have on your system (snap list --all will tell you)
[14:52] <cjwatson> diddledan: so your problem is simply that the URL you're trying to fetch doesn't exist
[14:52] <anarcat> zyga: thanks
[14:52] <cjwatson> diddledan: Downloading https://dl.winehq.org/wine-builds/ubuntu/pool/main/wine-devel_3.9.0~xenial_.deb...
[14:52] <cjwatson> (you get a 200 from the CONNECT and then a 404 from the underlying tunnelled protocol; that confused me for a while)
[14:52] <diddledan> o_O
[14:52] <mvo> cachio: can you point me to the snapcraft.yaml for the rsync snap please?
[14:53] <mvo> cachio: nevermind, just found it
[14:53] <diddledan> oooh. running locally sets $SNAP_ARCH, but for some reason that's not there in the buildd...
[14:53] <cachio> mvo, ok
[14:53] <cachio> it is in snapd repo
[14:53] <sparkiegeek> cjwatson: nice spot
[14:53] <anarcat> uh
[14:53] <cjwatson> diddledan: probably because you're using snapcraft as a snap
[14:53] <mvo> cachio: yeah, thanks, I will build a core18 version of this :)
[14:53] <anarcat> so this never worked apparently
[14:54] <cachio> mvo, great, thanks
[14:54] <cjwatson> diddledan: it's the snap execution path that sets SNAP_ARCH, so that's really the wrong variable to use here
[14:54] <cjwatson> (I'm not sure exactly what would be correct)
[14:54] <sparkiegeek> anarcat: the other possibility is that changes in core could have affected it, so might be worth jumping back to latest firefox and walking back through core versions
[14:54] <cjwatson> maybe just $(dpkg --print-architecture) ?
[14:55] <anarcat> or at least it's not a firefox-induced regression: i can't make it work with any snap i have on disk (60.0, 60.0.1, 60.0.2)
[14:55] <anarcat> i wonder if i had that working with 59
[14:55] <anarcat> sparkiegeek: ah yes, i could try the revert trick with core?
[14:55] <sparkiegeek> anarcat: yes
[14:55] <anarcat> is there a way to see which updates took place when? "logs" and "changes" doesn't show anything useful
[14:56] <diddledan> thanks for spotting that :-)
[14:57] <anarcat> hahaha reverting core to 16-2.32.6 breaks all font display whee!
[14:57] <anarcat> wow, blocky hell
[14:59] <anarcat> well shit - i think i had that problem before, but i don't remember how i solved it
[14:59] <anarcat> http://paste.anarc.at/snaps/snap-2018.06.14-10.59.05.png
[14:59] <anarcat> boom ^
[14:59] <sparkiegeek> anarcat: ... nice
[15:00] <anarcat> yeah
[15:00] <anarcat> so that was triggered by reverting core from 16-2.32.8 to 16-2.32.6
[15:00] <anarcat> i tried reverting back to 16-2.32.5 as well, no dice, and then reverting *forward* to 16-2.32.8 does not fix the issue
[15:00] <anarcat> and also, none of the core versions fix the u2f issue either
[15:01] <cjwatson> diddledan: np
[15:02]  * diddledan goes to sit in the corner with the cone-shaped hat with a big "D" written on it
[15:02] <cjwatson> diddledan: FWIW it might help if you used wget --no-verbose rather than wget --quiet
[15:02] <cjwatson> --quiet turns off all output, including errors
[15:02] <diddledan> http://static.tvtropes.org/pmwiki/pub/images/dunce_hat.jpg
[15:02] <cjwatson> so it's pretty unhelpful in this kind of situation
[15:03] <cjwatson> --no-verbose means you get one line of output in the successful case, and something useful in the error case
[15:03] <popey> jdstrand: oddly a later build worked fine!?
[15:04] <anarcat> sparkiegeek: any other suggestions?
[15:05] <sparkiegeek> anarcat: are you back to sensible fonts on latest core/firefox ?
[15:06] <anarcat> sparkiegeek: nope
[15:06] <anarcat> sparkiegeek: i'm trying to remove and reinstall FF now
[15:06] <diddledan> I just got a checksums don't match, popey , jdstrand
[15:06] <anarcat> i think it's what fixed it the last time
[15:06] <diddledan> same, normal build on BSI
[15:06] <anarcat> well that's one frustrating day
[15:09] <jdstrand> diddledan: what is the snap?
[15:10] <diddledan> https://build.snapcraft.io/user/diddledan/gog-galaxy-wine-snap/
[15:11] <diddledan> gog-galaxy-wine
[15:12] <cjwatson> jdstrand: https://launchpad.net/~build.snapcraft.io/+snap/be52b943c0d4d977217aac0ad5a8ad1c-xenial/+build/249197 is an affected build
[15:12] <cjwatson> snapcraft 2.42.1 says the build log
[15:12] <cjwatson> I don't really know the toolchain here but let me know if it looks as though LP is doing something wrong here
[15:13] <anarcat> aaand remove + install fixed the blocky font problem
[15:14] <jdstrand> cjwatson: yes, thank you
[15:15] <jdstrand> popey: that sounds like there is still a lurking timestamp issue
[15:15] <jdstrand> as in, the resquash takes too long and the timestamps are different in the resquashed snap
[15:16] <popey> Sounds plausible.
[15:16] <anarcat> sparkiegeek: sigh... and core 16-2.32.5 still exhibits the same u2f problem
[15:17] <jdstrand> it is weird that this has been enabled for 4 days and today is the first it is reported
[15:17] <cjwatson> wait, you're relying on the unsquash/resquash all happening within the same second or something?
[15:17] <cjwatson> have you considered using faketime?
[15:17] <jdstrand> cjwatson: obviously we shouldn't be. I'm speculating there is a bug
[15:17] <anarcat> testing this is excruciating: i need to revert, uninstall firefox, reinstall firefox, for every iteration
[15:17]  * cjwatson nods
[15:18] <jdstrand> cjwatson: squashfs-tools has not been super friendly for us. it would, for example, recreate symlinks during resquash with the current time rather than what was in the inode in the squash.
[15:19] <cjwatson> helpful
[15:19] <jdstrand> cjwatson: I'm suspecting something else in there. faketime is an interesting option I'll look into
[15:19] <jdstrand> indeed
[15:20] <jdstrand> roadmr: please disable resquashfs
[15:20] <roadmr> jdstrand: on it
[15:20] <roadmr> jdstrand: done
[15:22] <pedronis> a 2nd review of #5328 would be nice, it's small and only test code
[15:22] <mup> PR #5328: snapstate: stop using evolving SnapSpec internally, use an internal-only snapSpec instead <Simple> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5328>
[15:25] <zyga> pedronis: done
[15:25] <jdstrand> roadmr: thanks
[15:25] <jdstrand> popey, diddledan: your next uploads should work
[15:25] <pedronis> zyga: thx
[15:25] <diddledan> thanks :-)
[15:25] <popey> thanks jdstrand
[15:30] <mborzecki> pedronis: thanks for the review, i'll try to push an update soon so that we could probably land the branch sometime tomorrow if there are no more issues
[15:33] <jdstrand> diddledan: interesting:
[15:33] <jdstrand> -drwxrwxrwt root/root                 3 2018-03-07 04:41 squashfs-root/var/spool/samba
[15:33] <jdstrand> +drwxrwxrwx root/root                 3 2018-03-07 04:41 squashfs-root/var/spool/samba
[15:33] <jdstrand> diddledan: your snap had a sticky dir and the resquash did not
[15:33] <jdstrand> I'll look into that
[15:38] <jdstrand> curious, same with tmnationsforever
[15:38] <jdstrand> -drwxrwxrwt root/root                 3 2018-03-07 04:42 squashfs-root/var/spool/samba
[15:38] <jdstrand> +drwxrwxrwx root/root                 3 2018-03-07 04:42 squashfs-root/var/spool/samba
[15:38] <diddledan> tmnations is built using a very similar set of packages
[15:39] <pedronis> mborzecki: ok, added another small comments about a TODO
[15:39] <mborzecki> pedronis: thanks
[15:39] <mborzecki> pstolowski: current master failed with econnreset :P
[15:39] <pstolowski> noooo
[15:39] <jdstrand> it is weird that a subsequent build would produce different results for tmnationsforever
[15:39] <pstolowski> damn
[15:40] <mborzecki> pstolowski: https://travis-ci.org/snapcore/snapd/builds/392288895?utm_source=email&utm_medium=notification
[15:40] <jdstrand> well, it could be an overflow or something in squashfs-tools. anyway, I'll look into it
[15:40] <cjwatson> sergiusens: not quite transparent proxy, just transparent handling of authentication
[15:41] <cjwatson> sergiusens: I wouldn't rip out the proxy user/pass handling from snapcraft 'cause it is technically correct, but it should put less pressure on that to be absolutely correct
[15:42] <mborzecki> pstolowski:what if we could simulate network issues by using a proxy instead?
[15:44] <pstolowski> mborzecki: same story.. download request is happy after 1st attempt and we proceed with fetching assertions.. which fail and are retried as expected. but the test expects download to fail and be retried
[15:45] <pstolowski> mborzecki: we could i guess, but there must be an explanation..
[15:45] <mborzecki> pstolowski: is it using fakestore?
[15:46] <pstolowski> mborzecki: no
[15:46] <mborzecki> pstolowski: what if it used, and we add some error injection contraption to it?
[15:47] <mup> PR snapd#5328 closed: snapstate: stop using evolving SnapSpec internally, use an internal-only snapSpec instead <Simple> <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5328>
[15:48] <mborzecki> pstolowski: https://github.com/tylertreat/comcast https://github.com/shopify/toxiproxy both are written in (surprise, surprise) Go
[15:48] <pstolowski> mborzecki: we could, but current approach should work too :/
[15:52] <pstolowski> i don't know.. maybe gcloud is actually so crazy fast sometimes that it manages to download entire huge test snap before we apply iptables rule and download simply succeeds? fwtw i saw this download completed in ~10s when i executed download manually on gcloud spread machine
[15:52] <pstolowski> with ~10s it would be too slow and the test would do the right thing.. but maybe it's faster sometimes
[15:52] <pstolowski> dunno
[16:04] <sergiusens> cjwatson: no worries, we cannot remove it as we have known instances of people depending on them; but it does put us in a position where we need to solve specific use cases only
[16:04] <mborzecki> is github slow for anyone else too?
[16:08] <mborzecki> pedronis: https://github.com/snapcore/snapd/blob/master/asserts/device_asserts.go#L218 is this where we'd check for valid snap names in model assertion?
[16:39]  * zyga takes a break for an hour, no biking this time, just coffee and a new book
[16:40] <zyga> I need to vent my mind and rest for a while
[16:40] <zyga> after that I'm back to system slots mvo :)
[16:43] <zyga> jdstrand: thank you for the review on 5081
[16:43] <zyga> I agree with everything but one remark about having enough data to pick * vs */
[16:43] <zyga> perhaps I didn't understand you there
[16:44] <zyga> if you don't have time to see my comment there before your holidays then don't worry, I will improve the comments and land and we can polish this more after you return
[16:44] <zyga> I will now use this to construct apparmor permissions for mimics and this will fix one of the two remaining layout bugs :)
[16:46] <pedronis> mborzecki: yes
[16:47] <mborzecki> pedronis: ack, looks like a 3rd (or 4th?) copy of snap.ValidateName()
[16:47] <mborzecki> pedronis: anyways, added a todo note and pushed everything to github
[16:47] <pedronis> mborzecki: maybe, anyway, yes for now a todo is ok
[16:48] <pedronis> mborzecki: also I put some notes in the topic as well, don't know if you saw those
[16:49] <mvo> zyga: ta
[16:50] <mborzecki> pedronis: yup seen those, thanks for posting them
[17:13] <niemeyer> pedronis, Chipaca: Here are some notes from today's call:
[17:13] <niemeyer> https://forum.snapcraft.io/t/possible-evolution-path-for-snap-store-endpoints-regarding-epoch/5871/5
[17:15] <cjwatson> kyrofa: https://code.launchpad.net/~cjwatson/launchpad/snap-parse-architectures/+merge/347998 FYI
[17:15] <niemeyer> "On Tuesday, June 12, we incorrectly sent you an email stating that your billing account had been terminated for non-payment. No action is required on your part, and there has been no change to your active billing accounts. This email was sent in reference to billing accounts that had already been terminated."
[17:16] <cjwatson> kyrofa: initial work, more to come, but this is what integrates your code most directly
[17:16] <niemeyer> <3
[17:16] <niemeyer> GCE
[17:31] <kyrofa> Ah, cjwatson, awesome!
[17:34] <kyrofa> Looks like I didn't quite get the python2 compatibility I was hoping for judging from the changes-- not too bad I hope?
[17:34] <cachio> Chipaca, hey, there is a comment on #5242
[17:34] <mup> PR #5242: tests: new test for joystick interface <Reviewed> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5242>
[17:35] <Chipaca> cachio: hey
[17:35] <Chipaca> cachio: me?
[17:35] <cachio> it needs your opinion
[17:35] <cachio> Chipaca, yes
[17:35] <Chipaca> ah, seen it now
[17:36] <Chipaca> cachio: replied
[17:37] <Chipaca> cachio: we've not done that work yet, so it's still the only way to do it
[17:37] <mvo> zyga: progress on 5324 - with that I managed to run a trivial core18 spread test on a real(ish) core18 image
[17:37]  * mvo calls it a day with that success
[17:40] <cachio> Chipaca, great, thanks!!
[17:41] <cachio> mvo, congrats
[17:46] <niemeyer> mvo: \o/
[17:57] <cachio> mvo, is it possible to run the snapd suite?
[18:14] <mup> PR snapcraft#2160 opened: many: refactor snapcraft.yaml loading out of load_config <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2160>
[18:14]  * Chipaca EODs, for great justice
[18:28] <mup> PR snapd#5329 opened: DON'T REVIEW: tests: Adding debug information to know why econnreset is failing <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5329>
[18:33] <cjwatson> kyrofa: very minor unicode_literals handling, but nothing serious
[18:48]  * cachio afk
[18:58] <cjwatson> kyrofa: the only really substantive change I made was to allow snaps to declare that they build on architectures that LP doesn't support, which seems wise to me
[19:01] <kyrofa> Indeed, I suppose that makes sense
[20:58] <bdx> having a bit of an issue with python deps showing up for packages that define #/usr/bin/env python3 as their header
[20:58] <bdx> https://paste.ubuntu.com/p/XZnpjyzKbz/
[20:59] <bdx> I cat the gunicorn exe and I think its just getting the wrong env
[20:59] <bdx> https://paste.ubuntu.com/p/zBkpvyRXt7/
[20:59] <bdx> due to the fact that python3.6 is actually what is being used ....
[21:00] <bdx> I'm not really sure what exactly is going on .... last time I built this snap everything checked out but that was a few months ago, and on xenial
[21:01] <bdx> but now, following a build/install of the snap it seems packages are borked because of the env possibly
[22:13] <bdx> oh man ... I was so turned around ... pretty sure I've found my way
[22:46] <binarycreations> Oh man, I do not know what I am doing wrong...
[22:47] <binarycreations> This is my first attempt at creating a snap. I am trying to snap the anki desktop client.
[22:47] <binarycreations> A gist of my snapcraft.yaml is available (https://gist.github.com/binarycreations/3991eba94a9dc78bb9ee1e3d66168e88)
[22:48] <binarycreations> I am building my snap in a 16.04 Ubuntu VM using Vagrant so it is the server version of Ubuntu
[22:48] <binarycreations> I then run the snap on my host which is Arch Linux
[22:49] <binarycreations> They problem that I seem to have is, whilst the downloaded anki binary works fine on my host within the VM and snap I get a error from anki stating it can't find or load the libfontconfig.so
[22:53] <ondra> niemeyer ping
[22:54] <binarycreations> Is that an indication of a missing package? (i.e. I should find the package that includes that linked library in the stage-build)
[22:54] <binarycreations> Is it due to the fact I am trying to build and run a snap on Ubuntu Server, where the app requires Ubuntu Desktop (as in an X server and other related dependencies that would be detected by ldd and added to the snap?)
[22:57] <niemeyer> ondra: Hey
[22:57] <ondra> niemeyer hey
[22:57] <ondra> niemeyer  do we have interface, something like light weight content interface, which would allow one snap to change configuration of another snap?
[22:58] <niemeyer> binarycreations: The forum is generally a better place for those discussions as it allows people to respond at the best time for them without you having to wait here and without the conversation scrolling off
[22:59] <binarycreations> Okay, cool. I drop another question on there.
[22:59] <niemeyer> ondra: Not anything built-in that would allow the equivalent of "snap set" across snaps.. we did discuss something like that a while ago, but only lightly
[22:59] <niemeyer> ondra: I think it'd make sense to eventually have that as a proper mechanism
[22:59] <ondra> niemeyer agree
[23:00] <ondra> niemeyer I will kick off forum post about it to start gathering context
[23:00] <niemeyer> ondra: Sounds good, thank you
[23:01] <niemeyer> ondra: I think it can literally be some kind of interface that would enalbe "snapctl set" to take an extra argument with a snap name
[23:01] <niemeyer> ondra: We'd condition that to only work if the interface is connected
[23:01] <niemeyer> ondra: and we might allow auto-connection if both snaps are from same publisher, similar to how we do the content interface
[23:02] <niemeyer> ondra: I mean, by default.. we'd also allow auto-connection after manual reviews as usual
[23:02] <ondra> niemeyer but wouldn't you want to limit this between snaps A->B? Or you are thinking to have ability to configure all snaps?
[23:02] <ondra> niemeyer yeah
[23:02] <ondra> niemeyer sorry I misunderstood, so between defined snaps
[23:03] <niemeyer> ondra: We need to think carefully.. but I think we have some good precedence in the content interface.. the issues are very similar, even if the actual "API" is different
[23:03] <ondra> niemeyer yep
[23:04] <ondra> niemeyer one can go crazy there and start defining per config keys, but I do not thing we need that fine control
[23:05] <ondra> niemeyer I will kick of forum post and let's continue there
[23:05] <niemeyer> ondra: We still want to have schemas for the configuration, as a general feature.. we might eventually hook the two things together and allow partial access to a configuration via the schema.. but agreed, that's future
[23:05] <niemeyer> ondra: Thanks
[23:06] <ondra> cool
[23:51] <mup> PR snapcraft#2161 opened: many: automatically detect dependency changes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2161>