User1: good morning
 * zyga preps kids for school
User2: morning
User1: good morning everyone
User1: https://forum.snapcraft.io/t/yes-snaps-are-cross-distribution/3906 <- cool stuff :)
User3: User1 good morning
User4: PR snapd#4637 opened: devicestate: fix the TestDoRequestSerialErrorsOnNoHost failing on artful/bionic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4637>
User1: huh?
User1: mvo can you explain?
User2: User1 User3 morning
User2: User1 iirc there's an ongoing story about pickign the right 'unresolvable' domain in the tests, *.test was suppsoed to be the answer, but my guess is some resolvers were trying to resolve it actually
User2: User1 /var/lib/snapd/mount is something that was introduced in 2.31 cycle?
User1: no
User1: far older
User2: snap-mgmt --purge does not clean it up
User2: i'm checking snapd aur package and noticed that /var/lib/snapd/mount was left behind when i removed snapd-git
User1: mborzecki it's very very old, probably an omission then
User1: mvo could we use something like http://unresolvable.snapcraft.io
User1: and arrange with people so that it never resolves
User1: I'm almost inclined to buy really-nowhere.com ;-)
User3: User1 ups, thanks. so the issue appaears to be that for some daemons artful/bionic returns SERVFAIL instead of NXDOMAIN
User3: User1 its not fully clear yet why, I'm looking into this. we see this on bionic autopkgtests and also on one of my two artful systems
User1: mvo can I help somehow, I can setup nothing.zygoon.pl with any config desired
User1: how are you testing this?
User3: User1 I have one machine where i can reproduce it
User1: is it using systemd-resolved?
User4: PR snapd#4637 closed: devicestate: fix the TestDoRequestSerialErrorsOnNoHost failing on artful/bionic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4637>
User3: User1 I think so, I switched to it a while ago there, I would consider it a fluke without the autopkgtest failure that looks similar
User3: User1 internally we handle SERVFAIL as a temporary error and retry
User1: well, my offer stands, let me know if I can help
User3: User1 this is why we see a test failure, this test is expecting an error and it gets a "doing"
User1: ack
User3: User1 thanks! I will dig a bit
 * zyga looks for a color scheme appropriate for "gloomy polish morning"
User2: gloomy, it's fat thursday today
User2: User1 did you get your donut yet?
User5: User3 hi, don't autopkgtest machines  proxy http(s)? that probably gives a different kind of errors
User1: mborzecki no, not today
User1: mborzecki I will get one in a few days, today is the worst possible day to buy them (unless you make one at home0
User3: User5 thats an interessting idea, they do that
User6: o/
User3: User5 it might be two issues :/ anyway, I get a SERVFAIL in a fresh bionic kvm (which we consider a temp error) so thats something to look into
User7: morning
User1: https://jordaneldredge.com/projects/winamp2-js/ :D
User1: (drag and drop music to play)
User2: User1 i'll sync snapd-git aur PKGBUILD with that of snapd and open a PR to our repo to sync the recipe in packaging too
User1: mborzecki sounds good, thank you
User4: PR snapd#4638 opened: devicestate: fix autopkgtest failure in TestDoRequestSerialErrorsOnNoHost <Created by mvo5> <https://github.com/snapcore/snapd/pull/4638>
User1: anyone (sans chipaca who did) wants to look at https://github.com/snapcore/snapd/pull/4636
User4: PR #4636: snap: understand directories in layout blacklist <Created by zyga> <https://github.com/snapcore/snapd/pull/4636>
User8: i'm wondering snap is being used in the scenario of distributing a library itself. i.e. the package would contain a  standalone app but a library?
User1: wiking it's possible using the content interface
User1: though we have a constraint that snaps can only share among one snap publisher
User9: goooooooooooooooood mornin
User1: if someone wants to maintain a snap that is used by others we need to allow that, it's essentially a promise to maintain something correctly
User1: ikey happy pÄczki day :-)
User1: wiking, for example there's a gnome platform snap (AFAIK) that anyone can use even though it's published by a third party
User1: Chipaca morning :)
User9: zyga, and thee
User10: gnome-3-26-1604
User8: zyga, yeah i'm trying to avoid keep maintaining a deb/rpm package and possibly just switch to snap
User10: User1 moin
User1: wiking though for libraries we recommend just making a part that anyone can use
User1: parts can be easily embedded into an snap at build time
User10: the gnome platform snap is gnome-3-26-1604 right now (the name encodes the abi and base libs to make it easier to pick and choose)
User10: fwiw
User8: zyga, ok so i guess i should be looking into 'Sharing a C-level library'
User1: wiking so, who would consume your library?
User8: anybody who wants to use it? :)
User1: snaps, unlike classic packages, typically don't model runtime dependencies as distinct packages for end-users
User1: I'm almost certain that you want to make a part instead of a snap
User8: oh i see
User1: wiking you can ask kalikiana about parts
User1: wiking you can maintain a part on a shared pool of parts (I forgot the name)
User1: and anyone can build a snap that references your part by name
User8: https://docs.snapcraft.io/build-snaps/parts
User8: i guess
User1: parts are like -dev or -devel packages in classic systems
User1: yes
User8: k
User8: cool thnx for the quick support :)
User1: welcome, enjoy snaps :-)
User8: thnx
 * ikey needs to assault jdstrand's mindbrain today
 * zyga LOLs a little
