User1: What is the command to install two snaps in sequence ?
User2: kyrofa snapcraft#1719
User3: PR snapcraft#1719: many: account for python shebang args in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>
User4: sergiusens, that didn't restart, it's been going for two hours
User5: User1 not sure i understand? `sudo snap install <snap1>; sudo snap install <snap2>` ?
User2: bummer, why did it start only two hours ago?
User4: sergiusens, I had to start it because snapd toasted my local adt runs
User4: sergiusens, https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/12
User4: sergiusens, also, I did comment in the PR :)
User2: kyrofa yeah, that I did see; do we need this though?
User4: sergiusens, up to you, I'm fairly confident given that I had successful runs before the rebase, but they were on zesty
User2: kyrofa elopio we need less tests, or broader ones; how many of the catkin tests could be merged into one?
User2: same for all the other components
User2: they could be condensed into on with multiple parts/apps
User2: unless it warrants a separate one
User2: but I am going to be pragmatic here, many are only separate because it looks good on paper
User4: sergiusens, remember we're still not re-using the cache
User4: Simpler tests are way easier to maintain
User4: But yeah, we can definitely combine some catkin ones if that's the direction we want to go
User4: This normally doesn't hurt quite so badly, we simply need to get in the habit of running them more often and paying attention to the result. I suggest caution in making decisions about our tests in our current state of pain
User2: kyrofa well, tonight is your night and tomorrow is your morning, right?
User2: :-)
User4: Indeed
User1: What is test-snapd-cups-control-consumer , exactly ? Is it for printers ?
User5: User1 you can read it's description in `snap info test-snapd-cups-control-consumer`
User5: but as the name implies, it's a test snap for snapd to test the cups-control interfcase
User5: *interface
User1: >  A basic snap declaring a plug on cups-control
User1: so its for printers ?
User5: User1 it doesn't do anything, afaict
User5: User1 it's a test snap
User1: okay thanks
User5: User1 to test an interface's functionality, in this case the cups-control interface (which is an interface for printing, yes)
User1: nacc, thanks by the way - can now install 15 snaps ; one after another in one command, cheers pal.
User5: User1 sure, that's not really snap specific :)
User5: User1 i'm not sure if instll can take multiple snap names or not
User5: seems like it probably could
User4: elopio, another PR to snappy-m-o
User4: nacc, `snap remove` certainly can
User4: Haven't tried on install
User5: User4 yeah, me neither :)
User5: User4 never had a reason, tbh
User4: nacc, me neither
User1: User5 that kinda worked ( http://paste.ubuntu.com/25971109/ ) Althou, I think I may have boken pastebin (on the right) :(
User5: User1 not sure what you mean by 'right'? it's just a long linne
User6: snappy-m-o, github subscribe 1719
User3: PR #1719: firstboot: add firstboot assertions importing <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1719>
User6: snappy-m-o, github subscribe 1719
User6: snappy-m-o, github subscribe 1719
User3: PR snapcraft#1719: many: account for python shebang args in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>
User2: snappy-m-o github subscribe 1719
User3: PR snapcraft#1719: many: account for python shebang args in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>
User3: PR snapcraft#1719 closed: many: account for python shebang args in rewrite <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>
User7: User2 hmm, so just noticed something funny... "version: 2.20" results in a snap of version "2.2" rather than "2.20"
User7: User2 updating now to be 'version: "2.20"' which hopefully will fix that issue :)
User2: stgraber oh, yaml; pyyaml parses that as a number; we should probably just update our jsonschema (commented) and enforce the type
User2: kyrofa elopio take a look at snapcraft#1650 again please and I'll merge and tag after the travis tests are done
User3: PR snapcraft#1650: Release changelog for 2.35 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1650>
User4: sergiusens, bug #1732076 will still bite us
User3: Bug #1732076: Plainbox snapd test failure <Snapcraft:New> <https://launchpad.net/bugs/1732076>
User2: kyrofa I'll skip the install part in packaging
User2: kyrofa fwiw, i386 runs on lxd
User2: kyrofa actually, I won't skip it, just document it as part of the SRU
User2: at this point I am more interested in releasing a snap
User3: PR snapcraft#1740 opened: tests: add the home plug to the plainbox snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1740>
User6: snappy-m-o autopkgtest 1740 zesty:amd64
User6: snappy-m-o github subscribe 1740
User3: PR snapcraft#1740: tests: add the home plug to the plainbox snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1740>
User6: snappy-m-o autopkgtest 1740 artful:amd64
User8: morning everyone
User9: hey
User9: how are things?
User8: User9 hey
User8: things are good, the conference was very nice
User8: did you watch the video streams?
User9: no, but I'd like to later
User9: fighting release stuff
User9: https://forum.snapcraft.io/t/2-29-release-cycle-started/2562/7
User8: uhh
User8: what else have i missed?
User9: User8 not much I'd say
User9: User8 we could use some help debugging lxd issues today
User9: User8 I know about one issue that I'll try to finally address but it seems we have one more
User9: https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850
User8: looking
User9: I'm slowly waking up, I was working past midnight
User9: after kids are in school I'll probably take a nap
 * zyga is grumpy because everything fails and needs to be restarted
