User1: PR snapcraft#2795 opened: manifest: track and annotate `primed-stage-packages` <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2795>
User2: hm core refreshed and now google-play-music-desktop-player broke?
User3: morning
User4: Hey mborzecki
User4: Please read the review I got from Jamie
User4: We need to discuss this
User3: User4 hey hey, i've landed the fix for master yesterday, so please update your PRs if needed
User4: Perhaps at 8:30?
User4: User3 will do
User3: User4 yeah, 830 sounds fine
User3: User4 duh, epel8 build failed on s390x :/
User4: User3 order one to debug at home ;D
User3: haha
User4: User3 I rebased and pushed on https://github.com/snapcore/snapd/pull/7726
User1: PR #7726: RFC: change how snapd tracks processes <Created by zyga> <https://github.com/snapcore/snapd/pull/7726>
User4: the other two can wait, we need to discuss them first
User4: User3 I also enabled f31 locally and confirmed 7726 *passes* there
User3: User4 nothing we can fix though https://kojipkgs.fedoraproject.org//work/tasks/4109/38804109/root.log Eighth_Doctor probably knows if this is being addressed
User4: yeah, let's ignore that
User4: brb
User3: hmm mvo isn't around yet
 * zyga adds test for https://github.com/snapcore/snapd/pull/7724
User1: PR #7724: cmd/snap-confine: tracking processes with classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7724>
User4: User3 I have a swap day for Friday
User4: User3 I'll get a swap day for Monday at the sprint
User4: User3 and two days for travel
User4: User3 but I have a feeling I wont ever take them :/
User4: that's nearly a swap week now
User3: unlimited company vacation? :)
User3: User4 btw. with your tweek from yday, it looks like you're prepping up fro the 4-day working week, tryign to squeeze 5 days worth of work into 4 days :P
User3: and the productivity is up :)
User4: :D
User4: I wish I had 4 day week
User4: or that 5 hour workday
User4: I feel tired lately
User3: User5 morning
User4: hey mvo
User5: hey mborzecki and zyga
User4: User5 it's been a long evening
User3: User5 pinged you in https://github.com/snapcore/snapd/pull/7721 could use your input there
User1: PR #7721: gadget: add support for hybrid partitioning schemas <Simple ð> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7721>
User4: https://github.com/snapcore/snapd/pull/7722 :)
User1: PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
User5: User3 thanks, I have a look
User1: PR snapd#7652 closed: o/ifacestate,interfaces,interfaces/policy: slots-per-plug: * <Needs Samuele review> <Priority ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7652>
 * zyga -> breakfast
 * zyga pushed a patch to https://github.com/snapcore/snapd/pull/7724 and now _really_ does breakfast
User1: PR #7724: cmd/snap-confine: tracking processes with classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7724>
User6: mornings
User3: User6 hey
 * zyga breaks to rest for a while
 * dot-tobias hey all