User6: User9 are you trying to break everyone else's brain by using that weird term? :-P
User9: kinda. xD
User2: #4615 and #4633 are in need of 2nd review
User4: PR #4615: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4615>
User4: PR #4633:  snap: introduce  timer service data types and validation  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4633>
User10: User1 your blacklist checking code still has bugs i fear
User1: yeah?
User10: User1 at least as I understand it
User1: I implemented the thing we discussed last night, I'm adjusting tests to match
User1: what's the bug?
User10: User1 should an entry of /foo stop a later entry of /foo/bar ?
User1: if /foo is a file, no
User1: if foo is a directory, yes
User10: yes foo was a file iin this
User10: why not?
User1: I see what you are saying
User1: technically it will just fail but it should be validated
User1: hmm
User1: but that's good, actually :)
User1: it means validation gets easier
User10: it's good that it'd fail, but my experience is the error is nicer if it's caught in a validation step
User1: yep
User10: User1 does it?
User1: thank you, I'll adjust
User1: I think so
User1: we'll see :)
User10: you still don't want /foo to block /foolicious
User1: sure
User10: so for files it's "is this file a prefix of any complete prefix of this path"
User10: where complete prefix is up to a / or o$
User10: or $*
 * Chipaca is forgetting how to type
 * Chipaca goes to see if coffee is the answer
 * Son_Goku rises from the dead
User1: hey hey
User10: User7 what do you mean with "that's what we do in undoMountSnap"?
User10: User7 backend.UndoSetupSnap _is_ undoMountSnap
User10: unless that is exactly what you mean
User10: (thus my original phrasing)
 * Chipaca seems to be in an argument with himself
User10: no i'm not
 * Chipaca is too
User7: Chipaca, I mean, undoMountSnap calls backend.UndoSetupSnap, which does backend.RemoveSnapFiles
User10: User7 yes
User10: ah
User10: User7 now i understood
User10: User7 and feel dumb :-)
User7: Chipaca, so, it's the same cleanup that mborzecki does on error
User10: yes
User10: User7 I got confused there, sorry, all sorted now (for now!)
User7: no worries, happens all the time here ;)
User10: but there's a big difference
User10: i'll comment on the PR
User2: User10 please do
User7: Chipaca, good! you get my curiosity
User1: good morning niemeyer
User1: you're up early :)
User2: User1 can you give 4571 another pass?
User1: mmm
User1: reading
User1: @: :-)
User1: I know what it does but ... autotools :)
User1: btw, I meant to ask
User1: why do we need another configre.ac there? (in data0
User1: I never used a tree with more than one
User1: could those things be rolled into the main one?
User1: mborzecki ^
User2: User1 with paths going from cmd to ../data? hm don't know if out of source tree builds with work this way
User1: yeah
User2: User1 nvm, i can try that
User1: I'll read on
User11: User2 they don't
User10: User2 I was wrong
User2: User3 RemainAfterExit=yes is interesting, ^C when systemctl start is waitig does not make the service exit, it keeps on working in the background, trying to start it again sort of hangs/hooks to the job that already runs
User3: User2 hm, so its not a solution for us?
User11: User2 can we please make this so that --libexecdir=/usr/libexec works like it's supposed to?
User11: the only reason it doesn't currently is because of inconsistent implementations in makefiles/autofoo
User1: mborzecki done
User2: User11 have this in a separate branch now, quite a lot of changes, first i'd like to have autotools in data and then fix the libexec (would make the diff smaller also)
User11: and please use pkgconfig stuff
User11: it's already there since you've autotoolized it
User11: no reason not to
User10: my typing *and* my language (and probably my diction!) are shot to hell today
User2: User3 feels like this setting should be exposed in snap.yaml instead, it will change the behavior of the unit a bit, once started it sort-of remains 'active' until you stop it, meaning when ExecStart exits it's still considered active
User10: User2 still, +1, and maybe even good news :-)
User2: User10 btw. i recall there was a lp bug about snap try that failed would leave some stuff behind and remember going through this code once already ;) (although i didn't know that undo is only run if task was successful)
User1: Chipaca she sells sea shells on the ...
User10: User1 she sells sea shells on the sea shore // mollusc moltings mostly make measly money // the lady later lacks lucre and leans on loans // she barters her business to barely bypass bankruptcy // turns out tacky tourist trinkets turn in ten times the take // she shelves t-shirts by the sea shore.
User1: wow, I didn't know most of them
User10: User1 that's a newer take on the old one
User1: must write down for at-the-pub fun
User10: User1 https://www.smbc-comics.com/comic/2014-07-23
User10: User1 the original is making fun of a very early (and mostly ignored) paleontologist, https://en.wikipedia.org/wiki/Mary_Anning
User2: it'd be so nice if gnome-shell didn't log an exception every 3 seconds :/
User1: better not press ctrl-c
User1: it's like "red... no blue YAAAH"
User2: heh, use log is full of this BS: https://paste.ubuntu.com/26540491/
User2: and it's not even the extensions
User10: User2 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887082 /
User10: ?
User2: User10 yup, that's the one
User4: PR snapd#4612 closed: snap: exclude `gettimeofday` from `snap run --strace` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4612>
User2: User3 i think we could run `systemctl start --no-block always`, if the unit files are bad (dependencies are wrong, format is incorrect) systemctl fails right away, and then we proceed to stop all the services in the cleanup phase
 * pedronis lunch
User3: User2 this does sound good to me
User10: User2 User3 is this --no-block + poll?
User2: User3 we may consider waiting for a while to see if they do not enter a failed state, but this sounds like a compication and the 'while' may be hard to agree on
User2: User10 --no-block, with optional poll to see if ActiveState is not 'failed'
User10: User2 a'ight
User3: mborzecki, User10 what kinds of "gurantees" do we currently get from systemctl start? my understanding is that its not that much anyway but should not regress here of course
User10: User3 it comes back when the exec of the thing succeeded
User10: User3 or when the thing notified it was up, if it's a notifier
User10: User3 or when it finishes running, if it's a oneshot
User10: User3 or or or
User10: :-)
User10: User3 that's part of the problem :-)
User3: /o\
User3: indeed
User10: no-block + poll lets _us_ decide the vagaries (and makes cancelling cleaner)
User2: User10 User3 if i'm reading systemctl source code right, without --no-block, there will be a wait set up, for each of the jobs that failed, if any of those failed systemctl exits with error status
User4: PR snapd#4619 closed: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4619>
User1: Chipaca can you please have a 2nd look at 4636
User1: I implemented the thing we discussed last night
User1: and you would be the perfect 2nd reviewer
User10: User1 i like it
User10: User1 i'll go deeper after the standup
User1: thank you!
User12: User10 You coming?
User10: User12 nah
User13: zyga, any ideas here? https://askubuntu.com/questions/1004203/installing-snapd-on-14-04-fails
User1: yes
User1: 3.13
User1: install snapd, reboot
User1: it works
User10: would now be a good moment to start freaking out because there's an ubuntu on its way to the asteroid belt
User10: â¦ and it's not going to be getting updates!!! /o\
User10: it's going to be _so_ rootkitted by the time it gets back
User1: pesky space worms will eat it
User10: User1 https://i.imgur.com/vCrOo9e.gifv
User14: ctrl-?meta-j29
User14: ups, ignore that
User1: kyrofa I replied on the forum
 * kalikiana going out for lunch, back later