User9: we could use some time on stabilizing those tests
User8: travis again?
User9: User8 some of our spread tests are flaky
User9: User8 https://github.com/snapcore/snapd/pulls/ all they yetllow ones failed on some random thing
User8: i'll quickly look through those and see if there's anyting with the tests or just the CI was flaky
User8: User9 will artful cloud image be good enough for reproducing lxc problem that kyrofa reported?
User9: User8 I think so
User8: ok
User9: User8 not sure if he used 16.04 or 17.10
User9: User10 good morning
User9: User10 some ungood news: https://github.com/snapcore/snapd/pull/4228
User3: PR #4228: interfaces,tests: skip unknown plug/slot interfaces (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4228>
User9: User10 though please look at the diff, we need to see if this actually makes sense
User9: (I made it after midnight so not super sure)
User9: I was under the impression that the new load-time validation would handle this
User9: this is a regression caused by that patch
User9: it seems we validate a snap and then say "yeah it's broken but I'll load it anywy"
User9: and this is probably a wider hole to fill
User9: User10 other than that we also have the LXD regression, mborzecki and I will look at that (though I'm so sleepy I plan to take a nap for an hour as soon as kids leave)
User10: User9 god morning
User8: User10 hey
User10: User9 thanks for the update
User10: and good morning mborzecki
User10: User9 do we know anything more about the lxd issue? does it affect every snap ?
User10: User9 I also wonder why our lxd-test did not catch it :/
User9: User10 I have some ideas
User9: User10 the namespace didn't exist so snap-update-ns just bailed out
User9: User10 and there were no content changes to apply
User9: User10 this really requires the content interface test
User10: User9 and plainbox is using that iface?
User9: User10 I'm very convinced that we need to try to run the full test suite on lxd and see what is broken
User9: User10 I don't know actually,
User9: User10 it's possible
User9: kissiel: ^
User9: kissiel: is the checkbox/plainbox snap using content interface?
User9: User10 though AFAIK this was a test in snapcraft so perhaps an artificial one
User9: and obviousl I could be wrong and there's something lurking deeper about why this failed
User10: User9 thanks, that is already quite helpful!
User10: User9 hm, kyrofa reproduced it for hello-world in lxc so I doubt its the content iface
User10: User9 it works via sudo
User10: User9 which is also strange but it explains why our test did not catch it, it means a regression test should be simple at least
User9: User10 sudo will fix it because the denial was on cap_read_search
User9: User10 we are apparently trying to traverse a directory that is not readable to us
User9: User10 and then fail on the missing capability
User9: User10 sudo will just give us that
User9: User10 (not the capability but the read permission)
User9: User10 the freezer cgroup setup insie containers is something worth looking at
User10: User9 right, I'm trying to modify the lxd test so that we have a reproducer/regression test
User9: I feel like it's time to crash now, I'll be back closer to 10AM
User10: User9 sleep well
User3: PR snapd#4230 opened: tests: add test to run snap inside lxd as a user <Created by mvo5> <https://github.com/snapcore/snapd/pull/4230>
User8: User10 can i force remove core snap?
User10: User8 unfortunately not, you can "dpkg --purge snapd" (or fedora has a snap-mgr.sh script that does the same) to remove all snaps
User10: User9 just fyi, adding "capability dac_read_search" is not sufficient to fix the lxd issue
User8: hmm cgroup freezer directories are left behind once a snap runs (is that ok?), anyways, when a snap is run with sudo, it will be possible to create a directory under /sys/fs/cgroup/freezer
User10: User8 yeah, see 4230, we have a lxd test but unfortunately it runs as root so it did not catch the bug
User8: omg, broke lxd
User8: i restarted an ephemeral container, now i can't remove it nor stop if
User8: exec doesn't work either
User3: PR snapd#4231 opened: interfaces: add "refresh-schedule" attribute to snapd-control <Created by mvo5> <https://github.com/snapcore/snapd/pull/4231>
User9: re
User9: User10 any news?
User8: User9 snap-confine is setuid root right?
User10: User9 not much, we have a reproducer
User10: User9 in spread
User9: User8 yes
User9: User10 aha, that's good
User8: https://paste.ubuntu.com/25973100/
User8: i build this, make it chown root:root, u+s, and cannot create a frezer group
User10: User9 and the apparmor denial is not it, I added it for testing to snap-confine.appamor.in and it still fails
User10: User9 with permission denied but no apparmor denial anymore
User9: User10 I'm running your test locally now
User10: User9 cool
User3: PR snapd#4232 opened: store: add support for flags in ListRefresh() <Created by mvo5> <https://github.com/snapcore/snapd/pull/4232>
User10: User9 silly question, could we revert the freezer group in 2.29? or would that cause havoc?
User9: User10 I think a bit havoc, I'd have to look
User10: User9 hm, then lets see if we can do a proper fix
User9: User10 hmm, the container is weird
User9: I cannot switch to "ubuntu" user
 * kalikiana coffee
User9: User10 I know what the problem is, I think
User9: User7 around?
User9: User10 http://pastebin.ubuntu.com/25973198/
User9: User10 so two ideas for quick "solution":
User9: User10 1) make that step optional and let it fail, this means mount changes are not atomic in lxd
User9: User10 2) talk to stgraber and figure out why lxd sets up containers this way and what we can do about it
User9: mvo, User8 opinions?
User8: hmm that's why g+s works i guess
User9: User8 correct
User9: User10 it's actually a deeper problem:
User9: root@my-ubuntu:~# ls -ld /sys/fs/cgroup/devices/
User9: drwxrwxr-x 5 nobody root 0 Nov 16 09:13 /sys/fs/cgroup/devices/
User9: User10 unless we somehow disabled all udev tagging inside containers
User9: User10 it will break on when creating the device cgroup
User9: s/on//
User8: that's perhaps silly, but could we g+s snap-confine too? we're dropping both anyway right after setting up
User9: User8 that's another option, indeed
User9: though I'd like to understand the motivation behind lxd choices
User11: moin moin
User9: User11 hello
User8: User11 hey
User9: User11 welcome to the fire dept
User9: User11 pick your hose and let's put out the fires ;)
User11: oh dear
User11: User9 what's on fire?
User9: User11 lxd
User9: https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/12
User9: User11 also snapd crashes:
User9: https://bugs.launchpad.net/snappy/+bug/1732555
User3: Bug #1732555: Installing bad snap has snapd crashing <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1732555>
User9: User11 that one needs some love from pstolowski and perhaps you, something went south very much whe we switched to "validate on load"
User10: User9 hm, reading backlog. sorry, my laptop came back from repair just now (doorbell and all that)
User9: User11 I'm a bit sleepy still
User9: User10 great, did they hide that cable?
User11: User9 both of those claim to have a fix in a pr; is the fire putting out effort needed from me to review those prs?
User9: User10 btw I opened mine and I think I know why your cable was sticking out, there's a compartment for that cable where it's supposed to be held and be attached, if that part is loose it can easily slide through the hinge
User10: User9 yeah, its not longer visible, I wonder where they put it, I'm inclined to open the machine to see what happend to it. but opening the modern ones is a pita (IMO) so I probably won't
User9: User11 lxd is not fixed yet
User10: User9 aha, nice
User9: User11 and the snapd crash is just fixing the immediate problem, the deeper problem is not addresed
User9: User11 it seems the validate-on-load concept is validate-and-log-but-continue-anyway
User10: User9 I had it open before and tried to figure out where it belonged but couldn't find an obvious place and was too impatient then
User9: User10 I bought a x240 for a family member and I opened it to clean it and replace the heatsink thermal glue
User9: User10 (interestingly no internal battery there)
User9: anyway
User12: zyga, i'll look into this, thanks for the intermediate fix
User9: User12 thank you
User3: PR snapd#4229 closed: interfaces,tests: skip unknown plug/slot interfaces <Critical> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4229>
 * zyga is doing code reviews