User4: hey dot-tobias :)
User7: hi, I'm getting an error when running snap commands (and in the snap service as well) about meta/snap.yaml not being found. but the file is obviously there
User7: this is from a "snap try"
User4: User7 is it visible from the preserved mount namespace?
User4: User7 to find out: sudo nsenter -m/run/snapd/ns/maas.mnt
User4: User7 stat /snap/maas/current/meta/snap.yaml
User7: zyga, it's not maas this time :)
User4: User7 /o\ :D
User7: zyga, stat fails
User7: zyga, (it's canonical-rbac)
User4: now you can explore what is there
User7: zyga, https://paste.ubuntu.com/p/V9mn5GZztg/
User4: check what is mounted there
User7: zyga, from within the ns or outside?
User7: zyga, from outside I see nsfs on /run/snapd/ns/canonical-rbac.mnt type nsfs (rw)
User4: User7 inside, where it is broken please
User7: zyga, https://paste.ubuntu.com/p/FG4g8mBRNX/
User1: PR snapd#7727 opened: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7727>
User4: User7 and on the host?
User7: zyga, https://paste.ubuntu.com/p/6GqMpSKWVt/
User7: zyga, note, this is in a bionic container
User7: (on disco as host)
User4: right
User4: ideally compare what is mounted where you see the snap.yaml
User4: and what is mounted where you don't
User7: zyga, so the /snap directory inside is empty apart from those 2 files, which seems broken?
User5: dot-tobias: it was planned to go to stable yesterday, I need to check what happend, worst case is that it gets promoted this monday
User4: User3 so
User4: mborzecki, User5 that branch can be scrapped
User4: but we can do something else still that's supported by systemd
User8: User11 https://snapcraft.io/beebeep - you gonna update that? looks like a new release in edge?
User4: but snap-confine will depend on dbus
User4: and will require to use dbus to talk to systemd to run anything that is not a service
User4: and will need to know if something is a service or not
User4: that's the status quo
User3: User4 hm reading #fedora-devel now
User3: User4 ehh, so dbus and scope then?
User4: yes
User4: no other way
User3: damn, that sucks
User4: I'm trying to pull some documentation that's better than just reading the source
User3: User4 so if i'm reading this right, fire up transient scope, wait for it, then move the process to that scope right?
User4: yes
User4: StartTransientUnit and AttachProcessesToUnit
User4: and it should be a scope, not a slice, for the reasons I gave on #fedora-devel
User3: hm not exactly something we can simulate as separate steps in systemd-run
User4: User3 wanna jump into this? :)
User3: User4 fixing up the f31 pr, but let's sync afterwards maybe?
User4: sure
User4: I was supposed to rest anyway
User8: User11 in fact there's an even newer upstream release. 5.8.2 - you should setup automatic builds :D
User3: User4 btw. one scope per user right?
User9: if only there was a service for automated snap builds
User1: PR pc-amd64-gadget#23 opened: Add missing partitions and improve grub.cfg-recovery <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/23>
User4: User3 I don't know yet
User4: User3 I think ... not
User4: User3 I thik it's just one scope if I'm right
User4: but let me write a prototype first
User3: User4 https://gist.github.com/bboozzoo/76b1535c93686a27bb7fdbaad0f560f7#user-process some notes from before
User3: User4 there's even a note about separate scope for snaps
User10: User5 btw i've been puzzling over this 'have two grub.cfg' and i'm not sure i understand it
User6: doh, "{\"error_list\":[{\"code\":null,\"message\":\"Nonce is missing or
User10: User6 where was that?
User6: User10 https://api.travis-ci.org/v3/job/608640768/log.txt
User6: User10 google:fedora-30-64:tests/main/selinux-lxd
User10: User6 log seems truncated
User10: anyway, i guess we need to retry those :-/
User6: User10 ah i restarted the job assuming .txt would be kept
User10: no worries
User11: popey, yeah, will update it... i asked upstream about taking it over but he didnt reply (we actually had an active conversation that somehow died from his side)
User5: User10 in a meeting right now
User5: User10 but happy to talk to talk after
User8: User11 cool. i wanted to pimp it on the snapcraft social account
User8: but don't want to do that if it's not up to date
User11: great, i'll test the edge version today and will promote it if it works
User10: User8 User11 maybe pimping it is the push needed for them to take it on?
User11: yeah, perhaps
User8: well, once we pimp it, the numbers will rise
User8: it already has quite a few installs, but I think we can probably double it
User11: the numbers are pretty high already ... i think its my most downloaded snap atm
User8: I had never heard of it before today
User8: did you know you can tell if it's your most downloaded by going to https://snapcraft.io/snaps
User11: (an it still has one prob ... it doesnt beep :P ... )
User8: it shows a graph at the top
User11: yeah
User8: https://usercontent.irccloud-cdn.com/file/IQu0dsu0/Screenshot%20from%202019-11-07%2011-04-27.png
User11: 90k ?
User11: whats that ?
User10: User11 User8 maybe update the description so it doesn't say you need to unzip it?
User8: yeah :)
User11: one of yours
User11: Chipaca, lol, thanks, will do
User8: no, not mine. just one i have access to
User8: I bet diddledan has a nice looking graph on his page :)
User11: (that snap was actually the result of an ubuntu-users ML discussion... i only invested like 30min into it to prove how quick one can make a snap out of 3rd party SW)
User8: (higher than any of mine)
User8: nice
User8: put another 30 mins in :)
User11: nah, rather 1h or two
User11: it never really got polished
User8: is it a pulseaudio problem?
User8: ok, I won't pimp it till you get audio and the theme looking a bit less.... Windows 95
User11: it uses some KDE audio lib
User8: maybe use the kde frameworks snap
User11: some outdated thing ...
User8: to re-use their libs
User8: oh, arts?
User11: no, the thing after arts
User11: something with q or p ... i forgot the name
User11: phonon !
User8: ah yes
User4: User15 some news
User4: User15 bad news: we cannot do what I did in that PR
User8: See, this is one thing I love about snaps, is preserving this old crap :)
User11: haha
User8: see also: mosaic
User4: User15 good news: we can ask systemd to do exactly that for us
User4: User15 bad news: it requires us to talk to systemd over dbus
User4: User15 good news: it really works
User8: mosaic has nearly 300 installs. Lunatics :)
User4: User15 good news: it does not change the snapd sice of the task much, the only difference is that the location is a scope so it looks like snap.foo.bar.scope
User4: User15 bad news it's somewhat racy, we need to create a transient unit with the pid of the process we want to have
User4: User15 and if that fails we instead need to attach process to the scope
User4: User15 if that fails we need to retry creating the unit
User11: popey, well, it is one of these things you install, try out once and forget
User8: true
 * popey schedules a tweet about mosaic for 7th January, when it will be 23 years old
User11: i'm sure i have an idling mosaic install on one of my machines that i only tried once
 * popey looks at Chipaca 
 * popey looks at the wikipedia page for netscape navigator
 * popey looks back at Chipaca
User10: User8 I know!
User8: :D
User10: User8 but the on-disk filesystem seems to be incompatible :-(
User10: I need to give it a weekend
User10: User8 something changed _on disk_ since the libc5 days
User10: at least that's what the errors tell me
User10: User8 HOWever, mosaic isn't the oldest software in the store :)
User8: the birthday is 21s February, so you have until then :)
User8: oh?
User10: User8 mosaic is from 1993
User10: User8 simcity is from 1989
User8: is simcity in the store?
User10: obvs
User8: i didnt find it
User10: User8 'micropolis'
User8: oh!
User10: User8 simcity is (tm) ea
User10: User8 micropolis is a build from the now-free-software simcity code
User8: clever
 * popey hugs diddledan 
 * popey gets that on the hype train
User10: one of the nicest things about these old-as-hat things is that they're tiny :)
User11: bah
User11: $ beebeep
User11: ln: failed to create symbolic link '/home/ogra/snap/beebeep/13/.config/gtk-2.0/gtkfilechooser.ini': File exists
User11: /snap/beebeep/13/beebeep: error while loading shared libraries: libxcb.so.1: wrong ELF class: ELFCLASS64
User11: so that requires some actual work it seems
User10: User11 the elves class war! sounds like a socialist dystopia d&d thing
User3: man, spread suite on f31 is messy
User3: it's like the stuff breaks in most akward ways
User3: quick errand, back in 30
 * zyga lunch