User15: mvo, hey
User3: User15 hey
User15: mvo, I see this error compiling snapd on bionic https://paste.ubuntu.com/26541162/
User15: mvo, any guess?
User5: User15 hi, did you manage to start uploading some of those snaps that were missing in staging?
User1: mvo oh btw, I didn't get that snap to work yesterday
User15: pedronis, yes, the snaps are in the store
User1: but it should be ok now
 * pstolowski lunch
User1: I noticed that the build got done but upload failed because of stale auth
User5: User15 thx, I'll try again with the tests later today
User15: pedronis, still working on some fixes
User5: ok
User3: User1 what snap was that?
User5: User15 let me know if IÂ can help, also a couple we can just skip as discussed (lxd, canonical-livepatch and core transition)
User3: User15 hm, I have not seen this yet
User1: mvo the one you poked me about, snapd-hacker-toolbelt
User10: User1 #4606 could use your eyes
User4: PR #4606: snap: use custom unsquashfsStderrWriter for unsquashfs error detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/4606>
User3: User1 aha, irght
User3: User1 right thanks
User1: Chipaca sure, opened
User3: User15 golang in bionic is on 1.9 now, maybe that is the problem, let me check
User3: User15 hm, no, its like this for some time
User1: niemeyer btw, I forced myself not to fullscreen any windows now
User1: and I think I'm getting used to it
User1: I can fit a few 1080p "big" windows easily and the habit of getting everything maximised is just that, a habit
User3: User15 let me upgrade to bionic to test
User15: mvo, nice, tx
User15: pedronis, I uploaded 4 snaps
User15: for amd64 and i386
User3: User15 hm, there was a new golang-1.9 upload during the night it seems
User3: User15 so maybe/probably that is the reason
User15: mvo, mmm
User3: User15 but its a point release, should not break like this
User3: "should" :)
User3: anyway, once my upgrade is done I will know
User15: mvo, btw I am using the cloud image that perhaps has some differences with yours installation
User3: User15 I have a cloud image vm at hand too which I can try. I assume you did something like "sudo apt build-dep snapd" at some point, i.e. its not something like a missing pkgconfig or something like this (the error indicates its not)
User15: mvo, I updated the prepare-project script to use the external backend to test bionic
User15: mvo, I am using the same code we have to build in linode but in the external backend
User3: User15 ok
User16: User9 hey, steam-support is not forgotten! I traveled last week to the snapcraft sprint and a couple of other things came up, but as of last night, steam-support is back on top of the list so planned on working on it today
User16: User9 sorry for the delay
User9: yeah no worries bud, just figured id prod
User1: hey jdstrand
User16: it wasn't going to make 2.31 anyway, so still no issues with 2.32
User9: yeah figures
User16: hey zyga :)
User1: I'm working on hardening, I won't push anything major for you to review today though
User16: User1 cool (on both counts)
User1: landing existing stuff is fun enough :)
User16: it's getting quite close :)
User16: User1 let me double check with you. your changes to the content interface recently were a) only about the slot side and b) add a new 'source' attribute that has read and write lists under it, which may not be specified alongside the legacy read and write attributes. read and write legacy attributes are still supported
User16: User1 is that a good summary?
User1: yes
User1: that's accurate
User16: (I phrased that slightly weird, source is alone, read/write may continue to be used instead of source)
User16: ok cool
User4: PR snapd#4639 opened: store: enable deltas for core devices too <Created by mvo5> <https://github.com/snapcore/snapd/pull/4639>
User16: so, the review-tools now understand this :) (not in prod yet)
User1: woot, great
User3: User15 I can reproduce the error
User15: mvo, good
User16: I looked at the PR and it was clear enough, I just wanted to double check since the updated docs aren't there yet
User15: mvo, yesterday I was using a prebuilt core
User15: but then I tried to run all in the bionic and I got that error
User1: Chipaca replied
User15: pedronis, I see this errror https://paste.ubuntu.com/26541264/
User15: but the weird part is that test-snapd-base-bare snap is uploaded in the staging store
User5: User15 ah
 * zyga returns to snapshots
