[00:37] <nacc> hrm, why did my snap that just built get a version of 0.7.1-dirty? it's building via a LP build recipe and when I built the 0.7 version it built fine (as 0.7)
[00:41] <nacc> it also blew up by 10 M when it shouldnt' have
[00:49] <nacc> i dont' understand how snapcraft would ever emit a -dirty version for a git repo
[00:50] <nacc> seems like something is busted
[00:54] <nacc> and uh, like half my parts didn't build?
[00:55] <nacc> did something happen to change on LP between the two runs I just did?
[00:58] <nacc> cjwatson: --^ you may have some idea (i assume you're not around now, but maybe you would be later)
[01:09] <kyrofa> wgrant, same thing happened again with rev 5445 of nextcloud, blocking reviews again :(
[01:12] <wgrant> kyrofa: afk atm, will look in more depth when I'm back
[01:13] <wgrant> nacc: nothing's changed in LP there recently. compare logs?
[01:13] <nacc> wgrant: yeah i'll have to -- makes no sense
[01:13] <nacc> a build an hour ago worked fine
[01:23] <stgraber> hmm, why is s390x snap builds broken now?
[01:23] <stgraber> "Could not find a required package in 'build-packages': patchelf"
[01:23] <stgraber> it's not something the LXD snap itself is using, so wondering if snapcraft got updated and is unhappy on z somehow?
[01:24] <stgraber> hmm, or is it an external parts that's broken maybe? /me checks
[01:25] <stgraber> hmm, nope, doesn't appear to be coming from lxd or from the one external part we're using (go)
[01:25] <stgraber> sergiusens: ^ any ideas?
[01:26] <sergiusens> stgraber: oh, this is unfortunate, I'll have to propose a fix for that
[01:26] <stgraber> sergiusens: is that going to affect all s390x builds? if so, that's a bit of a problem :)
[01:27] <sergiusens> we don't have good testing infra for z to actually notice in this unfortunately
[01:27] <sergiusens> yes
[01:27] <sergiusens> stgraber: do you have a way test snaps on s390x builds?
[01:28] <stgraber> sergiusens: I have s390x systems, yeah
[01:30] <sergiusens> stgraber: lucky you; it is kind of late here, but I'll work on a quick fix tomorrow morning; if you are really in a hurry, I guess we can ask for a revert of the SRU
[01:31] <stgraber> sergiusens: is that an option for you? (revert)
[01:32] <stgraber> if so, I can do it pretty trivially using a cheap revert method, so not uploading a reverted package (because that makes the versioning crazy) but just remove the current SRU and publish the previous one again
[01:33] <sergiusens> stgraber: I can push a version that potentially fixes this, it is one line of code
[01:33] <stgraber> sergiusens: ah, give me a diff and I can test it for you
[01:36] <sergiusens> stgraber: http://paste.ubuntu.com/p/sc9TfT5sCG/
[01:37] <sergiusens> stgraber: in retrospect this could have been an arch specific Depdends :-/
[01:37] <stgraber> ok, that got me past the error, will see if the rest works, but it should
[01:38] <stgraber> sergiusens: do you have upload rights to push that or should I do it?
[01:38] <sergiusens> stgraber: I do; your snap is not classic so it should just work
[01:39] <stgraber> sergiusens: ok, if you upload a fix I can let it in and then push it straight to -updates once it's built
[01:40] <sergiusens> ok, one sec
[01:45] <sergiusens> stgraber: before dputting, care to corroborate this https://paste.ubuntu.com/p/VydCV8ssZr/
[01:46] <stgraber> sergiusens: LGTM
[01:48] <sergiusens> stgraber: awaiting approval
[01:49] <stgraber> accepted
[01:49] <stgraber> will wait for it to build and publish, then will release it into updates
[01:50] <sergiusens> stgraber: great thanks
[01:50] <sergiusens> stgraber: also, most of all, sorry for all of this; I think we should talk about this next week
[01:53] <stgraber> sergiusens: I thought that snapcraft had an autopkgtest suite, shouldn't that have caught it on s390x?
[01:54] <stgraber> and no worries, it's an easy enough fix, it's just a bad time for us as we're moving a lot of stuff around and are about to release betas for all our repos so want to make sure everything builds properly everywhere as we do that :)
[02:20] <sergiusens> stgraber: hey, sorry, dozed off for a bit, long day. We do have tests, but most of the things we build has always been red on s390x (we need to scope it down with some skips, but the release team preferred that we slowly fixed them)
[02:20] <sergiusens> I am heading out, if it still doesn't work, feel free to go ahead and revert
[02:24] <nacc> wgrant: i think it's the snapcraft SRU
[02:24] <nacc> totally broke my snap :/
[02:27] <nacc> wgrant: yeah ,i think my system at home hasn't received the update yet (nor has our CI based builds) so it isn't breaking, but ftpmaster.internal had
[02:27] <nacc> stgraber: --^ i guess sinc eyou were looking at it, something to worry about
[02:28] <nacc> classic snap that is not dirty is getting marked as -dirty and the python plugin behavior has apparently changed (at a minimum)
[02:31] <wgrant> nacc: Ah, ouch.
[02:36] <nacc> wgrant: i'm fairly sure, at least. I think I just happened to hit a weird window on ftpmaster
[02:59] <wgrant> nacc: Yeah, totally makes sense.
[03:07] <wgrant> kyrofa: Another compute node reboot semi-broke snap storage again, fixing.
[03:11] <stgraber> nacc: hmm, odd, something to look at after the s390x fix I guess
[03:14] <stgraber> nacc: lxd doesn't seem to hit that -dirty issue somehow
[03:32] <nacc> stgraber: it's not a classic snap is it?
[03:32] <nacc> i wonder if it only is hitting classic somehow
[03:32] <nacc> LP: #1752481 filed
[03:32] <mup> Bug #1752481: Regressions in 2.39.2 in xenial-updates in classic snaps (relative to 2.35) <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1752481>
[03:41] <stgraber> nacc: yeah, lxd is strictly confined
[05:30] <nacc> wgrant: hrm, are reviews backed up again? I have a few git-ubuntu ones that seem to be queued for longe rthan ormal
[05:31] <nacc> intersting LP reports that as a store upload failed, although the store found it
[05:31] <nacc> https://launchpad.net/~usd-import-team/+snap/git-ubuntu/+build/158161
[05:31] <nacc> (i rejected it manually)
[05:32] <nacc> oh nm, that one went through
[05:34] <wgrant> nacc: Things are a bit sluggish atm but should work
[05:35] <nacc> wgrant: ack, it does seem to be going through (the auto uploads from LP were hung, but i rejected those and the one i manually built was able to release)
[05:35] <wgrant> nacc: Ah yeah, looks like the stuck upload was 4h ago when things were still rather sad.
[05:36] <wgrant> Rebooting 100 different parts of a system at 100 different times over two weeks exposes some amusing issues
[05:36] <wgrant> Some of which we knew about, but a couple of which we didn't...
[05:53] <nacc> wgrant: ack, np!
[06:14] <happyaron> hi, is there a plan to review classic confinement requests?
[06:15] <mborzecki> morning
[06:17] <zyga> good morning
[06:17] <mborzecki> zyga: hey
[06:18] <zyga> hey :-)
[06:18] <zyga> -14 still
[06:18] <zyga> *brr*
[06:18] <zyga> man, I'm looking forward to any positive temperatures
[06:18] <zyga> even if +1
[06:21] <mborzecki> zyga: https://images.meteociel.fr/im/132/tempresult_ciz8.gif
[06:22] <zyga> I could look at that all day :)
[06:24] <keshav> hello people
[06:24] <zyga> hey hey
[06:24] <keshav> hi zyga
[06:24] <keshav> am bulldog
[06:24] <keshav> am having an issue
[06:24] <keshav> am snapping an app and its not getting its desktop entry in unity menu or any other app launcher
[06:25] <keshav> @zyga my snapcraft.yaml https://paste.ubuntu.com/p/Z727mQ4B9s/
[06:26]  * zyga honestly doesn't remember how to do desktop files
[06:26] <zyga> I know how they have to be after building
[06:26] <zyga> but I don't remember how to them in snapcraft
[06:26] <zyga> let me look
[06:26] <keshav> my .desktop file is under snap/gui with an icon
[06:27] <keshav> okay i appriciate
[06:27] <zyga> question: what happens after you build?
[06:27] <zyga> where is the destkop file relative to the top level directory of the snap
[06:27] <zyga> I found: https://github.com/ubuntu-core/snapcraft-examples/tree/master/03-hello-world-desktop-devmode
[06:28] <keshav> after install or while building snap ?
[06:28] <zyga> it has an app "hello-world-desktop" that matches the desktop file
[06:28] <zyga> after you finish building
[06:28] <zyga> what is in the prime/ directory
[06:28] <zyga> (I mean, what are the paths of .desktop files relative to the prime directory)
[06:28] <keshav> okay wai t
[06:28] <zyga> ok
[06:29] <keshav> inside setup/gui and snap/gui
[06:29] <keshav> also in meta/gui
[06:29] <zyga> ok
[06:29] <zyga> that looks good
[06:30] <keshav> yeah but after installing the app gets no entry in menus
[06:30] <zyga> ok
[06:31] <zyga> after installing look at /var/lib/snapd/desktop/applications
[06:31] <zyga> do you see your launcher there?
[06:31] <zyga> if so, look inside, does it have the Exec= line?
[06:31] <keshav> wait bro
[06:32] <keshav> nah no exec line is there
[06:33] <zyga> ok
[06:33] <zyga> that means the exec line was incompatible with the snap
[06:33] <zyga> and that's why you cannot launch it from the menu
[06:33] <zyga> what was the original exec line?
[06:33] <zyga> (in setup/gui)
[06:33] <keshav> okay wait
[06:34] <keshav> Exec=Kdictionary %F
[06:34] <zyga> ok, please change that to match your snap name
[06:34] <zyga> K is upper case, I suspect that's why it is being filtered out
[06:34] <keshav> damn
[06:34] <keshav> okay let me check bro
[06:34] <keshav> you are very helpful all the time
[06:36] <keshav> zyga all this need to be documented in snapcraft.io
[06:36] <zyga> no disagreement there
[06:43] <keshav> it working now
[06:43] <keshav> ty very much man
[08:08] <pstolowski> heyas
=== ubott2 is now known as ubottu
[08:09] <kalikiana> moin moin
[08:09] <zyga> hey hey
[08:09] <mborzecki> pstolowski: kalikiana: hey
[08:12] <mvo> hey pstolowski - good morning
[08:12] <mborzecki> mvo: hey
[08:13] <mborzecki> https://github.com/snapcore/snapd/pull/4769 needs a second look
[08:13] <mup> PR #4769: wrappers: detect whether systemd-analyze can be used in unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4769>
[08:20] <mup> PR snapd#4769 closed: wrappers: detect whether systemd-analyze can be used in unit tests <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4769>
=== LtWorf_ is now known as LtWorf
[08:47] <zyga> mvo do you have time for a 2nd review now?
[08:50] <ackk> kalikiana, so, it seems snapcraft lost the ability of building on different bases (as specified by the app's base attribute). Or is there a different way to do that now?
[09:00] <Chipaca> hah! be careful how you write "is this number is smaller than -1" in go or it'll get really grumpy
[09:00] <Chipaca> and good morning
[09:00] <zyga> good morning! :)
[09:00] <Chipaca> (and because you're thinking "smaller than -1" it'll take you a while to understand)
[09:01] <kalikiana> ackk: There's no such ability. Unless you're talking about Snapcraft's patching libraries to make them compatible with the target
[09:02] <kalikiana> ackk: That is, you can build on different hosts, but there is no explicit support for building against a different base (yet)
[09:02] <kalikiana> Chipaca: Do you have an example of that?
[09:03] <kalikiana> Like, what do you mean by grumpy
[09:03] <Chipaca> kalikiana: if d<-1 { println("smaller!") }
[09:04] <zyga> Chipaca so what's the catch?
[09:04]  * Chipaca giggles
[09:04] <Chipaca> it's funny how the brain works
[09:05] <Chipaca> zyga: kalikiana: <- is an operator
[09:05] <zyga> is d a channel? :D
[09:05] <zyga> btw, I really wished go used <= for that
[09:05] <zyga> <=shove=
[09:05] <zyga> =yank=>
[09:05] <zyga> <=poem=
[09:06] <Chipaca> zyga: ⇜
[09:06] <mborzecki> <~ ~>
[09:06] <zyga> gotta have your trigraphs
[09:06] <ogra_> mvo, the nightly core snap builds failed on all arches with a weird error (and i'm at embeddedworld, can't research atm) ... https://launchpadlibrarian.net/359032850/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
[09:06] <ogra_> OSError: [Errno 6] No such device or address: '/build/core/prime/dev/dsp2'
[09:06] <ogra_> Build failed
[09:06] <Chipaca> ogra_: oh hi
[09:06] <ogra_> (or zyga if you feel like looking ... )
[09:07] <zyga> hmm hmm
[09:07] <ogra_> hey Chipaca
[09:07] <zyga> hey ogra_, this doesn't ring a bell immediately
[09:07] <ogra_> (this error is seriously weird)
[09:07] <Chipaca> ogra_: I had a question for you, but then realised it's probably for mvo :-)
[09:07] <Chipaca> about tweaking a file on core
[09:07] <ogra_> heh
[09:07] <mvo> zyga: right now I'm working on apt :/
[09:08] <mvo> Chipaca: ok
[09:08] <mborzecki> hey Chipaca, ARS is a really unfortunate abbreviation for a timezone
[09:08] <zyga> kalikiana why does snapcraft want to open /dev/dsp2?
[09:08] <mvo> ogra_: hm, sounds like a test misbehaving
[09:08] <kalikiana> Chipaca hot damn, I did not see that. the thought that the 1 is not assumed to be a number... I guess that's where the parser is either too smart or not enough
[09:08] <zyga> if it is a device
[09:08] <zyga> this is coming from internal/elf.py
[09:08] <Chipaca> mborzecki: :-)
[09:08] <zyga> looks like a bug in snapcraft elf resolver
[09:09] <zyga> hey mvo, no worries :)
[09:09] <pstolowski> zyga, i had another layout test failure on 4358 (but it was run yesterday in the afternoon)
[09:09] <mvo> ogra_: aha, no - its our "fault"
[09:09] <zyga> Chipaca maybe you can do a 2nd review instead of mvo
[09:09] <mvo> ogra_, kalikiana I think the problem is that in "core" we ship some device files
[09:09] <ogra_> Chipaca, either in  https://github.com/snapcore/core-build/tree/master/config (needs a release of the deb to the PPA after committing) or via live-build hooks https://github.com/snapcore/core/tree/master/live-build/hooks
[09:09] <zyga> pstolowski do you remember what the error was
[09:09] <ogra_> well, debootstrap creates a populated /dev ...
[09:09] <zyga> I just merged a helper that will give us more debug data in such cases
[09:09] <ogra_> but it always did that
[09:10] <mvo> ogra_, kalikiana which we need for booting, snapcraft should just put them into the snap without trying to be smart and open them etc
[09:10] <zyga> ogra_ yeah, it looks like a snapcraft change
[09:10] <ogra_> ah
[09:10] <ogra_> yeah, that makes sense
[09:10] <pstolowski> zyga, cannot update snap namespace: cannot create writable mimic over "/etc": no such file or directory
[09:10] <mup> PR snapd#4773 closed: tests: add debug for layout test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4773>
[09:10] <pstolowski> zyga, https://api.travis-ci.org/v3/job/347256945/log.txt
[09:10] <Chipaca> ogra_: ack, i'll have a chat with em vee oh after things have frozen (i'm staying out of his path today)
[09:10] <zyga> pstolowski hmm hmm
[09:10] <zyga> thank you
[09:10] <pstolowski> zyga, snap-update-ns failed with code 1: File exists
[09:10]  * ogra_ goes back to booth duties (students-day here today ... will be crowded)
[09:10] <zyga> pstolowski I *bet* our test suite is broken
[09:10] <zyga> pstolowski as /etc doesn't just go away
[09:11] <zyga> let's hope we learn some more from debug data
[09:17] <zyga> Chipaca so about that review, maybe you want to look at 4760
[09:17] <zyga> it's not long really, a chunk of file got moved
[09:17] <Chipaca> zyga: will do
[09:17] <zyga> and a few bits got added to other places
[09:17] <Chipaca> wrapping up an edit here and will do
[09:18] <zyga> I'm pushing this as it is 2.32 material
[09:18] <zyga> and EOUTATIME
[09:18] <ackk> kalikiana, I'm building a base-18 snap on bionic
[09:20] <ackk> kalikiana, but it seems there' an hardcoded "core" mention in the code
[09:20] <ackk> kalikiana, BjornT was able to get it to work with this change: https://paste.ubuntu.com/p/s2t3wct5J3/
[09:20] <ackk> I mean, managed to build the snap, but then it seems there are missing libraries
[09:20] <ackk> and LD_LIBRARY_PATH is not set
[09:24] <Chipaca> zyga: looking
[09:24] <zyga> Thank you!
[09:26] <Chipaca> zyga: 4760, per-snap profiles?
[09:26] <zyga> yes
[09:30] <kalikiana> ackk: Perhaps you can file a bug with some context? I fear this is getting lost in IRC backlog otherwise.
[09:31] <ackk> kalikiana, sure
[09:33] <Chipaca> zyga: can you explain the 'per-snap' comments?
[09:33] <zyga> yes
[09:33] <Chipaca> good :-)
[09:33] <Chipaca> please do?
[09:33] <zyga> those are places that can benefit from per-snap paths instead of globs
[09:33] <zyga> so instead of /snap/*/**
[09:34] <Chipaca> ?
[09:34] <zyga> we can say /snap/$SNAP_NAME/**
[09:34] <Chipaca> /snap/thesnap/*8
[09:34] <Chipaca> yeah
[09:34] <zyga> and expand the variable
[09:34] <zyga> yep
[09:34] <zyga> I'm doing that in subsequent branches though
[09:34] <zyga> it's going to be a while
[09:34] <zyga> and it's tricky
[09:34] <Chipaca> k
[09:34] <Chipaca> ah!
[09:34] <Chipaca> i figur he wrote the shorter per-snap ones after writing the longer one :-)
[09:35] <Chipaca> zyga: branch looks fine, and jdstrand is awesome
[09:35] <zyga> Indeed :)
[09:35] <Chipaca> i'm reminded what a privilege it is for us to have him on team
[09:35] <Chipaca> zyga: is there any reason we aren't using templates for the templates?
[09:35] <zyga> legacy
[09:35] <zyga> one change at a time perhaps
[09:36] <zyga> this is very very old code now
[09:36] <Chipaca> zyga: ok, fair
[09:36] <zyga> I would love to get rid of ###SNAP_NAME### though
[09:36] <zyga> it's just weird
[09:36] <zyga> but predictable :)
[09:36] <Chipaca> +1, and +1 on one-change-at-a-time
[09:36] <zyga> thank you!
[09:36] <Chipaca> when the churn dies down a little maybe we can look at switching them to templates
[09:36] <Chipaca> but no hurry; this works
[09:36] <zyga> yeah, I'd like that
[09:37] <zyga> and unify the interface code with the same means of replacing text
[09:37] <zyga> we have a few weird conventions now with ###FOO### @@FOO@@ or {{foo}}
[09:38] <mborzecki> pstolowski: since you reviewed timer services before, can you take a look at https://github.com/snapcore/snapd/pull/4758 ?
[09:38] <mup> PR #4758: wrappers, tests/main/snap-service-timer: restore missing commit, add spread test for timer services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4758>
[09:38] <mup> PR snapd#4760 closed: many: generate and use per-snap snap-update-ns profile <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4760>
[09:40] <pstolowski> mborzecki, sure
[09:43] <Chipaca> go 1.10's caching of test results is uncanny
[09:44] <zyga> hmm?
[09:44] <zyga> what's that?
[09:46] <Chipaca> zyga: have /snap/bin/go be 1.10; run tests with it; see it zip through things it's tested that haven't changed
[09:46] <zyga> oh
[09:46] <zyga> that's *neat*
[09:49] <Chipaca> zyga: that's not the neatest bit
[09:49] <Chipaca> zyga: run tests, they pass; change the file, tests fail; edit the file back to what it was. Tests are already cached.
[09:50] <Chipaca> I'm afraid to look where it's caching and how big that cache is, but it's neat
[09:50] <zyga> in the cloud ;-))
[09:50] <mborzecki> iirc it's also running vet under the hood now
[09:51] <Chipaca> zyga: do you remember the name of the property of numbers where if a!=b, a>b or b>a?
[09:51] <Chipaca> mborzecki: and that yes :-)
[09:52] <zyga> hmm, no I don't sorry
[09:55] <zyga> I mean
[09:55] <zyga> Chipaca I can recall papers and who wrote them but I don't know how the term is called
[09:55]  * Chipaca adds a 'go go go go!' label
[10:02] <BjornT> kalikiana, ackk: https://bugs.launchpad.net/snapcraft/+bug/1752538
[10:02] <mup> Bug #1752538: Building snap using base-18 is broken with 2.39 <Snapcraft:New> <https://launchpad.net/bugs/1752538>
[10:22] <zyga> hmm
[10:22] <zyga> I run out of memory during tests
[10:22] <zyga> I'm building a string that's maybe dozen lines long
[10:23] <zyga> WTF?
[10:23] <zyga> on 8GB Vm
[10:23] <Chipaca> zyga: go test -memprofile mem.out
[10:25] <sergiusens> hey zyga, any insight on this one https://bugs.launchpad.net/snapcraft/+bug/1752498 to generate a more thorough response?
[10:25] <mup> Bug #1752498: cleanbuild fails with lxd snap <Snapcraft:New> <https://launchpad.net/bugs/1752498>
[10:25] <zyga> looking
[10:26] <zyga> so, the host is pureos, it uses snaps and has the lxd snap
[10:26] <zyga> and then that runs a xenial container
[10:26] <zyga> and that fails to mount snaps
[10:27] <zyga> do I get that right?
[10:27] <zyga> Chipaca trying
[10:28] <zyga> Chipaca it crashes with OOM and doesn't give me the mem.out file
[10:28] <Chipaca> zyga: go test -memprofile mem.out -timeout <something less than it takes to oom>
[10:28] <Chipaca> (but -memprofile might only work for successful tests, in which case you'll have to do it by hand)
[10:29] <Chipaca> (but try it this way first)
[10:29] <Chipaca> (parenthetical)
[10:29] <zyga> Chipaca it doesn't write the memory profile when a timeout occurs
[10:29] <zyga> I mean, not sure what to do
[10:29] <Chipaca> zyga: it's in a single test that fails, or is it the suite as a whole?
[10:29] <zyga> I don't get an OOM without a trivial loop
[10:30] <zyga> not sure yet
[10:30] <Chipaca> zyga: in the test, or in setupsuite, or in init, start the mem profiler, start a goroutine that sleeps then stops and closes the profiler before it ooms
[10:30] <zyga> running one test doesn't oom
[10:30]  * zyga thinks
[10:31] <Chipaca> in init would work (but tests can't have init? not sure)
[10:31] <zyga> I got something useful now
[10:31] <zyga> filepath.Split is broken? :/
[10:31] <Chipaca> probably not :-)
[10:32] <Chipaca> zyga: but, tell me how you think it's broken :-)
[10:33] <zyga> p is "/snap/vanguard/42/"
[10:33] <zyga> split of p is "/snap/vanguard/42/" ""
[10:33] <zyga> that's ... unexpected
[10:33] <Chipaca> zyga: you need to filepath.Clean it
[10:33] <zyga> yeah
[10:34] <Chipaca> filepath is broken in that half of the things Clean the path unconditionally, half of them break if you don't, and half of them return a Clean path, and half of them don't, and … none of those overlap
[10:34] <Chipaca> i mean, those four sets are different and not complementary
[10:34] <Chipaca> or something
[10:34] <Chipaca> it's a mess
[10:34]  * Chipaca should write a path package that did things properly :-p
[10:35]  * Chipaca is still working on a package that knows how wide something you printed to the terminal was
[10:36] <zyga> woah
[10:36] <zyga> that's silly
[10:36] <zyga> (^H dumb)
[10:36] <zyga> p is "/snap/vanguard/42/usr"
[10:36] <zyga> split of p is "/snap/vanguard/42/" "usr"
[10:36] <zyga> so filepath.Split returns unclean result
[10:36] <zyga> ...
[10:36] <Chipaca> zyga: that's because of the property of Split that the first element will always end in / so that you can + the things together and get the original
[10:37] <Chipaca> I'm not sure how that property is useful though
[10:37] <Chipaca> if you're looping, just lob off the last byte
[10:40] <zyga> yeah, done now
[10:41] <Chipaca> zyga: why were you accumulating in that loop though
[10:41] <zyga> I was doing this...
[10:41] <zyga> https://pastebin.ubuntu.com/p/68f45jQ2tG/
[10:41] <zyga> those are per-snap apparmor rules for snap-update-ns for a single layout line
[10:42] <zyga> I need to give write permissions to all the path segments
[10:42] <zyga> jdstrand ^ FYI, does that look sane>?
[10:42] <Chipaca> quoth the raven, eep
[10:42] <zyga> Chipaca less wildcards :)
[10:43] <Chipaca> zyga: i'm lazy, can you point me to the code that builds / uses this?
[10:43] <Chipaca> zyga: also can you review #4748 :-)
[10:43] <mup> PR #4748: store: don't ask for snap_yaml_raw except on the details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/4748>
[10:43] <zyga> not committed yetr
[10:43] <zyga> https://pastebin.ubuntu.com/p/j8XXgMzct8/
[10:43] <zyga> sure
[10:43] <zyga> I mean, not rocket science
[10:44] <zyga> just very talkative
[10:47] <zyga> Chipaca question about that PR, the filtering out thing I understand, the queryForSnapInfo part I don't
[10:47] <zyga> why is that needed?
[10:48] <Chipaca> zyga: because SnapInfo _does_ want to get the yaml
[10:48] <zyga> no no
[10:48] <zyga> I understand we want it
[10:48] <zyga> just don't understand how the code is laid out to need "snap_yaml_raw" explicitly mentioned in queryForSnapInfo
[10:49] <zyga> I assumed we took all the variables
[10:49] <zyga> so the exception list makes sense
[10:49] <Chipaca> zyga: so, this changes getStructFields to take a list of fields not to look at
[10:49] <zyga>  so the part at line 425 that gets all the things except the yaml, is is fine
[10:50] <Chipaca> zyga: and the default config loads all things except the yaml
[10:50] <Chipaca> zyga: but then we want that field back for snap info
[10:50] <zyga> what is the default?
[10:50] <Chipaca> so, start with the default field list, add yaml
[10:50] <zyga> defaultSnapQuery ?
[10:50] <Chipaca> yes
[10:50] <zyga> where is the logic that says defaultSnapQuery doesn't get the yaml field?
[10:50] <Chipaca> yes, if you expand just above queryForSnapInfo you 'll see it
[10:51] <zyga> yes, I did that
[10:51] <Chipaca> 1 sec...
[10:51] <zyga> I mean, reading this https://github.com/snapcore/snapd/pull/4748/files#diff-1f8872a5d54402aa220c723deb16293cR499
[10:51] <mup> PR #4748: store: don't ask for snap_yaml_raw except on the details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/4748>
[10:51] <zyga> I don't understand why it doesn't ask for the yaml field
[10:51] <Chipaca> zyga: +var detailFields = getStructFields(snapDetails{}, "snap_yaml_raw")
[10:51] <zyga> and detailFields gets copied to Store somewhere?
[10:52] <Chipaca> zyga: that's the default for the config
[10:52] <Chipaca> yes
[10:52] <zyga> ah
[10:52] <zyga> ok, then it makes sense now
[10:52] <zyga> thank you!
[10:52] <Chipaca> i mean, it was meant to be a small refactor
[10:52] <Chipaca> otherwise i'd've gotten rid of the indirection
[10:52] <zyga> it's fine, I just didn't connect the dots
[10:52] <Chipaca> but pedronis is doing a good job of doing exactly that while moving to the new api
[10:52] <Chipaca> so \o/
[10:53] <sergiusens> zyga: you got it right
[10:53] <zyga> sergiusens okay
[10:53] <mup> PR snapd#4748 closed: store: don't ask for snap_yaml_raw except on the details endpoint <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4748>
[10:54] <Chipaca> mborzecki: got a question on #4743 otherwise +1
[10:54] <mup> PR #4743: packaging/arch: sync with snapd/snapd-git from AUR <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4743>
[10:54] <zyga> sergiusens does pop os use our kernel?
[10:54] <Chipaca> also why are we doing this: UNCLEAN="$(git status -s|grep '^??')" || true
[10:54] <zyga> I know it used to be a derivative
[10:54] <Chipaca> that || true
[10:55] <Chipaca> wat
[10:55] <sergiusens> zyga: PopOS? I almost certain it does, cannot say for sure; but this is PureOS
[10:55] <mborzecki> Chipaca: i believe it's to cover the case when it's runnig in a spread test where the sources are packed sans .git directory
[10:55] <zyga> ah
[10:55] <zyga> sorry
[10:55] <zyga> then I don't know why it fails
[10:55] <zyga> maybe the kernel doesn't work with fuse
[10:55] <zyga> someone would have to look at the error messages in the journal
[10:55] <zyga> (the ones from the kernel)
[10:56] <sergiusens> zyga: once you know what it is, would it be wise to add it as a pre-flight check before attempting a `snap install` to even get started?
[10:57] <zyga> hmmm
[10:57] <zyga> no idea
[10:57] <zyga> I mean, we don't check if the kernel can mount squasfs files
[10:57] <zyga> or how such a check would look like
[10:57] <zyga> because the details are burried in kernel config
[10:57] <zyga> and you may not even be able to read that
[10:57] <mup> PR snapd#4758 closed: wrappers, tests/main/snap-service-timer: restore missing commit, add spread test for timer services <go go go go!> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4758>
[10:57] <zyga> (you can squashfs but you cannot read XZ compression, for example)
[10:58] <zyga> and inside a container it gets even more complex as you need FUSE and helpers
[10:58] <Chipaca> mborzecki: yeah, just that the construction is super weird (and makes you really think about whether UNCLEAN is bound if the git fails)
[10:59] <Chipaca> mborzecki: (but this itself wasn't a comment on your PR)
[11:01] <Chipaca> mborzecki: also, I'd love to know why ${foo=} even works
[11:03] <mborzecki> Chipaca: that's supposed to be the default value, if my memory serves me right the : in := is optional, but i might be wrong :)
[11:03] <mborzecki> let me check bash manpage :)
[11:03] <Chipaca> empirically yes
[11:03] <Chipaca> but the manpage doesn't say the : is optional
[11:04] <Chipaca> and i'd never seen this usage
[11:04] <Chipaca> ¯\_(ツ)_/¯
[11:04] <pedronis> Chipaca: yes, the manual copying  is annoying/fragile, not sure a complicated solution using reflection is better though
[11:04] <mborzecki> Chipaca: `Omitting the colon results in a test only for a parameter that is unset`
[11:04] <mborzecki> Chipaca: funny how they use : and 'colon' in that particular sentence
[11:05] <Chipaca> mborzecki: ooh
[11:05] <Chipaca> so ${foo?error} errors only if unset
[11:05] <Chipaca> fair enough
[11:07] <Chipaca> pedronis: was your comment on #4738 a request to remove or improve?
[11:07] <mup> PR #4738: snap: unify snap name validation w/python; enforce length limit <Created by chipaca> <https://github.com/snapcore/snapd/pull/4738>
=== Sir_Gallantmon is now known as Son_Goku
[11:09] <Chipaca> mvo: #4720 has you tagged for reviewing it, but it's got a +1 from zyga and j.d.strand, dunno how to proceed
[11:09] <mup> PR #4720: interfaces: add xdg-desktop-portal support to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4720>
[11:10] <Chipaca> zyga: I think you just broke 4714, is that something you could deconflict?
[11:10] <zyga> oh, I always deconflict that one :D
[11:11] <zyga> done
[11:21] <Chipaca> thanks
[11:21]  * Chipaca reviewing
[11:25] <Chipaca> woo! we're below 3 pages
[11:25] <Chipaca> :-(
[11:26] <mup> PR snapd#4743 closed: packaging/arch: sync with snapd/snapd-git from AUR <go go go go!> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4743>
[11:26] <Chipaca> zyga: why is tests/main/layout failing so much
[11:26] <zyga> I don't know yet, I merged some debug helper to see what we can learn
[11:27] <zyga> what I saw seemed to indicate that /etc is gone
[11:27] <zyga> which is ... worrying
[11:27] <Chipaca> zyga: https://pastebin.ubuntu.com/p/Yj8MKv3h2m/ <-
[11:27] <Chipaca> ah yes
[11:27] <zyga> perhaps I want to adjust the debug output to do "ls -ld /etc"
[11:28] <Chipaca> cachio__: good morning sir! as a waking-up present, you have conflcits in #4721
[11:28] <mup> PR #4721: tests: update interface tests to remove extra checks and normalize tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4721>
[11:33] <pedronis> zyga: remember there's a denial too, so not clear is gone, or cannot be operated on
[11:33] <pedronis> also I have /etc and /opt
[11:33] <pedronis> *I have seen
[11:33] <zyga> yep
[11:34] <zyga> but ENOENT cannot happen via apparmor
[11:34] <zyga> still unclear what is wrong really
[11:35] <pedronis> Chipaca:   improve
[11:36] <pedronis> I didn't get it was a joke
[11:36] <pedronis> it seems
[11:36] <Chipaca> pedronis: ok, i'll improve
[11:36] <pedronis> Chipaca: did you see my comment about copying fields,  did you have something better in mind? I have only complicated things
[11:37] <Chipaca> pedronis: I just wish these things were assignable
[11:37] <Chipaca> pedronis: wishful thinking on my part
[11:37] <Chipaca> nothing more, i fear
[11:37] <pedronis> ok
[11:37] <pedronis> wondering if there's a way to check I didn't leave out any field
[11:37] <pedronis> though
[11:38] <pedronis> I'll think a bit more,   I need to rename a couple of fields anyway
[11:38] <pedronis> because of last night discussions
[11:38] <pedronis> Chipaca: is go go go! a new thing?
[11:38] <Chipaca> pedronis: yes i created it today
[11:38] <Chipaca> and expect it to be given a more professional name :-) but
[11:39] <Chipaca> we need a tag to not waste time looking at a pr because it's good-to-go
[11:39] <Chipaca> maybe because i'm not always comfortable merging somebody else's code (as i presume if they haven't merged it there's a reason)
[11:39] <pedronis> in theory you can just go and merge it I suppose,  though for mine it would have been wrong, well not wrong, but I need to tweak it
[11:39] <pedronis> that is fair
[11:40] <pedronis> yes, not a fan of merging code unless I have the full context
[11:42] <Chipaca> zyga: does the layout error happen on every pass, or is it random?
[11:42] <zyga> random
[11:42] <Chipaca> zyga: IOW, should i just hit restart
[11:42] <zyga> if it was every pass it wouldn't land
[11:42] <Chipaca> because there's a bunch of prs red because of it
[11:42] <zyga> hmmm
[11:42] <zyga> I'll look into it
[11:43] <zyga> meanwhile please restart
[11:43] <Chipaca> zyga: so i should leave them red?
[11:43] <Chipaca> ah ok
[11:43]  * Chipaca punches the button
[11:43] <zyga> nah, I need to reproduce that or add more debugging
[11:44] <Chipaca> cachio__: in #4725, it's completely unclear to me whether you're saying it's in the model/gadget/whatever (and thus it shouldn't get removed and we have a bug), or not (and thus the model needs tweaking)
[11:44] <mup> PR #4725: tests: avoid removing preinstalled snaps on core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4725>
[11:46] <Chipaca> zyga: you probably want to re-review #4672
[11:46] <mup> PR #4672: tests: adding test for removable-media interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4672>
[11:46] <zyga> question about that ../../../bin/sh trick
[11:46] <zyga> how do you want to tackle that
[11:46] <Chipaca> the one that's going away?
[11:46] <Chipaca> first, do a scan of all snaps to make sure it's just our snaps that use it
[11:47] <Chipaca> second, let you use absolute paths
[11:47] <mvo> Chipaca: looking at 4720
[11:47] <Chipaca> third, forbid you from using ..
[11:47] <Chipaca> zyga: <end>
[11:48] <Chipaca> zyga: if the first step fails, we need to address that before moving to #2 and #3
[11:48] <zyga> ln -s .. foo
[11:48] <Chipaca> bah, #2 can move ahead independently and might be needed to address #1
[11:48] <zyga> ls foo/
[11:48] <zyga> just saying
[11:48] <Chipaca> zyga: this is snap.Container-level validation
[11:49] <Chipaca> so you can read that link, probably
[11:49] <mup> PR snapd#4720 closed: interfaces: add xdg-desktop-portal support to desktop interface <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4720>
[11:49] <Chipaca> * needs more work but it's doable
[11:50] <Chipaca> that is, snap.Container would need a ResolveSymlink or something, as the walk on its own doesn't have enough info
[11:50] <mup> PR core#82 opened: xdg-open: add implementation capable of opening local files <Created by jhenstridge> <https://github.com/snapcore/core/pull/82>
[11:57] <cachio__> Chipaca, we don't have a bug
[11:58] <cachio__> Chipaca, this PR is to run our test suite on caracalla device
[11:58] <cachio__> Chipaca, in this case the caracalla image has different snaps preinstalled
[11:58] <cachio__> some of them cannot be uninstalled
[11:59] <cachio__> Chipaca, so the idea is to avoid removing those when we reset
[12:01] <mborzecki> jamesh: hmm i see the xdg-open PR, what reminds me that I've seen some snaps call xdg-mime directly, discord does that for instance, do you think we should handle this as well?
[12:02] <jamesh> mborzecki: mvo's xdg-mime proxy already handles that, no?
[12:03] <mborzecki> jamesh: let me try to grab the log from discord
[12:05] <mvo> iirc we don't do xdg-mine, we do xdg-settings though
[12:05] <jamesh> ah.  Got those confused
[12:06] <mvo> jamesh: just saw your glib xdg-open PR, nice!
[12:06] <mvo> jamesh: will we need to register more handlers? I see we right now do http,https,mailto,help, how will open other types (like normal text) work?
[12:07] <jamesh> mvo: I've got a hack to make that work, but don't want to put it in core
[12:07] <mvo> jamesh: aha, nice
[12:07] <mvo> jamesh: so that will be per-snap?
[12:09] <jamesh> mvo: I just forwarded you an email about the hack I used: it relies on a stub shared-mime-info database so that everything maps to a single mime type
[12:09] <jamesh> i.e. not the kind of thing I'd want to make part of the ABI of the core snap
[12:10] <mborzecki> jamesh: https://paste.ubuntu.com/p/pHMSZgZG6M/ grep does not show any trace of xdg-mime in unpacked snap, so no clue where that's called from
=== chihchun_afk is now known as chihchun
[12:15] <mborzecki> jamesh: this is what it's trying to do with xdg-mime: https://paste.ubuntu.com/p/dsDJ7DqjfV/
[12:18] <jamesh> mborzecki: fwiw, I filed a wishlist issue against xdg-desktop-portal about supporting default app associations, but it got knocked back: https://github.com/flatpak/xdg-desktop-portal/issues/126
[12:18] <jamesh> mborzecki: if we wanted to support this kind of thing, it isn't something we can fob off to xdg-desktop-portal in future
[12:19] <jamesh> I am sympathetic to their point of view that confined apps shouldn't be changing associations
[12:20]  * Chipaca disappears in a cloud of 'omg lunch'
[12:31] <mup> PR snapcraft#1969 opened: Add a "--profile" parameter to cleanbuild <Created by chrisglass> <https://github.com/snapcore/snapcraft/pull/1969>
[12:34] <pedronis> mvo: I noticed we still avae snap.Info.LicenseAgreement and snap.Info.LicesenseVersion, are they still a thing in snapcraft.yaml ?
[12:34]  * pedronis can't type
[12:44] <kaliy> hi, quick question: I'm assuming that I need to use classic confinement if I need to drop a policykit policy file system-wide during install, is this correct? or could I do this in any other way?
[12:44] <Chipaca> kaliy: please don't do that unless you also remove it on uninstall
[12:45] <Chipaca> but, yes, as a classic snap you would be able to do that
[12:45] <kaliy> Chipaca: that's already done :)
[12:45] <Chipaca> kaliy: how?
[12:45] <kaliy> with the remove hook
[12:45] <Chipaca> we have a remove hook?
[12:45]  * Chipaca is behind the times
[12:45] <pedronis> we have all sorts of hooks
[12:46] <Chipaca> oh dear
[12:46] <kaliy> I was about to post to the forum asking for review for a classic confinement snap, but I wanted to make sure if I hadn't misunderstood something
[12:46] <Chipaca> pedronis: I had a vision of you doin ga 'From Dusk till Dawn' thing with hooks
[12:47] <Chipaca> kaliy: please do a forum post. I'm interested in knowing what you need the policykit thing for, to see if we can't accommodate it with interfaces in the future
[12:48] <Chipaca> kaliy: also i'd be interested in knowing how you'd handle a missing policy kit, or running on arch
[12:48] <Chipaca> (have you tested on arch)
[12:48] <Chipaca> then 'run snaps cross-distroly' breaks down easily for classic snaps :)
[12:49] <kaliy> Chipaca: this app uses a polkit policy for launching openvpn. the app will complain if no polkit agent is running, and we try hard to launch any usable polkit agent that can be found on the system
[12:49] <kaliy> I saw a reference to interfaces for polkit in the forum, but I was unsure how this would be implemented
[12:50] <Chipaca> kaliy: me too :-) more examples help
[12:50] <Chipaca> so, go forum post asking for classic, give us the juicy, juicy details of what you need :-)
[12:50] <kaliy> Chipaca: sure, thanks :)
[12:59] <pedronis> Chipaca: after standup could you look at the commits I added to #4770
[12:59] <mup> PR #4770: store: parse the JSON format used by the coming new store API to convey snap information <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4770>
[12:59] <Chipaca> doing so now
[13:02] <mup> PR snapcraft#1958 closed: store: support for more granular store permissions <enhancement> <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1958>
[13:25] <zyga> [Wed Feb 28 17:17:47 2018] audit: type=1400 audit(1519838267.637:342): apparmor="DENIED" operation="mount" info="Failed name lookup - deleted entry" error=-2 profile="/usr/lib/snapd/snap-confine//snap_update_ns" name="/etc/group" pid=14239 comm="3" flags="rw, bind"
[13:26] <zyga> so this clearly shows something removed /etc/group while we were working
[13:26] <mup> PR snapd#4774 closed: tests: adding ubuntu-14.04-64 to the google backend <go go go go!> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4774>
[13:31] <jdstrand> mvo: hi! I see in backscroll that you noticed the xdg-open PR. Please see this in particular: https://github.com/snapcore/snapd/pull/4766/#discussion_r171275533
[13:31] <mup> PR #4766: userd: add an OpenFile method for launching local files with xdg-open <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4766>
[13:34] <mvo> jdstrand: thanks, in a meeting right now but I will read this, thanks for the info. please note that this is not a security measure, this is just to get the transient parent for the window that is displayed :)
[13:38] <mup> PR snapcraft#1970 opened: meta: parse LAUNCHPAD_BUILD_INFO for inclusion in the manifest <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1970>
[13:38] <jdstrand> mvo: that's a different comment I want you to look at. that was just a warning. what I asked you to look at is the snap name lookup in snapFromSender since you can bypass the "I proved I could open the file" check in that PR
[13:39] <zyga> jdstrand hey
[13:39]  * kalikiana going for lunch
[13:39] <jdstrand> hey zyga
[13:39] <zyga> jdstrand I just found a bug in layouts and I'm super in progress with layout harderning
[13:39] <zyga> jdstrand /etc is the real /etc on classic
[13:40] <zyga> jdstrand so it's writable
[13:40] <zyga> jdstrand so we create symlinks there (oops)
[13:40] <zyga> jdstrand not sure if we should do
[13:40] <zyga> *what
[13:41] <jdstrand> zyga: can you connect the dots a little more. I understand on classic, /etc is the host's etc. this is why we don't allow specifying non-$SNAP* source mounts. what are you referring to?
[13:41] <zyga> we still allow one to make a symlink in /etc/foo -> stuff
[13:42] <zyga> and that creates a real symlink in real /etc
[13:42] <zyga> we also allow creating file bind mounts
[13:42] <zyga> and that creates a real empty file in the real /etc as a mount point
[13:42] <zyga> and in fact, any writable location will have this property
[13:42] <zyga> that the symlink and empty files/directories are really actually created there
[13:43] <jdstrand> ok, so while the source mount is $SNAP*, the target needs to exists for the mount point
[13:43] <jdstrand> exist*
[13:44] <jdstrand> that is definitely wrong
[13:44] <mup> PR snapcraft#1916 closed: lxd: initialize remote lazily <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1916>
[13:44] <zyga> well, that's not how layouts work
[13:44] <zyga> otherwise you cannot put stuff into /usr/share/myapp
[13:44] <zyga> myapp doesn't exist when the layout is being constructed
[13:44] <jdstrand> it is wrong that the files are leaking outside of the snap that is
[13:44] <zyga> oh, no disagreement there
[13:45] <zyga> it's just something we need to figure out
[13:45] <jdstrand> I thought that was going to be handled with a writable mimic?
[13:45] <zyga> it is
[13:45] <zyga> but /etc is _writable_
[13:46] <zyga> mimics are not constructed there
[13:46] <jdstrand> you're saying writable mimic only kicks in if the source is readable
[13:46] <zyga> we only invoke the mimic if the write returns EROFS
[13:46] <jdstrand> right. what if you always did that instead of doing that check?
[13:46] <zyga> I'm saying the mimic only kicks in when the mount point cannot be created
[13:46] <zyga> it's not clear at which level we'd construct the mimic
[13:46] <zyga> at the parent?
[13:46] <zyga> that is
[13:47] <zyga> for /usr/share/foo we'd always make a mimic at /usr/share
[13:49] <zyga> jdstrand stashing that converstation
[13:49] <zyga> can I ask you to take a quick look at a bit of apparmor policy
[13:49] <jdstrand> sc_populate_mount_ns has a list of dirs that are affected, no?
[13:49] <zyga> it's representative for all the layout bits we need to do
[13:50] <zyga> hold on, looking
[13:51] <zyga> jdstrand yes, I think that's roughly the list
[13:51] <zyga> though I don't know thinking about it quickly if that's _the_ list
[13:51] <zyga> or if something contributes elsewhere
[13:52] <jdstrand> zyga: we can either just do the parent or some variation on that, which would mean more mimics, or we are precise an when to mimic
[13:52] <jdstrand> which is fewer mimics
[13:52] <zyga> hmm, I almost agree
[13:52] <zyga> but not fewer in some cases, let's see /usr/share/foo/bar is something we need to make
[13:53] <zyga> this would give us a mimic at /usr/share and then another one (not needed) at /usr/share/foo, right?
[13:53] <Chipaca> niemeyer: mvo: I was trying to say something but it froze up
[13:54] <mvo> Chipaca: what was it?
[13:54] <cachio__> mvo, I already tagged 2 PRs for 2.32
[13:54] <zyga> jdstrand I need to think about this, I just realized this happens
[13:54] <jdstrand> I presented two choices. a) mimic the parent (or a variation), b) mimic based on this list
[13:54] <mvo> cachio__: thank you
[13:54] <zyga> jdstrand can you please look at this policy test: https://pastebin.ubuntu.com/p/CM9tJ5W7cF/
[13:54] <niemeyer> Chipaca: Ah, oops, sorry :)
[13:54] <Chipaca> niemeyer: mvo: bash in 16.04 (i haven't looked elsewhere) that --rcfile overrides reading /etc/bash.bashrc, but it doesn't
[13:54] <zyga> jdstrand ack
[13:54] <jdstrand> so, with 'a', you mimic at /usr/share/foo
[13:54] <Chipaca> niemeyer: mvo: so to do what I want to do I'm going to have to tweak /etc/bash.bashrc
[13:54] <jdstrand> but if you then have /usr/share/baz/norf, you mimic as /usr/share/baz
[13:54] <jdstrand> so that is 2 under /usr/share
[13:55] <zyga> with a) exiting code would also kick in and make a mimic at /usr/share since foo is not a thing in the base snap
[13:55] <niemeyer> Chipaca: That'd mean not working for most people.. :(
[13:55] <Chipaca> so, that. No biggie, but it's going to take a while more (and involve more people) than the quick hack it would've been otherwise
[13:55] <niemeyer> Chipaca: And perhaps some people upset when it does work :)
[13:55] <Chipaca> niemeyer: /etc/bash.bashrc is from core
[13:55] <jdstrand> but, if /usr/share is in the list, you mimic /usr/share
[13:55] <niemeyer> Chipaca: Ah, hmm, that's also not so great given bases
[13:55] <zyga> jdstrand I think we need the list of directories
[13:55] <niemeyer> Chipaca: I mean, behavior will be inconsistent
[13:55] <zyga> as that seems as a more natural thing to do
[13:55] <zyga> it's complex as that list is variable
[13:56] <zyga> and I don't know if it's simple to connect the dots yet
[13:56] <niemeyer> Chipaca: Did you dig into what was going on with --rcfile?
[13:56] <jdstrand> for /usr/share/foo/bar and tack on /usr/share/baz/norf under that existing mimic
[13:56] <zyga> perhaps we can start with a blacklist (e.g. extend it to refuse /home mounts) and a simpler rule for just /etc
[13:56] <zyga> (and similarly /var)
[13:56] <jdstrand> zyga: right. I'm not expressing a preference. I just recalled there was a list, so maybe it could be leveraged
[13:57] <zyga> jdstrand yeah
[13:57] <zyga> I just wanted to let you know because I didn't anticipate this before
[13:57] <Chipaca> niemeyer: as I said, the documentation says it overrides reading the system rc, but it doesn't
[13:58] <jdstrand> zyga: I like starting simpler. we would have to consider if there are any valid use cases for the ones we leave out of the list
[13:58] <Chipaca> the code is: load system rc; load rcfile or ~/.bashrc
[13:59] <jdstrand> zyga: I didn't explicitly think about this either-- I was thinking 'oh, this is a per-snap mimic so all is good'. curious, did this come about from the apparmor hardening?
[13:59] <jdstrand> zyga: btw, thank you for that hardening
[13:59] <Chipaca> niemeyer: are bases required to have bash?
[14:00] <zyga> jdstrand yes this came out of the hardening as I was testing this on my host system
[14:00] <zyga> jdstrand and I noticed /etc is populated with placeholders
[14:01] <zyga> jdstrand hardening is almost complete for layouts (modulo review and fixes) but I need to go all the way and make content interface do something similar or I won't be able to drop some of the wildcards
[14:02] <zyga> once content interface also adds update-ns rules I should be able to remove the biggest offenders :)
[14:02] <jdstrand> zyga: yeah for hardening! :)
[14:03] <jdstrand> zyga: you asked me to look at some apparmor rules?
[14:03] <zyga> yes
[14:03] <zyga> in the pastebin above
[14:03] <zyga> https://pastebin.ubuntu.com/p/CM9tJ5W7cF/
[14:03] <zyga> it's a part of a test
[14:03] <zyga> there's a simple layout
[14:03] <jdstrand> I responded to 4765 yesterday (you probably saw)
[14:03] <zyga> and the resulting rules
[14:03] <zyga> yeah, I will iterate with the hardening there
[14:04] <Chipaca> zyga: why does snap-confine create SNAP_USER_DATA, but not any other of the four data dirs?
[14:05] <zyga> Chipaca not sure
[14:05] <zyga> I think it is doing that because /home/zyga/snap/snapname/ is not writable in general
[14:05] <zyga> so it will do /home/zyga/snap/snapname/42/
[14:05] <zyga> the common one is done somewhere else (right?)
[14:06] <zyga> but really that's just a guess
[14:06] <zyga> that's some oooold code pre-dating many of the things we have now
[14:07] <mup> PR snapd#4739 closed: many: remove snapd.refresh.{timer,service} <go go go go!> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4739>
[14:08] <roadmr> hey folks. Is bsutton here? does anybody know him?
[14:09] <zyga> roadmr not me
[14:11] <pedronis> mvo:   snap-rervice-refresh-mode seems flaky:  https://travis-ci.org/snapcore/snapd/builds/347750674?utm_source=github_status&utm_medium=notification
[14:12] <Chipaca> zyga: there's no SNAP_USER_COMMON in snap-confine
[14:12] <zyga> I think that's something to garden
[14:12] <Chipaca> zyga: the mkdir, or the lack of them?
[14:13] <zyga> not sure, they ought to be made, just unsure where
[14:13] <zyga> I suspect in snap-confine though, due to permissions
[14:13] <mvo> pedronis: hm, I think we had this before that tests/main/snap-service-refresh-mode  was flaky, iirc cachio__ did some fixes (or was it mborzecki) from leftover systemd logs. I will look in a wee bit
[14:14] <Chipaca> zyga: ok, I'll dig
[14:14] <pedronis> thanks
[14:14] <Chipaca> zyga: I need to change this code anyway
[14:14] <zyga> what kind of changes do you need to make?
[14:14] <Chipaca> zyga: SNAP_DATA and SNAP_USER_DATA are going to point at symlinks
[14:14] <zyga> hmm
[14:14] <zyga> that's interesting
[14:15] <Chipaca> zyga: very precise symlinks, so, a little code to desymlink them and we'll be good
[14:16] <Chipaca> a readlinkat and a add-this-to-that
[14:16] <mborzecki> mvo: yup, it was journalctl --sync && journalctl --rotate
[14:16] <jdstrand> Chipaca: what is the symlink and what will the symlink point to? what is the motivation of the change?
[14:16] <Chipaca> jdstrand: current
[14:17] <cachio__> pedronis, mvo I'll take a look to that test
[14:17] <Chipaca> jdstrand: motivation is that if an app uses $SNAP_USER_DATA for something, they should be able to store it without it breaking on refresh
[14:17] <Chipaca> jdstrand: e.g. vlc using $SNAP_USER_DATA/Videos (or whatever) as default for where to find videos
[14:18] <jdstrand> Chipaca: that only solves part of the problem
[14:18] <Chipaca> jdstrand: (there's a second half of this work that's "move then copy back on refresh, instead of copy forward")
[14:18] <jdstrand> Chipaca: but will improve things, yes
[14:19] <jdstrand> Chipaca: the hard problem is open fds
[14:19] <Chipaca> jdstrand: that's fixed by the move-then-copy-back thing
[14:19] <Chipaca> right?
[14:19] <pedronis> mvo: cachio__:  journalctl has cursors, maybe we can use those
[14:20] <cachio__> pedronis, ok, let me check if that works on trusty
[14:21] <pedronis> --show-cursor  and  --cursor  and --after-cursor
[14:21] <jdstrand> I don't see how. it does solve newly opened files. eg, vlc opens 1/foo, a frefresh happens, the apparmor policy is reloaded, making 1/foo readonly and 2/foo readwrite, when vlc writes to its fd, the kernel will do a revalidation of that fd, see it is in 1/foo, which is readonly and then deny it
[14:21] <mborzecki> pedronis: hm intersting, worth exploring if the test continues to be flaky
[14:22] <mborzecki> pedronis: the last attempt was to make sure that the journal is flushed and rotated before each test
[14:22] <pedronis> that should be overkill with cursors (if they work on 14.04)
[14:24] <niemeyer> Chipaca: Yes, the shell needs to be in the base, at least for now
[14:24] <niemeyer> Chipaca: In a call, but will be with you shortly
[14:25] <jdstrand> Chipaca: there are only four ways to fix this: the application gets a signal and does something smart, we make the previous revision readwrite, we defer the policy reload or we have per-revision apparmor policy (like we did with click)
[14:25]  * zyga -> lunch
[14:25] <cachio__> pedronis, we can use cursors in all the systems but 14.04
[14:25] <pedronis> :/
[14:26] <Chipaca> jdstrand: if we mv 1/ 2/, won't the revalidation see the fd of 1/foo as on 2/ now?
[14:26] <cachio__> pedronis, 14.04 should be removed soon from our test suite I think
[14:26] <jdstrand> Chipaca: each has drawbacks. for the first, the app needs to be really smart. for the second, that destoys rollbacks. for the fourth, the running app writes to the old dir after the migration
[14:27] <jdstrand> Chipaca: the third is not impossible (defer/prompt the refresh if non-daemon processes are running in the freezer cgroup)
[14:27] <jdstrand> Chipaca: hmm, maybe. did you test that actually works?
[14:29] <Chipaca> jdstrand: I don't have the code to do that yet, no, but I should be able to get there before eod
[14:29] <jdstrand> Chipaca: we should ask jjohansen if that is expected to work
[14:30] <Chipaca> jdstrand: asking somebody whether it'll work >>> doing the work to check if it works :-)
[14:30] <Chipaca> jjohansen: OHI
[14:30] <jdstrand> Chipaca: well, I was thinking you would write a very small test to see if the revalidation happens rather than changing snapd since that might waste your time
[14:30] <jdstrand> Chipaca: let me ask
[14:30]  * Chipaca lets
[14:31] <pedronis> cachio__: do you that travis log or can I restart the tests?
[14:31] <pedronis> *do you need
[14:31] <cachio__> pedronis, restart it
[14:31] <pedronis> thx
[14:32] <cachio__> np
[14:33] <jdstrand> jjohansen: hi! consider a profile has '/1/** rw,' and an app has an fd for /1/foo. when the profile is reloaded to only allow '/2/** rw,' then when the app writes to the fd, it is denied cause of revalidation (fine)
[14:35] <jdstrand> jjohansen: now consider profile has '/1/** rw,', app has open fd to /1/foo. then, the app is frozen via freezer cgroup, /1 is moved to /2, the profile is updated to allow only '/2/** rw,' and reloaded, then app is unfrozen
[14:36] <jdstrand> jjohansen: what is expected to happen when the app writes to the open fd? does revalidation kick in? the path is different, but the inode backing it is the same
[14:36]  * zyga tunes in as this is interessting
[14:36] <jdstrand> Chipaca: fyi, jjohansen may not be online for a little while
[14:36]  * ikey also has the popcorn
[14:36] <zyga> I didn't know apaprmor does revalidation
[14:39] <Chipaca> jdstrand: it's ok, i've got plenty of other stuff to work on meanwhile :-)
[14:39] <jdstrand> Chipaca: assuming for a moment that works, deferring/prompting is still desired
[14:39] <jdstrand> Chipaca: this operation could take several seconds to migrate, reload, etc
[14:40] <kalikiana> re
[14:40] <jdstrand> Chipaca: while the whole time the application is frozen. if the application is vlc, its playback is stopped. the window goes gray, the user is like 'wth?'
[14:40] <elopio> cachio__: those look like network timeouts
[14:40] <Chipaca> jdstrand: yes, we still want apps to be able to say "don't refrsh me just yet plz"
[14:41]  * zyga never imagined jdstrand would say "the user is like 'wth?'" :D
[14:42] <jdstrand> Chipaca: if we have that ability. or even simply the ability to prompt and say "I have a refresh pending. Deferring the refresh until vlc closes'. Then you watch for when the cgroup has no non-daemon processes running in it, and do it then
[14:42] <Chipaca> zyga: jdstrand: do we know how many things are in the freezer?
[14:42] <jdstrand> Chipaca: then you don't need the rigamorole
[14:42] <zyga> yes
[14:43] <Chipaca> because we could defer a refresh if the freezer isn't empty
[14:43] <jdstrand> zyga: note, it was the user that said that, not me :P
[14:43] <zyga> you can enumerate processes and threads
[14:43]  * zyga hugs jdstrand for being so awesome
[14:43]  * jdstrand hugs zyga :)
[14:44]  * Chipaca adds it to quotes
[14:44] <Chipaca> zyga: do you have to freeze it before you can answer 'is it empty'?
[14:45] <jdstrand> Chipaca: yes, like zyga said. the trick is 'non-daemon' and by that I mean snap commands that don't use 'daemon: ...' in the yaml, since they are expected to be running
[14:45] <zyga> Chipaca I think no
[14:45] <zyga> although the process you will find may be gone now
[14:45] <zyga> so you can see "not empty" without freezing
[14:45] <Chipaca> jdstrand: daemons are a whole other … uh … species?
[14:46] <jdstrand> Chipaca: I may not be clear. we handle daemons across refresh fine. so we just want to know if non-daemons are in the cgroup.
[14:46] <cachio__> pedronis, journalctl on trusty supports cursors
[14:46] <Chipaca> jdstrand: yes
[14:46] <Chipaca> bah
[14:46] <Chipaca> yes
[14:47] <Chipaca> i wouldn't mind if at first we were just careful about purely-non-daemon snaps
[14:47] <mvo> niemeyer: I put the apt integration ideas here: https://forum.snapcraft.io/t/providing-hints-about-snaps-from-apt/4301
[14:47] <Chipaca> baby steps, etc
[14:47] <cachio__> pedronis, I'll make a change to use it instead of rotating the logs
[14:48] <mup> PR snapd#4776 opened: Do not auto-import from loop/ram devices <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4776>
[14:48] <niemeyer> mvo: Thanks!
[14:49] <niemeyer> Chipaca: I'm in the travel stuff call, but while the propaganda goes on: it would be nice to understand *why* --rcfile doesn't work
[14:49] <Chipaca> niemeyer: you mean, *why* the code does what it does?
[14:49] <niemeyer> Chipaca: Yeah, it's not like bash changes very often.. that sort of breakage sounds surprising
[14:50] <Chipaca> niemeyer: or are you asking about the code
[14:50] <jdstrand> Chipaca: I can imagine something along the lines of: refresh is downloaded. snapd sets a flag 'refresh pending', it checks the freezer, if nothing running, refresh. if running, idle til no running, then refresh, then unset the review pending flag. we can use the 'review pending' flag in snap run to avoid a race for starting the app between the 'is empty' check and the refresh is finished
[14:50] <Chipaca> niemeyer: it's a distro patch that adds /etc/bash.bashrc that tweaks the manapage one way, which is not how shell.c is written
[14:51] <jdstrand> Chipaca: with what I outlined, that could be all implemented without a prompt. ie, snapd becomes smarter about when to refresh. than at some future date, could tastefully alert the user that the refresh is pending
[14:51] <niemeyer> [niemeyer@nomad ../snapd/cmd/snap]% bash --rcfile ./foo.sh
[14:51] <niemeyer> What
[14:51] <niemeyer> niemeyer@nomad:~/src/github.com/snapcore/snapd/cmd/snap$
[14:51] <niemeyer> Chipaca: That's 16.04
[14:51] <Chipaca> jdstrand: “error: the app "hello-world" has a refresh pending; please try again later (you can close all current apps from the snap to make this happen faster)”?
[14:52] <jdstrand> Chipaca: yes. but maybe 'a refresh in progress' would be better
[14:52] <Chipaca> jdstrand: true
[14:52] <Chipaca> sounds very doable (but a lot of work) (also, need something for gui apps)
[14:53] <Chipaca> niemeyer: and without --rcfile?
[14:53] <zyga> jdstrand I'll do that lunch for real now, let me know if the apparmor rules in the pastebin look sensible, I will open a PR soon
[14:53] <jdstrand> Chipaca: because you only prompt for that when we started the refresh. ie, if vlc is running and a refresh is pending, the user should be able to launch another vlc
[14:53] <jdstrand> Chipaca: both need to be gone to [trigger the refresh, which blocks the launch
[14:53] <jdstrand> s/\[//
[14:53] <Chipaca> niemeyer: how about: bash --rcfile ./foo.sh -x
[14:54] <Chipaca> jdstrand: ah, gotcha
[14:54] <jdstrand> Chipaca: that's a pretty cool idea if I say so myself :)
[14:55] <Chipaca> jdstrand: quick write it down
[14:55] <jdstrand> I think it only took a year or more of my brain thinking about it in the background to think of it :P
[14:56] <jdstrand> Chipaca: the real trick is the 'is cgroup empty of non-daemons' check. everything else should be relatively straightforward
[14:57] <Chipaca> this still needs the 'drop revision from env vars'
[14:57] <jdstrand> Chipaca: yes
[14:57] <Chipaca> but might not need the 'cp -> mv && cp' change
[14:57] <jdstrand> Chipaca: cause we don't have a way to change the environ for a running process in a way that could possibly be contrued as sane
[14:58] <jdstrand> Chipaca: so the env handles new files. the defer handles open fds, but also adds robustness and improves usability
[14:59] <jdstrand> (and by handling them, it punts on them :)
[14:59] <jdstrand> but that's ok and desirable
[15:00] <jdstrand> it is very natural to defer an update if something is running. it is less so to change things behind the apps back
[15:00] <jdstrand> Chipaca: actually, we don't need the env. the refresh was deferred. the new env will only ever be in effect after the refresh
[15:01] <Chipaca> jdstrand: right, but if the app picks up the env var to stick it in config, it breaks
[15:01] <jdstrand> Chipaca: that's entirely fair
[15:01] <jdstrand> Chipaca: pointing at current is a good idea for lots of reasons
[15:01] <ackk> sergiusens, mvo, will "base-18" be called "core" on bionic, once it's released? or will it keep the numbering?
[15:02] <jdstrand> Chipaca: istr we didn't initially cause we weren't sure we always wanted the symlink
[15:02] <roadmr> zyga: I found bsutton in the forum :)
[15:02] <sergiusens> ackk: I have no idea, which is why I wanted this a bit more formally documented (not just IRC fly by conversation)
[15:03] <sergiusens> I suspect, no; but it would be nice to have this recorded
[15:03] <ackk> sparkiegeek, I'm asking 'cause we currently have "base: base-18" in our snap for bionic, if it's going to be called "core" I'm not sure how you could run a bionic snap on xenial
[15:03] <ackk> err, sergiusens ^
[15:03] <niemeyer> Chipaca: https://gist.github.com/niemeyer/c1cfd64dbc8b3f094333b061cd0422fb
[15:03] <ackk> sparkiegeek, sorry :)
[15:05] <Chipaca> niemeyer: exactly
[15:05] <Chipaca> niemeyer: that's /etc/bash.bashrc
[15:05] <niemeyer> Chipaca: I don't get it.. so what?
[15:05] <niemeyer> Chipaca: We can set a PS1 like that, can't we?
[15:05] <Chipaca> niemeyer: that's what sets up command-not-found, which won't work
[15:05] <niemeyer> Chipaca: Is there no way to disable it?
[15:05] <Chipaca> niemeyer: that's what echoes "here's how to run sudo"
[15:05] <mvo> mborzecki: fwiw, I looked at systemd-analyize in a chroot and also at the source, it does not require a dbus connection for me, so either thats a bug in older systemd (I only checked git) or the buildd is doing even stranger things
[15:06] <Chipaca> niemeyer: the first one yes, the second one no :-) (can't un-echo)
[15:07] <mup> PR snapd#4723 closed: Translate polkit strings <Created by gunnarhj> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4723>
[15:07] <Chipaca> niemeyer: if it's the best we can get, I'm ok with it; I'd rather tweak bash.bashrc in core to avoid that
[15:07] <niemeyer> Chipaca: Okay, but those sound like two separate issues: we can do less in bashrc, which would be a bug for the base, and then have a stock bashrc which does more, which doesn't have to be in the base
[15:07] <Chipaca> niemeyer: bases will still work because they (shouldn't / won't) have /etc/bash.bashrc in the first place
[15:08] <Chipaca> niemeyer: i mean, my proposed change for bash.bashrc was literally '[[ "$SNAP" ]] && return'
[15:08] <niemeyer> Chipaca: Ah, ok, and the PS1 change elsewhere?
[15:08] <Chipaca> yes
[15:08] <Chipaca> could also go with SNAP_COOKIE if SNAP is too easy
[15:08] <Chipaca> :-)
[15:09] <Chipaca> (aside: why do we have both SNAP_COOKIE and SNAP_CONTEXT)
[15:09] <niemeyer> Chipaca: Brilliant!
[15:09] <niemeyer> Chipaca: Histerical
[15:09] <Chipaca> sigh
[15:10] <niemeyer> Chipaca: One of these is obsolete and should be dropped eventually
[15:10] <Chipaca> niemeyer: you know how they cured hysteria, right?
[15:10] <Chipaca> I can't tell you because NSFW
[15:10] <Chipaca> anyhow, moving on
[15:38]  * cachio__ lunch
=== ikey is now known as ikey|busy
[15:54] <arm1e> Hi,
[15:55] <arm1e> I would like to package software as snaps but I have no packaging experience. I have read the documentation but where can I learn how to package software. I heve no programming experience, but really want to help port apps
[15:55] <Chipaca> zyga: i addressed your concerns with #4775 i think
[15:55] <mup> PR #4775: timeutil: timeutil.Human(t) gives a human-friendly string for t <Created by chipaca> <https://github.com/snapcore/snapd/pull/4775>
[15:55] <mup> PR snapd#4777 opened: i18n: simplify NG usage by doing the modulo math in-package <Created by chipaca> <https://github.com/snapcore/snapd/pull/4777>
[15:56] <zyga> Chipaca ack
[15:56] <Chipaca> popey: do you have anything you'd recommend arm1e ?
[15:56] <popey> wat wat?
[15:56] <mup> PR snapcraft#1971 opened: tests: remove dependency of internal repo from integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1971>
[15:56] <mup> PR snapcraft#1972 opened: tests: remove _options dependency from integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1972>
[15:57] <popey> oooh
[15:57] <popey> arm1e: hello!
[15:57] <arm1e> hey popey
[15:58] <popey> arm1e: https://docs.snapcraft.io/build-snaps/get-started-snapcraft
[15:58] <popey> thats a good place to start, to get your system setup to build snaps :)
[15:58] <arm1e> allready done :)
[15:58] <popey> (if anything on that page doesn't work, let me know, I wrote it)
[15:59] <popey> Maybe start seeking out some things to snap. Want an idea or two?
[15:59] <arm1e> please
[15:59] <Chipaca> pedronis: #4770 is all nice and pretty and ready to go places
[15:59] <mup> PR #4770: store: parse the JSON format used by the coming new store API to convey snap information <Created by pedronis> <https://github.com/snapcore/snapd/pull/4770>
[15:59] <pedronis> Chipaca: thx
[16:00] <popey> One relatively easy place to start is with electron apps
[16:00] <popey> Especially if they use electron-builder
[16:01] <popey> We wrote this task for Google CodeIn, but it's still valid. https://codein.withgoogle.com/tasks/5004124745629696/
[16:01] <mup> PR snapd#4770 closed: store: parse the JSON format used by the coming new store API to convey snap information <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4770>
[16:02] <popey> That might be a good starting point :)
[16:07] <arm1e> cheers
[16:07] <jjohansen> jdstrand: interesting question. It will depend on the ordering of the update and operations in the unfreeze. If the migration happens before the profile update, I think a revalidation should happen. Basically on the migration the task has to be associated with a profile before the profile update.
[16:07] <jjohansen> As long as that happens the revalidation should happen, if however the association of task to profile happens on say unfreeze, that would be after the profile update, and the update then becomes invisible to the task, so revalidation would not happen.
=== c_ is now known as Guest85417
[16:08] <Guest85417> any tutorial to build a golang snap?
[16:09] <Guest85417> i have an app that uses the com port, trying to port it on an ubuntu-core gateway
[16:09] <davidcalle> Guest85417: golang snaps have a nice intro here https://docs.snapcraft.io/build-snaps/go
[16:11] <Guest85417> Thanks. going to try this
[16:13] <jdstrand> jjohansen: interesting. I think the question is academic at this point, because the idea that prompted it had a usability issue
[16:18] <mup> Issue snapcraft#1973 opened: Support quering package manager in tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1973>
[16:21] <mup> Issue snapcraft#1974 opened: organize with forward slashes should be stripped <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1974>
[16:35] <cachio__> mvo, snapd upgrade does not work with last systemd on bionic
[16:35] <cachio__> mvo, confirmed also running on qemu
[16:35] <mvo> cachio__: what error do you see?
[16:35] <nacc> sergiusens: would really appreciate your guidance on LP: #1752481
[16:35] <mup> Bug #1752481: Regressions in 2.39.2 in xenial-updates in classic snaps (relative to 2.35) <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1752481>
[16:35] <cachio__> mvo, after upgrade the snaps are not mounted anymore
[16:36] <cachio__> mvo, I see this with systemd 237-3ubuntu3
[16:36] <zyga> mvo I looked at that briefly and mount units were all stopped
[16:37] <zyga> mvo I didn't recall if other things were stopped
[16:37] <cachio__> it is like you install a new snapd and then the snaps appear as broken
[16:38] <cachio__> mvo, I am kind of stuck, don't know where to see
[16:39] <cachio__> zyga, what do you suggest to review?
[16:39] <cachio__> zyga,  not sure how to continue
[16:39] <zyga> cachio__ look at the journal output during the update
[16:39] <zyga> see what happens
[16:39] <zyga> maybe there's a hint as to who stops the units
[16:40] <zyga> maybe they get stopped because of some reverse dependency with snapd
[16:40] <zyga> so maybe check if stopping snapd.{socket,service} affects anything else
[16:41] <cachio__> the only weir thing I saw in the logs is
[16:41] <cachio__> Mar 01 13:22:58 autopkgtest snapd[30308]: 2018/03/01 13:22:58.805777 main.go:78: Exiting on terminated signal.
[16:42] <cachio__> after the units are unmounted
[16:42] <zyga> that's snapd being SIGINT'ed probably
[16:42] <zyga> after?
[16:42] <cachio__> zyga, https://paste.ubuntu.com/p/zVWGtZc6yj/
[16:42] <cachio__> yes, afetr
[16:42] <cachio__> then the units are not mounterd
[16:43] <zyga> yeah
[16:43] <zyga> no idea
[16:43] <zyga> really
[16:44] <zyga> mvo more reasons to make 2.32.1.x as a quiet safe thing
[16:44] <cachio__> I'll add more log in this line to see if there is some hink
[16:44] <zyga> cachio__ reproduce this manually
[16:44] <zyga> and poke around
[16:44] <zyga> not sure
[16:44] <zyga> see if updating the package really triggers this
[16:44] <zyga> see if there's something in the postinst/preinst scripts
[16:46] <cachio__> zyga, already check those
[16:46] <cachio__> zyga, np, I have something to dig into
[16:47] <nacc> so i've got a tricky situation in a classic snap building on xenial; I need the latest version (well technically just the files) from specific packages (debian-archive-keyring and ubuntu-keyring) in the latest release.
[16:47] <zyga> cachio__ does it happen if you update from 2.31 to 2.31.1 on bionic?
[16:47] <cachio__> did not try that
[16:47] <zyga> I'm trying to understand if 2.32 is broken
[16:48] <zyga> or if bionic is broken
[16:48] <cachio__> I updated from 2.31.1 to the current
[16:48] <cachio__> well, if I run the same in another system it works
[16:48] <cachio__> even in an older bionic
[16:49] <cachio__> the problem is in the last bionic versions
[16:49] <cachio__> at some point systemd and the kernel were updated
[16:49] <mvo> cachio__, zyga hmmm, thank you. so just to confirm 2.31 is ok?
[16:49] <mvo> cachio__: or is that a bit of an unkown at this point?
[16:49] <zyga> mvo I don't know yet, I'm not checking either (digging in another hole)
[16:50] <cachio__> I'll run sru on this bionic version to see if it works
[17:04] <sergiusens> nacc: is your not working link an actual non working one?
[17:04] <sergiusens> nacc: is this version related?
[17:05] <nacc> sergiusens: it's a bunch of stuff it seems like
[17:05] <nacc> sergiusens: well, the snap it built is non-functional
[17:05] <nacc> sergiusens: and it *was* functional just before the snapcraft SRU
[17:06] <sergiusens> nacc: oh, ic; this seems not related to the patchelf work but probably our pip consolidation; kyrofa want to take look?
[17:06] <nacc> sergiusens: the version seems wonky, though
[17:06] <cachio__> zyga, mvo I installed 2.29 and upgraded to 2.31.1 and works
[17:06] <zyga> cachio__ good, thank you for checking htat
[17:06] <cachio__> then I upgraded to 2.32~ and failed
[17:06] <sergiusens> nacc: yes, some files got modified locally during build it seems; can I see your sources?
[17:06] <zyga> it means we can safely release point release from 2.31
[17:07] <zyga> cachio__ can you diff packaging before/after
[17:07] <nacc> sergiusens: https://git.launchpad.net/usd-importer?h=master
[17:07] <zyga> I mean the actual package for 2.31 and 2.32
[17:07] <zyga> I recommend meld (in the archive) for that
[17:07] <zyga> see if anything odd stands out
[17:07] <arm1e> popey: 'Update the version of electron-builder to “^19.53.0” in dev/Dependencies' How do I do this?
[17:07] <nacc> sergiusens: sigh
[17:07] <nacc> sergiusens: you changed where you look for setup.py
[17:08] <nacc> sergiusens: from self.builddir to self.sourcedir
[17:08] <nacc> sourcedir is not updated for subdir
[17:08] <cachio__> zyga, ok, I'll do
[17:08] <zyga> you can unpack the packages with dpkg or with mc :)
[17:08] <nacc> sergiusens: i can see it in the srcpkg diff
[17:09] <sergiusens> nacc: oh; darn :-/ To shed some good news though, you probably do not need to build your own python anymore
[17:09] <nacc> sergiusens: hey, that's something! :)
[17:09] <nacc> sergiusens: what changed there? we do depend on a newer python3 than in xenial
[17:09] <sergiusens> nacc: this happened https://forum.snapcraft.io/t/classic-snaps-failing-on-ubuntu-17-10/2324/34
[17:10] <nacc> sergiusens: relevant diff https://paste.ubuntu.com/p/8dC9Bmh7r2/
[17:10] <sergiusens> we use the python3 in xenial
[17:10] <nacc> sergiusens: right, that's tool old for us
[17:11] <sergiusens> nacc: yeah, this is kyrofa's refactor (not his fault) as it slipped me too... this source-subdir feature is such a pain :-/
[17:11] <nacc> sergiusens: now, what you linked to might fix some of the stuff i hit with the loader when i was building 'on' artful
[17:11] <nacc> sergiusens: ack, just happened to break us pretty badly :)
[17:11] <sergiusens> nacc: try the deb on bionic or the snap on artful, they should do the right thing
[17:12] <nacc> sergiusens: well, snapcraft cleanbuild jsut started failing on my bionic mahcine at home
[17:12] <sergiusens> nacc: it eventually broke everyone as it is a feature tied with single threaded strings
[17:12] <nacc> sergiusens: oh you mean for the above change, ack
[17:12] <popey> arm1e: it's in the package.json
[17:13] <nacc> sergiusens: the problem is right now i can now no longer cleanbuild and i can't get LP to build correctly because xenial-updates is busted :(
[17:13] <sergiusens> nacc: sorry, yeah, snapcraft in bionic-updates will give you what you need wrt to proper "library environemtns"
[17:13] <nacc> sergiusens: cool, i will try it
[17:13] <sergiusens> nacc: and source-subdir is a dreadful feature
[17:13] <sergiusens> nacc: the other dreadful feature we have is that we do not require `setup.py` in the source :-/
[17:17] <sergiusens> nacc we plan to do an SRU on Monday, I will make sure to include a fix for you
[17:25] <nacc> sergiusens: i can imagine; what would you recommend i do in the meantime?
[17:25]  * kalikiana heading out for the day
[17:25] <nacc> sergiusens: any idea on the version thing?
[17:26] <sergiusens> nacc: I think it is related to running pip from that source and a lack of .gitignore; I can run locally to determine which file is getting layed out where it shouldn't
[17:26] <nacc> sergiusens: would it make sesne to get the version *before* doing the build?
[17:26] <nacc> sergiusens: since using git to get the version is an attribute of the original repository
[17:27] <sergiusens> nacc: the reason it is done this way is to account for all the possible scenarios; this feature was mostly done to support giving the core image a version which would attach the version of snapd inside it; that meant; after the livecd-rootfs build was done and primed
[17:28] <sergiusens> nacc: but yeah, for `git` specifically we could
[17:28] <sergiusens> we will be working in the coming weeks on pre/post prepare,build,stage,prime and adding setters for version, description and summary as a start which could be scripted any way you like
[17:29] <nacc> sergiusens: nice
[17:41] <sergiusens> nacc: I will migrate to a faster location and work on this, I will keep you updated
[17:41] <nacc> sergiusens: thanks, i really appreciate it
[17:47] <cachio__> zyga, there are many diffs
[17:48] <cachio__> zyga, the systemd part is the same
[17:58]  * Chipaca EODs
=== alan_g is now known as alan_g|EOD
[18:14] <cachio__> mvo, I found something interesting
[18:15] <cachio__> mvo, if I upgrade from 2.29 to 2.32 it works
[18:15] <cachio__> it I upgrade from 2.31.1 it fails
[18:15] <mvo> cachio__: woah, that is interessting indeed
[18:29] <mup> PR snapcraft#1975 opened: python plugin: find setup.py when source-subdir is used <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1975>
[19:34] <sborovkov> Hi. Can anyone take a look at this forum thread? Ubuntu core nodes just die after few hours of uptime. https://forum.snapcraft.io/t/how-to-figure-out-why-ubuntu-core-keeps-restarting/4257/2
[19:34] <sborovkov> which seems to be a pretty serious issue
[19:35] <zyga> re
[19:35] <zyga> cachio__ did you unpack maintainer scripts?
[19:35] <zyga> as in, did the tree contain the upper-case DEBIAN directory
[19:36] <zyga> cachio__ and if so, did you did that part as well
[19:36] <cachio__> zyga, no that part
[19:37] <cachio__> something weird is that upgrade 2.29 - 2.32 works
[19:37] <cachio__> 2.31.1 - 2.32 doesn't
[19:38] <cachio__> I was running ubuntu core now
[19:38] <cachio__> zyga, there is an error that you could be interested
[19:38] <cachio__> the layout test is failing in ubuntu core
[19:40] <cachio__> zyga, last exec it passed
[19:41] <arm1e> popey: Sorry, had to sort kids. I am looking for the package.json file and it does not mention electron builder. There is one in the electron folder and another in the core folder
[19:41] <cachio__> zyga https://paste.ubuntu.com/p/wgDf97qZRP/
[19:41] <cachio__> zyga,  there is a denial
[19:42] <cachio__> but it is not failing 100%, sometimes it passes
[19:43] <zyga> I saw that error and that denial, not sure what's wrong yet
[19:43] <zyga> I'm spending time with my son now (homework)
[19:43] <zyga> cachio__ but I have one idea what is wrong with layouts now
[19:43] <zyga> may be the same bug, not sure yet
[19:44] <cachio__> zyga, sure, np
[19:47] <arm1e> can anyone help teach me about snapping an electron app please?
[19:48] <cachio__> zyga, the control files are identical
[19:49] <cachio__> for 2.31.1 and 2.32
[19:49] <cachio__> the only one diffs are some dependencies
[19:58] <arm1e> anyone help with building an electron app please? I cant find the "scripts" stanza in the package.json file
[19:58] <arm1e> there is no build or target
[20:09] <roadmr> hi sergiusens . parts-service is borky because one of the parts has yaml syntax errors. I contacted the author hours ago but nothing. WHat's usually done here? remove the part entirely?
[20:10] <sergiusens> roadmr: yes, remove the part
[20:10] <sergiusens> comment it out
[20:10] <roadmr> sergiusens: will do
[20:10] <roadmr> thanks!
[20:13] <mup> PR snapd#4755 closed: snap/squashfs: add BuildDate <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4755>
[20:57] <mup> PR snapd#4778 opened: tests: moving debian 9 from linode to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4778>
[21:38] <jdstrand> slangasek: hey, do you have a moment to talk about https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1751667
[21:38] <mup> Bug #1751667: classic snap does not run on live session <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Confirmed> <ubiquity (Ubuntu):New> <https://launchpad.net/bugs/1751667>
[21:39] <slangasek> jdstrand: sure
[21:40] <jdstrand> slangasek: I can give you the summary
[21:40] <jdstrand> slangasek: if you recall, the bionic kernels use overlay
[21:41] <jdstrand> slangasek: so I fixed that and classic and strict (and devmode) snaps all work (yay, will be in 2.32)
[21:41] <slangasek> nice!
[21:41] <jdstrand> slangasek: but something regressed in bionic in that nothing in /etc/apparmor.d/ is loaded
[21:41] <slangasek> hmm
[21:41] <jdstrand> slangasek: which causes snap-confine to fail like so:
[21:42] <jdstrand> $ hello-world
[21:42] <jdstrand> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[21:42] <jdstrand> slangasek: this happens with  just the livecd today, so you don't even get to the point where overlay broke things
[21:43] <jdstrand> slangasek: I couldn't remember what you did before to make classic snaps work
[21:43] <jdstrand> slangasek: really, we do *not* want to load all of /etc/apparmor.d, but we do want to load /etc/apparmor.d/*snap-confine*
[21:43] <jdstrand> slangasek: so I think in the general case, the livecd is doing the right thing
[21:44] <mwhudson> can we blame casper
[21:44] <jdstrand> slangasek: but we're missing the 'apparmor_parser -r /etc/apparmor.d/*snap-confine*' somewhere
[21:44] <slangasek> jdstrand: doesn't snap-confine being confined rely not just on /etc/apparmor.d being loaded, but also on snap-confine being at /usr/lib/snapd/snap-confine , which it isn't, because overlay?
[21:44] <jdstrand> slangasek: no
[21:45] <jdstrand> slangasek: if I do 'sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*', then I can run hello-world and see the overlay denial (or if you have my deb, it works)
[21:45] <slangasek> jdstrand: as far as what we did previously, I don't think we did anything... subiquity Just Worked by accident, and then failed when snapd restarted, so we fixed it so snapd didn't restart
[21:45] <mwhudson> subiquity is ok in this case because it runs as root
[21:46] <jdstrand> oh, was classic ever only ok with subiquity?
[21:46] <jdstrand> I was thinking ubiquity, but maybe it never worked there
[21:46] <slangasek> we never tested on ubiquity
[21:46] <jdstrand> slangasek: I think reexec will work with snapd 2.32 btw
[21:46] <jdstrand> ok, then no regression
[21:46] <jdstrand> I mean, someone should check subiquity-- pretty sure it will die without snapd 2.32
[21:47] <jdstrand> how could it not?
[21:47] <jdstrand> slangasek: ok, so if you were going to fix this in ubiquity, what would you do?
[21:47] <mwhudson> er hm if i load the apparmor profile subiquity doesn't start, complains about libudev.so.1
[21:47] <mwhudson> oh right that's the sort of thing 2.32 fixes
[21:48] <jdstrand> slangasek: all I want is to load the snap-confine profiles
[21:48] <mwhudson> jdstrand: what loads the profiles in a normal boot?
[21:48] <jdstrand> mwhudson: how does it complain about libudev.so.1?
[21:48] <mwhudson> jdstrand: DENIED on /rofs/lib/x64-64-linux-gnu/libudev.so.1
[21:49] <jdstrand> mwhudson: the apparmor init script. it knows that if it is on livecd not to load
[21:49] <jdstrand> mwhudson: that seems like you are not using the overlayfs kernel?
[21:49] <mwhudson> oh maybe this is aufs still :(
[21:49] <jdstrand> mwhudson: artful used aufs, so I would expect denials on /rofs
[21:50] <mwhudson> yes it is
[21:50] <jdstrand> mwhudson: bionic is shiny and uses overlay. you would see denials on /upper/... for various thinfs
[21:50] <jdstrand> things*
[21:50] <mwhudson> because https://code.launchpad.net/~mwhudson/debian-cd/live-server-cmdline-2/+merge/336177 is not merged
[21:51] <mwhudson> slangasek: can you merge that branch?
[21:51] <jdstrand> mwhudson: ah. yes, if you merge that and get snapd 2.32 (couple weeks?) that should work
[21:51] <mwhudson> slangasek: adam has long passed the timeout for complaining :/
[21:51] <slangasek> jdstrand: I think I would check where the at-boot apparmor_parser is being suppressed, and add an exclusion there for snap-confine.  Which I think means casper
[21:51] <jdstrand> slangasek: let me check something
[21:52] <slangasek> mwhudson: not currently, my stack is full.  email?
[21:52] <mwhudson> slangasek: ok
[21:52] <mwhudson> slangasek: is there anyone else who can review this stuff?
[21:52] <jdstrand> [ -d /rofs/etc/apparmor.d ]  && exit 0 # do not load if running liveCD
[21:53] <jdstrand> that is in /lib/apparmor/profile-load
[21:53] <jdstrand> and that exists in bionic
[21:55] <jdstrand> slangasek: so you are suggesting I do something more like: [ -d /rofs/etc/apparmor.d ] && apparmor_parser -r /rofs/etc/apparmor.d/*snap-confine* ; exit 0
[21:55] <jdstrand> I might have to tweak that for the shell, but you get the idea
[21:58] <jdstrand> slangasek: you know, actually, profile-load isn't used by the systemd unit
[21:58] <jdstrand> I'll look at casper
[22:00] <jdstrand> ah, but the initscript does
[22:00] <jdstrand> (apparmor's)
[22:01] <mwhudson> jdstrand: the service has conditionpathexists=!/rofs/etc/ ...
[22:01] <jdstrand> slangasek: ok, well, thanks for letting me bounce ideas off ofyou :)
[22:01] <mwhudson> and it calls the initscript, which has the same checks again, its seems...
[22:02] <jdstrand> since the initscript has it, I can remove the conditional
[22:02] <jdstrand> in the service
[22:03] <mwhudson> i guess that might affect things that require= on apparmor.service?
[22:03] <mwhudson> i don't know if there are any of those though
[22:03] <jdstrand> so the service calls the initscript, the initscript just loads those two things
[22:03] <mwhudson> oh right yes
[22:04] <mwhudson> once snapd 2.32 is in bionic please :)
[22:05] <jdstrand> mwhudson: why? the profiles are fine to load
[22:06] <jdstrand> mwhudson: loading the profiles just means that snaps fail to run in a different way
[22:06] <jdstrand> mwhudson: am I missing something?
[22:15] <slangasek> jdstrand: the conditional on the service surely makes a difference for whether dependent things consider the service started or not
[22:15] <slangasek> or to-be-started
[22:15] <slangasek> but maybe that gives the wrong answer here in any event
[22:15] <jdstrand> Condition: start condition failed at Thu 2018-03-01 21:18:49 UTC; 45min ago
[22:15] <jdstrand> that is what we have now
[22:16] <mwhudson> jdstrand: if the profiles are loaded subiquity fails to start
[22:17] <mwhudson> jdstrand: in the current situation the 'elevated privileges' check only fires if subiquity is started as non-root, which isn't interesting anyway
[22:17] <jdstrand> ah
[22:17] <jdstrand> yes
[22:18] <jdstrand> but if it is root, then snap-confine dies cause of /rofs
[22:18] <jdstrand> got it
[22:19] <jdstrand> maybe it would be better if snapd loaded them
[22:20] <mwhudson> right
[22:31] <jdstrand> bah, my test case was bad. snapd *will* load the profile itself. *sigh*
[22:32] <jdstrand> systemctl start snapd with 2.32 will load the profile since it generates the overlay. in the bug I did the wrong thing to reproduce
[22:32] <jdstrand> at least we know how to fix subiquity now :)
[22:32] <jdstrand> s/overlay/overlay policy/
[22:36] <jdstrand> sorry for the noise
[22:48] <mup> PR snapd#4714 closed: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/4714>
[22:50] <arm1e> I have been trying to snap up an electron app but I can't find the relevent sections in the json file. Can anyone please help
[23:00] <arm1e> I have been trying to snap up an electron app but I can't find the relevent sections in the json file. Can anyone please help
[23:00] <nacc> arm1e: i've never built an electron snap, but i can try and help
[23:00] <nacc> arm1e: what happens when you try to snap it?
[23:17] <mup> PR snapd#4779 opened:  interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779>
[23:18] <arm1e> Failed to parse package.json data.
[23:18] <arm1e> npm ERR! package.json must be actual JSON, not just JavaScript.
[23:18] <arm1e> npm ERR!
[23:18] <arm1e> npm ERR! Tell the package author to fix their package.json file. JSON.pars
[23:20] <arm1e> nacc, basicallly want to learn how to snap packages but I have no experience of packaging or programming and want to learn.
[23:21] <arm1e> I have completed the tutorial, but EVERY time I attempt to snap something there is a huge hurdle, such as files missing, or expected build properties not present. I just dont know how to learn if there is always a huge problem that I cant understand
[23:23] <nacc> arm1e: and where is the source?
[23:23] <nacc> arm1e: it feels counterintuitive to want to make snaps if you aren't the author of the thing you are snapping
[23:24] <nacc> arm1e: not impossible of course, but it can be harder
[23:24] <arm1e> https://github.com/LightTable/LightTable
[23:25] <arm1e> This is from the Google Code-in stuff I was given by popey
[23:25] <nacc> arm1e: it doesn't seem like a normal electron app, but i don't know
[23:26] <arm1e> Also tried https://github.com/princejwesley/Mancy/blob/master/package.json
[23:27] <arm1e> nacc:  That's what I thought so I gave up
[23:27] <arm1e> I will look into it another day. Too late now, off to bed
[23:27] <arm1e> nacc: thanks for trying :)