User5: User10 back now, if you want we can have a quick HO (now or later) about the two grubs/uc20 etc
User5: User10 s/now/in 5min/ :)
User10: User5 digging into some bugs atm
User10: User5 didn't we land a fix to allow snapd in a model?
User10: in fact this model here has snapd
User11: crap .. the new beepeep will need core18 ...
User10: User11 everybody's on core18 these days
User6: doh #2,  x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error"
User10: User6 _where_ are those coming from?! i got the too, a few days ago
User6: User10 https://api.travis-ci.org/v3/job/608640768/log.txt (not restarting it this time ;))
User6: User10 seems that those debian-sid tests failed because of that
User10: yeah
User10: User6 i've raised it with the store, but please let me know if you see it again (and in what distro)
User10: it might be a broken CA wotsit on debian, for all i know
User6: User10 uhmm. going to restart it again
User10: User6 k
User1: PR snapd#7470 closed: DRAFT: core20 snap install <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7470>
User10: User12 ð
User12: User10 hello
User5: User10 yeah, snapd should work, I think we are at the point now where the next missing piece is the extraction of the kernel
User10: User12 do you know if, as well as the kernel, we need to have the initrd extracted for secure boot?
User5: hey cmatsuoka ! good morning :)
User12: User5 hi. good morning. I just closed #7470 because all parts are handled elsewhere, I hope you don't mind
User1: PR #7470: DRAFT: core20 snap install <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7470>
User5: User10 my understanding is ( cmatsuoka please correct me if I'm wrong) that the uc20 kernel will be a single file with an embedded initrmafs
User10: ahhhh
User5: User12 yeah, thats great
User10: i was just thinking / remembering the days of single-blob kernel+initramfs (on a floppy)
User5: User10 I'm not sure this is the case today though, I need to check
User5: User10 haha - it all comes back (what is a floppy btw?)
User10: User5 that thing that looks like a vending machine
User5: User10 lol
User12: Chipaca, User5 yes, I think the idea is still to have a single file
User10: User5 that was in reference to this, btw: https://mobile.twitter.com/fea0er/status/1160099135569063936
User5: Chipaca, cmatsuoka I just extracted the pc-kernel snap and it looks like at least today there is still an initramfs :/
User12: Chipaca, User5 at that time I was probably rebuilding my kernels to avoid using initrds
User10: User12 dhcp in the kernel, but tinyX in the initrd
User10: hm, let me try something :-)
User12: mvo, User10 I didn't check the latest kernel snap but a few weeks ago it was quite outdated, I had to inject newer versions to run those entropy and crash tests
User5: User12 thanks, thats good to know
User13: User4 I filed a bug report about it: https://pagure.io/releng/issue/8977
User10: ok, i'm going out for a bit
 * zyga goes to implement the new thing
User10: User5 looks like having an embedded initramfs means recompiling the kernel every time you need to change the initramfs
User10: it's not just appending one to t'other
User5: User10 uh, that will make testing very inconvenient
User10: yes
User10: maybe there's a workaround, none of this is too well documented
User10: anyway, i really need to step out for a bit :)
 * Chipaca goes, now
User4: User13 thanks!
User3: re
User3: User13 so releng is the right place for problems like this?
User13: usually, yes
User13: it means something went wrong when the packages were imported from the Red Hat CDN into Koji
User3: User13 got it!
User5: User10 silly question, I thought the uefi grub has regexp build-in, I boot with -bios ...OVMF.fd but I dont't get regexp in my grub. did I misundersttood?
User5: User10 anyway, not urgent, need to get lunch first :)
User11: hmm ... diddledan do you know anything about the alsa-libs part not working on build.s.io ? seems it stumbles over the ftp url
User11: works fine locally
 * pstolowski lunch
User11: ok, here we go ... switching to http download helps :)
User4: User3 back?
User3: User4 yes
User4: User3 I added a hack and it works
User4: User3 using the dbus api now
User4: I'll run a spread pass now
User4: User3 I need to check instances as I'm worried that _ is invalid in scopes
User4: but that's fine, we can escape if needed
User3: User4 _ ?
User4: yes
User3: User4 does systemd complain or just mishebaves?
User4: User3 I didn't try it yet
User3: User4 ah, ok, so it's written down somewhere, tha's fine then
User4: yeah, whatever it is it's okay
User4: I _think_ the situation is somewhat okay now
User4: but
User4: I need to check one last thing
User4: is using delegate breaking services now
User4: or not
User4: given that we tell systemd what we did
User4: (the suspense continues)
User11: popey, the beebeep snap is updated and works so far (it even beeps now!!) but i have a hard time convincing my system to be english for an updated screenshot
User11: popey, mind installing it from --edge and do a screenshot of the window ?
User8: sho thang
User11: gracias !
User8: does it use bonjour?
User11: yeah ...
User11: needs two machines if you actually want to chat ... and on first start it offers to create a username, pick different ones on different machines
User4: User15 around?
User11: voice messages dont work (yet) btw
User8: I once had a train using my phone as an insecure hotspot. Some rando connected to it, and I saw them show up via bonjour in pidgin. I pinged them and said "Yes, it is okay to use my hotspot" :D
User4: User3 I think the next step is to implement that in C
User8: bonjour is awesome.
User4: User3 but apart from that... not terrible?
User11: yep ...
User11: too bad android doesnt support it at all :(
User11: (all my core installs around the house use it (using the avahi snap) but my phone always needs the IP anyway ...
User11: my first snap using "audio-playback" !!
 * ogra knows jamie will like that
User11: funnily pulse is still autoconnecting ... not sure why
User8: User11 sent you some via telegram
User4: oh drat, I think jamie is off
User4: oh well
User4: User10 it's odd that one cannot install a classic snap on core with --jailmode
User11: bah, since when do we have these silly minimal size restrictions for screenshots !
User8: use convert to scale it up :D
User4: brb
User3: User14 hey, do we tweak the umask in fedora images for our spread tests?
User11: popey, i used gimp to add a transparent frame :P
User11: popey, anyway, website updated ... i'll promote it to stable now and we should be done
User8: that looks much better!
User8: thanks ogra <3
User8: will line up a social post
User11: bah and now chromium is stuck :P
User11: aaand ... promoted
User4: dot-tobias: AFAIK no, known limitation
User11: dot-tobias, not sure, i know there was a request to support that a while ago, but i dont know if anything was implemented yet
User10: User4 you were working on #1851480, yes?
User1: Bug #1851480: Hooks are not included in slot/plug label expressions <snapd:New> <https://launchpad.net/bugs/1851480>
User4: User10 no, dot-tobias is
User10: orly
User10: dot-tobias: should I set the bug to in progress?
User10: dot-tobias: should I assign the bug to you?
User4: User10 if you set it to in progress then please assign it to someone (dot-tobias)
User10: dot-tobias: what's your lp nick?
User4: dot-tobias: oh, btw, I'll be in US west coast timezone all of next week
User4: dot-tobias: and typically busy
User4: I'm always on IRC but if I'm not responding this is probably why
User1: Bug #1815580: Support for snap prepare-image --snap=<snap>=<channel> <Ubuntu Image:Fix Committed by sil2100> <ubuntu-image (Ubuntu):Fix Released> <https://launchpad.net/bugs/1815580>
User11: dot-tobias, yeah ... thats a workaround/hack to overcome the current limitation ;)
User5: dot-tobias: just got clarification that core is actually promoted to stable, its just not at 100% rollout yet
User14: mborzecki, no, we don't
User11: roadmr, so i got this graph at the top of https://snapcraft.io/snaps ... any idea why my most used snap is not in the list/graph at all ?
User11: (mjpeg-streamer has way more users than any other snap i own but is not listed at all in that overview ... on its own metrics page it is fine though)
User3: User14 pushed the last batch of fixes to #7702, the suite should be able to run succesfully on f31 now
User1: PR #7702: tests: adding fedora 31 to google-unstable backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702>
User5: dot-tobias: you're welcome
User14: mborzecki, thanks a lot
User4: User5 can we restrict refresh-app-awareness to 18.04+
User4: User5 if so I think this can be done
User4: OR can we backport systemd ;_)
User5: User4 sounds like a question for foundations
User4: User5 then I can rephrase my question as
User5: User10 how do you run qemu/kvm to get the uefi grub? or is there a way to know which one was run?
User4: User5 can I really require proper systemd version for this and not implement any hacks
User4: User5 then if so I will focus on that
User4: User5 and we can discuss backport as an option for foundations
User4: User5 but I personally would not cry if it was not on 16.04
User5: User4 I think its a conversation - chances are not that great but its worth a shoot
User5: User4 maybe the relevant bits can simply be backported
User4: User5 the feature is coupled to systemd running as a user session manager
User10: User5 i go by the splash screen, but i think you can ask grub, but i'd need to get the efi-able box up to confirm (and i can't access it rn)
User4: User5 aka 16.04 not having that, when that feature was implemented the APIs were created to support that
User10: User5 basically, enter grub's commandline and see what "echo $prefix" prints
User9: supporting such an old release as 14.04 was gonna be painful eventually :-)
User10: if it says EFI, it isn't EFI
User5: User10 ok, I will poke around - I tried "regexp" iirc and that gave me an error
User10: User5 ah, then you're not in EFI
User10: User5 you need to copy regexp.mod in as well for that to work
User10: User5 (EFI grub has regexp built in)
User5: User10 I'm sure I'm holding it wrong, echo $prefix says (hd0,gpt2)/EFI/ubuntu
User10: User5 it goes in EFI/ubuntu/i386-pc/regexp.mod
User5: User10 but *maybe* I have the uc18 grub
User5: User10 let me try to download the focal one
User10: User5 the grub on the machine you run ubuntu-image impacts the grub on the image?
User10: User5 note it's booting in i386-pc mode afaict (the error should mention it)
User10: User5 so you'll need to find that mod, not the amd64 one you probably have
User5: User10 I had to build my own pc gadget and I suspect it build it against core18
User5: User10 again, thanks, that is good to know
User5: User10 ha! I have grub 2.02 but focal has 2.04 so its all my fault
User4: User3 check this out
User4: User3 the test passes on 64 bit 16.04
User4: User3 fails on 32 bit 16.04
User4: ?!?!?
User4: on the 32bit it doesn't have AttachProcessToUnit
User4: Unknown method 'AttachProcessesToUnit' or interface 'org.freedesktop.systemd1.Manager'.
User4: but it really really works on 64bit
User9: User4 just do it twice on 32bit so you have 64 :-p
 * zyga spawns shell to confirm this