User3: cachio_, mwhudson it looks like 1.9.4 #cgo LDFLAGS whitelisting broke snap-seccomp
User15: pedronis, not sure which could be the reason
 * Chipaca hugs zyga
User5: User15  IÂ dont't see that snap
User5: not in stable?
User5: no, sorry, mistyped
User5: User15 wondering if core is too old in that test
User5: User15 test-snapd-base-bare  seems to have the wrong type,   it says application and not base
User5: same in prod though
User5: mmh
User3: cachio_, mwhudson https://github.com/golang/go/issues/23672 is the issue, our ldflags -Wl,-Bstatic are not longer allowed
User1: hmm
User1: mvo are we in trouble?
User3: User1 a bit
User1: a little bit or the grammatical bit where it's really a bucket full of trouible
User5: User3 any idea why base snaps would work with the production store, but not staging (IÂ don't know what would be different)
User1: *trouble
User3: User1 our static linking in snap-confine of libseecomp no longer works
User1: hmmm hmmm
User3: User5 work in the sense that snap install base-18 from staging does not work?
User1: is that related to golang or to something else?
User5: User3 this  https://paste.ubuntu.com/26541264/
User3: User1 golang upstream change
User5: from cachio_
User3: User1 https://github.com/golang/go/issues/23672
User5: the base snap is there in staging, with the wrong type fwiw,  but it has the wrong type also in production afaict
User3: cachio_, pedronis is test-snapd-base-bare published in staging into the stable channel?
User1: mvo hold on but snap-confine is in pure c
User1: or did you meant snap-seccomp
User3: User1 sorry, snap-seccomp
User1: ahh
User1: ok
User1: well
User1: that sucks
User1: mvo let me know if you want to discuss options
User1: we could dlopen libseccomp from core perhaps
User15: mvo, yes
User1: (that would be good on a few levels, at least)
User15: mvo, in staging for all the archs in all the channels
User5: User15 what snapd version is in use there,  IÂ suppose master?
User15: pedronis, yes
User3: User1 I need to think a little bit about it, but it sucks
User5: User15 I can try as well in a little bit, not sure what would be different in staging though
User15: pedronis, it is weird because I can install test-snapd-base-bare
User15: in the staging store
User15: but if it used as base snap it cannot be found
User3: User15 quite confusing
User16: User13 hi! weird: kernel: [1304675.438833] audit: type=1400 audit(1518072222.273:174): apparmor="DENIED" operation="exec" profile="snap.nextcloud.mysql" name="/bin/systemctl" pid=19425 comm="mysql.server" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
User16: User13 I think it is falling back though, since I see: nextcloud.mysql[19403]: Shutting down MySQL
User16: nextcloud.mysql[19403]: .. *
User16: systemd[1]: Stopped Service for snap application nextcloud.mysql.
User2: User3 User1 moving each -Wl into separate line does not help I guess?
User3: User2 I can try, I think its a whitelist
User2: right: there's a review for --as-needed https://go-review.googlesource.com/c/go/+/92795
User2: User3 and thre are environment variables too
User2: User3 https://go.googlesource.com/go/+/867fb18b6d5bc73266b68c9a695558a04e060a8a
User2: this piece in particular: https://go.googlesource.com/go/+/867fb18b6d5bc73266b68c9a695558a04e060a8a%5E%21/#F3
User2: User1 tried this in the autotools branch https://paste.ubuntu.com/26541368/ automake went down with some bs error, clearly confused about the relative paths
User1: uh
User1: mborzecki what if we moved those upstairs
User1: that would work, right?
User2: that would work, but it will also clutter the toplevel dir
User17: is there a list of env vars available for use in snippits in snapcraft? (not for snaps themselves)
User1: sure
User1: Chipaca I added a review to snapshots (half of review really)
User2: User1 otoh, it's 3 files at most that need to be kept in the tree -> configure.ac, Makefile.am, autogen.sh, the rest is just temporary artifacts
User1: yeah
User1: maybe that's the solution
User1: mborzecki so
User1: mborzecki another idea
User1: how about if we add .dot-dot symlink
User1: and make data show up as cmd/.dot-dot/data
User1: :D
User2: hmm might work, let me try
User1: looking at 4606 now
User2: User3 by the looks of it, the arch package does not build due to the go changes atm
User2: right, pkg-config is broken now too
User2: go build github.com/snapcore/snapd/cmd/snap-seccomp: invalid pkg-config package name: --static
User2: User1 can you take a look at https://github.com/bboozzoo/aur-snapd/pull/3 ?
User4: PR bboozzoo/aur-snapd#3: snapd: updates <Created by bboozzoo> <https://github.com/bboozzoo/aur-snapd/pull/3>
User4: Issue snapcraft#1921 opened: Evaluate contents of manifest.txt, add reasons and surface to the user during staging <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1921>
User1: yes
User2: i'll push another fix with a workaround for go1.9.4 in a minute
User1: mborzecki done
User2: User1 thanks
User1: Chipaca +1
User4: PR snapd#4606 closed: snap: use custom unsquashfsStderrWriter for unsquashfs error detection <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4606>
User1: pstolowski which PR should I review first for you?
User7: zyga, #4401 please, thanks!
User4: PR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>
User4: PR snapd#4636 closed: snap: understand directories in layout blacklist <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4636>
User16: davidcalle (cc sergiusens): hey did you see my comment yesterday about https://docs.snapcraft.io/deprecation-notices/dn5?
User18: User16 is this the right report a bug against the snap review tools? https://bugs.launchpad.net/review-tools
User16: User18 I'd prefer that, yes (at some point soonish we'll deprecate click-reviewers-tools bzr branch and use only the review-tools git banch, so it would be good to get used to it)
User18: it was the first hit when i googled, :)
User18: thanks
User16: User18 before you file, perhaps you could say what the problem is now? quite a few updates are on their way to prod
User18: User16 I wanted to suggest that we prevent "empty" snaps from landing in the stable channel. In the same way we don't allow grade: devel ones in stable.
User18: e.g. there is a snap which just landed in stable called "toto". It is entirely empty, contains only a snap.yaml, nothing else.
User18: this shouldn't be allowed to land in stable IMO
User10: User1 woo
User16: User18 interesting. ok, file away :)
User18: ta
User16: User18 note that the review tools aren't run on channel promotions, only the initial upload, so a change tot he review-tools would mean no empty snaps in any channel
 * zyga breaks for back pain