User9: User10 offtopic, do you remember that zesty issue with the repair systemd unit?
User9: User10 is that something that needs love?
User9: User12 FYI: https://github.com/snapcore/snapd/pull/4228
User3: PR #4228: interfaces,tests: skip unknown plug/slot interfaces (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4228>
User9: User12 2.29 backport of that PR
User10: User9 I remember it, I thought it was conditionally dislabed and that would not put things into degraded state
User3: PR snapd#4228 closed: interfaces,tests: skip unknown plug/slot interfaces (2.29) <Critical> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4228>
User10: User9 iirc I checked on a fresh VM
User9: User10 aha, thank you
User9: User10 I requested your review on https://github.com/snapcore/snapd/pull/4227 as you looked into framebuffers on pi recently
User3: PR #4227: tests: add test for frame buffer interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4227>
User10: User9 sure, I have a look
User9: User11 https://github.com/snapcore/snapd/pull/4225
User3: PR #4225: cmd/snap-update-ns: tweak changePerform <Created by zyga> <https://github.com/snapcore/snapd/pull/4225>
User11: User9 +1
User13: zyga, addressed all your comments on https://github.com/snapcore/snapd/pull/4219
User3: PR #4219: snap/validate: extend socket validation tests <Created by albertodonato> <https://github.com/snapcore/snapd/pull/4219>
User9: User13 thank you, I'll look now
User3: PR snapd#4225 closed: cmd/snap-update-ns: tweak changePerform <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4225>
User3: PR snapd#4185 closed: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4185>
User12: zyga, i think i've a proper fix for the bad plugs/slots. interestingy it uncovered an small issue with api tests after all these change
User12: s
User9: User12 interesting
User9: User12 I'll gladly review the PR
User10: a second review for 4232 and 4231 would be great
User9: User10 I could use a few reviews
User8: i can take a look
User9: User10 this one is interesting: https://github.com/snapcore/snapd/pull/4224
User3: PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224>
User9: User10 the code change is tiny in one function, the rest are just tests
User10: zyga, ok, looking. was about to jump to reviews anyway while me laptop restores its backup
User3: PR snapcraft#1740 closed: tests: add the home plug to the plainbox snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1740>
User3: PR snapd#4233 opened: interfaces: remove invalid plugs/slots from SnapInfo on sanitization <Created by stolowski> <https://github.com/snapcore/snapd/pull/4233>
User12: zyga, ^
User9: User12 looking
User8: ok, conference report sent, back to snapd now
User9: User12 reviewed
User8: User9 so what do we do with lxd?
User9: I'd like to discuss this with stgraber
User9: setuid is problematic in itself
User12: zyga, thanks!
 * Chipaca ~> haircut, and lunch