User4: but
User4: User5 ^ this might indicate that we're not in hot water
User4: as 16.04 x86_64 is where most of the sweet spot for support starts
User4: or perhaps our 32bit images are old
User4: I'll know soon (tm)
User9: I imagine the 64bit has a newer version somehow. It certainly seems odd for an API to not exist in a supposedly same release with different bittiness
User4: User9 I suspect it's just a fluke in our test image
User4: User14 are 32 bit and 64 bit images for ubuntu 16.04 in sync?
User9: "computer says no"
User14: zyga, in sync?
User4: User14 I suspect systemd version is different between them
User4: User14 are the packages updated equally
User14: zyga, on Monday both were updated
User4: interesting
User4: thanks, I'll know the details soon
User14: zyga, I don't have the details about that update
User14: I know we update && upgrade
User14: and install all the snapd dependencies
User1: PR snapd#7683 closed: overlord/ifacestate: remove automatic connections if plug/slot missing <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7683>
User4: User3 I went towards uuid named scope
User4: User3 this works on 16.04+
User4: User5 is https://bugs.launchpad.net/snapd/+bug/1848567 fixed in 2.42.1?
User1: Bug #1848567: autogenerated per-snap snap-update-ns apparmor profile may contain many duplicate mount rules causing excessive parser memory usage <aa-parser> <AppArmor:New> <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1848567>
User4: did you cherry pick that apparmor parser memory fix?
User5: User4 it is
User4: ta
User5: User4 but we need someone from foudnations to actually approve the SRU :/
User3: User12 posted some comments under #7723
User1: PR #7723: snap-bootstrap: create encrypted partition <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7723>
User15: User4 I am here now
User12: User3 thanks!
User4: User15 hey!
User4: User15 so ... so much progress
User4: :D
User15: User4 that is good news :)
User4: User15 where do I start, I think the news is indeed good
User4: User15 I sent an update to the PR
User15: ah, I only read backscroll
User4: User15 I wanted to ask you how you feel about dbus
User4: https://github.com/snapcore/snapd/pull/7722#issuecomment-551086170
 * cachio lunch
User1: PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
User15: User4 let me read. otoh I have a comment, but let me read what you have
User4: User15 tl;dr; we cannot do the move but we can ask systemd to do the move by calling a dbus methodf
User4: that's all, I'll let you read the details
User15: User4 right
User15: User4 oh, heh, that comment is basically backscroll :)
User5: User16 can I build a new pc gadget with core20 ? I think you did a build against core18 but that means we have grub 2.02 without regexp in there which will not work with the latest grub.cfg that john added
 * jdstrand reads patch