User18: awww
User1: I'll continue reviewing 4401
User1: but later
User16: User18 the snapstore could, in theory, peek back at a previous run for channel promotions. that would need some design and likely help from the review tools
User16: User18 I'm not sure at what priority that would be. I'm guessing quite low for this particular issue
User16: User18 tbh, an empty snap seems like it isn't valid in any channel though
User18: User16 i think some might argue that it's not fair for a new developer to get punched in the face with words like "error" and "reject" as they're starting out with snaps
User16: User19 hey, do you have a moment to kick around an idea for organizing a new steam-support interface
User16: User18 well, they'll face all those same words if they do other things wrong. why is that one special?
User16: eg, the pick an invalid snap name
User16: they*
User18: *shrug* emoji
User16: User18 I'll put it this way. if you file the bug, I will fix it and this will apply to everything. if you don't, I'll conveniently forget about it. if you think the snapstore should support peeking back on channel promotions, then file it against the snapstore and add a review-tools task
User18: ok
User7: niemeyer, pedronis could you please take another look at #4401?
User4: PR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>
User19: User16 sorry, yeah I have a few minutes, /me is getting kids ready for school
User12: User7 SUre thing
User5: User7 likely tomorrow morning
User1: jjohansen o/
User5: User15 User3 I think the issue is that /details for test-snapd-busybox-static  doesn't have base set
User5: in staging
User19: hey zyga
User5: User15 User3 I remember some discussion about needing backfilling for something, and decided it was not worth it, it probably needs to be uploaded again
User5: unless it was just uploaded in which case, something else is going on
User15: pedronis, ok, I'll upload it
User16: User19 just ping me when ready. it might take up to 15 or so
User16: maybe faster. I tripled what I thought it might take :)
User5: User15 it seems old even in staging, afaict
User5: so re-uploading from prod to staging should help or so IÂ hope
User15: pedronis, I planned to copy the one in prod to staging
User5: sounds good
User15: pedronis, ok
User15: mvo, could you please share test-snapd-busybox-static with me?
User19: User16 15 min to discuss or implement?
User19: :)
User16: User19 hehe
User19: User16 shoot I have 15 min
User16: User19 it's true, I could just say 'you get the wide-open classic template' and *boom* it works :P
User16: User19 ok, more seriously
User3: User15 sure, one sec
User16: User19 architecture is this: steam has a steam client. the client allows you to buy, install, remove and launch games
User15: mvo, tx
 * zyga returns to being off, sorry :/
