[00:20] PR snapd#1811 closed: interfaces/builtin: usb serial-port support via udev [01:43] hello , how can i know what are the exact parts my snap will need ! [02:41] does anyone know how to find out whether my bluetooth on my raspberry pi is enabled or not? I want to make use of the bluetooth to find sth. [02:45] rfkill list all # should tell you [05:26] ogra_: hm, I cannot reproduce this with dnsmasq as server (just followed up to the bug); maybe you can attach your dhcpd config to the bug? can you reproduce this with a VM/container as well, or only with your device? [06:22] PR snapd#1839 closed: interface: network_manager: enable resolvconf [07:00] hey hey [07:07] good morning dholbach! [07:08] salut didrocks [07:08] good to see you're back again! :) [07:08] thanks! :-) been a long time with your holidays starting a week before mine! :) [07:09] yes :) [07:21] Hi all, any devs around that know about the progress of https://bugs.launchpad.net/snappy/+bug/1609930 [07:21] Bug #1609930: Support license acceptance === davmor2_hols is now known as davmor2 [08:13] ogra_: hey, did you write the images for the pi2 that had the corruption problems with "dd conv=sparse" ? [08:15] morning [08:16] mvo, ogra_: any last minute console-conf / RTM panics? [08:17] i have on my machine here a UI that lets you plug in ESSID / password for wlan but i'm not proposing trying to get that into RTM [08:20] mwhudson: I had some strange error from the network on the pi2, that console-conf could not connect to the users api endpoint of the store, however I have not investigated further, as the pi2 as more (and bigger) problems currently [08:21] mvo: uh, hm [08:44] mvo, hey you had a failure in https://github.com/snapcore/snapd/pull/1845 TestSignBuildMissingKey.pN58_github_com_snapcore_snapd_cmd_snap_test.SnapSignBuildSuite [08:44] PR snapd#1845: tests: use the real model assertion when creating the core test image [08:45] mvo, I suppose it was unrelated to your PR, as I'm hitting the same issue locally with another PR [08:45] mvo, how did you get rid of it? :) === stub` is now known as stub [08:47] Kaleo: we noticed some minutes ago and we will debug/fix, just ignore until then, should be quick [08:47] mvo, sweet === admcleod_ is now known as admcleod [09:02] mvo, with and without [09:04] mwhudson, err, why do you hold that ssid stuff back ? just to land it right after rtm ? (we will need it in any case) [09:04] ogra_: just wanting to avoid last minute breakage [09:05] well, that means no dragonboard image then (only wlan) [09:05] ogra_: would you like an image to test? [09:06] well core snap [09:07] we dont have a gadget for the dragon yet either ... but sure ... having something ready to test might be good once i got the gadget ... [09:07] the vfat corruption klind of held us up [09:07] so i didnt get to dragon yet [09:10] shipping is hard :( [09:23] bah, just missed a publisher run :( [09:33] ogra_: fwiw, I put some info into the fs corruption bug and a tiny reproducer [09:34] ah, awesome [09:36] well, i'm not sure it is mtools ... afauik for a vfat you also need to align the partition to the block size the vfat has ... i.e. if the vfat has 512 byte blocks, the partition nees to start and end on a pyhsical point thats divisible by 512 bytes [09:36] i havent checvked that if we do that [09:46] ogra_: I pushed a potential fix to my branch [09:47] ogra_: check the LP page, I will play with the new image now, but its clear that mtools causes havoc, the fs is already corrupted when it finishes [10:05] ogra_: https://launchpad.net/~canonical-foundations/+snap/snappy-first-boot <- latest core snaps there have wifi ui [10:05] in console-conf [10:05] (packages in https://launchpad.net/~canonical-foundations/+archive/ubuntu/ubuntu-image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial) [10:05] awesome, thanks ... will test that once i got to roll a new image [10:06] ogra_: np, hope it works, i haven't tested it at all! (the config it produces looks sane but that's as far as i can get) [10:06] qemu seems not to emulate any wlan interfaces [10:06] yeah ... i think kvm allows to attach host wlan devices though [10:12] mvo, afaik we have working mtools code in debian-cd somewhere [10:12] * ogra_ remembers that we used to run into similar probs back in the arm team days [10:12] ogra_: working as in not-corrupting? [10:12] yes [10:12] ogra_: its interessting, it seems to be subdir releated or recursive copy [10:13] ogra_: my reproducer is fine when not using subdirs but I didn't want to sink too much time into finding workarounds [10:14] how about if you do the recursion yourself in a shell loop ? [10:14] and copy file by file [10:14] * ogra_ found the old code ... http://paste.ubuntu.com/23136465/ [10:14] ogra_: that might work [10:15] mkdosfs ... vs mkfs.vfat [10:15] ogra_: no subdirs no recursive (-s) in that script, I would bet this works fine [10:16] yes, but we had to do the 512byte alignment ... [10:16] dd if=/dev/zero of="$IMAGE" bs=512 count=0 seek="$IMG_SIZE_BLOCKS" >/dev/null 2>&1 [10:17] and [10:17] VATSTART=$(parted $IMAGE unit B print|grep "^ 1"|awk '{print $2}') [10:17] VATSIZE=$(LANG=C fdisk -l ${IMAGE} 2>/dev/null|grep W95 |awk '{print $5}') [10:17] though that was using CHS with sfdisk [10:17] Hi all, does anyone know about the progress of https://bugs.launchpad.net/snappy/+bug/1609930 [10:17] Bug #1609930: Support license acceptance [10:19] ogra_: i am horrified to learn that this sort of thing is still a problem in 2016 :( [10:19] haha [10:20] ogra_: at least you don't have to deal with the buggy FAT parser in omap3 (?) ROMs? [10:20] yeah [10:25] ogra_: hm, no luck with recursion either [10:27] IMAGE_SIZE=$((134217728/512)) [10:27] mkdosfs -F 32 -C $IMAGE.vfat $IMAGE_SIZE [10:27] mvo, ^^^ no fsck errors for me with that ^^^ === hikiko is now known as hikiko|ln [10:28] ogra_: oh? [10:28] how the heck do i verify it now ... seems i cant loop mount it [10:30] ogra_: https://pastebin.ubuntu.com/23136501/ I still get that [10:30] ogra_: I mean, I still get fsck errors wit hthat [10:30] ogra_: or am I misunderstanding what you suggested? [10:30] i'm suggesting to replace line 7 [10:31] mkdosfs -F 32 -C $IMAGE.vfat $((134217728/512)) [10:31] try that instead [10:31] ogra_: aha, mkdosfs [10:32] ogra_: like this https://pastebin.ubuntu.com/23136505/ ? [10:32] well, you want the dd [10:33] oh, or not [10:33] -C might be enough actually [10:34] ogra_: I get the same corruption error with the pastebin script [10:34] weird, i dont [10:36] bah ... [10:37] actually naming the image corrently helps :P [10:37] *correctly [10:39] ogra_: oh, fun, it seems racy, I don't get it all the time [10:40] heh [10:41] mcopy has a-b option ... [10:41] fgimenez, you uploaded test snaps to the store for spread tests. Is that a typical thing to do? can I just upload one myself for my own tests? [10:41] b [10:41] Batch mode. Optimized for huge recursive copies, but less secure if a crash happens during the copy [10:41] hmm, doesnt help either [10:42] morphis, I believe I fixed everything you noted in https://github.com/snapcore/snapd/pull/1775 [10:42] PR snapd#1775: interfaces: add thumbnailer interface [10:43] morphis, I added a spread test but it depends on a snap that is pending review for publication in the store [10:43] mvo, how about using mmd to create dir tree on the target and then iuse mcopy per file [10:43] morphis, can you check that everything is to your liking? [10:43] Kaleo: will have a look, thanks! [10:43] :) [10:46] Kaleo, hey :) yes, we have a bunch of test snaps uploaded to the store that are used by the snapd spread suite, previously we used snaps currently there (hello-world for instance) but we needed to control the state of these snaps in order to make proper assertions and have reliable results [10:47] ogra_: https://pastebin.ubuntu.com/23136531/ works 1/2 the time [10:47] Kaleo, these test snaps are owned by the canonical shared account, so that we don't get locked on a specific user [10:47] mvo, well, then we just run it twice :P [10:48] *cough* [10:48] * mvo lunch [10:49] fgimenez, oh good, who can upload with that account? [10:51] mvo, hmmm do you call "mdir /" in there ? [10:52] err [10:52] mmd / i mean [10:56] Kaleo, mvo can help you, and thanks for the test! :) looks great [10:56] fgimenez, :) [10:57] mvo, I would like to upload a test snap to the store [10:57] test-snapd-thumbnailer-consumer [10:58] mvo, http://people.canonical.com/~kaleo/test-snapd-thumbnailer-consumer_1.0_amd64.snap [10:58] mvo, generated from https://github.com/snapcore/snapd/pull/1775 [10:58] PR snapd#1775: interfaces: add thumbnailer interface === chihchun is now known as chihchun_afk [11:15] Kaleo: did you upload this already under your account? if so we need to talk to nessita. you will need to delete it from your account and I can then upload it to the shared account [11:20] PR snapd#1847 opened: many: discard preserved namespace after removing snap [11:22] morning === hikiko|ln is now known as hikiko [11:29] mvo, heh... thats what oi call pragmatic :) ... back to loop mounting [11:29] s/oi/i/ [12:07] getting a build failure, missing a header file that builds fine without snapcraft. The dep is in the build-packages section. [12:09] usr/include is missing in stage/. Wut [12:11] stub, hi, can you tell me a bit more about the magic names for license files? Is there somewhere (I guess no doc yet, so in code form maybe) where these are referenced? [12:11] davidcalle: The magic names for license files are mentioned nowhere [12:12] davidcalle: We used to have a way of referencing the license (using license: in snapcraft.yaml). Now we don't. [12:13] stub: ok, I'll let someone invested in re-adding the feature reply then. [12:33] pitti, so looking at the leases file excerpt (attached to the bug), the uid stuff looks pretty inconsistent ... [12:33] what creates that uid string ? networkd ? [12:41] ogra_: yes, that's a "DUID" (https://tools.ietf.org/html/rfc3315#section-9) [12:42] ogra_: by default it's generated from /etc/machine-id [12:42] well, the non netplan images do not send it [12:42] right, isc-dhcp sends the hostname [12:42] see the top of the leases excerpt ... [12:42] we can also set ClientIdentifier=mac [12:43] (this is what isc-dhcp does, I suppose) [12:43] we should probably do that then [12:43] ogra_: the question is, why does your /etc/machine-id change? [12:43] hmm [12:45] i wouldnt know anything that explicitly deletes it [12:45] in our boot process [12:45] mvo, I had uploaded it but deleted it right away [12:46] ogra_: can you compare it between two boots, when the IP changes? [12:46] sure [12:47] ogra_: i. e. I'm not too fussed about setting ClientIdentifier=mac, but /etc/machine-id changing sounds bad for many other reasons [12:47] definitely ... [12:47] it normally doesnt change .... but perhaps something in the way we now create images using ubuntu-image makes do so [12:47] pitti, is autopkgtest compatible with snaps? [12:50] ogra_: could be that /etc/machine-id is not writable or not a persistent file at all (then a random one is generated on boot and bind-mounted) [12:50] it is writeable and our handling of writable files hasnt changed [12:51] Kaleo: yeah, now we need nessita, she will need to delte it from your account in the db so that I can reupload it, the name is now claimed :) [12:51] Kaleo: no, ATM it only knows about dsc and click; until the last CDO sprint at least there was no test specification for snaps [12:51] Kaleo: we will also need to change the hash, but unsquash/resquash is hopefully enough for this [12:52] mvo, hi! I'm here [12:52] what snap? [12:52] nessita, can you delete test-snapd-thumbnailer-consumer ? [12:52] nessita, from my account fboucault [12:53] Kaleo, one sec [12:56] niemeyer: ping [12:58] morphis: Heya [12:58] niemeyer: hope you had a good weekend :-) [13:00] morphis: hey [13:03] mvo: hey there, any thoughts on my comment in https://github.com/snapcore/snapd/pull/1785 [13:03] PR snapd#1785: many: add vendoring of dependencies by default [13:07] zyga: hey! [13:07] niemeyer: any reason why the hidraw and udisks2 interface PRs are not merged yet? [13:07] morphis: Yeah, it was good, thanks [13:08] morphis: hidraw we probably just need to rename it, udisks2 I didn't manage to get to it [13:08] morphis: Let's speak after the standup please [13:08] niemeyer: ok [13:09] Kaleo, do you have a link t your package? I can't find it [13:09] morphis: did you guys do the /media mount propagation change yet? [13:10] zyga: no, jdstrand and tyhicks are working on that [13:10] zyga: the patch ssweeny had didn't work so we followed up with jdstrand and tyhicks to get a solution in time for RTM [13:11] morphis: they are off today [13:11] morphis: and RTPM is today, right? [13:11] zyga: plan was actually ( ssweeny correct me if I am wrong) that a patch is ready on tuedsay [13:11] zyga: or better said, we provide a fix for this after RTM [13:11] nessita, I deleted it from the store's interface [13:12] morphis: I see, ok [13:12] nessita, it was at https://myapps.developer.ubuntu.com/dev/click-apps/5861/ [13:12] Kaleo, so that's enough [13:12] nessita, oh ok [13:12] mvo, ^ [13:12] Kaleo, is gone :-) [13:13] :) [13:27] Kaleo_: you should have mail [13:28] mvo, I do :) [13:28] mvo, what's the next step? === chihchun_afk is now known as chihchun [13:32] Kaleo_: in a meeting right now, lets talk in ~15min [13:33] k [13:41] pitti: it looks like the latest images have no entries in /etc/resolv.conf for the nameserver (at least in kvm) with netplan, a second dhclient eth0 fixes it. is that something known? or can I do anything to debug this? [13:43] morphis: hey, niemeyer asked me to ensure that udisks2 gets merged only if it makes sense (snap-confine makes it really work as expected) [13:44] pitti, thanks [13:44] zyga: ok, for that we miss the patch jdstrand and tyhicks are working on [13:48] mvo: not known, but confirmed in a container [13:50] mvo: is that actually breaking anything? [13:51] morphis: do you know if this will be ready tomorrow? [13:51] morphis: I think gustavo would rather not merge the interface before we merge this change [13:51] mvo: oh -- do you have libnss-resolve installed? I suppose not [13:52] zyga: https://paste.ubuntu.com/23137062/ is what I got from ssweeny, jdstrand and tyhicks [13:53] mvo: it's in ubuntu-standard, but maybe that isn't installed in snappy images; where would be the place to seed it? [13:53] PR snapd#1848 opened: snap: ensure that plug and slot names are unique [13:54] pitti, we dont even seed ubuntu-minimal ;) [13:54] pitti, livecd-rootfs in the image PPA is the place for adding a package [13:54] pitti, but why not just make it a dependency of nplan if it needs it [13:54] so that, or making it a dependency of netplan [13:55] well, it's not conceptually a netplan thing [13:55] would be the same with ifupdown or NM, we changed the resolver a while ago [13:55] ogra@anubis:~/datengrab/devel/branches/ubuntu-image-mvo$ sudo snap install ubuntu-image_0.5+mvo1_amd64.snap --devmode --force-dangerous [13:55] [sudo] Passwort für ogra: [13:55] error: unknown flag `force-dangerous' [13:55] GRRR [13:55] snapd ! stop changing every day ! [13:56] ogra_: today just use "--dangerous" [13:57] mvo, well --devmode is enough [13:57] ogra_: tomorrow it will "--might-exlode" [13:57] haha [13:57] ogra_: aha, yeah, devmode adds it implicitely [13:57] yep [13:57] pitti: thats fine, I can add it to livecdrotootffs [13:57] ffs ? heh [13:57] * ogra_ notes mvo had a clown for breakfast :D [13:58] pbek: did you know qownnotes in the store doesn't launch? [13:58] pbek: alan@gort:~$ /snap/bin/qownnotes [13:58] /snap/qownnotes/149/bin/desktop-launch: line 144: /home/alan/usr/bin/QOwnNotes: No such file or directory [13:58] mvo: still thinking where to put it -- container images have the same issue [13:59] (containers with netplan, I mean -- ifupdown calls resolvconf by itself) [13:59] pitti: I will add it manually for now to unblock us [13:59] pbek: running it manually works, like this:- $ /snap/qownnotes/149/bin/desktop-launch /snap/qownnotes/149/usr/bin/QOwnNotes [14:00] mvo: ok; that should work, still doesn't feel completely right [14:00] oh man ... [14:00] ogra_: one thing for classic, without ubuntu we have no password for the local sudo user anymore so our sudo classic env needs a nopasswd [14:00] pitti: ok, once you have a different solution, just let me know [14:00] * ogra_ broke with his rule to never post political or religious statements on social media ... i should have known what happens :/ [14:01] ogra_: Je suis McPomm? [14:01] pitti, yeah [14:01] mvo, did you see my PR for classic-snap ? [14:02] (should perhaps be a bind-mount though ... but cp felt safer that moment) === pstolowski is now known as pstolowski|lunch [14:02] ogra_: no, looking now [14:03] :) [14:03] fixes sudo [14:03] ogra_: does it? and its in the store already? [14:03] yes [14:03] happy to revert if you want to bind mount instead though [14:03] ogra_: hm, dosn't for me then :/ [14:03] ogra_: no, copy is fine [14:04] the issue is that the console-conf user isnt in the extrausers db [14:04] ogra_: and I'm not in the sudo group [14:04] thats fine [14:04] there should be a sudoers.d snippet for the user [14:05] ogra_: right, not in classic [14:05] we cant change the sudo group since it needs to be in the readonly /etc/group [14:05] oh, then we probably also need to copy the snippet [14:05] ogra_: yeah [14:05] morphis, zyga: To be clear, I'd like to hold the interface if it _only_ makes any sense once the snap-confine change goes in [14:05] funny, why did that work for me [14:05] ogra_: I have no idea :) [14:06] hmm, wasnt cyphermox' cloud-init stuff merged into u-i ? ... i still see the cloud-init mess on boot [14:06] morphis, zyga: Because snap-confine is in that tricky place right now where we have several non-trivial changes in progress, and I can't quite see which them will make it into RTM [14:06] niemeyer: I think that is the case today, morphis what do you think? [14:06] Having an interface that doesn't work at all for its intended purpose on RTM won't be very helpful [14:13] pitti, so you are right, i get a new machine-id for whatever reason [14:14] (sadly a reboot takes over 10min thanks to cloud-init on the pi currently ... no fun to test/debug) [14:17] mvo, fix for u-i looks good ... third reboot and my image is still fine [14:18] ogra_: yay [14:18] * ogra_ shakes head [14:18] [ 47.485605] cloud-init[2662]: 2016-09-05 14:00:33,698 - util.py[WARNING]: did not find either path /sys/class/dmi/id or dmidecode command [14:19] that was fixed in all distro tool using dmidecode like 5 years ago for arm ... [14:19] i wish c-i would make use of existing tools, that would really save having to fix things over and over [14:19] s/tool/tools/ [14:22] ogra_: you will like the most recent livecd-rootfs upload ;) [14:22] * ogra_ checks [14:22] * ogra_ hugs mvo wildly [14:24] mvo, so that ubuntu-core -> core rename ... did i understand niemeyer correctly that only the handling in snapd is needed for RTM and we'll do the actual switch later ? [14:24] also, what happens with the actual product name for the images [14:24] ogra_: this is still under investigation, maybe nothing for rtm because its too risky [14:24] (i.e. the download area on cdimage) [14:25] iirc slangasek and sabdfl both agreed the product name should be kept for the actual img files (especially in the light that we renamed ubuntu-core to ubuntu-base exactly for this) [14:29] (renamed -> the old core tarballs that is) [14:29] * ogra_ will just wait til the investigation is done then :) [14:29] hmm, the last snapd build in the PPA failed again on arm64 ... [14:30] ogra_: I upload a fix for classic with the sudoers.d now (unless you are already on it) === petevg is now known as petevg_afk [14:30] nope, still poking around on the pi2 atm ... so many bugs :/ [14:31] ARGH ! [14:31] ogra@localhost:~$ sudo snap install classic --edge --devmode [14:31] [-] Make snap "ubuntu-core" (354) available to the system [14:31] ... [14:32] damn ... forgot about the broken setup ... now it rolled me back to the last stable ubuntu-core [14:32] ogra@localhost:~$ sudo snap install ubuntu-core --edge [14:32] error: cannot install "ubuntu-core": snap "ubuntu-core" already installed [14:32] evilo ! [14:34] about time that we get the model assertion [14:35] ogra_: we have it, I hope to be able to create an image today with it for the pi2, waiting for the cloud-init change to lnad first [14:35] mvwell, there is a lot more ... like the machine-id changing every boot [14:35] mvo, ^^ [14:35] ogra_: aha, and I wanted to enable classic for multiple sessions, right now iirc we restrict to one but I think thats not needed [14:35] and for dragonboard we probably need the console-conf with wlan support [14:35] ogra_: it does? [14:36] mvo, yeah [14:36] meh [14:36] ogra_: do you happen to know why? [14:36] https://bugs.launchpad.net/snappy/+bug/1619721 [14:36] Bug #1619721: IP changes with every reboot [14:36] not yet ... and a reboot taking 10min doesnt really help ... so i'm waiting for the cloud-init drop here too [14:36] ogra_: machine-id or IP? [14:36] popey: thank you for reporting, I couldn't even test for a while because I get: "multiple nvidia drivers detected, this is not supported" [14:36] ogra_: heh :) [14:36] one is a result of the other [14:37] ogra_: ahhhh [14:37] netplan transfers the machine-id now [14:38] pbek, Bug 1615248 [14:38] Bug #1615248: ubuntu-core-launcher nvidia driver detection is bogus [14:38] there is a workaround [14:39] ogra_: thank you, I know. but I fear removing my envidia directories because currently two are in use... [14:39] in use ? [14:39] how can there be more than one in use ? :) [14:40] ogra_: ordering again? dbus-uuidgen running before the writable-paths are mounted maybe? [14:40] I don't know [14:40] if you tend to switch back and forth between two drivers, just rename the dir for the one not in use ... [14:40] there is no way that both are in use on a single boot [14:42] [ OK ] Started Snappy daemon. [14:42] [ OK ] Stopped Snappy daemon. [14:42] [FAILED] Failed to start Snappy daemon. [14:42] See 'systemctl status snapd.service' for details. [14:42] oh, lovely [14:43] thats what you get when being auto-rolled-back by 20 revisions :P [14:43] pbek: happy to test any time. [14:43] ogra_: I put my heart into it and moved some away ;) [14:44] yeah, just rename them, worst case you can move them back [14:44] popey: thanks a lot, that's my current desktion file: https://git.launchpad.net/~pbek/qownnotes-snap/tree/setup/gui/QOwnNotes.desktop [14:45] and that's the yaml: https://git.launchpad.net/~pbek/qownnotes-snap/tree/snapcraft.yaml [14:50] uhm ... [14:50] ogra@localhost:~$ mount |grep machine-id [14:50] tmpfs on /etc/machine-id type tmpfs (ro,relatime,size=94216k,mode=755) [14:50] ogra@localhost:~$ grep machine-id /etc/system-image/writable-paths [14:50] ogra@localhost:~$ [14:50] mvo, ^^^ any idea where that bindmount comes from ? [14:51] ogra@localhost:~$ grep -r machine-id /usr/share/initramfs-tools/* [14:51] ogra@localhost:~$ [14:51] definitely not from the initrd [14:52] why the heck is it a tmpfs at all [14:53] ogra_: systemd mounts it as that if the root fs lacks a machine-id and is not writable [14:53] ogra_: check dmesg [14:53] oh my [14:53] can we prevent that somehow ? [14:53] ogra@localhost:~$ dmesg|grep machine-id [14:53] [ 11.400424] systemd[1]: Installed transient /etc/machine-id file. [14:53] ogra@localhost:~$ [14:54] i assume it does that before processing fstab ? [14:55] yes [14:55] but the initrd should mount it if it's a symlink/mount, why doesn't it? [14:55] the initrd doesnt mount anything [14:55] it creates an fstab [14:56] I thought we changed it to mount the writable parts of /etc in initrd [14:56] nope [14:56] well, that was for system-image [14:56] but it's the same problem [14:56] still suspect its the ordering, i.e. we mount too late, i vaguely remember a similra 15.04 issue [14:56] i mounts one or two dirs that are actually needed by systemd to start at all ... [14:56] you *can't* mount stuff in /etc during boot [14:56] but beyond that it only creates fstab [14:57] well, at least not stuff that is needed for boot [14:58] iirc i even filed a bug that we should move it ... but james told me back then it was desired that systemd gets a chance to do fscks [14:58] so we never moved it to the initrd [14:58] I do remember having written a PR which moves it [14:58] maybe it was moved back [14:59] for initramfs-tools-ubuntu-core ? [14:59] i'm sure it never landed [14:59] well, whatever we used in system-image [14:59]