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:07 |
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> | 00:23 |
mborzecki | morning | 06:21 |
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:32 |
mup | PR snapd#6307 opened: systemd/systemd.go: add missing tests for systemd.IsActive <Created by mvo5> <https://github.com/snapcore/snapd/pull/6307> | 06:54 |
mup | PR snapd#6308 opened: release: 2.36.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6308> | 07:02 |
mvo | zyga: 6308 has some interessting bits, would love to understand where the code diff came from | 07:03 |
zyga | Hello | 07:16 |
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:17 |
mborzecki | zyga: mvo: hi | 07:28 |
=== pstolowski|afk is now known as pstolowski | ||
pstolowski | morning | 08:02 |
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:16 |
pstolowski | mvo: oh, still working today? | 08:17 |
mvo | pstolowski: fire is not fully over :( | 08:17 |
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:18 |
mvo | pstolowski: hopefully sil2100 (and foundations) can help with these issues | 08:19 |
pstolowski | mvo: :( | 08:21 |
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:22 |
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:23 |
zyga | Good morning | 08:32 |
mvo | zyga good morning :) | 08:33 |
zyga | Some patches required | 08:33 |
sil2100 | mvo: as per my e-mail, could you attach ds-identify.log from the cloud-init logs? | 08:34 |
sil2100 | mvo: anyway, I'm building an image for my pi3 now and I'll test it here as well | 08:41 |
mvo | sil2100: will do, mail goes out in 2min | 08:45 |
pedronis | mvo: hello | 08:46 |
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:49 |
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:50 |
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:51 |
pedronis | mvo: so it think maybe it's an OpenStack | 08:52 |
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:53 |
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:54 |
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:56 |
pedronis | wonderful | 08:58 |
sil2100 | check for 'OpenStack' returned maybe | 08:59 |
sil2100 | Oh yeah | 08:59 |
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:00 |
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:01 |
mvo | no set -e in ds-identify, thats an interessting choice | 09:03 |
mvo | anyway | 09:03 |
pedronis | mvo: sil2100: does ubuntu-image write some cloud-init conf | 09:04 |
pedronis | ? | 09:04 |
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:05 |
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:07 |
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:08 |
pedronis | mvo: there's some doc at the top of it, it mentions /etc/cloud/ds-identify.cfg and the kernel cmdline | 09:09 |
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:13 |
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:19 |
pstolowski | and i've just de-conflicted them | 09:20 |
mborzecki | i'm doing 6114 now | 09:20 |
pstolowski | thanks | 09:20 |
mborzecki | hm need to grab some coffee | 09:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
sil2100 | I had to do a cloud-init collect-logs previously | 09:30 |
sil2100 | /var/log/cloud-init.log is empty for me | 09:30 |
mborzecki | damn gnome-shell crashing on each unlock | 09:31 |
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:32 |
sil2100 | mwhudson: no syslog + eek, persistent journal not enabled by default | 09:34 |
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:35 |
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:38 |
zyga | anyone interested in 2nd review on https://github.com/snapcore/snapd/pull/6288 ? | 09:39 |
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:40 |
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:41 |
mvo | zyga I think there were issues with autopkgtest | 09:42 |
zyga | aha | 09:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
mvo | mwhudson: sleep well | 09:48 |
mvo | mwhudson: and thank you! | 09:48 |
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:52 |
mvo | pedronis: I don't know what enabled it originally, iirc /etc/cloud is empty | 09:55 |
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 | 09:56 |
mvo | pedronis: oh, ok. I suspect that 16 has a different ds-identify | 10:00 |
sil2100 | Ugh, indeed | 10:02 |
sil2100 | ds-identify-behavior-xenial.patch | 10:02 |
mvo | sil2100: oh, interessting - can you pastebin that one? | 10:03 |
sil2100 | Wait, one moment, this doesn't look right | 10:03 |
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:07 |
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:08 |
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:09 |
zyga | mborzecki https://bugzilla.redhat.com/show_bug.cgi?id=1648733 | 10:10 |
mborzecki | heh | 10:11 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
pedronis | mborzecki: this sound like we don't want to do it inconditionally, no? | 10:20 |
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:21 |
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:22 |
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:23 |
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:25 |
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:26 | |
mvo | sil2100: where did this come from? did u-i put it there ? | 10:27 |
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:29 |
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:30 |
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:32 |
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:33 |
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:34 |
pedronis | ah | 10:35 |
pedronis | we have two core related repos? | 10:35 |
mvo | pedronis: yes, sadly - core-build and core | 10:36 |
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:37 |
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:38 |
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:39 | |
pedronis | it seems definitely a good idea | 10:40 |
mvo | pedronis: I added a card for myself | 10:42 |
sil2100 | mvo: SHIP IT! | 10:42 |
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:43 |
pedronis | or is that done for clouds? | 10:44 |
pedronis | and we need it? | 10:44 |
mvo | pedronis: we ship https://github.com/snapcore/core18/blob/master/static/etc/cloud/cloud.cfg.d/10_snappy.cfg (ironically) | 10:46 |
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:47 |
mvo | pedronis: :( | 10:48 |
mvo | pedronis: so this is why the maybe become a yes? | 10:48 |
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:49 |
pedronis | mvo: sil2100: so it seems we need to port more bits from 16 to static/etc/cloud | 10:53 |
mvo | pedronis: what else is missing? | 10:54 |
pedronis | there's a bit about azure it seems | 10:54 |
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:55 |
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:56 |
* mvo also builds 2.36.3 for regular core beta | 10:59 | |
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:01 |
pedronis | sil2100: are you looking into why core18 CI is red? seems related to the checks for package removal | 11:04 |
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:09 |
pedronis | zyga: the last changes are all just in core18 afaiu | 11:10 |
zyga | great | 11:10 |
mvo | 2.36.3 is now in beta core everything but arm64 | 11:12 |
mvo | (the later is still building) | 11:12 |
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:13 |
mup | PR snapd#6309 opened: overlord/ifacestate: addHotplugSeqWaitTask helper <Hotplug π> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6309> | 11:19 |
pstolowski | zyga: ^ if you have a moment | 11:22 |
zyga | yep saw it | 11:22 |
zyga | +1 | 11:30 |
pstolowski | zyga: +1 on 6288, but plese see the comment | 11:30 |
zyga | pstolowski: applied! | 11:32 |
pstolowski | ty | 11:33 |
* pstolowski lunch | 11:39 | |
zyga | mborzecki: something to garden https://bugzilla.redhat.com/buglist.cgi?component=snapd&product=Fedora | 11:42 |
zyga | make sure to select *all* bugs | 11:43 |
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:44 |
mvo | zyga: ta | 11:54 |
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:56 |
Chipaca | I'm still working on the epochs rerefresh thing | 11:57 |
zyga | k | 12:00 |
pedronis | Chipaca: ok, let me know if you have questions or something | 12:00 |
Chipaca | pedronis: another? | 12:03 |
* Chipaca looks | 12:03 | |
pedronis | Chipaca: ? | 12:03 |
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:04 |
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:05 |
Chipaca | I'm going to have lunch and see if that makes things better :-) | 12:07 |
cachio | mvo, 509 and 510 are the right versions? | 12:10 |
cachio | for arm devices | 12:11 |
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:16 |
pedronis | mborzecki: thx | 12:17 |
* cachio afk | 12:18 | |
zyga | coffee | 12:21 |
mborzecki | wtf is going on with fedora repos? | 12:28 |
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:43 |
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:44 |
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:45 | |
mborzecki | zyga: the problem with refreshing fedora repos seem to happen only in gcp | 12:46 |
mborzecki | i can refresh just fine here | 12:46 |
zyga | cloudscale problem ;) | 12:48 |
zyga | mborzecki: idea | 12:48 |
zyga | mborzecki: spin up our own mirror | 12:48 |
zyga | try against that | 12:48 |
mborzecki | zyga: heh, hardly sounds like the thing we ought to be focusing on :) | 12:51 |
mvo | cachio: hey, yeah, 508,9 should be the right ones | 13:23 |
mvo | cachio: I will be afk for a bit but looking at tg | 13:24 |
cachio | mvo, good | 13:25 |
zyga | re | 13:35 |
zyga | this took forever, sorry | 13:35 |
zyga | is it just me or is travis stuck? | 13:36 |
pedronis | zyga: we might have hit some limit | 13:40 |
cachio | zyga, hey | 13:44 |
zyga | yes? | 13:44 |
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:45 |
zyga | did go 11 got introduced? | 13:46 |
zyga | as otherwise I don't see how go version is a factor | 13:47 |
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:49 |
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:50 |
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:51 |
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 | 13:52 |
cachio | pedronis, I'll join in 2 minutes | 14:00 |
=== ricab is now known as ricab|lunch | ||
thresh | how many snaps in the store are already using core18? | 14:26 |
mvo | cachio: core18 is still not good, it looks like /etc/cloud is not populated (cc sil2100) | 14:37 |
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:38 |
cachio | mvo, ouch | 14:39 |
cachio | bad news | 14:39 |
cachio | mvo, I'll run beta validation for 2.36.3 | 14:39 |
cachio | until core18 is ready | 14:40 |
sil2100 | mvo: huh? Something wipes out the /etc/cloud contents? | 14:40 |
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:41 |
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:42 |
sil2100 | Building | 14:43 |
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:47 |
sil2100 | But it should work | 14:48 |
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:49 |
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:50 |
mvo | sil2100: but even that has config :/ | 14:51 |
mvo | sil2100: well, actually I think we need to simply support cloud.cfg and ds-identify.cfg in the gadget | 14:53 |
mvo | sil2100: anyway, the above PR will unblock the world | 14:54 |
zyga | mvo: fun friday, it seems | 14:58 |
sil2100 | mvo: ok, this looks good, I'm just wondering - what is creating the empty /etc/cloud directory? Is it part of snap prepare? | 14:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 | |
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:07 |
* 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:09 |
mvo | sil2100: does the u-i snap embedd the snap command it uses? | 15:12 |
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:13 |
zyga | update from 1.9 | 15:14 |
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:15 |
=== ricab|lunch is now known as ricab | ||
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:16 |
sil2100 | mvo: of course you can o/ | 15:17 |
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:30 |
mvo | cachio: new coew18 is ready in beta | 15:34 |
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:39 |
mvo | cachio: uh, good luck | 15:40 |
sil2100 | mvo: ok I have the u-i hack + tests in place, let me give it a spin in a moment | 15:43 |
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:44 |
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:46 |
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:51 |
cachio | zyga, sure | 15:52 |
cachio | zyga, thanks for that fix | 15:52 |
mvo | sil2100: yeah, I like the idea of doing it in u-i | 15:58 |
* cachio lunch | 16:01 | |
cyphermox | mvo: property error for set-name in netplan? | 16:02 |
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:05 |
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:06 |
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:07 |
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:16 |
sil2100 | mvo: I'd like to wait for the autopkgtests to run for those | 16:24 |
sil2100 | s/those/this PR | 16:24 |
mvo | sil2100: nice one | 16:26 |
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:35 |
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:36 |
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:39 |
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:40 |
sil2100 | \o/ | 16:44 |
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:02 |
kyrofa | Hey zyga, did you have any other thoughts on https://forum.snapcraft.io/t/raspberry-pi-3-install-broken/8957/5 ? | 17:06 |
zyga | kyrofa: I bet a beer that it's either ENOSPC or EROFS after ext4 corruption on flaky sd card | 17:07 |
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:09 |
kyrofa | Indeed, we have not | 17:10 |
kyrofa | I'll go ping him on another forum :P | 17:10 |
=== pstolowski is now known as pstolowski|afk | ||
* zyga EODs | 17:20 | |
zyga | I'll check my PRs later | 17:20 |
zyga | I love how this page looks like for communicating features to users https://github.com/github/VisualStudio/issues/1878 | 17:24 |
sil2100 | mvo: ok, autopkgtests were happy with the branch, let me push it out to the archive | 17:41 |
sil2100 | mvo: I'll make it an interim release, e.g. not 1.6 per-se | 17:42 |
sil2100 | Actually hmm, I anyway need to get those changes out | 17:57 |
sil2100 | mvo: ubuntu-image 1.6 pushed to disco, SRUs to other series will follow | 18:00 |
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:39 |
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:40 |
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:41 |
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:42 |
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:44 |
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:45 |
pedronis | zyga: we really don't want to push core16 much yet | 18:54 |
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 | 18:55 |
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:01 |
pedronis | fedora tests are a mess atm | 19:09 |
diddledan | yey? | 19:10 |
zyga | pedronis: shall I disable it? | 19:17 |
pedronis | zyga: maybe, it's causing a lot of red atm | 19:18 |
zyga | on it | 19:18 |
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:22 |
mup | PR snapd#6312 opened: spread: disable fedora-29-64 <β Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6312> | 19:23 |
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:24 |
cachio | pedronis, sure | 19:32 |
cachio | I think I'll send the results tomorrow | 19:32 |
cachio | pedronis, today I am using my phone internet and it goes so slow | 19:33 |
sil2100 | cachio: thanks! | 19:43 |
cachio | zyga, opensuse update failed | 19:45 |
cachio | zyga, https://paste.ubuntu.com/p/pC9bphSTgr/ | 19:46 |
cachio | using master | 19:46 |
zyga | cachio: this error shows up when you update and not reboot | 20:01 |
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:57 |
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:58 |
mvo | zyga: sure | 20:59 |
zyga | ha | 21:10 |
zyga | you were faster | 21:10 |
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:11 |
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:12 |
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:13 |
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:23 |
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:24 |
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:25 |
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:27 |
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:28 |
zyga | because CPU uber slow | 21:29 |
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:30 |
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:31 |
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:33 |
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:35 |
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:36 |
mup | Bug #1808593 opened: AppArmor denies ptrace for ufw snap in lxc after purging ufw <Snappy:New> <https://launchpad.net/bugs/1808593> | 21:45 |
mup | Bug #1808593 changed: AppArmor denies ptrace for ufw snap in lxc after purging ufw <snapd:New> <https://launchpad.net/bugs/1808593> | 21:48 |
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:08 |
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:09 |
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:10 |
pedronis | roadmr: 2.33 already if I believe the changelog | 22:11 |
roadmr | pedronis: yay thanks | 22:11 |
pedronis | roadmr: yes, 2.33 | 22:12 |
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:13 |
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:37 |
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:58 |
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> | 22:59 |
thiras | is there a way to check if a local snap file (not downloaded from Canonical) has right to access to disk? | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!