User3: User2 yeah, same problem everywhere I presume, the go change is a security update so I guess its applied everywhere :/
User16: User19 many steam games use a process lifecycle where they will ptrace child processes
User16: User19 this is just how it goes (proprietary blobs)
User19: User16 have I mentioned how much I hate proprietary blobs lately
User2: User3 i've pushed a fix to arch package, so that it builds now :/ funny cause it was building in the morning (i was working on it a bit), then ~2pm they pushed an update of go and it broke
User1: Chipaca I pushed 4640 with one more layout feature
User3: User15 on your way
User16: User19 so I had the idea that it would be nice if the launcher was in one profile, and it would launch games in a different profile. we'll call the launcher profile the client profile and the games profile the game profile
User4: PR snapd#4640 opened: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640>
User3: User2 what fix did you use? CGO_LDFLAGS_ALLOW=.* or similar :) ?
User15: mvo, tx
User16: User19 the game profile would be under a different label, and it could ptrace itself (let's not worry about seccomp in <4.8 kernels for this discussion) but not the client
User2: User3 just this patch https://github.com/bboozzoo/snapd/commit/3286baf646fa7974c165efd9b63c690d08dff6b7 the rest seemd to build just fine
User12: User7 LGTM I think.. I've skimmed through it, and haven't spent as much time on it as last time, but if pedornis is happy and it works, I'm happy with the change
User3: User2 ok
User2: User3 and we did disable the static linking in arch anyway as libseccomp is only dynamic
User12: It's certainly quite nice to have auto-connect on its own task
User3: User2 aha, ok
User7: niemeyer, ty
User16: User19 so, that is the germ of the design. in terms of implementation, I really want to use a Px rule with a sibling profile, because of the way snapd is architected and generates profiles, that is convenient
User19: User16 ack, launcher, client, game A, game B, game C, profiles ...
User16: User19 but I ran into: https://bugs.launchpad.net/apparmor/+bug/1696552
User4: Bug #1696552: syntax errors when specifying px rules with exec transitions that have '.' in the name <AppArmor:New> <https://launchpad.net/bugs/1696552>
User2: ok, end of the week for me, cu all on monday
User19: User16 oh, sorry I meant to have that fixed already, I can add it to todays todo, its an easy fix
User16: User19 launcher/client are the same, games likely will share a profile in the initial implementation since the steam client (proprietary blob) has no concept of change_profile/etc
User16: User19 (I would use file rules to transition to the games profile)
User16: User19 well, I was trying to think through that. yes we should clearly fix the parser. that is a given
User19: User16 that makes me a sad panda but ack
User16: User19 but, that means SRUs for Ubuntu (possible) and then updates for suse, solus, Ubuntu derivatives, etc (improbable for the whole list), which means that steam will work on some distros, bt not others (bad for snapd)
User9: steam what now
User9: ears twitched
User16: User19 re file rules> yeah. not terribly excited by that, but the secret hope is that if we can improve on steam's security story by preventing games from attacking the client, then maybe, just maybe, they'd be open to building something into their client down the line
User16: User19 perhaps a pipe-dream, but one can hope :)
User9: not outside the realms of possibilities tbh
User19: User16 yes, sorry wish I could write bug free software, but I seem to be gifted with talents else where
User9: we already know they flirted with flatpak in the past purely to look only at bubblewrap re: sandboxing
User16: User19 because of what I just mentioned with parser and other distros, I started exploring other ideas
User16: User19 haha, no need to apologize. apparmor is awesome!
User16: User9 hey, I was serious that steam-support was on the list for today :)
User9: :D
User9: kickin ass
User16: User19 so I came up with an idea to use a child profile
User19: that can work
User16: User19 I have two choices with that. one I greatly prefer in terms of snapd architecture
User16: it can. I did it
User16: User19 so, I can either generate profiles like this:
User16: 'profile client { profile { game } }' or I can do 'profile client {} profile client//game {}
User16: '
User16: the second is preferred in terms of how snapd is architected. again, I can do the first
User16: note that in the second, 'client' and 'client//game' are in different files
User16: which means that I need to be concerned about profile load and remove order
User19: User16 so the second is supported, you do need to be worried about order to a degree
User16: I'm able to deal with load ok, but remove generates a parser error because if I unload 'client', it unloads 'client//game' so then when I unload 'client//game' there is an error
User19: if you remove a parent before its child, the child should get repeated as well, and the 2nd remove should complain with ENOENT
User16: precisely
User19: right
User16: I thought I tried it the other way..
User16: (too)
User16: and I think the unload of the parent had a parser error cause the child was already removed
User16: let me double check that
User19: that should just work, if not there is a bug
User19: I also need to fix the parser so that if they are both specified, it just does the right thing
User16: that makes sense
User19: it can figure it out, currently it doesn't
User16: for the snapd case, currently it loads and removes one at a time
User16: I can change snapd to do things of course
User19: User16 I need to step away, finish your dump and I'll answer when I get back
User16: User19 ok, good timing. I couldn't find my profiles so it'll take me a minute
User1: jdstrand anything I can help with?
User10: not for the first time i find myself trying to use markdown in a go comment
User16: User1 not at this time
User9: Chipaca, backtick all the things
User10: ikr
User20: flexiondotorg: I've just promoted audacity to candidate - tell the LNL crew that the last of their three desired snaps is snapped
User9: lol
User20: oh ello ikey
User20: :-p
 * diddledan tells ikey directly
User1: ikey I had that period where everything was pre-formatted and I could not stand otherwise
User9: ello diddledan lol
User9: zyga, i went so overboard on it i added a markdown parser to solus SC
User9: and it has the markdown in the git tags
User9: forms our changelogs :P
User1: that's pretty nice
User9: ref: https://dev.solus-project.com/R3571:37e7f17508ecdedf13f061cad974b2a09ee10687
User9: client side: https://ibin.co/3r15d94CbaGW.png
User9: some stuff like the CVE IDs automatically link
User16: User19 ok, I was wrong: load parent, load child, unload child, unload parent works fine: https://paste.ubuntu.com/26541896/
User16: User19 if I change the load or unload order, then I get ENOENT
User16: User19 which means, I can make this child approach work. I'll just need to adjust snapd to do something special with load/unload with this approach
 * jdstrand now checks what apparmor does with the cache files
User19: User16 the cache file is based on the file name that the child profile is in
User19: so it will get its own cache file if its in a separate file
User19: if you put them in the same cache file they will share
User19: if the compiler merges them into a single cache file
User19: you will get 2 symlinks to the merged file
User19: note: you won't see that one happen yet
User16: User19 interesting. so I could keep the text profiles separate, but have a single cache file
User16: ?
User19: User16 uh theoretically, the current parser don't actually handle that yet
User16: heh, ok, then that is out
User16: but yes, I could put both into the same text file
User19: but you can cat the 2 binaries together to get a single, and it will work
User19: User16 another approach is to do
User19: profile A {
User19: ...
User19: }
User19: include "children"
User19: that would put them in a single text file, and allow you to stash the children profiles in separate files that are out of the regular load path
User19: err, not single text file, single cache file
User19: User16 the parser will pickup the ability to merge profiles into a single cache file when they are specified on the same parser invocation and they meet certain criteria, but there are a few other things I need to land first
User16: User19 so if I do 'profile parent {} profile child {}' in the same file, it doesn't work on unload (ENOENT), regardless of order. (load works both ways)
User19: oh! that would be a parser bug, I wonder when that broke, and why arekm isn't yelling at me
User16: User19 to be clear, if I have the parent and child in different cache files, apparmor_parser will be sensitive to load order?
User16: User19 (this is artful btw)
User19: User16 yes separate cache files will be load order sensitive
User16: ok. I *should* be able to lexically sort them for cache loading
User16: and I *could* adjust snapd for handling load/unload order
User9: doesn't apparmor_parser already do that? given that you can apparmor_parser load a directory that is purely a binary cache
User19: sorry, I'll fix it in the parser too, but that will require and SRU which gets us back to the whole doesn't work every where problem
User9: and no source files..
User16: the question for me then becomes, is that better than profile client { profile game{}}
User19: dammit why didn't you point this out to me 5 years ago
User19: :P
User16: User9 yes but different init scripts do different things
User9: yeah i replaced them with aa-lsm-hook in solus
User16: I need to make sure this works everywhere
User9: for the betters
 * jdstrand nods