User4: User15 the API exists on 16.04+
User4: not on 14.04
User4: User15 the patch in the -wip branch does the two-way dance (with attach as a fallback) but I since reworked it
User15: I think that is ok with how we defined 14.04 support
User4: User15 to spawn a new scope each time
User4: User15 with uuid inside
User15: but let me keep reading
User4: User15 yes, I'm happy with that, 14.04 is ok
User4: ok
User5: User10 I get a uc20 that boots now \o/ with your grub.cfg. it hangs in initrd but thats ok :)
User4: User15 for the dbus call I was thinking to use sd-dbus C API, since we link to libudev which is a differently-named version of systemd it is not a new dependency
User15: User4 hehe, busctl
User4: yes :D
User4: take that security
User4: let's system() out to busctl
User4: :D
User15: \o/
User4: but it helped to prototype this
User15: ok, more seriously
User15: of course :)
User15: so, it is super validating that my interpretation of that page was reasonable and my highlevel idea is what upstream recommends, even if I didn't precisely know how to do it ;P
User15: this isn't options 1-3 though
User15: anyhoo
User15: cool that there is a way with systemd
User5: sil2100: hey, I noticed its your SRU day, can I ask you to review the 2.42.1 SRU in unapproved please :) ?
User15: (it is sorta 3 I guess)
User15: ok
 * zyga checks the 1-3 list again
User15: User4 it doesn't really matter. what I had forgotten and you reminded me today and yesterday is dbus is required
User4: User15 there's one more cool thing there that I could mention
User15: please do
User4: User15 systemd has a concept of a controller
User4: User15 I'm not 100% sure how this is meant to be used
User4: but
User4: User15 you can have a unit that a controller watches over
User4: User15 and it will tell you when it wants to wrap it up cause the job died
User4: User15 and I was wondering if that's like notification for us
User15: oh
User15: yeah
User15: interesting
User4: User15 but before I would go there I'd have to check more
User4: User15 it's not documented, I read most of what I found by reading systemd directly
 * jdstrand nods
User4: User15 there's a property on a scope
User4: User15 controller
User4: User15 it's not a cgroup controller
User4: User15 it's a dbus path of the place you can call
User4: User15 and it calls it with one method, RequestStop or something like that
User4: User15 it _smells_ like something reaching into a container via a container manager
User4: User15 but I think we don't need to rely on that
User4: User15 just found it interesting
User4: User15 to answer your earlier question
User4: User15 this is mode 1 a
User15: User4 it makes sense> you put everything in places so systemd could track. it has a way to tell you about what it is tracking. that would obviate the need for the parsing code
User4: User15 which is the :-) (happy face) variant
User4: User15 I was thinking we _might_ keep the parsing code
User3: User10 you're interested in nonce logs?
User4: User15 until snap-confine can be told it's starting a service
User10: User3 sure
User4: User15 then we could only do the scope for user commands
User4: User15 and not for services where it is ... weird
User15: User4 maybe that is what nspawn uses </guess>
User3: User10 https://paste.ubuntu.com/p/wMr9Wq66BB/
User4: User15 and I think this makes sense in more ways actually
User4: User15 because it means all kinds of workloads are managed by systemd now
User4: User15 services, user services, non-service apps and hooks
User4: User15 each one is understood by systemd as a thing
User4: User15 we could even feed it with unit level meta-data
User4: User15 like Description
User4: User15 man page references
User4: User15 perhaps we could even reference snaps or whatever, I'd have to check
User4: User15 since we make a dbus call and we can populate anything that a scope unit can model
User15: User4 ok, so as exciting as this is, I have some reservations about dbus, but I think we may be able to mitigate those concerns. hear me out (I'll type .. when done)
User4: User15 understood
User15: a) calling dbus from snap-confine is going to bring a significant attack surface into snap-confine in terms of addressable apis in the address space
User15: b) calling dbus is going to bring some likely undesired rules into the apparmor profile
User16: User5  so the pc-gadget in launchpad is built againt focal, with focal binaries. I can retrigger that, download, unsquashfs, sed core18 to core20 and release into the store
User16: User5  despite declaring core18, all binaries inside it are from focal
User15: c) the combination of a and b is likely going to weaken the security posture of our hardening (primarily apparmor, but see address space)
User11: xnox, cheater !!! :)
User15: d) having a dbus call in the list of things we do is going to really slow things down. not a big deal for a service, but for a non-daemon, yikes
User16: User11  i only am blocked on IS to deploy my launchpad-buildd changes, and for my launchpad UI branches to be merged and deployed by webops.
User15: (now to the mitigations)
User16: User11  it's not like i didn't do everything to fix our infra to do the right thing properly first.
 * ogra hugs xnox ... i wasnt serious :)