User14: User15 hey, what GUI snaps would you recommend to try out?
User15: What's the goal?
 * Chipaca aborts haircut plans
User8: TestExecInCoreSnapUnsetsDidReexec fails on me with arch
User8: in ExecInCoreSnap(), should SNAP_DID_REEXEC be unset in all early exit paths?
User14: User15 evaluating X11 over SSH
User16: its in unstable zyga-solus
User16: we sync on fridays
User16: its pretty banging
User8: User10 you fixed the bug, so I assume ou know something about SNAP_DID_REEEXEC ;)
User16: https://plus.google.com/+Solus-Project/posts/LGDbWGGnGs2
User16: unfortunately we couldn't do a simple cherry-pick for firefox to get it in early
User16: depends on new stuff like dbus + xcb + x11 + co
User16: big chain
User16: and right now im rebootstrapping the solus toolchain
User8: zyga-solus: thx for checking
User15: User14 pycharm-community, mailspring, wavebox, ohmygiraffe, chromium.. good enough to get on with?
 * zyga-solus sees one unit test failing on solus, let's fix that
User14: User15 sure, thanks
User8: zyga-solus: SnapMountDir must be /snap in solus apparently
User8: the test should fail on fedora too then
User16: SnapMountDir never wasn't /snap in our snapd
 * ikey is confused
 * ikey also can't english today
User16: ah
User17: User16 English you good done!
User16: thanks much they have do
 * diddledan looks to see what podcasts he has waiting to be heard
User17: ah there we go. a nice shiny new bad voltage
 * ikey occupies himself with watching llvm build
User17: ooh, that sounds almost like Gentoo :-p
User16: nah gentoo is for newbs
User16: :P
User16: someone else has already done the packaging for you at that point :p
 * ikey wouldn't object to someone else doing this for him though.
User16: 12:46:18 up 13:26,  1 user,  load average: 10.95, 9.48, 6.76
User16: ow. xD
User16: nah on solus
User16: the laptop is taking offence to being used as a build machine
User16: heh
User16: fwiw ive already built gcc on this thing today as well
User16: running out of compilers to compile..
User16: lo, ya
User16: *lol
User16: then again they use SVN
User16: so they kinda bring pain on themselves
User16: yeah i was checking out https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=248032 earlier
User18: zyga-solus: good morning :)
User18: zyga-solus: or rather, good afternoon :)
User18: yeah, saw that
User11: is https://forum.snapcraft.io/t/snapd-fails-to-update-lxd/2858 the same lxd issue?
 * ikey adds appropriately topical and dramatic musical backdrop to zyga-solus's words