User9: gotcha
User19: User16 what of
User19: profile A {
User19: include "children"
User19: }
User19: that should work
User16: let me try that
User19: and allow you to have the children in separate files
User16: User19 children is a dir?
User19: User16 that is up to you
User16: let me try as a file
User19: you could specify specific files, or have a dir you just drop stuff in
User19: come to think of it, I think that is what arekm is doing now, and why he isn't yelling at me for the other being broken
User16: User19 I can't get that to work
User16: User19 https://paste.ubuntu.com/26542021/
 * jdstrand tries a dir
User19: User16 in /tmp/child2
User19: lose #include <tunables/global>
User19: and rename profile snap.steam-client.steam-client//game to just game
User16: that makes sense
User16: ok, that works
User16: I only have to mess with the parent
User9: like any good child would..
User16: it does mean I have to have snapd not do anything with the child profile though
User16: (as in, load/unload it itself)
User16: ok, so several options with the child
User16: 1. embed the child in parent
User16: 2. have child separate from parent, figure out load order in snapd
User16: 3. have child separate from parent via #include, adjust snapd to not fiddle with child in interface connections
User16: these are options I can work through
User16: User19 my next question is: is there anything different I could try that we haven't discussed?
User16: User19 eg, apparmor namespace. I don't *think* so since the Px bug I mentioned was filed when playing with apparmor namespaces
User19: User16 you could use a namespace, I am not sure you want to atm
User19: the scope isn't separated from the view, so once you enter the namespace
User16: User19 yeah, I kept trying to think through if that would help anything, but couldn't
User19: you can't see the rest of the system profiles etc. It more like in a container or VM
User16: plus, the status of namespace support across distros might make it problematic
User19: loading into the namespace has the same issues
User16: oh yeah, that would likely be a lot of trouble too
User16: ok
User16: User19 thanks, this was very helpful
User19: but you could get away with just tearing down the namespace to remove all its policy
User21: User3 doh
User16: User19 in terms of snapd, that change would not be terribly different that just dealing with the parent in option 3
User19: User16 that said I very much would like snappy to use a namespace, I just need to land the scope work and have it propagate everywhere first :(
User21: User3 feel free to upload any fixes you need or tell me what i need to fix...
User19: User16 right
User16: User19 yeah. we'll get there
User3: User21 its a good question, I need to think about it and probably look at the go upstream diff
User3: User21 the change broke both our pkgconfig usage and our LDFLAGS
 * mwhudson goes back to bed for a bit
User3: User21 we use -Wl,-Bstatic
User3: User21 heh, do it, its not super urgent, I call it a day soon here
User16: there is also a variation on one, where I modify snapd such that a snap command could end up as an embedded child profile
User16: but anyway, that is for me to work through
User16: User19 thanks for all your help!
User19: User16 np
User16: User19 there is actually another option. we fix the parser for Px/px and make the use of the interface conditional on that fix being available
User16: this way, anyone distro who wanted the fix could pull the patch into their parser
User16: s/anyone/any/
User16: I'll bring this up to the snapd team
 * kalikiana wrapping up for the day
User3: User1 we will need is-nfs-home: [yes|no] as part of the system-key
User1: mmm
User1: yes
User1: I think so
User3: User1 tests are breaking
User3: User1 without it
User1: hmmm
User19: User16 that works for me too
User3: User1 I need to check, we have a bit of a recursive import problem, some of this code probably needs to go into osutil or something
User1: mvo how did it break, I mean, we test this, right?
User1: mvo, I forgot where I put the nfs code but yeah
User3: User1 yes, this is where it breaks, the test restarts snapd and assumes it re-genreates security profiles
User3: User1 and we no longer re-genreate on every restart
User1: aha, so not broken in the wild, just in an upcoming branch?
User1: or broken in the wild now
User3: User1 not broken in the wild
User3: User1 just in 4629
User1: ahh
User1: god
User1: good :)
User1: I can fix that if you want
User1: can you look at 4640 when you have some time? I will look at nfs part
User3: User1 I would not say no to this offer :)
User1: thank you :)
User3: User1 probably in my morning but yeah, I have a look. I'm bit behind in reviews in general, maybe I can have a review-friday
User3: User1 I also wanted to stop pusing new PRs before my others are landed. but this is really hard
User1: yeah
User1: after this I only have layout spread PR (it depends on it now) and then I'll switch to hardening
User1: Chipaca how about you?
User10: User1 what about me?
User1: fancy doing 4640?
 * zyga looks at nfs untangling
