[00:54] zyga: snap refresh to a bogus channel succeeds when the store is throttling connections, because it returns bogus results that snapd thinks are "ok go for it" [00:56] zyga: https://bugs.launchpad.net/snapd/+bug/1804245 [00:56] Bug #1804245: empty response from store when throttled allows switch to nonexistent track [07:41] Where are the logs for the snap version of snapcraft? I get a "Sorry, an error occurred in Snapcraft.Sending an error report" when running snapcraft cleanbuild === pstolowski|afk is now known as pstolowski [08:04] mornings [08:31] pstolowski: hi, can you try to merge master into #6315 [08:32] PR #6315: overlord/ifacestate: include interface name in the hotplug-disconnect task summary [08:33] pedronis: will do [08:40] pushed [09:43] PR snapd#6265 closed: cmd/snap: attempt to restore SELinux context of snap user directories [09:44] PR snapd#6321 closed: spread: show free space in debug output [09:46] PR snapd#6302 closed: wrappers: address review feedback from #6301 [09:55] pstolowski: could I get a review of #6306 , it has a bit of non-nice hack for tests atm but that should go away with go1.9 (go vet in 1.6 is too picky) [09:55] PR #6306: release: use locking around lazy intialized state [09:55] sure [10:52] pstolowski: #6315 is green [10:52] PR #6315: overlord/ifacestate: include interface name in the hotplug-disconnect task summary [10:53] ty [10:53] PR snapd#6315 closed: overlord/ifacestate: include interface name in the hotplug-disconnect task summary [11:18] is it a known issue that core18 ships a dbus machine-id file? [11:18] $ cat /snap/core18/current/var/lib/dbus/machine-id [11:18] a7579438e8b04d97a185d6aeefb83323 [11:19] that breaks a number of things for core18-based snaps [11:19] including ibus support [11:20] $ cat /snap/core18/current/var/lib/dbus/machine-id [11:20] a7579438e8b04d97a185d6aeefb83323 [11:20] SNAP! [11:20] sil2100: ^ [11:20] that's kind of unexpected [11:42] Looking [11:45] eh [11:45] Indeed, we missed that one [11:45] The removal of the machine-id was done in livecd-rootfs ;/ [11:53] sil2100, would it be useful if I filed a bug to track the issue? (if so, where?) [11:55] oSoMoN: https://bugs.launchpad.net/snap-core18 [11:55] I'll be fixing it now [11:55] thanks [11:57] sil2100, https://bugs.launchpad.net/snap-core18/+bug/1809107 [11:58] Bug #1809107: core18 contains var/lib/dbus/machine-id [12:02] pedronis: I don't know much about the implications of that, is this a blocker for core18 release you think? [12:03] e.g. should I fast-track this through QA to stable and re-spin core18 images today ASAP? [12:04] Testing the fix [12:04] sil2100: not sure, need to think a bit [12:09] PR core18#107 opened: As per what we did in core16, remove dbus's machine-id [12:09] oSoMoN: sil2100: I'm a bit confused because afaict snaps don't have access to that file anyway by default [12:12] pedronis, oSoMoN: if anything, the PR above seems to do the trick [12:17] pedronis, oSoMoN: I'll merge the PR so that the new core18 can go to validation straight away [12:18] PR core18#107 closed: As per what we did in core16, remove dbus's machine-id [12:20] cachio: hey! Once the new core18 snap appears at the store, could you run your tests on it? [12:24] sil2100: what about /etc/machine-id ? [12:29] pedronis: I trunkate it [12:30] We did the same for core === ricab is now known as ricab|lunch [12:31] pedronis: anyway, in case we decide that we want to re-spin for this, could you give Eric a sign? [12:31] * sil2100 AFK for lunch [12:45] Another core 18 snap coming? [12:49] cwayne: yes [12:50] sil2100: is this the only change that we would get since the last core18? [12:55] (seems so) [12:58] pedronis: yeah, I suppose [12:58] cwayne: could your team pick it up? [12:59] sil2100: the snap test will be automatically picked up yes [13:00] eh, we missed the auto-import window, I triggered it manually, should be there soon [13:01] oSoMoN: a new core18 build is in progress, could you test out the new version once it hits the store? [13:01] * sil2100 now really AFK for lunch + vet [13:46] sil2100, sure, I'll test it as soon as it's out, edge channel I suppose? [13:47] could it be that revision 520 is it already? [14:25] oSoMoN: yes, 520 seems correct, I see no /var/lib/dbus/machine-id and an empty one in /etc [14:26] pstolowski: did you foget to submit the commnet in #6306? I don't see anything new there on GH unless I'm confused [14:26] PR #6306: release: use locking around lazy intialized state [14:27] pedronis: damn, indeed. now [14:28] pstolowski: thanks I see it now [15:00] sil2100, pedronis: 520 does the job, the regression with ibus that I was observing with the chromium snap is gone [15:00] thanks for fixing that so promptly! [15:00] when can I expect 520 to make it to stable? [15:19] oSoMoN: we are trying to QA it quickly [15:39] hey [15:39] how are things? [15:39] * zyga was freezing his ... ears off outside today [15:42] wear earmuffs :) [15:43] I was wearing everything I could, just have to admit not used to the cold anymore [15:45] hey all, can you please tell me which is the right image on http://cdimage.ubuntu.com/ubuntu-core/ to use in Multipass for "core"? http://cdimage.ubuntu.com/ubuntu-core/16/current/ is from April last year, http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ is from August, are there no newer images? [15:45] zyga: hehe well, sometimes it is just too cold. [15:46] I ended up walking most of the way [15:46] Saviq: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ is the latest deal [15:46] the streets are clogged with traffic jams [15:46] sil2100: is core18 healthy? [15:46] Saviq: we basically only re-create new images with every point-release (not counting some really emergency cases) [15:46] zyga: core18 is in testing right now [15:46] zyga: I'll tell you once I have results! [15:46] ;) [15:46] sounds good, thank you [15:48] zyga: certification team gave +1 on the snap, now just waiting for cachio [15:48] pedronis: did you talk to Eric? [15:48] sil2100: ack, it's kinda surprising since that means it would like to reboot pretty soon after first boot [15:50] Indeed [15:51] PR snapd#6322 opened: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get [15:55] sil2100, it is running [15:56] it is gonna take about 1~2 hrs to complete [15:56] sil2100, so far so good [15:58] * cachio lunch [16:02] eeek [16:02] Not good [16:21] sil2100, perhaps before [16:52] PR core18#108 opened: Remove build-time openssh-server host keys and add service to auto-generating them on boot [16:56] Would it be "sane" to share the whole snap tree using content interface ? I have a snap crossbar (WAMP router) and I want my app (also a snap) to start that router. [17:06] om26er, i'd call it "unelegant" but there is surely no technical reason to not do that [17:08] zyga: hey! You around? [17:08] zyga: could you take a look at https://github.com/snapcore/core18/pull/108 ? [17:08] PR core18#108: Remove build-time openssh-server host keys and add service to auto-generating them on boot === pstolowski is now known as pstolowski|afk [17:27] PR core18#108 closed: Remove build-time openssh-server host keys and add service to auto-generating them on boot [18:14] cwayne, plars: hey! New core18 snaps need validation! [18:15] cwayne, plars: could someone track that and make sure it's pushed forward? [18:15] sil2100: you don't need to tell us, it's done automatically [18:15] Images are different though :) [18:22] cwayne: thanks ;p Just poking in case of some infra failure [18:22] So that someone can poke it with a stick [18:32] cachio: are you testing the new core18 (528 etc) ? [18:33] pedronis, yes [18:33] thx [18:33] tests being executed [18:33] pedronis, I'll keep you updated [20:32] sil2100, +1 to go to candidate and stable [20:32] snapd tests passed [20:34] cachio: do you guys do any BT testing, or just the bt snapd interfaces? [20:34] just interfaces [20:34] cwayne, [20:34] sil2100: hey, I'm around now [20:35] cwayne, I am going to get my son [20:35] I'll be back in 30 minutes [20:35] cwayne, do you need anything urgent? [20:35] cachio: nope [20:35] otherwise I'll be back soon [20:35] cwayne, nice, thanks [20:36] sil2100: hey [20:36] sil2100: if I could I would -1 that pull request [20:36] what there ensures that keys are generated only once? [20:36] Too late [20:36] That's the mechanism from core16 [20:36] do we have *perl* on the image? [20:37] there are better ways for first boot systemd units [20:37] sil2100, hold on [20:37] I guess it is too late [20:37] I just saw an error [20:37] but this doesn't look great [20:37] I don't know the details but it works, and works only once [20:37] looks like a hack [20:37] I believe you [20:37] cachio: ...uh? [20:38] sil2100, https://paste.ubuntu.com/p/NbXvcW6Vtt/ [20:38] cachio: interesting, any logs that go with the unit? [20:38] sil2100, seems to be related with the last change, right? [20:39] zyga: yes [20:39] hmm [20:39] zyga, no [20:39] no logs [20:39] let me try again [20:39] I meant, cachio: yes [20:40] sil2100, https://paste.ubuntu.com/p/DbGGCsc2pt/ [20:40] zyga, ~ [20:40] cachio: what device is that? [20:40] Crap [20:40] it is a vm with ubuntu core i386 [20:41] sil2100, zyga https://paste.ubuntu.com/p/Dmj2DmtyVp/ [20:41] What the heck? [20:42] sil2100: sent my review on https://github.com/snapcore/core18/pull/108#pullrequestreview-186738700 [20:42] PR core18#108: Remove build-time openssh-server host keys and add service to auto-generating them on boot [20:42] sil2100: did you test this locally? [20:42] I'm surprised about the path [20:42] specifically /usr/lib/snapd/ssh-host-keygen [20:42] Why is /usr/lib/snapd/sshd-host-keygen gone? I did and I remembered it worked [20:43] But now it doesn't [20:43] what ships that file? [20:43] sil2100, could you reproduce that? [20:43] I added it in the PR [20:44] sil2100: ah I see it now [20:44] zyga: I took all of this from core-build and live-build hooks [20:44] Fuck [20:44] core18 [20:44] zyga: so snapd overrides that directory right? [20:44] sil2100: I don't remember from the top of my head [20:44] I presume yes [20:45] sil2100: in core18 yes [20:45] likely [20:45] sil2100: perhaps that script should ship in /usr/bin [20:45] How did that work, I got working keys [20:45] timing? [20:45] sil2100: we bind mount that whole thing [20:45] Let me move it [20:45] Probably timing [20:45] sil2100: the overriding at first boot is complicated [20:45] it invovles services as well [20:45] sil2100: can you consider my other comments before landing the next revision (at your discretion) [20:45] in core18 [20:45] core was easier snapd was inside it [20:45] hey pedronis :) [20:45] so that dir was fixed [20:45] zyga: I would prefer to just do it now, we're REALLY late [20:46] This is like REALLY REALLY REALLY late [20:46] sil2100: as I said, at your discretion [20:46] sil2100, zyga pedronis it is a fresh install https://paste.ubuntu.com/p/zZYJ5h4ZD6/ [20:46] sil2100: I'm super worried about shipping ssh keys [20:46] that we didn't notice this [20:46] sil2100: can you at least go over the list of files in the core18 snap that is produced [20:46] Anyway, the script as-is was in core so it won't be worse than it was already at least [20:47] zyga, pedronis sil2100 I need to leave, I need to get my son now [20:47] I'll be back as soon as possible [20:47] please telegran me [20:48] zyga: that script shipped like that in core16, we can improve it, but probably not right now [20:49] pedronis: sounds good [20:49] pedronis: but I think whoever is responsible for core18 should eyeball the list of files [20:49] pedronis: imagine we shipped this [20:49] with those keys [20:50] zyga: that's what sil2100 did, that's how we got here, afaiu [20:50] that's good [20:54] Ok, first boot works, no failures here, trying second boot with the path change' [20:55] zyga: ok, I moved the script to /usr/bin/ and it seems to work [20:55] sil2100: sounds very good [20:56] sil2100: it might need a different name there tough, snapd- ? [20:56] when it was in lib/snapd it didn't need a prefix [20:56] PR core18#109 opened: Move the ssh keygen script to /usr/bin [20:57] pedronis: +1 on that [20:57] It's good to change that just in case, let me do that [20:57] Maybe to core-? [20:58] Since it's not really a snapd thing [20:58] Sure, it was in the snapd directory but well, not sure [20:59] zyga, pedronis: PR ready for a quick review [21:00] looking [21:00] Thank you guys [21:00] thank *you* :) [21:01] +1 [21:01] \o/ [21:01] looks good [21:01] I'm doing a quick test build and test run to see if the new name didn't have a typo and then we can build the snap [21:01] Merging it in the meantime [21:02] PR core18#109 closed: Move the ssh keygen script to /usr/bin [21:05] Ok, looks good, kicking new builds [21:05] \o/ [22:32] I need to go AFK for a bit [22:32] I'll be back in ~30 minutes [22:49] ok, it will take to finish [23:16] Back [23:31] cachio: how's the testing? [23:32] sil2100, so far it is ok [23:32] last time failed 1 test which is failing because an env issue I have [23:33] the when I checked the error I saw this time it was something different [23:33] this time I fixed that issue on the environment but it is running slower [23:34] sil2100, but I need to make sure everything went well before the +1 :) [23:41] cachio: sure! [23:54] cachio: do you have a sense of how much long it will take? [23:54] pedronis, it is 60% [23:55] I think first suite will finish in 30 minutes maximun [23:55] second in 35 [23:55] with those we will have a good idea [23:56] so far no errors [23:59] but last time the last test failed :(