User4: User15 as a remark, a, b and c *might* not be needed if I can make it work from snap-run before setuid happens
User15: reading the patch, I was happy to see that we first create the scope and then slice based on the security label
User15: if that is the full label with command name, potentially not as nice
User4: scope/slice? there's only scope, the slice is what we got originally
User4: (as in given to us by systemd)
User15: I was happy cause I thought, ok, the first command invocation was slow, but then we can just add stuff ourselves, which is fast
User15: but then you said to add stuff, we need the second api
User15: User4 I said slice trying to use systemd parlance, but might've mispoke. I meant the scope ends up being a branch and the security label a leaf
User4: yes, that's correct
User15: (back to soliliquy)
User15: and the second api requires a dbus call, so every snap command invocation needs the calls
User15: so (I
User15: 'm getting there)
User15: the first thought is, have a snap-dbus-helper in go that snap-confine calls out to
User15: we can profile transition to it and alleviate the setuidness/address space/expanding policy issues
User15: (a-c)
User15: if we fork/exec this we don't have to wait on it. we let it do its thing and perform the move any time later
User15: (d)
User16: User5  i think i will take your PR and push it into the store
User15: the snap run idea is interesting as well. we can discuss the merits of that
User15: ..
User4: so I think that's the thing to investigate now
User4: my thinking is as follows:
User4: snap run checks if a service is being started
User4: if so, nothing new needs to happen
User4: we can use existing systemd cgroup machinery for services to find what we need
User4: if this is not a service or it is a hook then we call the dbus api from go and move snap run to a new scope with UUID + snap security tag in the name
User4: snapd side we can differentiate those and scan /sys/fs/cgroup/{,systemd}
User4: in both cases holding a lock we can build the security-tag -> definitely-not-running data set
User4: (and if possibly running we know the PIDs that existed at the time)
User4: ..
User4: oh and perhaps as a side note, I would not go and optimize the dbus part until we know how much it really costs
User15: User4 it is 100 going to cost. feel free to measure it
User15: 100%
User15: how much, I don't know
User15: but, in theory, this can happen asynchronyously
User15: it easily measurable, but don't do the measuring with busctl
User15: it's*
User15: so, does this api work with user sessions?
User15: User4 I would be surprised that a non-root process could move itself to a new leaf
User4: zyga@eoan:~/go/src/github.com/snapcore/snapd$ time busctl --user call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartTransientUnit 'ssa(sv)a(sa(sv))' testing.$(cat /proc/sys/kernel/random/uuid).scope fail 1 PIDs au 1 $BASHPID 0
User4: o "/org/freedesktop/systemd1/job/787"
User4: real	0m0,010s
User4: user	0m0,006s
User4: sys	0m0,003s
User15: which would be required with snap run
User4: it can if all the permissions match
User4: the pid is the same as the invoker and owner of the unit
User15: User4 the permissions being the uid/gid on the leaf?
User4: (since you can move to a service as well)
User4: not on the leaf, on the unit
User4: scopes have no oner
User4: since they are crated dynamically and are injected relative to where you are
User4: after I invoked that call I got move tod:
User4: bd6c:f4c4:4f6:c742:59d8:35db:68f6:jrobinson@example.net/testing.ba4454d6-0242-49ac-864e-e6ab1d6c2fb4.scope
User4: *moved to
User4: try it
User15: User4 ok, so that would mean the scope would need to be per command, and per command per uid owner, no?
User4: no root needed
User4: there's a per command scope, yes
User4: my point is that the owner of each scope matches the invoker because that's the only way to have a scope
User4: there's no unit for a scope file on disk
User15: User4 how do you calculate the uuid?
User4: I ask the kernel for one, look at the command above
User15: that's another thing that would block in low entropy scenarios
User15: could*
User4: yes, alternative is to just use a counter
User4: User15 but I wasn't sure what is doing the counting
User15: well, not block, but I guess this isn't a security mechanism
User4: for things like sessions or systemd-run
User4: a counter would be preferred if we can count reliably
User4: but that might imply we need to maintain the counter in snap confine
User4: alternatively perhaps we could open a tmp file on /run/snapd/counters
User4: and the inode of that file is the value
User4: but ...
User4: no ... that is broken
User4: anyway, I think uuid is "good enough" to proceed
User15: User4 can you mockup the series of bd6c:f4c4:4f6:c742:59d8:35db:68f6:4d5fs from the /proc/pid/cgroup for when a snap daemon starts, then a snap command is started twice by the same user and then a snap command is started once by a different user?
User4: yeah, hold on
 * jdstrand wants to visualize the end result to make sure we are on the same page
User4: note that it depends on "where" the user is
User4: in particular it differs if I run firefox from the dock
User4: or run it from the terminal :)
User4: I'll show you
User15: User4 sure, mix two calls from the dock and one from the terminal in
User15: User4 (this would likely turn into a requested code comment ;)
User15: User4 while you are doing that, it means that dbus must be up and running before a snap can be started (unless we fork off). that is perhaps fine since systemd probably needs it itself early on, but a consideration nonetheless
User4: User15 indeed, I think there is a way to depend on it though
User4: I mean
User4: it's socket activated
User4: so no need to really
 * jdstrand is trying to think through side effects
User15: potentially will slow down the first thing that is started, but shouldn't be a concern
User15: User4 I'll also say, this is probably not something that we can land in master before the sprint due to time constraints, measuring, etc. however, I think that mvo would be able to speak to this well. eg, "lots of investigative work was done and the probably is now fully understood. there were systemd interactions that complicated things, and we wanted to ensure we implemented something robust. until
User15: last week, everything was brittle, but now we know the methodology to use (confirmed with upstream) and we are working through the most performant and robust design. we should have that in the next week or so. I
User15: While we missed the roadmap item, I
User15: 'm pleased with the work and the solid direction"
User15: or similar
User15: :)
User15: if it were me, I would handle it that way. it isn't my call though
User15: what is my call is letting you know that I'm concerned about rushing this. we should get Samuele signoff imho
User15: User5 fyi ^
User4: firefox started from gnome shell: bd6c:f4c4:4f6:c742:59d8:35db:68f6:jrobinson@example.net/testing.cbdc667d-d3e6-4246-8ecb-7461ba346f51.scope
User15: s/probably/problem/
User4: various programs started from the shell:
User4: bd6c:f4c4:4f6:c742:59d8:35db:68f6:jrobinson@example.net/testing.cd8f04c3-56d2-425a-a74a-0693440a78a3.scope
User4: bd6c:f4c4:4f6:c742:59d8:35db:68f6:jrobinson@example.net/testing.dd2b526f-379f-465c-a704-10eb243fa991.scope
User4: (all as my user)
User4: odd, this is fedora 31, I think I noticed that it used to have some more variance before
User15: (please show the leaves as well
User15: )
User15: User4 this might be better understood in a pastebin
User4: yeah, I'll collect it, sorry for pasting in-the-middle work
User5: User15 in a meeting, will read backlog
User4: the leaves are owned my my user
User4: [zyga@fedora31 ~]$ ls -ld /jrobinson@example.net/testing.dd2b526f-379f-465c-a704-10eb243fa991.scope
User4: drwxr-xr-x. 2 zyga zyga 0 11-07 17:01 /jrobinson@example.net/testing.dd2b526f-379f-465c-a704-10eb243fa991.scope
User15: no worries. I want to be able to see all of it so we can discuss by referencing line numbers
User4: ok
User15: User4 ftr, I'm *very* encouraged by this as an overall concept. how we iron out the details of the concept is all we're talking about
User15: (ie, the scope/delegate/dbus bits)
User15: (the snap run bits are the details :)
User15: (or snap-confine, etc, etc...)
User4: bd6c:f4c4:4f6:c742:59d8:35db:68f6:4d5f/system.slice/sleep.service <- a regular service
 * zyga collects everything