User10: User1 doing it right now
User1: thank you
User1: I want that spread test out there
User1: mvo any objections if I move more stuff to osutil?
User1: like more of mount
User1: I can move it to osutil/mount so that it doesn't cause a massive cluster of alterations if that makes it better
User10: User1 do you find "%[1]s %[1]s" % (a,) clearer than "%s %s" % (a, a)?
User1: TBH, not really
User10: User1 then use the other ones :)
User10: I mean, if you were passing around an enormous struct by value, it might be worth it?
User10: but usually it's not
User10: (in the common case of the thing being a poiner or a simple value, afaict it's more expensive in both memory and time to use the indexed version)
User10: (add to that that it's less clear... Â¯\_(ã)_/Â¯ )
User10: like, 300ns vs 200ns for the two-args version
User10: not that i'd be insane enough to have measured this
 * Chipaca hides
User1: :)
User1: hahah
User1: thank you Chipaca
User1: how long does "time go test ./..." in the root of the project take for you guys/
User1: mvo that will be one big branch
User13: jdstrand, yeah I've looked into that one, even grepped the entire snap and can't find where it calls sytemctl. Wonder if it's in a binary somewhere
User3: User1 I like osutil/mount
User1: I moved it to osutil now, we'll see how that looks like
User16: User13 just looking at the logs, seems to be coming from mysql
User13: jdstrand, yeah, just none of its scripts. I'll take a quick grep of its src
User3: User1 ok, I was thinking it might be easier to use "mount" just like before but of course if we end up with two "mounts" (one in osutil one in interfaces) that sucks
User1: yeah :/
User3: User1 anyway, I will wait for the PR :)
User1: I'm not done, let's see how it looks like in the end
User16: User9 I responded to the forum. I've pinged niemeyer to comment before I proceed
User16: User12 and I pre-apologize for the walls of text between https://forum.snapcraft.io/t/blowing-off-steam-lets-plan-steam-support-interface/3457/14 and https://forum.snapcraft.io/t/blowing-off-steam-lets-plan-steam-support-interface/3457/27, but we're pushing the envelope here
User13: jdstrand, yeah nothing in the source either. No clue what's causing it
User12: User16 Appreciated!
User16: User17 hey, you probably say, but I reviewed pr 4545. lgtm for my stuff, but the changes from zyga prompted some discussion with him
User4: PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
User16: s/say/saw/
 * zyga finished a very boring branch just now
User1: man
User1: the things we have to do to make it compile ;-)
User4: PR snapd#4641 opened: many: move mount code to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/4641>
User4: PR snapd#4642 opened: many: add nfs-home flag to system-key <Created by zyga> <https://github.com/snapcore/snapd/pull/4642>
User1: jdstrand hey, do you have a sec
User16: User1 what's up?
User1: https://github.com/snapcore/snapd/pull/4640
User4: PR #4640: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640>
User1: 65 lines :)
User1: it's something I think we need for layouts and ...
User1: ... :)
User1: could you please look?
User16: man github reviews are pretty ugly with the use of '%[1]s'
User1: yeah, I will change that to %s %s
User17: User16 thanks, I'll wait to be told what to do :)
User16: User1 I wasn't necessarily saying that. personally I do find it easier to read as %s %s, but I can do either :)
User16: that said, I'm fine if you change it :)
User1: please review as-is, i'll do that separately
User1: cool :-)
 * jdstrand nods
 * ikey clicks the forums
User9: apologies for le delay
User9: also the forums is making me think there is gonna be some kind of zombie event soon
User9: massive letters "12 DAYS LATER"
User1: jdstrand updated
User16: User9 hehe
User1: ikey zombie event?
User16: User1 that is much easier on the eyes :)
User9: zyga, 28 days later :P
User9: yknow, rapid moving shoulder munchers
User16: of course, where did my pending comments go...
User1: ikey, you mean stress-eating during weekends?
User1: ;-)
User9: no i mean literal zombies :P
User9: also its not "stress eating". its uhm.. *thinks*.. weekly hormone rebalance therapy.
User9: yeaa...
User1: "literal zombies"
 * zyga turns the dishwasher on
User9: yeah they chase you and say things like "totally" until *you* groan
User1: I think my kids are like zombies sometimes
User1: User16 after that PR I have spread test for layouts
User9: probably a phone app to figure that one out.. ^^
User1: it's pushed, just waiting for the PR to land :)
User1: jdstrand replied
User1: actually edited my response, sorry
User1: jdstrand if that's okay with you I will edit the symlink comment
User1: eh
User1: new golang broke -everything-
User1: not a great tay
User1: *day
User1: jdstrand do you want me to add the examples you listed to unit tests?
User16: User1 please see me comment to your comment. yes, more tests please but note that I didn't enumerate everything in the review
User1: jdstrand the one with 'more subtle' cannot be detected
User1: as yaml will fold the old value and replace with the new one
User1: as for remaining tests, I will add some more but the "bind-file" thing is identical in validation to "symlink" and those have a lot of tests already (though not added in that PR)
User1: The case where the same source is treated differently is interesting, that is not handled yet
User1: it will fail at runtime but it won't get caught by the validator
User1: once master is fixed tomorrow I will add those
User4: PR snapcraft#1908 closed: tests: update tests to work in adt <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1908>
User16: User1 ok, so those are keys to a dictionary. That's fine then. we should have a test that shows only one happened imho
User21: hi when does snapd do the sd_notify thing to notify systemd that it has started up?
User21: in particular wrt seeding on first boot
User21: aha systemd.SdNotify("READY=1")
User21: hm ok looks like it notifies before seeding is known to be done
User21: hmm the idea of having snapd write the unit looks better i think
snappy
Ubuntu IRC