=== chihchun_afk is now known as chihchun [03:37] PR snapcraft#2326 closed: plugins: remove implicit source === cpaelzer_ is now known as cpaelzer [05:09] morning [05:29] PR core18#74 opened: hooks: use core18.start-snapd.service for ordering [05:45] PR core18#74 closed: hooks: use core18.start-snapd.service for ordering [05:48] PR snapd#5910 closed: snapshotstate: restore to current revision [05:54] PR core18#75 opened: static: show snapd firstboot messages on /dev/console [05:56] PR core18#75 closed: static: show snapd firstboot messages on /dev/console [06:23] o/ [06:25] zyga: hey [06:28] hey zyga and mborzecki [06:29] PR core18#76 opened: static: make run-snapd-from-snap wait for seeding [06:29] :-) [06:46] PR core18#76 closed: static: make run-snapd-from-snap wait for seeding [07:05] uh, on the pi I get "backend.go:319: cannot create host snap-confine apparmor configuration: cannot s [07:05] ynchronize snap-confine apparmor profile: open /var/lib/snapd/apparmor/profiles/ [07:05] snap-confine.snapd.1122.m8GcXdqQ5cDR~: no such file or directory" quite often [07:05] at firstboot seeding === pstolowski|afk is now known as pstolowski [07:05] * mvo wonders what is going on there [07:05] mornings [07:05] hey pstolowski [07:15] mvo: didn't we fix that? [07:15] mvo: is the pi using anything modern or is this the release image? [07:15] (release as in 16.04) [07:16] zyga: let me check, it should use master [07:17] zyga: rev is 2.35.4+git1480.gdb577fc [07:17] from 7h ago [07:18] hmm, then it looks real [07:19] I'm debugging a different issue right now, we look after this but it looks scary as it breaks first boot seeding [07:19] k [07:20] its a race most likely [07:20] does not happen all the time [07:20] and I think not at all on quick HW like amd64 [07:20] plus it is (currently) mask by this other bug that console-conf runs too early [07:31] mvo: is https://github.com/snapcore/snapd/pull/5917 still something we want (AFAIK you want to branch master so back ports are not needed) [07:31] PR #5917: cmd/snap: attempt to start the document portal if running with a sess… [07:31] PR snapd#5927 closed: cmd/snap-update-ns: remove empty placeholders used for mounting [07:32] zyga: I think its something we want [07:32] k, just land it then [07:32] note, the master version landed already [07:32] zyga: I will branch again once 2.35.4 is in candidate [07:32] zyga: aha, ok [07:32] this is just a back port [07:32] ok [07:35] mvo: I still have a small image.go PR to do (now that everything in snapd itself has landed), can be backported after the main branching tough [07:36] pedronis: ok, thank you [07:48] zyga: I think I have an idea about the bug, will go full force once I am finished with the current console-conf sync issue [07:48] let me know what you find [07:55] PR snapd#5951 opened: spread-shellcheck: fix interleaved error messages, tweaks === chihchun is now known as chihchun_afk [08:12] anyone wishing to review #5947 and #5948 ? feel free to do one or both [08:12] PR #5947: many: cleanup remaining parallel installs TODOs [08:12] PR #5948: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names [08:12] pstolowski: any of your hotplug PRs need attention? [08:12] pstolowski: i have #5860 open [08:12] PR #5860: interfaces/hotplug: helpers and struct updates [08:15] mborzecki: I can do after noon [08:15] mborzecki: you can review that one, yes; i generally miss Gustavo's reviews on all of them. i'll have new PRs today I think, i'm going to split my code and propose complete feature in 2-3 pieces, so there will be new material to review. thanks for asking! [08:15] still fighting that test === chihchun_afk is now known as chihchun [08:28] PR core18#77 opened: hooks: ensure serial-console-conf also runs after core18.start-snapd.service [08:42] pstolowski: Sorry, haven't managed to get to the rest of them yesterday (did get to the key gen one).. will put the others at the top of my queue today [08:43] niemeyer: sure, thanks for the device key review, addressed your feedback and trying to land (travis is not cooperating, again) [08:50] PR core18#77 closed: hooks: ensure serial-console-conf also runs after core18.start-snapd.service [09:07] PR core-build#36 closed: initramfs: fix shellchecks on bionic [09:21] * zyga -> small break [09:25] * zyga is about to throw the towel on the overlayfs test [09:29] cjwatson, did the builders become stricter with the recent changes ? i just did manual re-builds of some of my snaps that never had probs building and all of a sudden they fail to release ... there are warnings about host libs being pulled in but i think they were there before and did not make the snap get stuck [09:29] ogra: no [09:29] weird [09:29] ogra: "failed to release" is from the store, not from the builders, anyway [09:30] yeah, but i dont even see the re-built snaps in the store ... like they never arrived [09:30] so this is either due to snapcraft or due to the review tools, probably; unlikely to be the builders [09:31] ogra: it's not fair to ask me to speculate on this without giving me a link [09:32] https://launchpad.net/~build.snapcraft.io/+snap/3fc16b55a813a672666c6ff13690918e-xenial/+build/323860 [09:32] aha ! [09:32] Temporary failure in name resolution [09:32] looks liek some internal DC thing [09:33] (sorry, i only looked at build.s.io ... could have checked LP directly) [09:33] That's the ENOMEM issue on ackee [09:33] It is SUPER WEIRD [09:34] are there chances clicking retry will work (else i'll just leave it as is for the moment, there were no important snaps re-built, only because of security notifications) [09:35] We have three workers that run various jobs such as store uploads; as of a few weeks ago, occasionally one of them gets into a state where it starts getting ENOMEM for all attempts to allocate memory, despite there being loads of memory free and all the other usual things you might check in this situation [09:35] This results in a bunch of things failing, including DNS resolution [09:35] weird indeed ... [09:35] yeah [09:36] Hmm, one of the workers is in that state right now [09:36] it might be a good idea to forward the error message to the build.snapcraft.io log or some such [09:37] especially since the only link to look at LP is at the top of the log iself ... not sure how many people will actually use that to find out more [09:39] The BSI log is just the build log [09:39] Can't do that [09:40] I have a spec for improvements to LP's store upload process [09:40] It's probably not next on my list but maybe the one after that [09:40] well, this is mostly about the UI of build.s.io ... not even sure thats in your area of things :) [09:42] having some direct link to the LP build or some more info than a bland "Failed to release" with no further info on the page would help [09:50] Evan says we're not allowed :P [09:50] haha [09:50] (to have a direct link to LP) [09:50] yeah ... i got that [09:51] PR core18#78 opened: static: show seed progress on console on firstboot [09:55] PR core18#78 closed: static: show seed progress on console on firstboot [09:56] ogra: Bug in the BSI UI, I think - it's meant to show it but there's a confusion about ![] not being true in JS [09:56] ah [10:05] PR snapd#5952 opened: tests/ifacestate: moved asserts-related mocking into helper [10:07] why are timers/sockets enabled in StartServices() rather than AddSnapServices() ? [10:07] pedronis: can you take a look ^ ? [10:07] pstolowski: yes, after lunch [10:09] ogra: Anyway, you can try using Retry, though due to the various problems outlined in https://docs.google.com/document/d/1vabN2wBNtGdBqShN1xi9a-osfGPtmA8EARdXfs2kfDI it's possible that it will require a full rebuild in order to be uploadable [10:10] cjwatson, well, i just tried retry and got a permission error [10:10] seemingly i'm not allowed to retry [10:11] A permission error saying what precisely? [10:11] Oh, from https://launchpad.net/~build.snapcraft.io/+snap/3fc16b55a813a672666c6ff13690918e-xenial/+build/323860 ? Yeah, LP doesn't know that you own the snap on BSI. [10:11] right [10:11] I've hit Retry but it probably won't work [10:12] well, that particular snap is less important anyway ... and i'll trigger rebuilds for the others [10:14] Yeah, that hit the silly duplicate-snap-content error from the store [10:14] Which is one of the things my spec covers [10:37] PR core18#79 opened: snap-snapd-from-snap: remove all debug output [10:57] if/when you spot a unit test on travis taking ages talking to the apt mirror, please let me know [10:58] I want those logs [10:59] e.g. https://travis-ci.org/snapcore/snapd/jobs/439058232 [11:09] PR snapd#5953 opened: apparmor: create SnapAppArmorDir in setupSnapConfineReexec [11:11] ppisati, hmm, 4.4.0-1099-raspi2 doesnt have the modules fix yet ? (i just had an upgrade on my pi's and the splashes went away) === pstolowski is now known as pstolowski|lunch [11:15] cjwatson, hmm, are we short on arm builders again (all my retried builds now sit in "building soon" state for all amr arches) [11:15] *arm [11:16] ogra: see #is-outage please [11:16] work in progress [11:16] ok [11:25] https://paste.ubuntu.com/p/gTn99BMxhg/ snap services with sockets and timers [11:36] pstolowski|lunch: Nitpick (and optional, obviously): [11:36] // attribute name and value are separated by null character [11:37] That's exactly what the code below it says [11:37] more clearly [11:38] zyga: re: https://forum.snapcraft.io/t/snap-layouts/7207/4?u=tobias → Added an answer, but it seems there's something else going on there. I'm running a command in my install hook to copy files over from $SNAP/folder/subfolder/* to $SNAP_DATA/subfolder, could it be that? This happens even when I completely remove the “partly duplicated file name” section from the layout stanza. [11:39] pstolowski|lunch: Ah, there's something else.. will comment on the PR [11:40] dot-tobias: I don't think the hook is a factor, it runs after the setup process, in any case, if you can share a snap that I can play with (even a dummy one that has this bug) it would help as I was unable to reproduce this [11:41] zyga: Will cook up something, thanks [11:56] pstolowski|lunch, hey, already working in nested suite [12:04] Chipaca: niemeyer: i see you've discussed including timers in snap services commands, i've posted a note in the topic https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262/33 feel free to provide suggestions [12:06] cachio: hey, https://github.com/snapcore/spread-images/pull/17 had to execute those manually, but afaict the host after those changes appears to work fine [12:06] PR spread-images#17: tasks/google/update-arch-linux: tweak Arch image update [12:09] mborzecki, nice, checking [12:20] PR snapcraft#2323 closed: go plugin: support for bases [12:21] mborzecki: Thanks! === pstolowski|lunch is now known as pstolowski [12:23] oh, what a surprise, opensuse failing agian :-(((((( [12:24] can we add a rule, "to be supported by snapd, your distro's mirror archive must be *this* available"? [12:26] PR snapcraft#2327 opened: pluginhandler: remove prepare, build and install scriptlets [12:29] mborzecki, works!! [12:34] mborzecki: Responded [12:38] PR snapcraft#2328 opened: godeps plugin: support for bases [12:38] mvo_: I put a reproducer in bug 1796017 [12:39] Bug #1796017: git ubuntu build-source fails with missing libreadline.so.6 [12:39] I'm a bit baffled as to why this doesn't work. Is there anything else going on eg. seccomp? [12:39] Or other necessary environment changes that I missed? [12:55] mborzecki, [12:58] PR core18#79 closed: snap-snapd-from-snap: remove all debug output [13:10] argh [13:10] sergiusens, !!! [13:10] Snapping 'pi-kiosk' | [13:10] Snapped pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap [13:10] Stopping local:snapcraft-sadly-choice-amoeba [13:10] Retrieved "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap" [13:11] sergiusens, thats a snapcraft cleanbuild of a snap using build-on/run-on ... [13:11] ogra: stop naming your snap "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')])" [13:11] ogra: we'll get kyrofa to take a look when he gets in [13:11] i'd kind of expect the resulting snap file not to contain python code in its name [13:12] but, cleanbuild is also deprecated to a baseless world [13:12] so how do i build my snaps now ? [13:15] ogra: if you set a base, you get a build vm [13:15] sergiusens, so i need to touich all the snaps i have ? [13:15] (for re-builds when getting security notifications ??) [13:15] ogra: no, if you do not change anything, you don't need to touch anything [13:17] cjwatson, i know you are busy with the outage ... but i see some weird cross build behaviour on the builders that i can not reproduce locally either with a plain build or withz a snapcraft cleanbuild [13:17] checking for arm-linux-gcc... /usr/bin/arm-linux-gnueabihf-gcc [13:17] checking whether the C compiler works... no [13:17] configure: error: in `/build/pi-kiosk/parts/psplash/build': [13:17] configure: error: C compiler cannot create executables [13:17] PR snapcraft#2329 opened: pluginhandler: remove legacy plugin loading without project [13:18] the fun part is that theer is a part before that just used /usr/bin/arm-linux-gnueabihf-gcc to build a binary [13:18] ogra: I have no idea, sorry. Try catting config.log after the failure to get more details [13:19] hmm., k [13:30] Chipaca: can you take a quick look at https://github.com/snapcore/snapd/pull/5951 ? [13:30] PR #5951: spread-shellcheck: fix interleaved error messages, tweaks [13:37] mborzecki: what do you think about my 'activator' comment? [13:38] PR snapcraft#2330 opened: pluginhandler: remove big solidus workaround [13:44] * Chipaca ~> school run* [13:44] * wee (maybe) [13:51] hi, is there a way to specify the container image/release when running "snapcraft cleanbuild"? [13:52] PR snapd#5759 closed: ifacestate: implementation of defaultDeviceKey function for hotplug === chihchun is now known as chihchun_afk [14:01] cjwatson, here we go https://launchpadlibrarian.net/392453534/buildlog_snap_ubuntu_xenial_amd64_ae16fdc83ee020a5817d7f0243e105b5-xenial_BUILDING.txt.gz seems while my desktop and cleanbuild automatically install binutils-arm-linux-gnueabihf when i add a "build-packages" entry for gcc-arm-linux-gnueabihf, the LP builder doesnt do so [14:01] at least thats my guess for: [14:01] configure:2973: /usr/bin/arm-linux-gnueabihf-gcc conftest.c >&5 [14:01] collect2: error: ld returned 1 exit status [14:01] grrr ! IRC [14:02] configure:2973: /usr/bin/arm-linux-gnueabihf-gcc conftest.c >&5 [14:02] /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find crt1.o: No such file or directory [14:02] /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find crti.o: No such file or directory [14:02] collect2: error: ld returned 1 exit status [14:02] sergiusens, hi, maybe you have insights on my question above? [14:04] aha ! [14:04] libc6-dev-armhf-cross iss a recommends ... ok [14:04] *is [14:05] cjwatson, thanks for pointing in the right direction i think i got a workaround for that one (though it is still weird that cleanbuild doesnt expose that issue) [14:15] Hey folks.. I'm back [14:26] whee ! a properly cross built gadget snap on build.snapcraft.io !!!! [14:26] https://launchpad.net/~build.snapcraft.io/+snap/ae16fdc83ee020a5817d7f0243e105b5-xenial/+build/349077 [14:27] very nice ! [14:44] ackk: no, there is not; we are moving to a new model which will be trickled by the use of bases. [14:45] PR snapd#5954 opened: [wayland] explicitly permit file locking for wayland lock [15:00] jdstrand, so i have https://dashboard.snapcraft.io/snaps/dashkiosk-client-image-config/revisions/11/ ... using a self-provuded udisks2 interface, is there any chance you would approve that or should i rip out the code using that interface ? [15:02] jdstrand, source is at: https://github.com/ogra1/dashkiosk-client-image-config [15:03] sergiusens, I see, so there's currently no way of cleanbuilding a core18 snap [15:18] kyrofa ping [15:19] ackk: no, for that you probably want to be on edge and set SNAPCRAFT_BUILD_ENVIRONMENT=multipass (and set base: core18) [15:19] ondra, hey there [15:20] sergiusens, ah I see. I do use edge and core18 base [15:20] sergiusens, so this will only be available on multipass? [15:21] ackk: just missing the env then, but edge should switch to creating the VM by default real soon [15:21] sergiusens, thanks [15:21] ackk: for the time being yes, it what was agreed to during the roadmap sprint. Next cycle we will bring back lxd [15:22] kyrofa hey [15:22] kyrofa can you please check https://code.launchpad.net/~ondrak/+snap/toolbox [15:22] kyrofa for whatever reason on arm64 it breaks when priming [15:23] ogra: mm, may be the sort of thing that gets ironed out by moving to a common build container/VM/whatever [15:24] cjwatson, well, fallout of --no-install-recommends i think [15:25] apparently the cleanbuild lxd container installs recommends by default [15:25] ogra: which is in the LP build chroots' apt.conf [15:25] ogra: hence my comment [15:25] right [15:26] * cachio lunch [15:29] ondra, is peekfd an app? [15:30] kyrofa yep [15:30] ondra, looks like you're using usr/bin/peekfd as an app, but for whatever reason on arm64 it doesn't exist (not that the traceback is turned into a nicer error on edge) [15:30] kyrofa unless it exist only on armhf and x86 and not on arm64 [15:30] s/not/note/ [15:31] Yeah not sure why, but that's the issue [15:32] kyrofa can one define app per arch in this case? [15:35] ondra, I'm afraid not [15:35] kyrofa damn, so need to remove it from all, or bug against package I guess [15:41] ondra, or add a wrapper that can handle it not being there and error out [15:41] But yeah, I'd look into why it's not there [15:43] kyrofa unrelated question, I have project which has two flavours. Ideally I'd like to build it from same branch, but that means two different snapcraft.yaml files, is there easy way to handle this? [15:46] ondra, snapcraft doesn't have a way to consume two snapcraft.yamls, if that's what you're asking. Launchpad doesn't support it, either [15:47] kyrofa yep, something along those lines [15:55] sergiusens: hi! what are the implications of https://bugs.launchpad.net/snapcraft/+bug/1794805 for the snapcraft parts service? https://parts.snapcraft.io/v1/parts.yaml [15:56] Bug #1794805: Remove wiki parts <18.10-build-vm> [15:56] hehe was just about ask my own question :) [15:59] sergiusens: with the remote parts wiki going, will there be some other method of re-using parts definitions across snaps? and what timescales are we looking at for this being unavailable? [15:59] PR core18#80 opened: static: show some progress during firstboot [16:01] roadmr: should keep on working, you use the deb, correct? [16:01] joc: https://forum.snapcraft.io/t/proposal-templates/6019 [16:01] joc: if you are using bases, they are gone [16:01] sergiusens: I mean for the service itself - will it still be used or do we need to sunset it? [16:02] sergiusens: (but if it's expected to keep working for people using the .deb or something else, not a problem, it can stay up as long as needed) [16:02] roadmr: when no one else builds with no base defined is the time we can put it to sleep [16:02] sergiusens: gotcha, that's exactly what I wanted to know. Thanks! [16:03] (sounds like that might be a long time in coming, but that's ok - parts service is quite lightweight, it can stay there indefinitely) [16:04] sergiusens: by "using bases" do you mean having e.g. "base: core18" in my snapcraft.yaml? [16:04] joc: yes [16:04] oof [16:05] Chipaca: so I would like to have a way to make "progress.Spin()" show stuff even when `snap watch` is not run from a terminal. the easiest way seems to be to add Spin() to quiteProgress but I wonder if that is the right option. maybe an option to waitMixin? [16:05] Chipaca: wdyt? [16:05] PR snapcraft#2329 closed: pluginhandler: remove legacy plugin loading without project [16:05] mvo: 1 sec [16:06] Chipaca: no rush :) [16:06] mvo: I like it (in fact I thought it did that already) [16:06] mvo: maybe only show the message if it changes? [16:06] PR core18#80 closed: static: show some progress during firstboot [16:06] Chipaca: aha, ok - so far it is doing a print on Notify() but not on Spin(msg) [16:06] not sure how often we're calling Spin with the same message [16:06] Chipaca: +1 [16:06] mvo: yep, just saw that [16:06] Chipaca: awesome, I will make it happen (and +1 on checking if the message changes) [16:07] joc: the deb will not break, it is essentially frozen; which means it will get no new features either [16:07] mvo: OTOH, if this is for running it on /dev/console, is that not a tty? (or are we checking stdin instead of stdout?) [16:07] Chipaca: we check stdin [16:07] mvo: isn't that a bit silly? [16:07] Chipaca: of course we could simply check stdout [16:07] Chipaca: I guess :) [16:08] of course by now there are people depending on us checking stdin [16:08] but we could check both :) === pstolowski is now known as pstolowski|afk [16:08] bah, dunno [16:08] wtyt? [16:08] we could also switch to checking stdin, and warn people via the forum [16:08] Chipaca: one slightly complication is that my code does "snap watch --last=seed | tee -a /dev/console" [16:08] "this was silly, we fixed it, sorry if we broke you but surely you agree it's less silly now" [16:08] mvo: boo :-) [16:08] er [16:08] Chipaca: because we still want these messages in journalctl -u [16:09] mvo: so why not 'snap watch --last=seed < /dev/console | tee -a /dev/console? [16:09] Chipaca: aha, nice [16:09] s/\?/'?/ [16:09] Chipaca: yeah, that should work, let me quickly test [16:09] mvo: also, I'd recommend writing it '--last=seed?' [16:10] unless you know for sure there is a seed change already [16:10] Chipaca: yeah, I totally know [16:10] k [16:10] Chipaca: but good advice, thanks [16:11] ogra: does it honor the slot side of the contract for udisks2? in other words, does it ship udisks2 such that other snaps can connect to it and use udisks2? [16:11] * zyga resumes work on user-mounts [16:12] hey jdstrand, how are you? [16:12] jdstrand, well, it runs a daemon that spawns udisksd when a USB key is plugged in ... [16:12] zyga: hey, pretty good. very busy :) how are you? [16:13] jdstrand: had an interrupt but made a lot of progress for user mounts today [16:13] jdstrand: expect some patches relatively quickly :) [16:14] jdstrand, not sure what else the udisks2 "contract" requires ... the daemon-script is rather specifc to import a neplan yaml file if it exists ... and since this is for embedded systems it a) has an install hook check that prevents it from being installed on non-core and b) does not run udisksd permanently [16:15] ogra: if you slots udisks2, then your snap is expected to provide the udisks2 service [16:16] ogra: why are you slotting udisks2? [16:16] jdstrand, well, how else would i get mounting to work from a snap ? [16:17] ogra: I don't know what your snap does. have it plugs udisks2 and then talk to udisks2 to do that for you? [16:17] i'd just use a udev monitor script and call mount driectly, but there are no interfaces offering that [16:17] PR core18#81 opened: static: tweak run-snapd-from-snap to avoid having to change `snap watch` [16:17]