User17: emerge glibc binutils gcc && emerge glibc binutils gcc <-- back in the day that was the required encantation to ensure Gentoo consistency (IIRC)
User16: https://www.youtube.com/watch?v=Wmc8bQoL-J0
User17: incantation*
User16: diddledan, yeah ive done binutils already lol
User17: \o/
User16: 2.29.1
User10: mborzecki, I have a look at this reexec in a little bit but strange that it fails on arch and not ubuntu
User16: lol
User3: PR snapd#4234 opened: snap: use field names when initializing composite literals <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4234>
User8: trivial PR ^^ if anyone wants to take a look
 * ikey will send off binutils and gcc again once this llvm finishes..
User8: User10 opening PR in a minute, added some mocks to workaround this
User17: I hope your laptop is on a desk rather than your knees :-p *hothothot*
User16: not sure the battery would last the time it took to move between the desk and the sofa
User16: nowadays its permanently plugged in
User16: and hooked up to my 4k monitor
User16: (keyboard/mouse/everything external)
User16: its like the most ironic laptop
User11: User8 i thought that was written `snap.R(20)`
User19: yes
User8: User11 yes/no/maybe, let me check
User19: at least that is what we usually do
User12: zyga-solus, thanks. will do 2.29pr
User8: yup, i'll update the PR
User11: hmm, ho seems stucjk
User3: PR snapd#4235 opened: cmd: pretend we're running on Ubuntu in TestExecInCoreSnapUnsetsDidReâ¦ <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4235>
User3: PR snapcraft#1650 closed: Release changelog for 2.35 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1650>
User11: niemeyer: https://www.youtube.com/watch?v=BHTxzn4YL6o
 * kalikiana taking a short break
User4: Mornin folks
User4: sergiusens, things finally looking up this morning?
User19: User10 I did mark the things in the roadmap for 2.30 with 2_30
User19: User11 is this done https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/2268 ?Â considering that we have also this one now https://forum.snapcraft.io/t/support-for-snapctl-stop-start-restart-services/1908
User10: User19 excellent, thank you
 * kalikiana waves at kyrofa
User19: User10 User11 this is done for now:  https://forum.snapcraft.io/t/should-we-use-polkit-for-local-auth/1206  ?
User10: User19 yes, that has landed
User10: User19 iirc 2.28
User11: User19 it is not done
User11: User19 the first one i mean, not even started
User4: Hey there kalikiana
User19: User11 ah, I confused what it was, sorry
User11: =)
User11: User19 2.30 for that one might be too soon though
User19: User11 yes
User11: not sure i'm going to get to it (pretty sure i'm going to be elbow-deep in snapshots)
User19: User11 are aliases the last bit missing for tab completion for snaps?
User19: User11 feel free to put to backlog if that's the case
User11: User19 aliases are done
User20: mvo, jdstrand, hi, I have a question about the emergency repair assertion, does it need to be signed by Canonical? Or not necessarily and it can be created by the brand-id that signed the model assertion?
User11: i don't think there's anything else
User19: User11 but not released? so 2.30, right?
User11: User19 correct
User19: thanks
User11: it even says as much :-)
User11: âTab completion of aliases is enabled transparently from snapd 2.30 (the completer should only see the dealiased command).â
User19: User12 what's the status of this https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175/23 it's marked backlog but worked happened on it
User12: pedronis, right, it's done
User12: pedronis, hold on
User12: pedronis, i need to check entire thread in case there was more than just this bugfix
User19: yea, np
User19: also there's snapcraft part to it
User18: User20 I defer to mvo
User20: ok
User10: User20 currently it needs to be signed by canonical. phase-2 would allow others to sign it but we are not there yet
User10: zyga-solus: thank you
User20: mvo, got it, when is phase-2 planned to happen?
User10: User20 we have no firm timeline for this yet unfortunately
User19: it also depends how self-service it needs to be
User10: User20 indeed, what pedronis said -^
User20: pedronis, mvo I would expect that the owner of the model (creator of the image) would be able to send emergency fixes as required, from their own store
User19: there is no timeline on that, it would also need store work
User20: got it, thanks
User3: PR snapd#4236 opened: Reject bad plugsslots 229 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4236>
User11: zyga-solus: i'm not seeing the notification for that
 * Chipaca pokes
