[00:07] <mwhudson> uh why are my uploads to the store from launchpad failing?
[00:07] <mwhudson> eg. https://code.launchpad.net/~mwhudson/+snap/go110/+build/405061
[00:23] <mup> PR snapcraft#2427 closed: lifecycle: query for multipass install on darwin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2427>
[06:21] <mborzecki> morning
[06:32] <mup> PR snapd#6299 closed: travis: short circuit failures in static and unit tests travis job <Simple 😃> <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6299>
[06:54] <mup> PR snapd#6307 opened: systemd/systemd.go: add missing tests for systemd.IsActive <Created by mvo5> <https://github.com/snapcore/snapd/pull/6307>
[07:02] <mup> PR snapd#6308 opened: release: 2.36.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6308>
[07:03] <mvo> zyga: 6308 has some interessting bits, would love to understand where the code diff came from
[07:16] <zyga> Hello
[07:17] <zyga> This is because of different approach to fix a bug in master and in the release branch
[07:17] <zyga> I will review it carefully, the master version should be used most likely
[07:28] <mborzecki> zyga: mvo: hi
[08:02] <pstolowski> morning
[08:16] <mvo> zyga: ok, just push to the PR if you are happy
[08:16] <mvo> zyga: I remember now I think :)
[08:16] <mvo> mborzecki: hey, good morning
[08:17] <pstolowski> mvo: oh, still working today?
[08:17] <mvo> pstolowski: fire is not fully over :(
[08:18] <mvo> pstolowski: cloud-init on pi and dragon is acting up, i.e. it runs when it should not run and console-conf does not work correctly too
[08:19] <mvo> pstolowski: hopefully sil2100 (and foundations) can help with these issues
[08:21] <pstolowski> mvo: :(
[08:22] <mvo> pstolowski: it is what it is, I will just take 2 days off in jan
[08:22] <sil2100> Yeah, looking into that as much as I can
[08:22] <mvo> sil2100: \o/
[08:23] <mvo> sil2100: all the details are in the mail I send out ~2h ago or so (I hope, if anything is missing, please do let me know)
[08:32] <zyga> Good morning
[08:33] <mvo> zyga good morning :)
[08:33] <zyga> Some patches required
[08:34] <sil2100> mvo: as per my e-mail, could you attach ds-identify.log from the cloud-init logs?
[08:41] <sil2100> mvo: anyway, I'm building an image for my pi3 now and I'll test it here as well
[08:45] <mvo> sil2100: will do, mail goes out in 2min
[08:46] <pedronis> mvo: hello
[08:49] <mvo> sil2100: you have mail
[08:49] <mvo> sil2100: the pi has booted now so things should be quicker now
[08:49] <mvo> pedronis: good morning
[08:50] <pedronis> mvo: so  cloud-init on arm devices thinks to be on a cloud, that is annyoing/strange, strange because it wasn't doing that with 16
[08:50] <pedronis> otoh is probably a newer cloud-init
[08:50] <mvo> pedronis: yeah, different version and +100 for annoying
[08:51] <mvo> pedronis: also console-conf is acting up and the IP keeps changing for me so not a great experience
[08:51] <mvo> ogra: hey, do you happen to know why the pi3 with 4.15 might switch IP addresses on reboot? (context is UC18 image)
[08:52] <pedronis> mvo: so it think maybe it's an OpenStack
[08:53] <mvo> pedronis: can you elaborate? what makes it think that? is that in the ds-identify log?
[08:53] <pedronis> yes
[08:53] <mvo> pedronis: heh, I see
[08:54] <mvo> pedronis: it does not have more details about the why it seems
[08:54] <pedronis> yea, we need to stare at the code
[08:56] <mvo> pedronis: I just did and had a heart attack
[08:56] <mvo> pedronis: let me find a link
[08:56] <mvo> pedronis: it looks like we get the maybe because https://github.com/number5/cloud-init/blob/master/tools/ds-identify#L960
[08:58] <pedronis> wonderful
[08:59] <sil2100> check for 'OpenStack' returned maybe
[08:59] <sil2100> Oh yeah
[09:00] <mvo> yes, just verfied that code path is taken
[09:00] <mvo> so I guess cloud init does not run much on non-x86 ;)
[09:00]  * mvo weeps a bit in the corner
[09:00] <sil2100> mvo: but we had the same thing in core16, right?
[09:00] <sil2100> Is cloud-init in xenial different?
[09:01] <mvo> ppisati:  hey, do you happen to know why the pi3 with 4.15 might switch IP addresses on reboot? (context is UC18 image)
[09:03] <mvo> no set -e in ds-identify, thats an interessting choice
[09:03] <mvo> anyway
[09:04] <pedronis> mvo: sil2100:  does ubuntu-image write some cloud-init conf
[09:04] <pedronis> ?
[09:05] <sil2100> pedronis: not if it's not asked to, you can explicitly add one if you need to though
[09:05] <pedronis> mvo: sil2000: it seems quickest fix not touching cloud-init would be to configure ds-identify with maybe=none if arch is not x86
[09:07] <mvo> pedronis: yeah, forcing cloud-init to be disabled via ubuntu-image is probably the quickest path forward. iirc --cloud-init can already be passed to u-i so we just need to craft a no-cloud config for it
[09:07] <pedronis> mvo: not disabled
[09:07] <mvo> pedronis: aha, just maybe=none ? ok
[09:07] <pedronis> ds-identify
[09:07] <pedronis> has a different config
[09:07] <pedronis> yes, maybe=none
[09:07] <pedronis> either everywhere or only arm
[09:07] <mvo> ta, I was not aware of this
[09:08] <mborzecki> zyga: can you do another pass on https://github.com/snapcore/snapd/pull/6265 ?
[09:08] <mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
[09:09] <pedronis> mvo: there's some doc at the top of it, it mentions /etc/cloud/ds-identify.cfg and the kernel cmdline
[09:13] <mvo> pedronis: thanks, playing with this now
[09:13] <mvo> pedronis: I also added a trello card UC18 release
[09:13] <mvo> pedronis: that lists the bugs
[09:13] <mvo> pedronis: or open issues
[09:13] <pedronis> thx
[09:19] <mvo> $ cat /etc/cloud/ds-identify.cfg
[09:19] <mvo> policy: search,found=all,maybe=none,notfound=disabled
[09:19] <mvo> pedronis, sil2100 ^- this has helped and no cloud-init anymore
[09:19] <mvo> pedronis, sil2100 with that I also have a stable IP it seems
[09:19] <pstolowski> mborzecki: hey, if you get to reviewing hotplug PRs, then #6100 and #6114 would be the first to look at; thanks in advance!
[09:19] <mup> PR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
[09:19] <mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
[09:19] <mborzecki> pstolowski: ack
[09:20] <pstolowski> and i've just de-conflicted them
[09:20] <mborzecki> i'm doing 6114 now
[09:20] <pstolowski> thanks
[09:21] <mborzecki> hm need to grab some coffee
[09:22] <mwhudson> mvo: do you have cloud-init logs from when it was causing problems?
[09:22] <sil2100> mvo: btw. from the failed run you had, could you upload the cloud-init log tarball somewhere?
[09:23] <mvo> mwhudson: cloud init logs for the console-conf setup? or just where it thinks its in a cloud?
[09:23] <mwhudson> mvo: one where set-name ended up in places it shouldn't
[09:24] <mvo> mwhudson: I can probably do that but need to rewrite the sd card and start from scratch, this is also tricky because cloud-init keeps the logs in /run but I cannot login with the broken network
[09:25] <mwhudson> mvo: ugh
[09:25] <sil2100> mwhudson: so far I can share with you mvo's cloud-init-generator and ds-identify logs
[09:25] <mwhudson> debug shell time?
[09:25] <mvo> mwhudson: yes, just annoying to add in uboot, I struggle with this everytime because I never remember how to do it correctly :(
[09:26] <mwhudson> everyone loves uboot
[09:26] <mvo> mwhudson: but I give it a poke in some minutes, just trying to debug another failure on this pi
[09:26] <mvo> mwhudson: hahaha
[09:26] <mwhudson> ok
[09:26] <mwhudson> mvo: basically cloud-init does have code that will write netplan with set-name in it
[09:26] <zyga> mborzecki: reviewed
[09:26] <mwhudson> i don't at all understand how it could be triggered in this context
[09:27] <mwhudson> but i also have no other ideas how else it could get there
[09:27] <mwhudson> wait
[09:27] <mwhudson> "cloud-init keeps the logs in /run"
[09:27] <mwhudson> is that a core specific thing?
[09:27] <mwhudson> break in the initramfs and mount /run as a real partition? :)
[09:28] <mwhudson> (systemd might get angry if you do that i guess)
[09:28] <mvo> mwhudson: to break I need to add a kernel comandline and then I might as well add a debug shell. oh well, I think I will do that
[09:28] <mwhudson> oh yeah
[09:28] <mvo> mwhudson: maybe its in /var/log as well, I will check
[09:29] <mwhudson> it certainly is in classic
[09:29] <mvo> mwhudson: pretty sure that the generator log is only in /run but I guess thats not relevant for you, right?
[09:29] <mwhudson> yeah no i want cloud-init.log and cloud-init-output.log
[09:29] <sil2100> Didn't see anything in /var/log
[09:29] <mvo> mwhudson: cool, if thats the case then I can help sooner
[09:30] <sil2100> I had to do a cloud-init collect-logs previously
[09:30] <sil2100> /var/log/cloud-init.log is empty for me
[09:31] <mborzecki> damn gnome-shell crashing on each unlock
[09:32] <mwhudson> sil2100: hmm
[09:32] <mwhudson> sil2100: syslog?
[09:32] <mborzecki> zyga: thanks for the review, i didn't think about adding a selinux backend, but maybe we should once the cleanups are in
[09:34] <sil2100> mwhudson: no syslog + eek, persistent journal not enabled by default
[09:35] <mwhudson> sil2100: i am not surprised :/
[09:35] <mwhudson> (persistent journal vs sd cards?)
[09:35] <sil2100> Let me re-flash and enable persistent journal
[09:38] <zyga> mvo: I pushed to https://github.com/snapcore/snapd/pull/6308
[09:38] <mup> PR #6308: release: 2.36.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6308>
[09:38] <zyga> the diff isn't 0 but it is as close as it should
[09:38] <zyga> yes, the release branch had one more patch that was in the chain of fixing system key issue
[09:38] <zyga> it was because my initial branch got closed and reshuffled and I lost track of that
[09:39] <zyga> anyone interested in 2nd review on https://github.com/snapcore/snapd/pull/6288 ?
[09:40] <mup> PR #6288: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6288>
[09:41] <zyga> mvo: do you know what is the status of SRUs into bionic?
[09:41] <zyga> 2.35.5 is in proposed
[09:41] <zyga> 2.34.2 is in main/updates
[09:42] <mvo> zyga I think there were issues with autopkgtest
[09:42] <zyga> aha
[09:43] <zyga> real or just noise?
[09:43] <mvo> zyga: I did not dig into them, iirc autopkgtest killed our tests because they ran too long
[09:43] <zyga> uhhh
[09:43] <zyga> anyway, it's probably not super urgent but it would be good to update the classic package
[09:43] <mvo> zyga I'm not sure what the latest status is though
[09:43] <zyga> and as soon as 2.36.x is out, do that as well
[09:43] <mvo> zyga absolutely
[09:43] <zyga> mvo: no worries, one thing at a time
[09:43] <zyga> mvo: :)
[09:43] <mvo> zyga its a mess - I think we need to disable adt again, its just not working in our cloud :(
[09:44] <zyga> for context, I'm asking because of this bug last evening: https://bugs.launchpad.net/snapd/+bug/1806070
[09:44] <mup> Bug #1806070: snapd.seeded.service never completes preventing full boot to default target <amd64> <apport-bug> <bionic> <snapd:Fix Released> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1806070>
[09:44] <zyga> the package in the archive is preventing snapd seeding and refreshing in some cases
[09:44] <mvo> zyga thanks! I remember we talked about this
[09:44]  * zyga looks at the snow outside
[09:44] <zyga> brr
[09:44] <zyga> I miss my old computer
[09:44] <zyga> the one that doubled as room heater
[09:45] <ppisati> mvo: does the ethernet mac change?
[09:45] <sil2100> ppisati: it's just the IP, I guess it's all good from the kernel side, it's more like a cloud-init thing
[09:46] <mvo> ppisati: yeah, sorry for the noise, it stopped for me AFAICT once I disabled cloud-init
[09:46] <mvo> ppisati: which should not have run in the first place but that is a different story.
[09:46] <ppisati> ack
[09:47] <mwhudson> mvo: i think i have more or less convinced myself that the set-name comes from cloud-init
[09:47] <mwhudson> mvo: and now i am going to bed
[09:47]  * mwhudson zzzz
[09:47] <sil2100> Indeed, mwhudson thanks!
[09:48] <mvo> mwhudson: sleep well
[09:48] <mvo> mwhudson: and thank you!
[09:52] <pedronis> mvo: we should be careful with the notfound value in that config, it was enabled I think in your original log, not sure where that comes from
[09:55] <mvo> pedronis: I don't know what enabled it originally, iirc /etc/cloud is empty
[09:56] <pedronis> mvo: I mean, I'm not sure what happens if it's set to disabled and there's cloud init config
[09:56] <pedronis> or somebody attaches a disk some of that
[09:56] <pedronis> it was working on 16
[10:00] <mvo> pedronis: oh, ok. I suspect that 16 has a different ds-identify
[10:02] <sil2100> Ugh, indeed
[10:02] <sil2100> ds-identify-behavior-xenial.patch
[10:03] <mvo> sil2100: oh, interessting - can you pastebin that one?
[10:03] <sil2100> Wait, one moment, this doesn't look right
[10:07] <pedronis> mvo: 16 had also this:  https://github.com/snapcore/core/blob/master/live-build/hooks/40-cloud-init-run-after-networkd-wait-online.chroot
[10:08] <pedronis> probably not relevant given that in 18 networkd is used in all server images?
[10:08] <mvo> sil2100: one more interessting observation - even when I run console-conf I get a prompt to run it again instead of the usual "here is the machine IP and how you log in". but could be an artifcat
[10:08] <mvo> pedronis: that is the default now unless I very much misremember
[10:09] <mvo> pedronis: I remember looking at this patch and if we still need it
[10:09] <mvo> (I might be wrong though and can double check in a wee bit)
[10:10] <zyga>  mborzecki https://bugzilla.redhat.com/show_bug.cgi?id=1648733
[10:11] <mborzecki> heh
[10:13] <pedronis> mvo: I read dsidentify, nocloud is a kind of cloud,  either the things ubuntu-image writes or a properly labeled fs shoild make dsidentify detect that
[10:13] <pedronis> so that's not a notfound case afaict
[10:13] <mvo> pedronis: hm, ok
[10:14] <pedronis> see dscheck_NoCloud
[10:14] <zyga> Chipaca: heh, this is fun https://bugs.launchpad.net/snapd/+bug/1808450
[10:14] <pedronis> still wondering where the notfound=enabled comes from
[10:14] <zyga> Chipaca: %q needs to be localised :)
[10:14] <pedronis> shouldn't be the default
[10:14] <mup> Bug #1808450: Strings with placeholders don’t include quotation marks so they can’t be changed per locale <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1808450>
[10:14] <Chipaca> zyga: hrm?
[10:15] <mvo> pedronis: interessting
[10:15] <Chipaca> zyga: yeah, no
[10:15] <Chipaca> zyga: somebody's being very ornery there
[10:15] <zyga> well, I kind of agree
[10:15] <sil2100> pedronis: I think it is the default, when you check ds-identify's DI_DEFAULT_POLICY_NO_DMI I guess?
[10:15] <zyga> snapd would not get a passing grade from my polish tearcher
[10:15] <zyga> teacher
[10:16] <pedronis> sil2100: ah
[10:16] <mborzecki> pedronis: left some benchmarks in https://github.com/snapcore/snapd/pull/6265#discussion_r241703113 it's a vm running as a snapshot, though i took care to drop the caches each time, i'll see if i can get some measurements where the are actual writes to a spin drive
[10:17] <mup> PR #6265: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
[10:17] <mborzecki> fwiw the numbers aren't terrible, 27s for 600k small files, better than fontconfig
[10:20] <pedronis> mborzecki: this sound like we don't want to do it inconditionally, no?
[10:21] <pedronis> mvo: anyway afaik  we can just set  maybe=none and the parsing will use the defaults for the rest
[10:21] <pedronis> s/afaik/afaict/
[10:21] <mvo> pedronis: cool, I can try in a bit but right now I am running the testsuite
[10:22] <mborzecki> pedronis: the pr was already updated to do it only when the ~/snap (the dir) is not using the default label
[10:22] <mvo> pedronis: it looks like all the issues cachio had with running the arm tests are from cloud-init being enabled, so far I ran the core18 specific tests and all green, main is running now as well
[10:22] <pedronis> good
[10:23] <mvo> pedronis: I'm sure sil2100 will find a good config and a way to get it into the system and then this fire is hopefully also done
[10:25] <Chipaca> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1808450/comments/1
[10:25] <mup> Bug #1808450: Strings with placeholders don’t include quotation marks so they can’t be changed per locale <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1808450>
[10:25] <pedronis> mvo: sil2100: we can have that file in core18 itself?
[10:25] <pedronis> that file = ds-identify.cfg
[10:26] <Chipaca> zyga: I mean, I agree, except in Spanish guillemots are very much optional / recommended-but-not-required
[10:26] <zyga> I agree about the low priority
[10:26] <Chipaca> zyga: and the 2nd preferred quote symbols are … “”
[10:26] <sil2100> pedronis: so I see that in core 16 we had /etc/cloud/ds-identify.cfg
[10:26] <sil2100> With policy: search,found=first,maybe=none,notfound=disabled
[10:26] <Chipaca> zyga: to which " is a close enough approximation for now
[10:26] <sil2100> Trying to figure out where this file is coming from
[10:26]  * zyga is happy that he can at least read loads of spanish 
[10:27] <mvo> sil2100: where did this come from? did u-i put it there ?
[10:29] <sil2100> mvo: that's a good question, trying to figure it out - u-i doesn't really have mechanisms for arbitrary files in /etc
[10:29] <mborzecki> spread jobs hitting travis timeouts?
[10:29] <sil2100> mvo: huh
[10:29] <sil2100> mvo: it's in the core snap
[10:30] <sil2100> mvo: not sure what's adding it, but if you unsquashfs core you can see the file there - I didn't see it created in any hooks so far, cloud-init itself also doesn't seem to ship it (at least as a file, maybe through maintainer scripts?)
[10:32] <mvo> sil2100: oh, run
[10:32] <mvo> sil2100: eh, fun
[10:32] <pedronis> mvo: sil2100: fascinating
[10:32] <mvo> sil2100: ok, we can put it back if that fixes all the issues
[10:32] <pedronis> anyway means doing the same for 18 wouldn't be too crazy :)
[10:32] <mvo> pedronis: :)
[10:33] <sil2100> Yeah, sounds like the best way ;) I'll try to figure out where it's created out of curiosity anyway
[10:33] <sil2100> But this would fix "all the issues"
[10:33] <mvo> sil2100: I think ubuntu-core-config created this
[10:33] <mvo> sil2100: give me a sec
[10:33] <sil2100> mvo: oh, that's something new!
[10:33] <sil2100> I saw it in the image PPA once but didn't know it was used
[10:33] <sil2100> Sweet
[10:33] <mvo> sil2100: we no longer use it
[10:34] <mvo> sil2100: its a pain
[10:34] <pedronis> core build is so byzantine
[10:34] <mvo> sil2100: I mean, the configs are split between gits
[10:34] <mvo> sil2100: so we fixed this in the core18 build but sometimes (like now) we still suffer
[10:34] <mvo> pedronis: indeed
[10:34] <mvo> sil2100: fwiw https://github.com/snapcore/core-build/tree/master/config/etc/cloud
[10:35] <pedronis> ah
[10:35] <pedronis> we have two core related repos?
[10:36] <mvo> pedronis: yes, sadly - core-build and core
[10:37] <sil2100> At least it's all known now \o/
[10:37] <mup> PR core18#105 opened: static: add ds-identify.cfg back <Created by mvo5> <https://github.com/snapcore/core18/pull/105>
[10:37] <pedronis> mborzecki: when you a little bit of time could you look at https://github.com/snapcore/snapd/pull/5712 , it's long lived but now I finally got to make it green, had to adjust for parallel installs changes
[10:37] <mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
[10:37] <mborzecki> pedronis: ack
[10:38] <pedronis> mvo: that config tree seems a bit in the wrong repo to me
[10:38] <mvo> pedronis: you mean core-build?
[10:38] <pedronis> yea
[10:38] <pedronis> if it's basically content of the thing
[10:38] <mvo> pedronis: this is why I created https://github.com/snapcore/core/pull/83
[10:38] <pedronis> it should go into core somehow
[10:39] <mup> PR core#83: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[10:39] <pedronis> ah
[10:39] <mvo> pedronis: and then it did not get merged /o\
[10:39] <sil2100> eeek
[10:39]  * mvo weeps harder in the corner
[10:40] <pedronis> it seems definitely a good idea
[10:42] <mvo> pedronis: I added a card for myself
[10:42] <sil2100> mvo: SHIP IT!
[10:43] <pedronis> mvo: sil2100: there's some other bits of cloud/ that might be relevant there btw
[10:43] <pedronis> I suppose the resize bit is done differently now though
[10:44] <pedronis> or is that done for clouds?
[10:44] <pedronis> and we need it?
[10:46] <mvo> pedronis: we ship https://github.com/snapcore/core18/blob/master/static/etc/cloud/cloud.cfg.d/10_snappy.cfg (ironically)
[10:47] <pedronis> very
[10:47] <mvo> pedronis: which is iirc the same as in uc16 - or am I misunderstanding
[10:47] <pedronis> yes
[10:47] <pedronis> it's ironic indeed because without cloud-init it would have done nothing
[10:48] <mvo> pedronis: :(
[10:48] <mvo> pedronis: so this is why the maybe become a yes?
[10:49] <pedronis> ?
[10:49] <mvo> pedronis: what I meant its ironic that we only had half the config. but you indicate that if we had no config at all cloud-init would not have bothered to run?
[10:53] <pedronis> mvo: sil2100: so it seems we need to port more bits from 16 to static/etc/cloud
[10:54] <mvo> pedronis: what else is missing?
[10:54] <pedronis> there's a bit about azure it seems
[10:55] <mvo> pedronis: pretty sure that is obsolete but worth checking with someone from the cloud team
[10:55] <pedronis> https://github.com/snapcore/core-build/blob/master/config/etc/cloud/cloud.cfg.d/99-snappy-azure.cfg
[10:55] <pedronis> sil2100: can you check if we need this ^ or not anymore ?
[10:56] <pedronis> mvo: ok, probably easiest for sil2100 to do that
[10:56] <mup> PR core18#105 closed: static: add ds-identify.cfg back <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/105>
[10:56] <mvo> building a new core18 with the right ds-identify.cfg now
[10:59]  * mvo also builds 2.36.3 for regular core beta
[11:01] <mup> PR snapd#6296 closed: tests: new backend used to run upgrade test suite <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6296>
[11:04] <pedronis> sil2100: are you looking into why core18 CI is red? seems related to the checks for package removal
[11:09] <zyga> mvo: is new snapd okay but we need changes to core18 or will you do another snapd release to fix the cloud issues?
[11:10] <pedronis> zyga: the last changes are all just in core18 afaiu
[11:10] <zyga> great
[11:12] <mvo> 2.36.3 is now in beta core everything but arm64
[11:12] <mvo> (the later is still building)
[11:13] <sil2100> pedronis: I didn't get to fixing them, but I confirmed that they're not real issues - the test env needs fixing, it's on my plate for ASAP
[11:19] <mup> PR snapd#6309 opened: overlord/ifacestate: addHotplugSeqWaitTask helper <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6309>
[11:22] <pstolowski> zyga: ^ if you have a moment
[11:22] <zyga> yep saw it
[11:30] <zyga> +1
[11:30] <pstolowski> zyga: +1 on 6288, but plese see the comment
[11:32] <zyga> pstolowski: applied!
[11:33] <pstolowski> ty
[11:39]  * pstolowski lunch
[11:42] <zyga> mborzecki: something to garden https://bugzilla.redhat.com/buglist.cgi?component=snapd&product=Fedora
[11:43] <zyga> make sure to select *all* bugs
[11:44] <mup> PR snapd#6310 opened: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6310>
[11:44] <zyga> mvo: found the patch that didn't make it into master https://github.com/snapcore/snapd/pull/6310
[11:44] <mup> PR #6310: interfaces: return security setup errors <Created by zyga> <https://github.com/snapcore/snapd/pull/6310>
[11:54] <mvo> zyga: ta
[11:56] <Chipaca> I need to go to the boys' school for 2pm, meaning I'm not going to be here for the standup (although I should be back by 2.30 so I might see y'all if it extends a bit) (but, traffic, so dunno)
[11:57] <Chipaca> I'm still working on the epochs rerefresh thing
[12:00] <zyga> k
[12:00] <pedronis> Chipaca: ok,  let me know if you have questions or something
[12:03] <Chipaca> pedronis: another?
[12:03]  * Chipaca looks
[12:03] <pedronis> Chipaca: ?
[12:04] <Chipaca> pedronis: I split one out from Epochs yesterday
[12:04] <pedronis> Chipaca: forgot to assign it to you?
[12:04] <Chipaca> pedronis: " make sure to check and trigger new refreshes if there are further transitions available"
[12:04] <Chipaca> ah, drat, yes
[12:04] <Chipaca> pedronis: thanks
[12:05] <pedronis> removing mine, and tweaking yours
[12:05] <Chipaca> thanks
[12:05] <Chipaca> and I didn't notice but replied in public to a private message
[12:05] <Chipaca> hope nobody's too confused :-D
[12:05] <Chipaca> or at most as confused as i clearly was
[12:07] <Chipaca> I'm going to have lunch and see if that makes things better :-)
[12:10] <cachio> mvo, 509 and 510 are the right versions?
[12:11] <cachio> for arm devices
[12:16] <mborzecki> pedronis: left one suggestion under https://github.com/snapcore/snapd/pull/5712 otherwise lgtm
[12:16] <mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
[12:17] <pedronis> mborzecki: thx
[12:18]  * cachio afk
[12:21] <zyga> coffee
[12:28] <mborzecki> wtf is going on with fedora repos?
[12:43] <zyga> mborzecki: they have holidays too?
[12:43] <mborzecki> heh
[12:43] <zyga> I need to go run an errand, brb in 30 minutes
[12:43] <Son_Goku> oh god, I'm so happy
[12:43] <Son_Goku> this is my last day of work for 2018
[12:44] <zyga> I wished :)
[12:44] <zyga> Son_Goku: I'm iterating on https://github.com/snapcore/snapd/pull/6111
[12:44] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[12:44] <Son_Goku> zyga, I didn't take much vacation this year, since I only had the one trip for Flock
[12:45] <zyga> I need to run that errand but the last part is the with/bcond work
[12:45] <zyga> and then I need to figure out why go is broken in leap again :)
[12:45] <zyga> afk :)
[12:45]  * Son_Goku waves
[12:46] <mborzecki> zyga: the problem with refreshing fedora repos seem to happen only in gcp
[12:46] <mborzecki> i can refresh just fine here
[12:48] <zyga> cloudscale problem ;)
[12:48] <zyga> mborzecki: idea
[12:48] <zyga> mborzecki: spin up our own mirror
[12:48] <zyga> try against that
[12:51] <mborzecki> zyga: heh, hardly sounds like the thing we ought to be focusing on :)
[13:23] <mvo> cachio: hey, yeah, 508,9 should be the right ones
[13:24] <mvo> cachio: I will be afk for a bit but looking at tg
[13:25] <cachio> mvo, good
[13:35] <zyga> re
[13:35] <zyga> this took forever, sorry
[13:36] <zyga> is it just me or is travis stuck?
[13:40] <pedronis> zyga: we might have hit some limit
[13:44] <cachio> zyga, hey
[13:44] <zyga> yes?
[13:45] <cachio> fedora 29 is taking more time than other systems
[13:45] <cachio> I saw it is taking time to build snapd
[13:45] <zyga> any idea why? download speed? more updates than usual?
[13:45] <cachio> could tha because because it is using go 11?
[13:46] <zyga> did go 11 got introduced?
[13:47] <zyga> as otherwise I don't see how go version is a factor
[13:49] <cachio> not sure when I was introduced
[13:49] <cachio> but after last update it is taking more time to run fedora29
[13:49] <zyga> after last update of what?
[13:49] <cachio> fedora 29
[13:49] <zyga> of the image?
[13:49] <cachio> there was a kernel update
[13:49] <cachio> zyga, yes
[13:49] <zyga> can you diff the package manifest in the old and the new image?
[13:50] <zyga> I don't know what changed
[13:50] <pedronis> zyga: is the description of 6310 up-to-date? didn't we learn that the SIGTERM was coming from systemctl stop snapd ?
[13:50] <zyga> I also don't have an suspicion what could be a factor
[13:50] <cachio> zyga, sure
[13:51] <zyga> pedronis: it's the original patch that got lost in various changes, this is to match the release merge PR that mvo noticed has some delta
[13:51] <pedronis> zyga: this for master though, right?  so an up-to-date description would be best
[13:52] <zyga> yes, it is the same patch as before, just proposed in a branch that got closed
[13:52] <zyga> I can edit the description, sure
[13:52] <pedronis> thank you
[14:00] <cachio> pedronis, I'll join in 2 minutes
[14:26] <thresh> how many snaps in the store are already using core18?
[14:37] <mvo> cachio: core18 is still not good, it looks like /etc/cloud is not populated (cc sil2100)
[14:38] <pstolowski> mborzecki: updated #6114
[14:38] <mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
[14:38] <pstolowski> mborzecki: could you also take a look at the #6309 (simple)
[14:38] <pstolowski> ?
[14:38] <mup> PR #6309: overlord/ifacestate: addHotplugSeqWaitTask helper <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6309>
[14:38] <mborzecki> mhm
[14:38] <pstolowski> thanks
[14:39] <cachio> mvo, ouch
[14:39] <cachio> bad news
[14:39] <cachio> mvo, I'll run beta validation for 2.36.3
[14:40] <cachio> until core18 is ready
[14:40] <sil2100> mvo: huh? Something wipes out the /etc/cloud contents?
[14:41] <sil2100> mvo: hm, looking into core18 snap's squashfs I see /etc/cloud/ds-identify.cfg
[14:41] <sil2100> mvo: you don't have it?
[14:42] <sil2100> mvo: are you sure you're testing the right image/core18 snap?
[14:42] <sil2100> Let me build a test image and check on my pi3
[14:42] <mvo> sil2100: if you boot your VM, do you see a populated /etc/cloud ?
[14:42] <mvo> sil2100: x86 should be enough
[14:43] <sil2100> Building
[14:47] <sil2100> mvo: ah, I see what's happening, /etc/cloud is in writable-paths
[14:47] <sil2100> hmmm
[14:47] <mvo> sil2100: I have a theory
[14:48] <sil2100> But it should work
[14:49] <mup> PR core18#106 opened: static,hooks: make /etc/cloud a "synced" dir for now <Created by mvo5> <https://github.com/snapcore/core18/pull/106>
[14:49] <sil2100> AH
[14:49] <sil2100> Holy moly
[14:50] <mvo> sil2100: the rabbit hole is deeper
[14:50] <mvo> sil2100: I just added another paragraph
[14:50] <mvo> sil2100: anyway, I think this is the best we can do for now but we may need to deprecate ubuntu-images --cloud-config option
[14:50] <mvo> sil2100: or push it into cloud.cfg.d or something
[14:51] <mvo> sil2100: but even that has config :/
[14:53] <mvo> sil2100: well, actually I think we need to simply support cloud.cfg and ds-identify.cfg in the gadget
[14:54] <mvo> sil2100: anyway, the above PR will unblock the world
[14:58] <zyga> mvo: fun friday, it seems
[14:59] <sil2100> mvo: ok, this looks good, I'm just wondering - what is creating the empty /etc/cloud directory? Is it part of snap prepare?
[15:00] <sil2100> Since I don't remember we have anything in ubuntu-image that does that explicitly
[15:00] <zyga> https://github.com/snapcore/core18/search?q=%2Fetc%2Fcloud&unscoped_q=%2Fetc%2Fcloud
[15:00] <zyga> sil2100: it is 020-extra-files.chroot
[15:01] <mup> PR snapd#6311 opened: image: do not write empty etc/cloud <Created by mvo5> <https://github.com/snapcore/snapd/pull/6311>
[15:01] <mvo> sil2100: yeah, see 6311 (coming in a sec if mup is attentive)
[15:01] <sil2100> mvo: so maybe it'd be just better to remove that one?
[15:01] <sil2100> I mean, synced is fine I guess, but maybe we don't have to do it, all we need is to not create that empty dir?
[15:02] <mvo> sil2100: we could remove it its a good question, removing requires building the images with a snap command build with 6311
[15:02] <sil2100> ubuntu-image also won't put any files there, the only cloud-init stuff it puts in is the user-data
[15:03] <sil2100> hm
[15:03] <mvo> sil2100: snap prepare-image creaets the dir even if its empty
[15:03] <mvo> sil2100: thats a bug and then u-i puts the empty dir into the writable dir
[15:03] <mvo> sil2100: of course if we can teach u-i to not copy the empty dir that would be even nicer
[15:03] <sil2100> Ah, ok
[15:04] <mvo> sil2100: if you are comfortable with chaning u-i that works for me as well, slightly preferable
[15:04] <sil2100> mvo: ok, I guess it's just safest to go with synced then, since I see there's multiple places where the dir can pop up
[15:04] <mvo> sil2100: we still have a problem with gadgets that ship a cloud.conf because we no longer "merge" the configs but I think this is a feature :)
[15:04] <sil2100> mvo: since as per what zyga pasted we also create the empty /etc/cloud dir in core18 itself
[15:05] <mvo> sil2100: its fine if its in the core18 snap
[15:05] <mvo> sil2100: the problem is really that its also in /writable
[15:05] <mvo> sil2100: and snap prepare-image creates it and then u-i puts it there
[15:05] <sil2100> Ah, right!
[15:06] <sil2100> Stupid me
[15:06] <mvo> sil2100: I can poke a u-i to see if there is a single place to check
[15:06] <mvo> sil2100: no worries a) its friday b) its complicated
[15:06] <mvo> sil2100: (not necessarily in this order ;)
[15:06] <sil2100> mvo: it's certainly possible to do in u-i, no problem
[15:06] <sil2100> Problem is in releasing u-i again ;p
[15:06] <sil2100> i.e. not something to be done on Friday
[15:06] <mvo> sil2100: heh
[15:06]  * zyga hugs sil2100 and mvo
[15:07] <mvo> sil2100: as long as cachio can create correct images we can release monday ;)
[15:07]  * mvo hugs zyga
[15:07] <mvo> zyga: yeah, fun week so far
[15:09]  * sil2100 hugs zyga back
[15:09] <sil2100> mvo: ok, for now I approved the synced MP
[15:09] <sil2100> I'll prepare a hack for u-i in the meantime
[15:12] <mvo> sil2100: does the u-i snap embedd the snap command it uses?
[15:13] <mup> PR core18#106 closed: static,hooks: make /etc/cloud a "synced" dir for now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/106>
[15:13] <zyga> so leap 42.3 *does* have new go 1.10
[15:13] <mvo> sil2100: I take it for now to unblock sergio - if we have something better we can revert without any harm
[15:14] <zyga> update from 1.9
[15:15] <sil2100> mvo: I don't think the u-i snap ships snap, I think it uses the system one
[15:15] <sil2100> I'll double check
[15:16] <mvo> sil2100: can I become part of the people who can trigger a build in https://code.launchpad.net/~ubuntu-core-service/+snap/core18 ?
[15:16] <mvo> sil2100: aha, nevermind - autobuild started
[15:17] <sil2100> mvo: of course you can o/
[15:30] <mvo> sil2100: fwiw, with an image generated with #6311 cloud-init is disabled so this part is fine
[15:30] <mup> PR #6311: image: do not write empty etc/cloud <Created by mvo5> <https://github.com/snapcore/snapd/pull/6311>
[15:34] <mvo> cachio: new coew18 is ready in beta
[15:39] <cachio> mvo, nice
[15:39] <cachio> I'll start after lunch
[15:39] <cachio> still without iternet at home
[15:39] <cachio> I think I'll need to go to another place
[15:40] <mvo> cachio: uh, good luck
[15:43] <sil2100> mvo: ok I have the u-i hack + tests in place, let me give it a spin in a moment
[15:44] <mvo> sil2100: cool
[15:44] <mvo> sil2100: \o/
[15:44] <mvo> sil2100: the "synced" change also works, tests are running on my pi3 and all the stragness is gone (noe more property set-name error in netplan etc)
[15:46] <sil2100> mvo: it's best to have more options to choose from I suppose ;) And I also think it'd be easier to fast-track ubuntu-image to release pockets than for instance snapd, since our livefs builders use archive packages for building the images
[15:51] <zyga> cachio: I solved the problem with opensuse leap
[15:51] <zyga> cachio: I will push a small update soon
[15:51] <zyga> cachio: but it might be best to refresh all opensuse images
[15:51] <zyga> though let's do this only after my fix is merged
[15:52] <cachio> zyga, sure
[15:52] <cachio> zyga, thanks for that fix
[15:58] <mvo> sil2100: yeah, I like the idea of doing it in u-i
[16:01]  * cachio lunch
[16:02] <cyphermox> mvo: property error for set-name in netplan?
[16:05] <sil2100> cyphermox: yeah, due to cloud-init meddling with the netplan config in some cases the netplan config ends up with a set-name: without a match:
[16:06] <sil2100> Like, it's injecting set-name when it shouldn't
[16:06] <cyphermox> yeah, ok
[16:06] <cyphermox> sil2100: to me "when it shouldn't" for set-name is pretty much always
[16:07] <cyphermox> I feel strongly like it's something that should be avoided at all costs, and kind of sad that it got in, because it's often a cause for confusion :(
[16:16] <sil2100> mvo: https://github.com/CanonicalLtd/ubuntu-image/pull/167 <- seems to work
[16:16] <mup> PR CanonicalLtd/ubuntu-image#167: Do not copy-over /etc/cloud to the rootfs if it's empty <Created by sil2100> <https://github.com/CanonicalLtd/ubuntu-image/pull/167>
[16:24] <sil2100> mvo: I'd like to wait for the autopkgtests to run for those
[16:24] <sil2100> s/those/this PR
[16:26] <mvo> sil2100: nice one
[16:35] <mvo> sil2100: btw, can you commit to https://github.com/snapcore/core18 now? if not we need to ask niemeyer  to give you commit access
[16:36] <mvo> sil2100: I slightly prefer your u-i workaround, if thats ok with you and if we can give cachio a way to create the images I'm +1 on this one and we can revert the core18 commit that uses a synced dir
[16:36] <niemeyer> mvo: sil2100 should have access, as long as he accepted the invitation to join the team
[16:36] <mvo> sil2100: but no super strong opinion, synced is also easy to change later it won't do any harm
[16:39] <sil2100> mvo: so I'd still keep the synced writable-path for now until I push out a new ubuntu-image - I guess it might be enough for us to have it in disco, then I guess it should go relatively fast
[16:40] <sil2100> mvo: not sure if we built core18 images before on disco
[16:40] <sil2100> (like, on the disco livefs)
[16:40] <mvo> sil2100: ok
[16:40] <mvo> sil2100: I leave this to you then
[16:40] <mvo> sil2100: thanks, fwiw, tests on the pi look good now still
[16:44] <sil2100> \o/
[17:02] <zyga> cachio: on second thought
[17:02] <zyga> cachio: please run "zypper refresh && zypper update" on all suse images
[17:02] <zyga> cachio: the fix is really equivalent to doing that and rebooting :/
[17:02] <zyga> so we may just as well do that
[17:06] <kyrofa> Hey zyga, did you have any other thoughts on https://forum.snapcraft.io/t/raspberry-pi-3-install-broken/8957/5 ?
[17:07] <zyga> kyrofa: I bet a beer that it's either ENOSPC or EROFS after ext4 corruption on flaky sd card
[17:09] <kyrofa> zyga, want me to suggest trying another SD card?
[17:09] <zyga> We should first get full logs from systemd
[17:09] <zyga> I don't think we got an answer since yesterday
[17:10] <kyrofa> Indeed, we have not
[17:10] <kyrofa> I'll go ping him on another forum :P
[17:20]  * zyga EODs
[17:20] <zyga> I'll check my PRs later
[17:24] <zyga> I love how this page looks like for communicating features to users https://github.com/github/VisualStudio/issues/1878
[17:41] <sil2100> mvo: ok, autopkgtests were happy with the branch, let me push it out to the archive
[17:42] <sil2100> mvo: I'll make it an interim release, e.g. not 1.6 per-se
[17:57] <sil2100> Actually hmm, I anyway need to get those changes out
[18:00] <sil2100> mvo: ubuntu-image 1.6 pushed to disco, SRUs to other series will follow
[18:39] <diddledan> can I specify something in snap.yaml (using snapcraft's passthrough) that will match the arch-triplet of the current system so that I can move $SNAP/usr/lib/$ARCH_TRIPLET/webkit2gtk-4.0 to /usr/lib via bind mount without adding every arch separately?
[18:39] <zyga> not using passthrough
[18:39] <diddledan> I obviously mean bindmounting it to /usr/lib/$ARCH_TRIPLET/webkit2gtk-4.0
[18:40] <diddledan> and I'm referring to using layouts
[18:40] <zyga> snapd doesn't support arch triplet because it's distro specific
[18:40] <zyga> we tried to and abandoned that
[18:40] <zyga> only snapcraft does
[18:40] <diddledan> so how do I do this?
[18:41] <zyga> manually
[18:41] <zyga> not sure
[18:41] <zyga> using snapcraft?
[18:41] <zyga> why are you using passthrough?
[18:41] <diddledan> for layouts
[18:41] <zyga> you can use layouts now without that
[18:41] <diddledan> layout isn't supported by snapcraft yet
[18:41] <zyga> it is
[18:41] <diddledan> nope
[18:41] <zyga> yep
[18:41] <zyga> since 3.0
[18:41] <zyga> but
[18:41] <zyga> for unknown reason you need to start using "base: core18"
[18:41] <zyga> while technically not required
[18:41] <zyga> it's a snapcraft bait and switch
[18:42] <diddledan> well that's silly
[18:42] <diddledan> :-p
[18:42] <zyga> I don't disagree :)
[18:42] <zyga> it would not be silly if we had shipped core16
[18:42] <zyga> and you could just say "base: core16"
[18:42] <zyga> "layouts: ..."
[18:42] <zyga> now it is silly
[18:44] <zyga> mvo: if you are working by any chance
[18:44] <zyga> could we ship core16 base snap alongside core18?
[18:44] <diddledan> hah: "You need multipass installed to build snaps which use the base keyword" <-- I've already got it!
[18:44] <diddledan> oh!
[18:45] <diddledan> it's trying to install multipass inside a multipass vm because I accidentally left SNAPCRAFT_BUILD_ENVIRONMENT=multipass in the environment
[18:45] <diddledan> turtles all the way down
[18:54] <pedronis> zyga: we really don't want to push core16 much yet
[18:55] <zyga> pedronis: then we should not marry core18 with layouts in snapcraft IMO
[18:55] <pedronis> zyga: did I say we should
[18:55] <zyga> we do :)
[18:55] <zyga> or did
[19:01] <pedronis> also for clarity: core16 is not stable yet
[19:01] <diddledan> well blow me down with a feather! you're right, using base:core18 does indeed enable layout: to work
[19:09] <pedronis> fedora tests are a mess atm
[19:10] <diddledan> yey?
[19:17] <zyga> pedronis: shall I disable it?
[19:18] <pedronis> zyga: maybe, it's causing a lot of red atm
[19:18] <zyga> on it
[19:22] <cachio> sil2100, hey, still don't have internet at home
[19:22] <cachio> sil2100, I'll make the validation over the weekend and I'll send the results
[19:22] <zyga> pedronis: done
[19:22] <cachio> so we can continue to stable
[19:23] <mup> PR snapd#6312 opened: spread: disable fedora-29-64 <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6312>
[19:24] <pedronis> cachio: if you are sending out mails about the results, please cc also me
[19:24] <pedronis> thank you
[19:24] <pedronis> zyga: thx, let's see if that one gets green
[19:32] <cachio> pedronis, sure
[19:32] <cachio> I think I'll send the results tomorrow
[19:33] <cachio> pedronis, today I am using my phone internet and it goes so slow
[19:43] <sil2100> cachio: thanks!
[19:45] <cachio> zyga, opensuse update failed
[19:46] <cachio> zyga, https://paste.ubuntu.com/p/pC9bphSTgr/
[19:46] <cachio> using master
[20:01] <zyga> cachio: this error shows up when you update and not reboot
[20:57] <mvo> zyga: we talked about this, ideally we would just make core an alias for core16 in snapd
[20:57] <mvo> zyga: so that snapd understands that it just needs core for this
[20:57] <zyga> mmm
[20:58] <zyga> mvo: anyway, not urgent
[20:58] <zyga> mvo: I'm trying to land https://github.com/snapcore/snapd/pull/6312
[20:58] <zyga> if you want to look
[20:58] <zyga> it should help
[20:58] <mup> PR #6312: spread: disable fedora-29-64 <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6312>
[20:59] <mvo> zyga: sure
[21:10] <zyga> ha
[21:10] <zyga> you were faster
[21:11] <mup> PR snapd#6312 closed: spread: disable fedora-29-64 <⚠ Critical> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6312>
[21:11] <pedronis> it's merged
[21:11] <zyga> thank you :)
[21:12] <zyga> I restarted a few PRs
[21:12] <zyga> let's see
[21:12] <zyga> mvo: I left a few comments on https://github.com/snapcore/snapd/pull/5845
[21:13] <mup> PR #5845: interface: add new `{personal,system}-files`  interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/5845>
[21:13] <zyga> not sure if you want to do anything about it
[21:13] <zyga> or just merge it
[21:13] <zyga> it's green
[21:23] <roadmr> ohai zyga
[21:23] <zyga> hey :)
[21:23] <roadmr> how's it going? is the glue trick keeping you safe from spaghetti?
[21:23] <zyga> haha
[21:23] <zyga> yes!
[21:23] <zyga> it's a miracle
[21:24] <zyga> printing on 1st go
[21:24] <zyga> I'm shocked
[21:24] <roadmr> great! how do you unglue the piece from the bed when it's done?
[21:24] <zyga> should have learned this months ago
[21:24] <zyga> the bed comes off and you just bend it slightly
[21:24] <zyga> things pop off without any issues
[21:25] <roadmr> zyga: how'd you find out about this?
[21:25] <zyga> about the glue?
[21:25] <zyga> read that it helps
[21:25] <zyga> found some information on the internet by chance
[21:27] <roadmr> interesting, sounds like it'd be a very well-known fact, as I think it's a common problem
[21:27] <roadmr> glad it's working well now :)
[21:27] <roadmr> zyga: hey a snapd-related question - you may know and save me hours of dredging through the code base
[21:27] <zyga> it may be well known, I'm happy I know it too :)
[21:28] <zyga> how can I help?
[21:28] <roadmr> zyga: do you remember at some point, snap deltas were disabled for armhf devices because $REASONS?
[21:29] <zyga> because CPU uber slow
[21:30] <roadmr> zyga: hm, and were they enabled at some point? or are armhf devices still delta-less?
[21:30] <zyga> I don't know that
[21:30] <zyga> I don't know how the delta was disabled
[21:31] <roadmr> zyga: ok.. I found something about enabling deltas for core devices, back in February, but that seems to be arch-agnostic
[21:31] <roadmr> zyga: ok, no problem - thanks! maybe I'll ask ogra whom I remember talked about this at some point
[21:33] <ogra> roadmr, they were in fact not enabled in the beginning because nobody had measured the performance for single core arm, but Chipaca did some research at some point, i thought they were enabled later on
[21:35] <roadmr> hi ogra ! yes, sorry, as I'm here grilling you guys I'm also analyzing download logs and it looks like they were enabled at some point; I'm trying to determine when (basically which version of snapd did that). For instance, I see some armhf devices with  2.35 getting deltas, while others with 2.32 seem to not get deltas
[21:36] <roadmr> ogra, zyga : if I can pinpoint the version that enabled this, I can tell the guy using that old 2.32 to upgrade to 2.3x so they can benefit from awesome bandwidth savings for free
[21:36] <roadmr> if Chipaca is the one who did it, I can ask him on Monday; I'm in no rush :)
[21:45] <mup> Bug #1808593 opened: AppArmor denies ptrace for ufw snap in lxc after purging ufw <Snappy:New> <https://launchpad.net/bugs/1808593>
[21:48] <mup> Bug #1808593 changed: AppArmor denies ptrace for ufw snap in lxc after purging ufw <snapd:New> <https://launchpad.net/bugs/1808593>
[22:08] <mvo> zyga: I want to address the comments but not today :) thanks for those!
[22:08] <pedronis> roadmr: it was done in february, not by John
[22:09] <roadmr> pedronis: https://github.com/snapcore/snapd/pull/4639 ?
[22:09] <mup> PR #4639: store: enable deltas for core devices too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4639>
[22:09] <pedronis> yes
[22:09] <roadmr> pedronis: and that went out in snapd 2.33.1?
[22:10] <thiras> I'm getting "ENOENT: no such file or directory, lstat '/snap/code'"
[22:10] <thiras> at the vscode
[22:10] <thiras> any idea what is this?
[22:11] <pedronis> roadmr: 2.33 already if I believe the changelog
[22:11] <roadmr> pedronis: yay thanks
[22:12] <pedronis> roadmr: yes, 2.33
[22:13] <roadmr> pedronis: great! thanks for helping confirm.
[22:13] <roadmr> this matches what I see in logs, btw
[22:13] <roadmr> thanks for the help folks, I appreciate it, I know it's late for you
[22:37] <mup> PR snapd#6288 closed: cmd/snap-confine: refactor call to snap-update-ns --user-mounts <Per-user mount ns  🐎> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6288>
[22:58] <mup> PR snapd#6307 closed: systemd/systemd.go: add missing tests for systemd.IsActive <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6307>
[22:58] <mup> PR snapd#6309 closed: overlord/ifacestate: addHotplugSeqWaitTask helper <Hotplug 🔌> <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6309>
[22:59] <mup> PR snapd#6263 closed: Retrieving all pages for 'find' command, not only one <Created by WiseRaccoon> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6263>
[23:53] <thiras> is there a way to check if a local snap file (not downloaded from Canonical) has right to access to disk?