| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#2326 closed: plugins: remove implicit source <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2326> | 03:37 |
|---|---|---|
| === cpaelzer_ is now known as cpaelzer | ||
| mborzecki | morning | 05:09 |
| mup | PR core18#74 opened: hooks: use core18.start-snapd.service for ordering <Created by mvo5> <https://github.com/snapcore/core18/pull/74> | 05:29 |
| mup | PR core18#74 closed: hooks: use core18.start-snapd.service for ordering <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/74> | 05:45 |
| mup | PR snapd#5910 closed: snapshotstate: restore to current revision <Snapshots πΈσ > <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5910> | 05:48 |
| mup | PR core18#75 opened: static: show snapd firstboot messages on /dev/console <Created by mvo5> <https://github.com/snapcore/core18/pull/75> | 05:54 |
| mup | PR core18#75 closed: static: show snapd firstboot messages on /dev/console <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/75> | 05:56 |
| zyga | o/ | 06:23 |
| mborzecki | zyga: hey | 06:25 |
| mvo | hey zyga and mborzecki | 06:28 |
| mup | PR core18#76 opened: static: make run-snapd-from-snap wait for seeding <Created by mvo5> <https://github.com/snapcore/core18/pull/76> | 06:29 |
| zyga | :-) | 06:29 |
| mup | PR core18#76 closed: static: make run-snapd-from-snap wait for seeding <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/76> | 06:46 |
| mvo | uh, on the pi I get "backend.go:319: cannot create host snap-confine apparmor configuration: cannot s | 07:05 |
| mvo | ynchronize snap-confine apparmor profile: open /var/lib/snapd/apparmor/profiles/ | 07:05 |
| mvo | snap-confine.snapd.1122.m8GcXdqQ5cDR~: no such file or directory" quite often | 07:05 |
| mvo | at firstboot seeding | 07:05 |
| === pstolowski|afk is now known as pstolowski | ||
| * mvo wonders what is going on there | 07:05 | |
| pstolowski | mornings | 07:05 |
| mvo | hey pstolowski | 07:05 |
| zyga | mvo: didn't we fix that? | 07:15 |
| zyga | mvo: is the pi using anything modern or is this the release image? | 07:15 |
| zyga | (release as in 16.04) | 07:15 |
| mvo | zyga: let me check, it should use master | 07:16 |
| mvo | zyga: rev is 2.35.4+git1480.gdb577fc | 07:17 |
| mvo | from 7h ago | 07:17 |
| zyga | hmm, then it looks real | 07:18 |
| mvo | I'm debugging a different issue right now, we look after this but it looks scary as it breaks first boot seeding | 07:19 |
| zyga | k | 07:19 |
| mvo | its a race most likely | 07:20 |
| mvo | does not happen all the time | 07:20 |
| mvo | and I think not at all on quick HW like amd64 | 07:20 |
| mvo | plus it is (currently) mask by this other bug that console-conf runs too early | 07:20 |
| zyga | 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 |
| mup | PR #5917: cmd/snap: attempt to start the document portal if running with a sess⦠<Created by zyga> <https://github.com/snapcore/snapd/pull/5917> | 07:31 |
| mup | PR snapd#5927 closed: cmd/snap-update-ns: remove empty placeholders used for mounting <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5927> | 07:31 |
| mvo | zyga: I think its something we want | 07:32 |
| zyga | k, just land it then | 07:32 |
| zyga | note, the master version landed already | 07:32 |
| mvo | zyga: I will branch again once 2.35.4 is in candidate | 07:32 |
| mvo | zyga: aha, ok | 07:32 |
| zyga | this is just a back port | 07:32 |
| mvo | ok | 07:32 |
| pedronis | 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:35 |
| mvo | pedronis: ok, thank you | 07:36 |
| mvo | 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 |
| zyga | let me know what you find | 07:48 |
| mup | PR snapd#5951 opened: spread-shellcheck: fix interleaved error messages, tweaks <Simple π> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5951> | 07:55 |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | anyone wishing to review #5947 and #5948 ? feel free to do one or both | 08:12 |
| mup | PR #5947: many: cleanup remaining parallel installs TODOs <Parallel installs β> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5947> | 08:12 |
| mup | PR #5948: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names <Parallel installs β> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5948> | 08:12 |
| mborzecki | pstolowski: any of your hotplug PRs need attention? | 08:12 |
| mborzecki | pstolowski: i have #5860 open | 08:12 |
| mup | PR #5860: interfaces/hotplug: helpers and struct updates <Hotplug π> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5860> | 08:12 |
| zyga | mborzecki: I can do after noon | 08:15 |
| pstolowski | 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 |
| zyga | still fighting that test | 08:15 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR core18#77 opened: hooks: ensure serial-console-conf also runs after core18.start-snapd.service <Created by mvo5> <https://github.com/snapcore/core18/pull/77> | 08:28 |
| niemeyer | 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:42 |
| pstolowski | niemeyer: sure, thanks for the device key review, addressed your feedback and trying to land (travis is not cooperating, again) | 08:43 |
| mup | PR core18#77 closed: hooks: ensure serial-console-conf also runs after core18.start-snapd.service <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/77> | 08:50 |
| mup | PR core-build#36 closed: initramfs: fix shellchecks on bionic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/36> | 09:07 |
| * zyga -> small break | 09:21 | |
| * zyga is about to throw the towel on the overlayfs test | 09:25 | |
| ogra | 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 |
| cjwatson | ogra: no | 09:29 |
| ogra | weird | 09:29 |
| cjwatson | ogra: "failed to release" is from the store, not from the builders, anyway | 09:29 |
| ogra | yeah, but i dont even see the re-built snaps in the store ... like they never arrived | 09:30 |
| cjwatson | so this is either due to snapcraft or due to the review tools, probably; unlikely to be the builders | 09:30 |
| cjwatson | ogra: it's not fair to ask me to speculate on this without giving me a link | 09:31 |
| ogra | https://launchpad.net/~build.snapcraft.io/+snap/3fc16b55a813a672666c6ff13690918e-xenial/+build/323860 | 09:32 |
| ogra | aha ! | 09:32 |
| ogra | Temporary failure in name resolution | 09:32 |
| ogra | looks liek some internal DC thing | 09:32 |
| ogra | (sorry, i only looked at build.s.io ... could have checked LP directly) | 09:33 |
| cjwatson | That's the ENOMEM issue on ackee | 09:33 |
| cjwatson | It is SUPER WEIRD | 09:33 |
| ogra | 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:34 |
| cjwatson | 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 |
| cjwatson | This results in a bunch of things failing, including DNS resolution | 09:35 |
| ogra | weird indeed ... | 09:35 |
| ogra | yeah | 09:35 |
| cjwatson | Hmm, one of the workers is in that state right now | 09:36 |
| ogra | it might be a good idea to forward the error message to the build.snapcraft.io log or some such | 09:36 |
| ogra | 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:37 |
| cjwatson | The BSI log is just the build log | 09:39 |
| cjwatson | Can't do that | 09:39 |
| cjwatson | I have a spec for improvements to LP's store upload process | 09:40 |
| cjwatson | It's probably not next on my list but maybe the one after that | 09:40 |
| ogra | well, this is mostly about the UI of build.s.io ... not even sure thats in your area of things :) | 09:40 |
| ogra | 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:42 |
| cjwatson | Evan says we're not allowed :P | 09:50 |
| ogra | haha | 09:50 |
| cjwatson | (to have a direct link to LP) | 09:50 |
| ogra | yeah ... i got that | 09:50 |
| mup | PR core18#78 opened: static: show seed progress on console on firstboot <Created by mvo5> <https://github.com/snapcore/core18/pull/78> | 09:51 |
| mup | PR core18#78 closed: static: show seed progress on console on firstboot <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/78> | 09:55 |
| cjwatson | 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 |
| ogra | ah | 09:56 |
| mup | PR snapd#5952 opened: tests/ifacestate: moved asserts-related mocking into helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5952> | 10:05 |
| mborzecki | why are timers/sockets enabled in StartServices() rather than AddSnapServices() ? | 10:07 |
| pstolowski | pedronis: can you take a look ^ ? | 10:07 |
| pedronis | pstolowski: yes, after lunch | 10:07 |
| cjwatson | 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:09 |
| ogra | cjwatson, well, i just tried retry and got a permission error | 10:10 |
| ogra | seemingly i'm not allowed to retry | 10:10 |
| cjwatson | A permission error saying what precisely? | 10:11 |
| cjwatson | 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 |
| ogra | right | 10:11 |
| cjwatson | I've hit Retry but it probably won't work | 10:11 |
| ogra | well, that particular snap is less important anyway ... and i'll trigger rebuilds for the others | 10:12 |
| cjwatson | Yeah, that hit the silly duplicate-snap-content error from the store | 10:14 |
| cjwatson | Which is one of the things my spec covers | 10:14 |
| mup | PR core18#79 opened: snap-snapd-from-snap: remove all debug output <Created by mvo5> <https://github.com/snapcore/core18/pull/79> | 10:37 |
| Chipaca | if/when you spot a unit test on travis taking ages talking to the apt mirror, please let me know | 10:57 |
| Chipaca | I want those logs | 10:58 |
| Chipaca | e.g. https://travis-ci.org/snapcore/snapd/jobs/439058232 | 10:59 |
| mup | PR snapd#5953 opened: apparmor: create SnapAppArmorDir in setupSnapConfineReexec <Created by mvo5> <https://github.com/snapcore/snapd/pull/5953> | 11:09 |
| ogra | 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) | 11:11 |
| === pstolowski is now known as pstolowski|lunch | ||
| ogra | 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 |
| ogra | *arm | 11:15 |
| cjwatson | ogra: see #is-outage please | 11:16 |
| cjwatson | work in progress | 11:16 |
| ogra | ok | 11:16 |
| mborzecki | https://paste.ubuntu.com/p/gTn99BMxhg/ snap services with sockets and timers | 11:25 |
| niemeyer | pstolowski|lunch: Nitpick (and optional, obviously): | 11:36 |
| niemeyer | // attribute name and value are separated by null character | 11:36 |
| niemeyer | That's exactly what the code below it says | 11:37 |
| niemeyer | more clearly | 11:37 |
| dot-tobias | 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:38 |
| niemeyer | pstolowski|lunch: Ah, there's something else.. will comment on the PR | 11:39 |
| zyga | 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:40 |
| dot-tobias | zyga: Will cook up something, thanks | 11:41 |
| cachio | pstolowski|lunch, hey, already working in nested suite | 11:56 |
| mborzecki | 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:04 |
| mborzecki | 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 |
| mup | PR spread-images#17: tasks/google/update-arch-linux: tweak Arch image update <Created by bboozzoo> <https://github.com/snapcore/spread-images/pull/17> | 12:06 |
| cachio | mborzecki, nice, checking | 12:09 |
| mup | PR snapcraft#2323 closed: go plugin: support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2323> | 12:20 |
| niemeyer | mborzecki: Thanks! | 12:21 |
| === pstolowski|lunch is now known as pstolowski | ||
| Chipaca | oh, what a surprise, opensuse failing agian :-(((((( | 12:23 |
| Chipaca | can we add a rule, "to be supported by snapd, your distro's mirror archive must be *this* available"? | 12:24 |
| mup | PR snapcraft#2327 opened: pluginhandler: remove prepare, build and install scriptlets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2327> | 12:26 |
| cachio | mborzecki, works!! | 12:29 |
| niemeyer | mborzecki: Responded | 12:34 |
| mup | PR snapcraft#2328 opened: godeps plugin: support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2328> | 12:38 |
| rbasak | mvo_: I put a reproducer in bug 1796017 | 12:38 |
| mup | Bug #1796017: git ubuntu build-source fails with missing libreadline.so.6 <usd-importer:In Progress by racb> <https://launchpad.net/bugs/1796017> | 12:39 |
| rbasak | I'm a bit baffled as to why this doesn't work. Is there anything else going on eg. seccomp? | 12:39 |
| rbasak | Or other necessary environment changes that I missed? | 12:39 |
| cachio | mborzecki, | 12:55 |
| mup | PR core18#79 closed: snap-snapd-from-snap: remove all debug output <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/79> | 12:58 |
| ogra | argh | 13:10 |
| ogra | sergiusens, !!! | 13:10 |
| ogra | Snapping 'pi-kiosk' | | 13:10 |
| ogra | Snapped pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap | 13:10 |
| ogra | Stopping local:snapcraft-sadly-choice-amoeba | 13:10 |
| ogra | Retrieved "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap" | 13:10 |
| ogra | sergiusens, thats a snapcraft cleanbuild of a snap using build-on/run-on ... | 13:11 |
| ijohnson | ogra: stop naming your snap "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')])" | 13:11 |
| sergiusens | ogra: we'll get kyrofa to take a look when he gets in | 13:11 |
| ogra | i'd kind of expect the resulting snap file not to contain python code in its name | 13:11 |
| sergiusens | but, cleanbuild is also deprecated to a baseless world | 13:12 |
| ogra | so how do i build my snaps now ? | 13:12 |
| sergiusens | ogra: if you set a base, you get a build vm | 13:15 |
| ogra | sergiusens, so i need to touich all the snaps i have ? | 13:15 |
| ogra | (for re-builds when getting security notifications ??) | 13:15 |
| sergiusens | ogra: no, if you do not change anything, you don't need to touch anything | 13:15 |
| ogra | 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 |
| ogra | checking for arm-linux-gcc... /usr/bin/arm-linux-gnueabihf-gcc | 13:17 |
| ogra | checking whether the C compiler works... no | 13:17 |
| ogra | configure: error: in `/build/pi-kiosk/parts/psplash/build': | 13:17 |
| ogra | configure: error: C compiler cannot create executables | 13:17 |
| mup | PR snapcraft#2329 opened: pluginhandler: remove legacy plugin loading without project <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2329> | 13:17 |
| ogra | 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 |
| cjwatson | ogra: I have no idea, sorry. Try catting config.log after the failure to get more details | 13:18 |
| ogra | hmm., k | 13:19 |
| mborzecki | Chipaca: can you take a quick look at https://github.com/snapcore/snapd/pull/5951 ? | 13:30 |
| mup | PR #5951: spread-shellcheck: fix interleaved error messages, tweaks <Simple π> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5951> | 13:30 |
| Chipaca | mborzecki: what do you think about my 'activator' comment? | 13:37 |
| mup | PR snapcraft#2330 opened: pluginhandler: remove big solidus workaround <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2330> | 13:38 |
| * Chipaca ~> school run* | 13:44 | |
| Chipaca | * wee (maybe) | 13:44 |
| ackk | hi, is there a way to specify the container image/release when running "snapcraft cleanbuild"? | 13:51 |
| mup | PR snapd#5759 closed: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug π> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5759> | 13:52 |
| === chihchun is now known as chihchun_afk | ||
| ogra | 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 |
| ogra | at least thats my guess for: | 14:01 |
| ogra | configure:2973: /usr/bin/arm-linux-gnueabihf-gcc conftest.c >&5 | 14:01 |
| ogra | collect2: error: ld returned 1 exit status | 14:01 |
| ogra | grrr ! IRC | 14:01 |
| ogra | configure:2973: /usr/bin/arm-linux-gnueabihf-gcc conftest.c >&5 | 14:02 |
| ogra | /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find crt1.o: No such file or directory | 14:02 |
| ogra | /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find crti.o: No such file or directory | 14:02 |
| ogra | collect2: error: ld returned 1 exit status | 14:02 |
| ackk | sergiusens, hi, maybe you have insights on my question above? | 14:02 |
| ogra | aha ! | 14:04 |
| ogra | libc6-dev-armhf-cross iss a recommends ... ok | 14:04 |
| ogra | *is | 14:04 |
| ogra | 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:05 |
| niemeyer | Hey folks.. I'm back | 14:15 |
| ogra | whee ! a properly cross built gadget snap on build.snapcraft.io !!!! | 14:26 |
| ogra | https://launchpad.net/~build.snapcraft.io/+snap/ae16fdc83ee020a5817d7f0243e105b5-xenial/+build/349077 | 14:26 |
| ogra | very nice ! | 14:27 |
| sergiusens | ackk: no, there is not; we are moving to a new model which will be trickled by the use of bases. | 14:44 |
| mup | PR snapd#5954 opened: [wayland] explicitly permit file locking for wayland lock <Created by gerboland> <https://github.com/snapcore/snapd/pull/5954> | 14:45 |
| ogra | 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:00 |
| ogra | jdstrand, source is at: https://github.com/ogra1/dashkiosk-client-image-config | 15:02 |
| ackk | sergiusens, I see, so there's currently no way of cleanbuilding a core18 snap | 15:03 |
| ondra | kyrofa ping | 15:18 |
| sergiusens | ackk: no, for that you probably want to be on edge and set SNAPCRAFT_BUILD_ENVIRONMENT=multipass (and set base: core18) | 15:19 |
| kyrofa | ondra, hey there | 15:19 |
| ackk | sergiusens, ah I see. I do use edge and core18 base | 15:20 |
| ackk | sergiusens, so this will only be available on multipass? | 15:20 |
| sergiusens | ackk: just missing the env then, but edge should switch to creating the VM by default real soon | 15:21 |
| ackk | sergiusens, thanks | 15:21 |
| sergiusens | ackk: for the time being yes, it what was agreed to during the roadmap sprint. Next cycle we will bring back lxd | 15:21 |
| ondra | kyrofa hey | 15:22 |
| ondra | kyrofa can you please check https://code.launchpad.net/~ondrak/+snap/toolbox | 15:22 |
| ondra | kyrofa for whatever reason on arm64 it breaks when priming | 15:22 |
| cjwatson | ogra: mm, may be the sort of thing that gets ironed out by moving to a common build container/VM/whatever | 15:23 |
| ogra | cjwatson, well, fallout of --no-install-recommends i think | 15:24 |
| ogra | apparently the cleanbuild lxd container installs recommends by default | 15:25 |
| cjwatson | ogra: which is in the LP build chroots' apt.conf | 15:25 |
| cjwatson | ogra: hence my comment | 15:25 |
| ogra | right | 15:25 |
| * cachio lunch | 15:26 | |
| kyrofa | ondra, is peekfd an app? | 15:29 |
| ondra | kyrofa yep | 15:30 |
| kyrofa | 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 |
| ondra | kyrofa unless it exist only on armhf and x86 and not on arm64 | 15:30 |
| kyrofa | s/not/note/ | 15:30 |
| kyrofa | Yeah not sure why, but that's the issue | 15:31 |
| ondra | kyrofa can one define app per arch in this case? | 15:32 |
| kyrofa | ondra, I'm afraid not | 15:35 |
| ondra | kyrofa damn, so need to remove it from all, or bug against package I guess | 15:35 |
| kyrofa | ondra, or add a wrapper that can handle it not being there and error out | 15:41 |
| kyrofa | But yeah, I'd look into why it's not there | 15:41 |
| ondra | 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:43 |
| kyrofa | 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:46 |
| ondra | kyrofa yep, something along those lines | 15:47 |
| roadmr | 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:55 |
| mup | Bug #1794805: Remove wiki parts <18.10-build-vm> <Snapcraft:Fix Committed by sergiusens> <https://launchpad.net/bugs/1794805> | 15:56 |
| joc | hehe was just about ask my own question :) | 15:56 |
| joc | 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 |
| mup | PR core18#80 opened: static: show some progress during firstboot <Created by mvo5> <https://github.com/snapcore/core18/pull/80> | 15:59 |
| sergiusens | roadmr: should keep on working, you use the deb, correct? | 16:01 |
| sergiusens | joc: https://forum.snapcraft.io/t/proposal-templates/6019 | 16:01 |
| sergiusens | joc: if you are using bases, they are gone | 16:01 |
| roadmr | sergiusens: I mean for the service itself - will it still be used or do we need to sunset it? | 16:01 |
| roadmr | 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 |
| sergiusens | roadmr: when no one else builds with no base defined is the time we can put it to sleep | 16:02 |
| roadmr | sergiusens: gotcha, that's exactly what I wanted to know. Thanks! | 16:02 |
| roadmr | (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:03 |
| joc | sergiusens: by "using bases" do you mean having e.g. "base: core18" in my snapcraft.yaml? | 16:04 |
| sergiusens | joc: yes | 16:04 |
| joc | oof | 16:04 |
| mvo | 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 |
| mvo | Chipaca: wdyt? | 16:05 |
| mup | PR snapcraft#2329 closed: pluginhandler: remove legacy plugin loading without project <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2329> | 16:05 |
| Chipaca | mvo: 1 sec | 16:05 |
| mvo | Chipaca: no rush :) | 16:06 |
| Chipaca | mvo: I like it (in fact I thought it did that already) | 16:06 |
| Chipaca | mvo: maybe only show the message if it changes? | 16:06 |
| mup | PR core18#80 closed: static: show some progress during firstboot <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/80> | 16:06 |
| mvo | Chipaca: aha, ok - so far it is doing a print on Notify() but not on Spin(msg) | 16:06 |
| Chipaca | not sure how often we're calling Spin with the same message | 16:06 |
| mvo | Chipaca: +1 | 16:06 |
| Chipaca | mvo: yep, just saw that | 16:06 |
| mvo | Chipaca: awesome, I will make it happen (and +1 on checking if the message changes) | 16:06 |
| sergiusens | joc: the deb will not break, it is essentially frozen; which means it will get no new features either | 16:07 |
| Chipaca | 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 |
| mvo | Chipaca: we check stdin | 16:07 |
| Chipaca | mvo: isn't that a bit silly? | 16:07 |
| mvo | Chipaca: of course we could simply check stdout | 16:07 |
| mvo | Chipaca: I guess :) | 16:07 |
| Chipaca | of course by now there are people depending on us checking stdin | 16:08 |
| Chipaca | but we could check both :) | 16:08 |
| === pstolowski is now known as pstolowski|afk | ||
| Chipaca | bah, dunno | 16:08 |
| Chipaca | wtyt? | 16:08 |
| Chipaca | we could also switch to checking stdin, and warn people via the forum | 16:08 |
| mvo | Chipaca: one slightly complication is that my code does "snap watch --last=seed | tee -a /dev/console" | 16:08 |
| Chipaca | "this was silly, we fixed it, sorry if we broke you but surely you agree it's less silly now" | 16:08 |
| Chipaca | mvo: boo :-) | 16:08 |
| Chipaca | er | 16:08 |
| mvo | Chipaca: because we still want these messages in journalctl -u | 16:08 |
| Chipaca | mvo: so why not 'snap watch --last=seed < /dev/console | tee -a /dev/console? | 16:09 |
| mvo | Chipaca: aha, nice | 16:09 |
| Chipaca | s/\?/'?/ | 16:09 |
| mvo | Chipaca: yeah, that should work, let me quickly test | 16:09 |
| Chipaca | mvo: also, I'd recommend writing it '--last=seed?' | 16:09 |
| Chipaca | unless you know for sure there is a seed change already | 16:10 |
| mvo | Chipaca: yeah, I totally know | 16:10 |
| Chipaca | k | 16:10 |
| mvo | Chipaca: but good advice, thanks | 16:10 |
| jdstrand | 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:11 | |
| zyga | hey jdstrand, how are you? | 16:12 |
| ogra | jdstrand, well, it runs a daemon that spawns udisksd when a USB key is plugged in ... | 16:12 |
| jdstrand | zyga: hey, pretty good. very busy :) how are you? | 16:12 |
| zyga | jdstrand: had an interrupt but made a lot of progress for user mounts today | 16:13 |
| zyga | jdstrand: expect some patches relatively quickly :) | 16:13 |
| ogra | 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:14 |
| jdstrand | ogra: if you slots udisks2, then your snap is expected to provide the udisks2 service | 16:15 |
| jdstrand | ogra: why are you slotting udisks2? | 16:16 |
| ogra | jdstrand, well, how else would i get mounting to work from a snap ? | 16:16 |
| jdstrand | 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 |
| ogra | i'd just use a udev monitor script and call mount driectly, but there are no interfaces offering that | 16:17 |
| mup | PR core18#81 opened: static: tweak run-snapd-from-snap to avoid having to change `snap watch` <Created by mvo5> <https://github.com/snapcore/core18/pull/81> | 16:17 |
| jdstrand | ogra: this sounds like a conversation for the forum. I suggest stating what it is your snap requires, and how you'd like to get there | 16:17 |
| ogra | jdstrand, https://github.com/ogra1/dashkiosk-client-image-config/blob/master/netplan-import ... thats the daemon script ... it watched udev for udb block device plug events ... if one is there, it mounts the usb block device and looks for a netplan config | 16:18 |
| ogra | *watches | 16:18 |
| ogra | s/udb/usb/ | 16:18 |
| mup | PR core18#81 closed: static: tweak run-snapd-from-snap to avoid having to change `snap watch` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/81> | 16:19 |
| ogra | jdstrand, well, i need the snap for a demo at IoT worldcongress next week, i'll just rip out that feature, i doubt i'll have the time to re-implement it differently in time | 16:19 |
| ogra | effectively i just need an interface that allows me to run mount/umount and we dont have that | 16:20 |
| jdstrand | ogra: you are calling udisckstl, why not plugs: [ udisks2 ] and have the udisks2 snap installed? | 16:20 |
| jdstrand | then just talk to that other snap | 16:21 |
| ogra | do we have that for all arches ? | 16:21 |
| * ogra checks | 16:21 | |
| ogra | hmm, k | 16:21 |
| jdstrand | ogra: I see an armhf in edge | 16:21 |
| kyrofa | Hey ogra, any ideas on this? https://askubuntu.com/questions/1082277/socketcan-device-on-ubuntu-core | 16:21 |
| jdstrand | it's old, but it is there | 16:21 |
| ogra | edge ... hmm | 16:21 |
| zyga | roadmr: hey | 16:21 |
| roadmr | hehey zyga ! how goes it! | 16:22 |
| zyga | I need a hand in debugging a store side bug (presumably) | 16:22 |
| zyga | remember that snap? | 16:22 |
| zyga | I tried it again | 16:22 |
| ogra | ah, also in stable | 16:22 |
| jdstrand | ogra: looks like morphis did it. that would be the ce team now I guess | 16:22 |
| zyga | first time I kept the hack with chmod | 16:22 |
| zyga | it passed | 16:22 |
| zyga | second time it did not | 16:22 |
| zyga | I think something else is wonky | 16:22 |
| jdstrand | yes, and stable | 16:22 |
| zyga | I can show you the error I'm getting, it's very terse though | 16:22 |
| ogra | jdstrand, thanks, i'll try to use that one ... effectively simply having snapd allow you to import a netplan config (like we allow system-user assertions) would be the proper solution after all | 16:23 |
| roadmr | zyga: sure, error would be nice | 16:23 |
| zyga | roadmr: let me re-make it, I also had issues with snapcraft in that run | 16:23 |
| ogra | jdstrand, trying to create appliance images that do not force you to attach a serial cable to configure wlan ... (and that already have the screen occupied, so you cant use console-conf there) | 16:24 |
| ogra | jdstrand, if i reject the held snap, i should be capable to upoad again without them getting stuck in the sotre review ? | 16:24 |
| ogra | *store | 16:25 |
| ogra | kyrofa, i think thats actually one for awe, i dont have moch experience with CAN bus stuff (but he has) | 16:25 |
| jdstrand | ogra: yes | 16:26 |
| ogra | kyrofa, but it looks like we are lacking an interface to even use them on core | 16:26 |
| ogra | jdstrand, my prob with adding more snaps to the image is that snapd takes 3-5 min per snap on first boot btw ... i'm already at a 20min first boot with this image | 16:27 |
| ogra | but i guess i'll ave to bit that bullet for now | 16:28 |
| ogra | *bite | 16:28 |
| zyga | roadmr: got them | 16:28 |
| zyga | The store was unable to accept this snap. | 16:28 |
| zyga | - __all__: The upload does not appear to be a valid package. | 16:28 |
| roadmr | \o/ | 16:28 |
| zyga | that's all I got | 16:28 |
| roadmr | yeay | 16:28 |
| zyga | the package can be installed locally obviously | 16:28 |
| zyga | note: I did the upload as root | 16:29 |
| zyga | as a user snapcraft crashes | 16:29 |
| zyga | kyrofa: ^ wanna see? | 16:29 |
| roadmr | zyga: hm, can you either run the review tools on the package locally to see what they say, or shoot me a copy of the built snap? | 16:29 |
| zyga | roadmr: could I just send you the snap please? | 16:30 |
| roadmr | zyga: sure thing | 16:30 |
| kyrofa | zyga, I'm missing context, what are you doing? | 16:32 |
| zyga | kyrofa: I'm using snapcraft push *.snap | 16:32 |
| zyga | and it crashes with ... | 16:32 |
| zyga | https://www.irccloud.com/pastebin/164aZPmQ/ | 16:33 |
| ogra | kyrofa, i forwarded the question to tony now ... | 16:33 |
| ogra | kyrofa, did you see my issue with the architectures build-on/run-on thing under cleanbuild above ? | 16:33 |
| ogra | kyrofa, : | 16:34 |
| ogra | <ogra> Snapping 'pi-kiosk' | | 16:34 |
| ogra | <ogra> Snapped pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap | 16:34 |
| ogra | <ogra> Stopping local:snapcraft-sadly-choice-amoeba | 16:34 |
| ogra | <ogra> Retrieved "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap" | 16:34 |
| ogra | it somehow includes python code snippets in the final snap name | 16:34 |
| roadmr | zyga: hm we may need jdstrand's help on this | 16:38 |
| zyga | oh/ | 16:38 |
| zyga | roadmr: what's the error from the review tools? | 16:39 |
| roadmr | zyga: https://pastebin.canonical.com/p/8Sj2fXx5M4/ | 16:39 |
| zyga | hmm, wasn't this the same error as before? | 16:40 |
| roadmr | zyga: I think that python traceback from the failure to rm is causing the store to barf (because it expects the tools output to be json - even if I say --json it has that Python thing at the end) | 16:40 |
| zyga | those as not writable by owner | 16:40 |
| roadmr | zyga: yes, I fixed that store-side, but IIRC your earlier snap didn't show this output from the tools | 16:40 |
| zyga | ahh | 16:40 |
| zyga | I See | 16:40 |
| roadmr | if the tools can't clean up and barf like this, I can't fix that store-side directly :/ | 16:40 |
| jdstrand | zyga: where is this snap? | 16:41 |
| zyga | jdstrand: sent via wormhole to roadmr | 16:41 |
| roadmr | jdstrand: the top-level dir ias this mode drwx------ | 16:41 |
| zyga | it's just a fedora base I was sending before | 16:41 |
| jdstrand | I'd need the snap if I'm going to look at fixing the review tools | 16:42 |
| zyga | jdstrand: I can wormhole it to you as well if you don't mind | 16:42 |
| jdstrand | that's fine | 16:42 |
| roadmr | it's not huge, only 18 MB | 16:42 |
| zyga | sent | 16:43 |
| jdstrand | ok, I'll take a look at it | 16:43 |
| roadmr | jdstrand: I suspect the fix will be similar to what I did store-side https://bazaar.launchpad.net/~ubuntuone-pqm-team/software-center-agent/trunk/revision/5055 | 16:43 |
| jdstrand | zyga: while I have you. can I get your opinion on something | 16:43 |
| jdstrand | roadmr: ack, thanks | 16:43 |
| jdstrand | zyga: so, I need to add 'unsafe' to the default template | 16:44 |
| zyga | sure, I'm all ears | 16:44 |
| jdstrand | zyga: but it fails spread cause apparently opensuse 42.3 has a too old apparmor_parser | 16:44 |
| kyrofa | ogra, yuck, that's interesting | 16:44 |
| zyga | right, I remember that branch | 16:44 |
| jdstrand | zyga: that doesn't know what 'unsafe' is | 16:44 |
| roadmr | actually - the review tools' recursive_rm appears to be identical to what we have in the store, so pretty sure my fix will apply :D | 16:44 |
| jdstrand | zyga: so, I think the most correct solution is to use apparmor_parser from the core snap. however, I don't want to do that in this PR because whenever we move to this sort of scenario, it has a long tail of little fixes | 16:45 |
| jdstrand | zyga: we can do that in a future pr | 16:45 |
| zyga | would a parser from core produce binary compatible with the host kernel? | 16:45 |
| jdstrand | zyga: sure, why not? | 16:46 |
| jdstrand | the parser is fully aware of the kernel | 16:46 |
| zyga | that's good | 16:46 |
| jdstrand | using the parser in core would mean we could update apparmor in Ubuntu only to fix parser bugs, enhancements, etc, etc | 16:46 |
| jdstrand | kinda like how we pulled back xenial's apparmor to trusty | 16:47 |
| jdstrand | we could do that 'forever' | 16:47 |
| zyga | ok | 16:47 |
| jdstrand | and not worry about other distro's apparmor | 16:47 |
| jdstrand | anyhoo | 16:47 |
| zyga | so that's the preferred solution | 16:47 |
| jdstrand | that is the ideal | 16:47 |
| zyga | and in the meantime? | 16:47 |
| jdstrand | but, again, I don't want to do that, so we have some choices | 16:47 |
| jdstrand | I explored the idea of having a parser features list and populating it, just like we do with the features dir | 16:48 |
| zyga | oh, that's interesting | 16:48 |
| jdstrand | it works, but there are a number of test case mockings which got me wondering if there is another way | 16:48 |
| jdstrand | (especially since if we go the apparmor_parser from core route, we just rip out this code) | 16:49 |
| zyga | btw, what is the unsafe vs safe transition about? | 16:49 |
| jdstrand | secure_exec | 16:49 |
| jdstrand | ie, stripping LD_LIBRARY_PATH | 16:49 |
| jdstrand | it is explained in the pr | 16:49 |
| jdstrand | so the other option is, if we are PartialAppArmor already, we know we don't have a new enough parser, so don't use unsafe if PartialAppArmor | 16:50 |
| zyga | ah | 16:50 |
| zyga | ok | 16:50 |
| jdstrand | this is cheap, but mildly inaccurate, but since the code is going to be ripped out soon, who cares? | 16:50 |
| zyga | that would partially regress arch and opensuse tumbleweed though | 16:50 |
| jdstrand | so... do you care? | 16:50 |
| jdstrand | :) | 16:50 |
| zyga | ha | 16:50 |
| zyga | so that's the question | 16:50 |
| zyga | I think that's fine if you are really going to do the full deal | 16:51 |
| zyga | as in schedule wise | 16:51 |
| zyga | I'm sure you would | 16:51 |
| jdstrand | zyga: that's the thing, arch and tumbleweed should have a new enough apparmor_parser, so I can special case them or do something with downgradeConfinement, etc so they get unsafe | 16:51 |
| zyga | in that case I think we're good | 16:52 |
| jdstrand | or not, and just say that they don't get unsafe until we use the parser from core | 16:52 |
| jdstrand | well, as it happens, I have a new manager now and slowly coming out from the last couple months | 16:53 |
| jdstrand | I can add moving apparmor_parser from core to the roadmap | 16:53 |
| jdstrand | err | 16:53 |
| jdstrand | moving to apparmor_parser from core to the roadmap | 16:53 |
| zyga | +1 | 16:53 |
| zyga | we should do the same for snap-seccomp | 16:53 |
| jdstrand | I mean, this has a ton of benefits way beyond this | 16:53 |
| zyga | for statx and the lkike | 16:53 |
| zyga | *like | 16:53 |
| jdstrand | yeah | 16:54 |
| zyga | we should also answer the question of reexec=0 distros | 16:54 |
| jdstrand | sure, but to me, we would always use the apparmor from core, regardless of reexec | 16:54 |
| jdstrand | or do you see a problem with that? | 16:54 |
| zyga | technically no | 16:55 |
| zyga | but policy wise it could be borderline iffy | 16:55 |
| jdstrand | who's policy? | 16:55 |
| jdstrand | fedora shouldn't care-- they don't have apparmor | 16:55 |
| zyga | but they have seccomp | 16:56 |
| zyga | I imagine this is the same deal | 16:56 |
| zyga | but anyway, we don't have to discuss this now, I think technically we are in agreement | 16:57 |
| zyga | and we can keep the code that uses distribution tools | 16:57 |
| jdstrand | zyga: well, if we are planning on keeping the code, probably need parserFeatures | 16:58 |
| jdstrand | we don't necessarily need to downgrade to PartialConfinement though | 16:58 |
| jdstrand | that's a 3rd option. I check to see if the parser supports a syntax we know older ones don't have, and then populate something in snapd (other than PartialAppArmor) that we can query when using that one rule | 16:59 |
| jdstrand | sorta sounds like based on this conversation that is possibly the best path forward | 17:00 |
| zyga | jdstrand: we can probably use system key for that | 17:00 |
| zyga | or a combination of system key and locally held state in AppArmor backend | 17:00 |
| jdstrand | right, I was initially thinking of that | 17:00 |
| jdstrand | ok, I'll just go that route for now | 17:00 |
| zyga | ok | 17:01 |
| jdstrand | zyga: thanks | 17:01 |
| zyga | my pleasure :) | 17:02 |
| ogra | jdstrand, fyi, works very nicely with the udidks2 snap, thanks for the hint (if only the firstboot wouldnt be 5min longer now) | 17:08 |
| jdstrand | ogra: nice! :) | 17:10 |
| jdstrand | ogra: I wonder why it takes so long... that seems like a bug? | 17:11 |
| ogra | jdstrand, yeah, its a known go bug with checksumming sha256 stuff on arm ... snapd uses that when installing a snap for the first time ... so each snap delays the firstboot | 17:12 |
| ogra | jdstrand, ijohnson has sent a fix upstream some months ago but that has still not been included | 17:13 |
| ogra | (go upstream) | 17:13 |
| ogra | picking sha256 for snaps was a bit overzealous ;) | 17:13 |
| ijohnson | it's actually sha3 hashing | 17:14 |
| ogra | ah, i thought it was 256 | 17:14 |
| ogra | some sha :P | 17:14 |
| ijohnson | well it's sha3 with length 256 | 17:14 |
| ogra | sha-la-la :) | 17:14 |
| zyga | ha | 17:14 |
| zyga | I was _just_ typing that | 17:14 |
| ijohnson | (although I thought that snapd used 384, but my fix fixes all sha3) | 17:14 |
| ogra | (sorry, hard day ... tired and silly) | 17:14 |
| ogra | zyga, welcome to my level of sillyness then :) | 17:15 |
| zyga | ogra: I'm always silly | 17:15 |
| zyga | I feel quite at home | 17:15 |
| ogra | heh | 17:15 |
| ogra | mvo, i saw yu landed the password expiry stuff ... any chance that goes into some non-edge channel before the weekend ? | 17:19 |
| ogra | (likely not, but i thought i'd ask at least) | 17:19 |
| mvo | ogra: there is a good chance actually - to hit beta, once the current beta moves to candidate I will do a new 2.36~pre2 | 17:46 |
| mvo | ogra: and that will move to beta | 17:46 |
| ogra | beta sounds perfect ... | 17:47 |
| mvo | sil2100: the various races for the pi firstboot (and dragon) are hopefully all under control now, I guess we just need to dig into the probert issue (and someone needs to test on a dragonboard) | 17:50 |
| mvo | sil2100: I will push new test images later tonight or early tomorrow but nothing special about them, just current edge (and soon beta) for core18 and friends | 17:50 |
| mvo | sil2100: (mostly just fyi) | 17:50 |
| zyga | jdstrand: I subscribed you to https://bugs.launchpad.net/snappy/+bug/1796362 | 17:56 |
| zyga | please check my last comment there | 17:56 |
| mup | Bug #1796362: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks <Snappy:Incomplete> <https://launchpad.net/bugs/1796362> | 17:56 |
| zyga | mvo: is dragonboard fixed now? I can test it if you need that | 17:56 |
| jdstrand | roadmr: can you pull r1132. it has the fix for zyga's snap | 17:57 |
| zyga | mvo: do you want to do a simple boring review with a function rename | 17:57 |
| zyga | jdstrand: oh, that was quick, thank you! | 17:57 |
| mvo | zyga: dragonboard - I'm not sure its fixed, let me build a new test image. I fixed some firstboot races | 18:08 |
| zyga | k | 18:08 |
| mup | PR snapd#5955 opened: cmd/snap, tests: snapshots for all <Snapshots πΈσ > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955> | 18:21 |
| sil2100 | mvo: thanks! I'm usually just building images myself to always have the latest core, but I know there are others that were doing some tests on the pre-built ones | 18:51 |
| sil2100 | mvo: I saw a lot of good fixes getting merged today, thanks for those! | 18:51 |
| sil2100 | mvo: we're still working on some bits and pieces to enable dailies, but now with the official assertions we can push things a bit more forward | 18:52 |
| mvo | sil2100: great, thank you. building them yourself is fine of course :) | 19:21 |
| mvo | zyga: dragonboard is up at http://people.canonical.com/~mvo/core18/ | 19:21 |
| mvo | zyga: but no rush | 19:21 |
| mvo | zyga: also I'm not sure things will be better than at the sprint, but you never know :) | 19:22 |
| mvo | sil2100: fixes> yeah, nothing beats testing on real HW there were some races | 19:22 |
| mup | PR snapcraft#2331 opened: meson plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2331> | 19:29 |
| jdstrand | zyga: hey, can you add this to your list: https://github.com/snapcore/snapd/pull/5739 (waiting for spread tests to finish) | 19:58 |
| mup | PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5739> | 19:58 |
| mup | PR snapcraft#2332 opened: waf plugin: support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2332> | 20:12 |
| mup | PR snapcraft#2328 closed: godeps plugin: support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2328> | 20:24 |
| thresh | popey, pingie "download button" art | 20:29 |
| roadmr | jdstrand: hi! sure will do | 20:35 |
| mup | PR snapcraft#2330 closed: pluginhandler: remove big solidus workaround <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2330> | 20:45 |
| popey | thresh: i pinged design about that yesterday, and was told it's in the lawyers queue for licensing. | 21:03 |
| popey | thresh: thanks for the ping :) | 21:03 |
| mup | PR snapcraft#2333 opened: catkin, catkin-tools: add support for bases <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2333> | 22:12 |
| mup | PR snapcraft#2248 closed: plugin: update catkin plugin to support melodic <do-not-merge-yet> <Created by NickZ> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2248> | 22:15 |
| mup | PR snapd#5861 closed: cmd/libsnap: add functions for handling facts <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5861> | 23:10 |
| mup | PR snapd#5859 closed: many: introduce facts, export experimental features as facts <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5859> | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!