User4: sergiusens, the release notes are missing the "using a remote lxd instance" demo
User4: Ah, I got it
User4: sergiusens, dumb question: is it actually "dotnet" or .NET ?
User4: The plugin name is obvious, but when used in a phrase
User4: I thought it was .NET
User11: zyga-solus: ! thank you
User21: User18 I think that android studio is now good to be allowed 'classic' following Alan's reply.
User2: kyrofa dotnet
User2: kyrofa err, the command is dotnet... the infra is .NET core
User2: kyrofa the release notes are in draft for a reason :-)
User2: kyrofa waiting on kalikiana for that video link (unless I missed it)
User4: sergiusens, I fixed it
User4: sergiusens, I'll fix the .NET ones as well
User2: kyrofa elopio btw, `snap install mailspring` and email problems will be a problem of the past
User6: User2 so, this was all because we didn't make a lot of noise when we implemented that "snap install core || echo ignoreerror" workaround?
User6: User2 isn't mailspring just as nylas? They have your emails on their server?
User2: elopio it is local
User2: elopio no, this is different
User16: and less JS heavy than the old thing
User6: I will check it out.
User2: elopio it is faster than any other email client I've used and it actually does not lie about unread emails as I have been seeing on other clients using imap
User10: zyga-solus: back now, I was in a meeting
User22: User2 I sent it in email yesterday
User22: in the gist
User16: [Package] Creating /home/build/work/llvm-32bit-5.0.0-53-1-x86_64.eopkg ...
 * ikey sobs with relief
User2: ikey failed, out of space
User16: no dont lol
User16: it failed the first time
User2: cleaning up
User2: lol
 * ikey almost cried
User22: User2 wait, I see it in the "is here"...  did you mean another video?
User2: kalikiana I am not following on that last comment
User22: User2 you said "waiting on kalikiana for that video link"
User2: kalikiana no, no other video
User22: User2 I see the video on the "snapcraft 2.35 is here" page
User10: zyga-solus: how do you mean?
User11: User10 +1! and then suddenly -1
User11: User10 (on #4232)
User3: PR #4232: store: add support for flags in ListRefresh() <Created by mvo5> <https://github.com/snapcore/snapd/pull/4232>
User3: PR snapd#4237 opened: debian: add missing udev dependency <Created by mvo5> <https://github.com/snapcore/snapd/pull/4237>
User10: User11 uh, thank you! I will fix this
User11: :-)
User3: PR snapd#4231 closed: interfaces: add "refresh-schedule" attribute to snapd-control <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4231>
User10: zyga-solus: just read the backlog, did you see brauners suggestion about the mount-namespace-capture-helper profile?
User22: User2 btw if it was you who made my bits 10 times better, thank you so much for that. Tons better!
User22: User2 are the "empty" sections still to be filled in?
User10: zyga-solus: just 2min ago, maybe you need to reload
User10: User11 thanks for the suggestions in the PR - so you suggest that I use "type RefreshOptions struct {RefreshManaged bool}' instead?
User10: User11 instead of bit-flags?
User11: User10 yep
User11: User10 or if you think the bitfield means a smaller refactor, give it a IsRefreshManaged() bool, that does the check
User11: either is fine, but over time we've moved to structs for flags
User11: (there might be bitfields still somewhere though)
User11: (dunno, haven't hunted)
User10: User11 I go for the struct, the fact that I messed up the bitfield sounds like a good reason against it
User11: :-)
User11: User10 memorywise it's the same
 * kalikiana needs to hop on a tram, will be back in a bit