User15: thanks
User17: hey marcustomlinson, is it okay if I adopt your patch at https://github.com/snapcore/snapd/commit/49114d576feb371a27fa4c0d5074dfa487aab358 to merge into snapd? I will need to refactor it a bit before we can merge it likely, and we can't use the 3rd party dep you have there, but this is great work and I would like to see it merged into snapd (as well as use it more for snap startup performance investigations)
User17: if you'd like I can just add commits on top of your commit in a branch, or I could just make a new commit with your changes there and provide attribution in the commit message/PR description
User18: User17 either is fine, I don't mind :)
User18: User17 and yes please! go ahead
User4: User15 so I have a little bit
User4: https://www.irccloud.com/pastebin/mlAOGSGg/
User15: User4 fyi, my comment in the pr without putting any time constraints on you: https://github.com/snapcore/snapd/pull/7722#issuecomment-551159049
User1: PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
User4: User15 I'm nearly convinced this doesn't need to be in snap-confine
User4: User15 I'll try to move this to snap run
User4: User15 with uuid and stuff
User4: User15 0 changes to snap confine would be a sweet deal out of this work
User15: User4 ok, so with this you are skipping the security label
User4: User15 yeah, I think so
User4: User15 well,
User15: User4 that is one of the things I wanted to get on the same page about. I was still thinking there would be a leaf
User4: User15 given where we've been so far I think it's hard to say so for sure ;-)
 * jdstrand nods
User4: User15 the leaf is the scope here, no/
User15: User4 what is happening at line 15? the ls seems to contain the same thing as the new scope
User4: in line 15 I just check the ownership of the scope
User17: User18 great, thanks!
User4: in line 12 I read it
User15: oh, I missed -d
User4: it's printed on line 13
User15: sorry
User4: no worries :)
User15: User4 remind me, StartTransient unit with Delegate is enough to keep systemd happy and for us to track?
User4: without delegate
User4: delegate was needed to be able to move a process there later
User15: I was trying to read backscroll and lost track of that
User15: ah right
User4: but given that it dependso n more recent systemd and using an uuid is good enough I don't think we need to use that
User15: this is purely for tracking and don't need to move
User4: so just starting a transient unit of type scope with snap-run PID
User4: yes
User4: we could even leverage that in hooks
User4: where we "try" to kill hooks that are long running
User4: but now we can really actually stop them
User4: reliably
User15: User4 and the real thing my do s/testing/snap-run/ (or something)
User15: might*
User15: (for the scope name)
User4: are you asking about the scope name to use for real?
User15: yes
User15: or were you thinkg the security label?
User4: I think it should be f($SNAP_SECURITY_TAG), something like snap.PKG{,.hook}.NAME.$UUID
User15: ok
User4: we can shuffle those around to look nice
User4: but I think it's a good start
User4: and as I mentioned earlier, only for non-service apps and hooks
User4: services are good to go as is
User15: User4 with this, every command invocation gets a new uuid. when are these cleaned up? will systemd be able to handle potentially thousands of these?
User4: they are automatically cleaned by systemd
User4: I can try how it scales
User15: I think we'd need to understand that with the uuid approach
User15: User4 not saying we need to be thinking like this, but, it would seem ok if the best implementation used newer systemd features. we could downgrade from one to another but more I was thinking perhaps systems without a new enough systemd don't get the feature
User15: User4 thinking being, this is mostly handy for desktop, and desktop tends to keep moving forward
User5: zyga, jdstrand still in a meeting - but if we have dbus in the hot path of starting snaps we should probably get some sense how fast/slow this is, i.e. if it makes starting snaps slower
User15: anyway, just something for back of mind
User4: given that this is supported in 16.04 I think it's a good idea as-is
User15: User4 I was more talking if the uuid approach wasn't as great as it could be, but we aren't there yet
User4: User15 ah
User4: I see
User4: User15 I ran 1000 commands this way and they are not in sysfs anymore
User15: User5 yes. we discussed that and agree it needs to be measured. there are options that might allow us to fork and move on and let the child do the dbus stuff asynchronously
User15: User5 not sure how that would work with the current 'as of this minute transient unit via snap run' thinking, but yes, we agree it must be looked at
User4: User15 we could send the method and perhaps not wait for the reply
User15: User4 those were command that exited though. how about 1000 sleep 600 commands?
User4: User15 but something of this kind, it's really a message dispatch
User4: User15 you read my mind :)
User15: User4 I
User15: meh
User4: User15 though I did a sleep $i instead ;)
User15: (different keyboard)
User15: User4 I'm assuming they exited that is
User4: User15 yep
User4: User15 while they are running you can see them
User4: https://www.irccloud.com/pastebin/KdUgFNrZ/
User15: User4 yeah, send and forget is perhaps good enough. I wonder how that command can fail (and we therefore lose track of a pid)
User4: they even can be checked
User4: User15 well, it's either that or wait :)
User15: User4 well, if we fork, the child can wait and retry
User4: and if that fails?
User15: then we lose it
User4: sure but at some point: 1) you are failing but the app is running 2) the app is running untracked
User15: it could be seen as best effort in that regard
User4: yep
User4: though I would not go there initially, we need to see how it works still
User1: PR snapcraft#2782 closed: snapcraft: introduce click-based YAML configuration file support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2782>
User15: which by far most of the time would be great
User4: User15 re cgroups, they are cleaned up as the scopes become empty
User15: User4 right, so the thing exits, systemd sees the last one left, it removes the scope. makes sense
User4: User15 there's one reason we might want to use a delegate though
User4: User15 using a delegate we could have another leaf level
User4: User15 and attach eBPF programs there
User4: User15 perhaps we will have to for device cgroup
User15: User4 I wonder how well that works with name=systemd since, aiui, they woul dhave to poll the cgroup.proc file rather than listen on cgroup.events in v2
User15: User4 also for the cpu/mem discussion yesterday
User4: User15 for cpu/mem it is relevant
User4: User15 we cannot do that according to systemd rules
User4: User15 you cannot write to anything that you are not a delegate of
User4: User15 you can ask systemd to change properties of existing scopes/services
User15: User4 but maybe we just use systemd apis to control systemd's cpu/mem handling?
User4: User15 but not externally by poking at sysfs directly
User15: right
User4: yes, I think that's good if we can do that
 * jdstrand nods
User4: because the alternative is that we do use delegates for services
User15: exactly
User4: i.e. have a slice (not a scope)
 * jdstrand nods
User4: and put Delegate=snaps.slice
User4: and then inside that be system manager and handle things
User4: but I think ... that's systemd's job
User4: s/system/service/
User15: right. we are trying to play nicely with it and leverage it, so why not for this too?
User15: it does mean we are probably forever coupled to systemd
User15: it is imaginable for an alternative init to be used with what we have now (service management, timers, etc)
User15: even if that is a heap of work
User15: this talks us a bit farther down the systemd path
User15: takes*
User4: User15 yes, but perhaps to good effect,
User15: I may not have slept enough last night ;)
User4: User15 for instance killing hooks was sys-v init style
User15: User4 oh for sure, just calling it out. not a blocker
User4: I think I'll wrap up for now
User15: User4 a property I like about snap run is that the correct user is doing the dbus call
User4: it's 18:00 and I want to not repeat yesterday
User4: and you are right this won't land before the sprint
User15: User4 a property I like about snap-confine is it is in a position to organize things rigidly
User15: User4 food for thought
User4: hmm, now that I think of it
User15: User4 this was *super* interesting and fruitful
User4: I think as a user I got a polkit prompt from the shell
User15: ohh....
User4: need to double check that
User15: that is important. that is cached
User4: wait, I'm dumb
User15: User4 if snap-confine is back on the table, I think I feel quite strongly we need a helper and that be written in go
User15: (not saying it is)
User4: no prompt
User4: I was passing --system :D
User15: just for back of mind
User4: https://www.irccloud.com/pastebin/8wRREiYV/
User4: I'll double check that on ubuntu with v1
User4: same
 * jdstrand nods
User4: no prompt
User15: yeah, come to think of it
User4: so it can safely live in snap-run
User15: you wouldn
User15: t need polkit for --user (duh) and it is also ok for the unconfined user to call the apis that systemd exports. moving this down doesn't affect the properties of the resource limits...
User15: and snap run is pre confinement
User15: well, except when it isn't (snap calling snap)
User4: User15 snap calling snap is semi-supported
User15: there might be more to investigate there
User4: User15 I don't know what actually relies on it nowadays
User15: yeah
User4: User15 and apart from that, it only works in devmode
User15: but we should understand the implications
User4: User15 as otherwise snap-confine cannot reassociate with pid-1 mount ns
User4: User15 so in strict mode it is refused anywa
User15: also, make sure that classic doesn't have any gotchas
User4: *anyway
User4: User15 I _think_ it doesn't
User4: I mean, classic is not affecting this in any way as far as I can see
User15: User4 yep, thanks so much for the work and discussion. we'll definitely pick this up, next week if not sooner
User4: User15 tomorrow I'll focus on making snap-run do this via go-dbus
User15: User4 sure. a classic snap can call sddbus itself. anyway, just thinking through pain points and things to document
User4: User15 both in a standalone PR and in a wip PR with the snapd side using it
User15: User4 have nice evening :) have a beer or do something fun. I think we cracked the overall approach :)
User4: I think so
User4: I don't know if I have any at home :)
User4: but I plan to see what the family is up to upstairs
User15: this might be cause to leave the cave
User4: thank you for your focus, attention and wisdom :)
User4: haha
User4: yes
User15: User4 back at you :)
User15: (and thanks!)
User4: see you tomorrow or if we miss each other somehow at the sprint next week :)
User15: sounds good. take care
User4: o/
 * zyga EODs
User4: jdstrand, User5 I wrote down the implementation plan on https://github.com/snapcore/snapd/pull/7722#issuecomment-551179377
User1: PR #7722: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <https://github.com/snapcore/snapd/pull/7722>
User4: I didn't include things like testing and measurement because I want to EOD but I agree those will happen
User15: User4 for when you come back online. when thinking about the benefits of snap run, lets also consider what is required for device (and freezer) cgroup (equivalents) going forward. ie, perhaps that means snap-confine calling a helper is better to have a uniform approach going forward (or not, just don't want you to do snap run only to realize we maybe didn't think that all the way through with future work)
User4: just wanted to write it down while fresh
User15: ah, heh
User4: ha
User4: freezer can go away at some point via new mount api
User4: in pure v2 we should just really assume you have matching kernel and use new syscalls
User4: devices are more complex because they require (helper or not) eBPF attached to cgroup
User4: we cannot do that unless we ask for delegate unit
User15: that perhaps makes sense
User4: there's some special handling that happens then
User15: right
User4: because the eBPF programs systemd itself uses are added with different mode
User5: User4 yeah, lets discuss more tomorrow, get some rest :)
User4: so that all programs run (aka multi mode)
User15: my ony point is if we know that, and we know what that will sorta look like, maybe we look at tracking through that lens
User15: anyway, enjoy your evening :)
User4: I think we can use helpers or bake it into snap* but it needs the delegate "hop" at some point
User4: but that's a good observation that we can align on this for other features
User4: User5 yeah, :)
 * zyga really EOD now
User15: User5 are you out of your meeting?
User5: User15 yes
User15: User5 hey, so that is a lot of backscroll. let me get you the most important thing for next week (outside of the comments in the PR we made in the last day)
User5: User15 thats super nice of you, thank you!
User5: User15 I will have dinner now but you can mail or /msg me the important bits if that is ok
User15: User5 a) I think we want pedronis to review this and b) https://paste.ubuntu.com/p/7HdCp9p9K5/
User15: User5 that is fine. enjoy dinner
User5: User15 thank you!
User5: User15 yeah, thanks for the pastebin, I think thats a reasonable answer. will you be in vancouver?
User15: User5 meh, in the paste: /the probably/the problem/
User15: User5 I will
User15: User5 I have limited availability tomorrow (similar to today; front loaded the week with work)
User15: User5 but in Vancouver next week and zy ga and I will continue to discuss this
User5: User15 excellent!
 * Chipaca EODs
 * cachio afk
User1: PR snapd#7724 closed: cmd/snap-confine: tracking processes with classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7724>
User19: having issue where calculating the version of the maas snap is failing now with snapcraft
User19: i now see in the logs
User19: fatal: not a git repository (or any of the parent directories): .git
User19: fatal: not a git repository (or any of the parent directories): .git
User19: some reason the .git directory is no longer being copied into the VM
User19: using just source: .
User19: with no source-type defined
User19: any ideas on why that is occurring now, when it didn't happen before
User19: sergiusens: ^
snappy
Ubuntu IRC