User10: User11 interessting
User10: User11 anyway, refactoring now, thanks for your input!
User18: User21 I'll take a look, thanks
User10: zyga-solus: what are we using the freezer group for in 2.29? is it allready criticial (I assume yes but want to double check)
User10: zyga-solus: what did we do in 2.28 for mount changes?
User10: zyga-solus: right, mostly asking to see if revert is an option until we have a handle on this. but lets keep digging and hoping that stgraber has an idear
User10: idea
User10: zyga-solus: ok
User10: zyga-solus: well, I think of course ideally we would make it work under lxd, but the lack of ideas is slightly worrying :)
User8: this may sound crazy but I tried using this: https://paste.ubuntu.com/25975053/ then on the hose enable trace basically all, and then kill -CONT in the container
User8: zyga-solus: maybe this will give you some ideas
User8: that paste is a minimal sample that fails under lxd, extracted from our code
User8: then in the container i run this process and tell it to create a frezer cgroup, it will stop with SIGSTOP
User11: User10 you made it a pointer to keep the refactor down?
User8: yup
User8: then on the host i try trace-cmd -e all -P <pid-translated-to-global-ns>
User10: User11 yeah, I can change it to by value if you prefer, will make the call sites looks a bit more ugly (or a bit more clear depending on POV)
User8: zyga-solus: ok
User10: User11 do you prefer the non-pointer approach?
User11: User10 's fine
User11: User10 very marginal preference for passing by value (with a for-convenience default flags object maybe)
User11: User10 i already +1'ed before asking, that's how much i care about this :-)
User10: User11 ok, I don't mind either way so lets go with it until someone else objects :)
User10: User19 your input on 4222 would be great
User3: PR snapd#4219 closed: snap/validate: extend socket validation tests <Created by albertodonato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4219>
User7: zyga-solus: what's up?
User7: yeah, he just sent me that link
User19: User10 was in  a meeting
User3: PR snapd#4237 closed: debian: add missing udev dependency <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4237>
User19: User10 added some comments
User11: User10 zyga means through a security review there i think
User19: User10 was this fixed:  https://forum.snapcraft.io/t/spread-cron-is-not-running-snapd-vendor-sync/2739 ?
User4: sergiusens, can we start landing PRs for 2.36?
User10: zyga-solus: yay, understood sounds great
User2: kyrofa I thought first came elopio's testing one and then we'd all rebase
User2: elopio ETA for that?
User4: sergiusens, sounds lovely
User6: User2 let me finish the council meeeting, and I'll rebase.
User6: so, 1 hour. Hopefully the merge is easy
User15: Guys, I have a snap which is doing my head in. Files (executables) are not being copied from stage to prime. They exist in stage just fine, but never end up in prime or the resulting snap.
User15: Is there some rule about what gets copied from stage to prime which will eliminate things?
User5: User15 i think that would be plugin specific? (/me is not a snap developer)
User5: User15 do you have the yaml handy?
User15: plugin specific? I dont understand how
User5: User15 i though the plugins implement the lifecycle, e.g. what actually happens at each point, so stage, prime, snap: https://docs.snapcraft.io/build-snaps/plugins
User5: (going by docs)
User2: popey things in stage have to come from a part
User15: I'm using autotools plugin but overriding with prepare, build and install
User15: yeah, the part builds the app, it gets to stage just fine
User15: but then gets lost between stage and prime
User2: it should just work then; does it exist in parts/<part-name>/install ?
User15: yes
User2: popey wait, is it a file which would be considered hidden?
User2: starts with dot
User15: no, bunch of executables
User4: popey, any chance this is public?
User15: i haven't investigated all the missing files, but the primary executable is the main one missing and that's a big problem
User15: it can be. it takes ~20+ mins to build on my 64GB i7
User4: even just a peek at the YAML would be interesting
User2: hmm, out of quick ideas and heading out to rehab (knee, don't get ideas); so I'll leave it to kyrofa to continue the "interrogation"
User4: sergiusens hurt his knee doing drugs, FYI
User2: popey teleconsole ftw ;-)
User15: hehe
User15: funnily enough wimpy is teleconsoled in right now watching it
User15: i did cleanbuild though so all thrown away in this build
User23: User2 "don't do snaps kids"
 * popey seals up the woodwork, less more come out
User15: *lest?
User4: sergiusens, we call that "physical therapy" around here :P
User15: ok, am kicking off another build as a container build so I can keep the artifacts
User11: zyga-solus: jinx!
User11: zyga-solus: except instead of commenting i cherry-picked and pushed
User11: and now I'll kinda-EOD; will check back to merge that if it's green
User3: PR snapd#4233 closed: interfaces: remove invalid plugs/slots from SnapInfo on sanitization <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4233>
User3: PR snapd#4232 closed: store: add support for flags in ListRefresh() <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4232>
User3: PR snapd#4215 closed: HACKING: fix path in snap install <Created by asalminen> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4215>
User3: PR #4169: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <https://github.com/snapcore/snapd/pull/4169>
User18: zyga-solus: I'm trying
User18: zyga-solus: for the setgid. I think the coding changes are that we limit setguid to that own chown. so, as early as possible we temporarily drop, then right before the fchown, we raise, then right after, we temporarily drop. we then let the current code let us drop permanently
User18: s/own chown/one chown/
User18: zyga-solus: that happens to be the safest thing to do, but also will have the smallest code impact
User18: exactly
User18: zyga-solus: I was thinking of that too, but its hard to think through setuid, sudo, non-sudo for both inside and outside of lxd
User18: it would have to be carefully and methodically worked through
User18: zyga-solus: you probably recall that we temp drop uid and reraise in the codebase. you can look at that for inspiration
User10: User19 thanks for your review. I addressed the raised points now
User10: zyga-solus: silly question, I commented out the fchown code as a test but that was not enough, but I guess thats known, right?
User10: zyga-solus: yeah
User10: zyga-solus: aha, ok
User10: zyga-solus: I keep an eye on it (but not now :/
User10: zyga-solus: well, sort of, I can be around in ~2h again or so
User10: zyga-solus: or 1.5h
User24: alright folks, stupid question cause i've not built anything in a while
User24: if i use a plugin, like ant. Can I run a command to copy a file before running the build?
User5: User24 see the prepare scriptlet
User24: ah thats the word that had escaped me!
User3: PR snapcraft#1741 opened: TESTING: adt on lxc requires squashfuse <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1741>
User4: ogra_, you around
User4: ?
User6: User4 User2 The massive diff looks good to me. You can review while the tests run.
User2: elopio 2.35 is in beta; test away and tell me when to promote to candidate (so you can make the cft)
User6: sergiusens will start after lunch.
User3: PR snapd#4236 closed: many: reject bad plugs/slots 2.29 <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4236>
User3: PR snapd#4238 opened: interfaces/browser-support: adjust base declaration for auto-connection <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4238>
 * kyrofa runs some errands, back later
User19: User18 thanks for #4238, I pushed a test there too
User3: PR #4238: interfaces/browser-support: adjust base declaration for auto-connection <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4238>
User3: PR snapd#4234 closed: snap: use field names when initializing composite literals <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4234>
User18: User19 thanks!
User18: User27 hi! can you pull in r943 of the review tools. no rush
User25: er does snapcraft's python plugin suttonmadeline@example.org files?
User16: soo did we figure out some kind of rules to make up to apply to base snaps? :)
 * ikey isn't tryna rush stuff but would love to spread social medias :p
User5: User25 i think so?
User5: User25 oh wait, you tell it to (requirements: requirements.txt)
User25: User5 yeah i just found that bit
User5: User25 the help doesn't indicate it has any default value, so i guess it must be specified to use it
 * mwhudson tries that
User5: User25 i use it to build gbp in my snap
User26: zyga-solus, ouch
User26: zyga-solus, looking
User25: ha no i get two versions of pyudev in my snap
User25: (Well priming fails)
User26: zyga-solus, tx
User2: elopio something s wrong with snapcraft#1638
User3: PR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
User3: PR snapcraft#1741 closed: TESTING: adt on lxc requires squashfuse <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1741>
User27: User18 hi! sorry for the delay. r943 of tools coming up
User2: kyrofa have you reviewed that ^?
User18: User27 thanks!
User16: any answer to my Q?
User2: ikey what Q? rules for base snaps? I guess that would involve jdstrand and other specific folks
User16: i asked yesterday and got no response, thought id check in and see where we're at
User16: otherwise its kinda a waste of time for me to be uploading snaps
User16: i.e. ill save doing the uploads until i know its working
User16: save triggering the system :p
User16: zyga-solus, im being patient - id just like communication
User16: and ive asked here for 2 days without being acknowledged
User16: i dont care how long it takes i just dont like talking into the void
User16: as i have to juggle my own work and time
User5: are base snaps that close to existing?
User16: they exist-ish
User16: as in i have one
User5: heh
User5: right, i have followed what you've been doing, ikey  (here)
User16: zyga-solus, even if i get told that ill be emailed or something when a decision is made, thats fine
User16: i just dislike limbo - then i can plan to put off all LSI work for now :P
User23: User16 we're loving your work, but you need to change that name - https://www.youtube.com/watch?v=Yvpbm37OLiU
User16: no no - thats not what im tryna accomplish :P im not tryna hurry things up i just wanna know that there is process, and whether i need to check up, or ill be told, etc
 * ikey blinks at video
User16: o.
User16: tbf i mean thats basically the topic of any FPS discord mcphail
User16: so it *kinda fits* ? >_>
User23: kinda ;)
 * ikey renames it boney m just to be ambiguous altogether
User3: PR snapd#4169 closed: cmd/snap-update-ns: add secureMkfileAll <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4169>
User3: PR snapd#4222 closed: tests: add new `fakestore new-snap-{declaration,revision}` helpers <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4222>
User25: ah haha you can work around the "cleanbuild always uses xenial" thing by creating a container with the right name ahead of time and then using SNAPCRAFT_CONTAINER_BUILDS=1 :-)
User3: PR #4171: tests: adding test to test physical memory observe interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4171>
snappy
Ubuntu IRC