[03:01] zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1614162 [03:01] zyga: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d3e4a6577d [05:07] morning [06:01] hey mborzecki [06:03] Pharaoh_Atem: thank you for the note, hopefully someone will merge the fix [06:03] oh [06:03] zyga: hey [06:03] it's been proposed to bodhi :) [06:03] * zyga needs to wake up properly [06:03] I will test it with the build process and report ! [06:04] zyga: have you gotten around indcluding more flags in -ldflags=-extldflags=-static on opensuse? [06:05] mborzecki: no, I haven't touched opensuse in a while [06:05] (i.e. still broken as before) [06:05] on old release [06:06] damn, i'm trying to find a way through the shell quoting mess [06:06] yeah :/ [06:06] on the up side [06:06] indigo is in devel:languages:go now [06:06] maybe some part of the mess can be handled elsewhere [06:06] i think it only works in rpm spec because the spec is processed outside of shell :/ [06:07] I'm not fully here yet, need to get dressed and take Bit for a wlak [06:07] *walk [06:39] PR core-build#34 opened: travis.yml: fix xenial base tarball URL [06:59] and back now [06:59] hey moo :) [06:59] hey zyga [06:59] man, I need to teach the spell checker that mvo and moo are *not* the same :D [07:00] how are you doing guys? [07:02] zyga: doing well, how are you? [07:04] good, just finishing coffee :) [07:20] -ldflags=-extldflags=-foo is an abomination [07:20] -ldflags "-extldflags '-foo'" behaves differently === pstolowski|afk is now known as pstolowski [07:21] morning [07:22] and bash if very funny splitting -ldflags=-extldflags='-foo -static' into -ldflags=-extldflags=\'foo -static, so you get 2 options and -static is passed to go build pfff [07:23] ended up doing the 'array' expansion trick [07:48] PR core-build#33 closed: fix typo for handle_writable_paths() [07:48] PR core-build#34 closed: travis.yml: fix xenial base tarball URL [07:56] PR snapd#5942 closed: client: speedup unit tests [07:58] PR snapd#5941 closed: systemd, wrappers: speed up wrappers unit tests [08:00] PR core18#70 closed: hooks: add rfkill [08:01] PR snapd#5939 closed: tweak .travis.yml so we no longer get weird env output in the logs [08:01] PR snapd#5943 closed: osutils: unit tests speedup; introduce «run-checks --short-unit» [08:09] zyga: Good morning and sorry to bother you (again) with a layouts question: https://forum.snapcraft.io/t/snap-layouts/7207/3?u=tobias → Happy for any suggestion that resolves this issue, since I cannot publish my snap without this 😞 [08:09] good morning, looking [08:10] dot-tobias: hey, can you double check this on edge? [08:10] though let me double check that edge is really edge now, release messes that up [08:10] eh, no [08:10] edge is not edge :/ [08:10] mvo: how soon can we get edge builds back to normal? [08:10] zyga: Happy to check once edge is edge :-) [08:11] dot-tobias: I'll check locally soon, just let me wrap something up [08:11] zyga: Sure, glad you have time for this at all 😊 [08:12] PR core18#72 opened: writable-path: enable persistent journal [08:13] zyga: meh, one sec [08:15] zyga: I restored edge [08:15] zyga: and triggered a vendor sync manually [08:15] zyga: I suspect that vendor-sync is not running automatically right now (cc cachio) [08:16] mvo: thank you again [08:16] mvo: reviewed ^ [08:16] thank you! [08:19] PR snapd#5451 closed: interfaces: honor static attributes when reloading conns [08:20] PR snapd#5497 closed: overlord/patch: patch for static plug/slot attributes [08:31] Mornings [08:31] moin moin [08:31] hey guys [08:32] hey niemeyer and Chipaca [08:32] Chipaca: nice job on the test speedups! [08:32] today's a weird day for me, one of the boys is at a new school having a trial day, and I need to go do a tour of it at 1pm (so no 2pm standup for me) [08:32] mvo: :-D [08:32] mvo: mborzecki: I struggled with where to draw the line between shortening sleeps, and skipping on testing.Short() [08:33] mvo: mborzecki: so feedback very appreciated [08:33] i started also working on overlord, but it's a lot hairier [08:33] :) [08:33] Chipaca: yeah [08:33] Chipaca: my only concern is slow/overcommited hardware but we can tweak things into the other direction once we get results from autopkgtest [08:34] mvo: maybe, maybe, we tell autopkgtest to only run --short-unit now [08:34] niemeyer: if you could add github.com/snapcore/pi-gadget to the things that mup watches, that would be great! [08:34] ogra: your feedback on github.com/snapcore/pi-gadget pull 9 would be great [08:34] mvo: Thanks for the reminder [08:35] PR #9: Added the travis config file [08:35] mvo: DOing it right away [08:35] thank you! [08:38] PR snapd#5945 opened: overlord/snapstate: block parallel installs of snapd, core, base, kernel, gadget snaps [08:39] mvo: SHould be up [08:40] PR snapd#5946 opened: cmd/snap: unhide --name parameter to snap install, tweak help message [08:40] morning niemeyer [08:40] o/ [08:44] PR snapd#5947 opened: many: cleanup remaining parallel installs TODOs [08:45] niemeyer: I heard that Brazil has some exciting election time now [08:47] oh man [08:50] mborzecki: how does a user learn about instances? [08:50] PR core18#73 opened: hooks: run console-conf after snapd.seeded.service [08:51] mborzecki: I suspect the install docs is where. In which case, we need a longer explanation :-) [08:51] Chipaca: from the docs atm [08:51] Chipaca: you mean snap install help? [08:51] mborzecki: yeah. Maybe work with degville to get a concise paragraph in there about 'em [08:51] right now it only makes sense if you know what they are already [08:52] Chipaca: yes, the pr only mentions instance key but now how it can be used [09:02] mvo, perhaps also bump the tag of the pi2 u-boot build o they are on the same version [09:02] s/o/so [09:04] ogra: sure, will do [09:06] zyga: Yeah, pretty interesting [09:06] In a sad way [09:07] Chipaca: so you're saying "" would pop up in place of snap.TypeApp? [09:07] It's OMG what will the crazy guy do, vs. let's continue 16 years of recession [09:08] niemeyer: yeah, it seems the chances of the reasonable candidate are pretty slim in the 2nd round [09:08] Chipaca: hm we set TypeApp if type was empty in Yaml, but when using store data we leave whatever the store sent :/ [09:09] zyga: The second candidate is not reasonable either.. it's continuing the 16 years of power abuse [09:10] in that case the reasonable thing is to really leave, which is depressing for all, impossible for many [09:11] Right [09:23] pedronis: quick question, having a model assertion, kernel and gadget need to be valid 'store' snap names too, not only required-snaps? [09:24] mborzecki, you can use --extra-snaps (at the cost of upgradeability and interface auto-connections) [09:24] with ubuntu-image that is [09:24] mborzecki: handling "" as well would be the safe route [09:25] mborzecki: but, supposedly it's now never "" outside of tests [09:25] mborzecki: but², we don't validate this fact [09:25] we probably should if we're going to assume it inside [09:26] bah [09:26] mborzecki: all it'd take is a tweak to snap/types.go's unmarshallers [09:26] we already (still!) have a check for type "application" [09:26] could add "" to the list :) [09:26] or, live dangerously and remove "application" _and_ "" support [09:41] ogra, apw I would like to upload http://paste.ubuntu.com/p/HnXmvSHCww/ to cosmic and to our core18 ppa (and possible sru to bionic) - does that look sensible? [09:42] mvo, totall [09:42] y [09:42] go ahead [09:42] ogra: a bit of a meta question, it looks like hwclock from busybox tries to open some files in /dev/rtc - are there devices where we use fixrtc that actually have a rtc device? [09:42] ogra: thanks [09:43] mvo, there are "hat's" for the pi providing rtc [09:43] ogra: thanks [09:43] (and indeed there are other arm board with rtc too) [09:43] ogra: I will update the comment with that info [09:44] in general fixrtc needs an overhaul though due to the stuff that zyga found (kernel not updating timestamp of the rootfs on shutdown because of the readonly mount) [09:44] ogra: I updated http://paste.ubuntu.com/p/3VNNRmqZpj/ with a comment [09:45] mvo, well, i wouldnt make that "pi" specific ... fixrtc is in all our arm installs [09:45] (armhf that is ....) [09:46] ogra: thanks, updated again http://paste.ubuntu.com/p/wdQDrzqTqv/ [09:49] mvo, looks good [09:52] mborzecki: I'm not sure I understand the question [09:53] pedronis: there was a TODO in device_asserts to check whether required-snaps are valid store snap names when decoding model assertion [09:54] pedronis: i've extended this to cover kernel, gadget and base [09:54] ok [09:54] remember kernel and gadget takes = as well now [09:58] PR snapd#5948 opened: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names [10:00] pedronis: ^^ [10:02] mvo, if it is always using /dev/misc/rtc, you could do like [10:02] [ -e /dev/misc/rtc ] && ... [10:06] apw: yeah, I was thinking about this, it tests /dev/rtc /dev/rtc0 /dev/misc/rtc in busybox. the downside of adding the checks is that then we need to keep the initramfs code in sync with busybox/kernel - if this search paths ever change we will most likely not notice. OTOH it seems very unlikely this changes (famous last words) [10:14] PR core-build#35 opened: scripts/ubuntu-core/rootfs: fix mkdir error when the file exists [10:19] mvo, oh for a -q options ... oh well [10:52] apw: yeah, --quiet would rock. I looked at the source, busybox is a bit simple in this regard unfortunately [10:57] yeah sure it is [11:06] PR snapd#5945 closed: overlord/snapstate: block parallel installs of snapd, core, base, kernel, gadget snaps [11:10] oh boy [11:10] so [11:10] not sure how to proceed [11:10] I want to run snapd in a "container" [11:10] (ish) [11:10] it seems that I need to run systemd in the container as well [11:10] and to make it a proper container enough so that it doesn't bite the host [11:12] zyga: that sounds right, could you use lxd? [11:12] no [11:12] because I really need to craft everything in a specific way [11:16] * zyga proceeds to unshared more [11:17] la la la [11:17] running systemd partially unshared is fun, [11:17] (where fun == reboot to fix your system) [11:45] some small progress made, [11:46] cachio: i'm playing with arch-apparmor image you prepared and #5894 branch, seems to be working now, i'll a full run of arch tests on this image [11:46] PR #5894: many: enable AppArmor on Arch [11:52] off to pick up the kids [12:04] I need to take the dog out [12:04] ttyl [12:13] PR core-build#35 closed: scripts/ubuntu-core/rootfs: fix mkdir error when the file exists [12:28] oh damn ... its a holiday in the us ! [12:29] (so i guess no jdstrand today ... ) [12:30] mvo, shellcheck isnt happy with your initramfs-tools-ubuntu-core it seems [12:30] In ./hooks/resize line 20: [12:30] . /usr/share/initramfs-tools/hook-functions [12:30] ^-- SC1091: Not following: /usr/share/initramfs-tools/hook-functions was not specified as input (see shellcheck -x). [12:32] ogra: aha, thanks - where do you see that? i have a look [12:32] mvo, i got a mail from LP with link to the build log ... https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/15520942/+files/buildlog_ubuntu-bionic-amd64.initramfs-tools-ubuntu-core_0.7.45+ppa2_BUILDING.txt.gz [12:32] PR snapcraft#2325 closed: plugins: remove the python2 and python3 plugin when using a base [12:33] ogra: aha, I see, the bionic build? [12:33] yeah [12:33] ogra: i guess this is why we did not see this before, the test runs on xenial and bionic is more strict. I will fix in a wee bit [12:38] re [12:38] PR snapcraft#2322 closed: project_loader: add build-environment part property [12:41] Is there a quick way to get an unpacked snap to use with "snap try", apart from me unpacking the snap by hand? [12:42] "snap unpack" doesn't appear to exist [12:52] rbasak: unsquashfs [12:52] rbasak: we have snap pack because certain arguments to squashfs matter [12:52] rbasak: and because we also do some validation (AFAIR) [12:53] rbasak: on the "unpack" phase there's not much to do [12:53] though I agree that for consistency we perhaps might [12:55] zyga: aha! Just want I wanted. Thanks. Saves my mount/rsync/unmount triple :) [12:56] zyga: perhaps document that in "snap help try"? Eg. "The try command installs an unpacked snap into the system for testing purposes, such as one extracted from a snap with unsquashfs(1)." - then I'd have found it. [12:56] s/one/a directory/ perhaps [12:57] Or maybe "the" [12:57] mmm, yeah, that feels like a good idea [13:15] or maybe just add 'snap unpack' :) [13:15] hello from just-out-of-the-meeting--land === pstolowski is now known as pstolowski|lunch [14:13] jdstrand, arent you celebrating that guy who got lost looking for india today (just asw MP comments from you) ? [14:13] read: are you working ? [14:14] s/asw/saw/ [14:26] PR snapd#5949 opened: osutil,asserts,daemon: support force password change in system-user assertion [14:31] PR core-build#36 opened: initramfs: fix shellchecks on bionic === pstolowski|lunch is now known as pstolowski [14:35] cwayne, hey, do you know the status of 2.35.4? [14:35] is it ready to go to cnadidate? [14:46] mvo: around? Taking the current edge git-ubuntu snap, if copy $SNAP/usr/local/bin/quilt to /tmp inside a snap shell and apply your MP to that, running quilt results in "Illegal instruction (core dumped)". I'll dig deeper. [14:58] rbasak: if you move $SNAP/usr/local/bin/quilt the $ORIGIN based rpaths will most likely be wrong [15:00] the local/bin/ files are just wrappers that set PATH and LD_LIBRARY_PATH [15:01] I've narrowed it a bit. [15:01] If I just set PATH and LD_LIBRARY_PATH to the core snap only, then everything crashes with SIGILL. Including ls, ldd, etc. [15:09] mvo: hmmm, interesting, a fresh image built with the new model assertion doesn't segfault with probert on my raspi3 anymore [15:10] mvo: this is really annoying, how could this issue suddenly disappear? [15:16] mvo: I also have proper wired networking, no crashes in console-conf [15:17] Let me try a complete vanilla image [15:32] rbasak: woah, let me try to reproduce this myself [15:33] rbasak: you really find all the interessting bugs :) [15:33] sil2100: oh, so you have wired and wireless? [15:33] sil2100: note that for me it works on the pi without wifi [15:33] sil2100: but on the 3b+ with wifi I still had issues (looks like crashes) [15:34] sil2100: let me try on the 3b+ again [15:34] mvo: I couldn't connect to my wireless AP but it didn't crash or anything [15:34] I have a regular 3b [15:35] sil2100: and you see the wireless in the config? [15:35] So on a vanilla image I see a crash in console-conf [15:35] build.snapcraft.io now builds for all architectures by default: https://forum.snapcraft.io/t/more-architectures-enabled-in-build-snapcraft-io/7733 [15:35] Similar to the one ondra reported, with console-conf crashing because it cannot run snap create [15:36] *create-user [15:36] sil2100: ok, let me try again on my pi3 [15:37] mvo: I'm also trying different combinations right now [15:37] sil2100: about snap create - I pushed a PR to run console-conf after snapd.seeded.service - this way console-conf should have a fully working snapd and some of the issues we saw earlier should be fixed [15:39] argh ! build.s.io all of a sudden produces s390x and ppc64el builds ! [15:39] crazy world [15:42] See ten lines back :) [15:43] "all architectures", but still no builds for RCA 1802 [15:43] psh [15:43] I regret that we also don't build for Doric columns [15:43] * cachio lunch [15:43] nor for for the TMS320C80 [15:44] it's like you're not even trying [15:44] * cjwatson looks forward to that contract [15:44] heh [15:49] sil2100: yeah, on my pi3b+ I also now see console-conf, nice. also disturbing why it suddenly works, I will try with a fresh dd of the image again to see if its maybe firstboot related [15:50] PR core18#73 closed: hooks: run console-conf after snapd.seeded.service [15:52] sil2100, FYI core 16 edge works fine on my b+ over here ... i think we can push the gadgets to stable [15:52] ogra: ok, let's coordinate regarding that tomorrow [15:52] (just got mine on sat.) [15:52] sil2100, +1 [15:53] mvo: strange indeed - anyway, as for the config, if I checked correctly I had no wlan in the yaml but I guess that's normal since I didn't configure it - since somehow it was unable to connect to my AP [15:53] But maybe I simply forgot the password ;o [15:53] sil2100: heh [15:53] sil2100: I couldn't connect to my wlan either so maybe something with the kernel or userland [15:54] just use core16, it works fine :P [15:54] always that upgrade obsesion :P [15:54] Ok, but at least we can now properly use the images on the pi [15:54] ogra: ;) [15:55] sil2100: I also had no wired network on the pi3 b+ so maybe something with that model, my pi2 was fine [16:10] PR snapd#5623 closed: advise-snap: add --dump-db which dumps the command database [16:17] mvo: Sent a note on #5871.. it's a LGTM, but I screwed up the review and sent a comment too soon, sorry [16:18] PR #5871: snapstate: only report errors if there is an actual error [16:19] pedronis: ping [16:20] niemeyer: thanks! [16:24] sil2100: so good news and bad news - after a fresh flash still no crash on the pi3 b+, so yay! but also no network (not wired nor wirelss) [16:28] arch & gce, a story of crng init :/ https://paste.ubuntu.com/p/SwKw5C7XKS/ [16:32] mvo: ouch [16:32] grrr [16:35] niemeyer: pong [16:37] niemeyer: the code will work as you expect it, I was trying not to use parent in the docs of this, but the model is more that a child store is extended by including more (parent) stores [16:39] mvo, are you sure the right dtb is being used (the core of the b+ is identical to the other pi3's, only peripherials differ and they are declared in the dtb) [16:39] PR snapcraft#2300 closed: [WIP] plugins: remove implicit source [16:39] PR snapcraft#2326 opened: plugins: remove implicit source [16:39] pedronis: "extension" is fine, the question is because it sounds like the who-extends-whom is reversed [16:40] pedronis: The thing declaring the friendly stores is the one that accepts (extends) snaps from the listed ones [16:40] niemeyer: yes, it exposes snaps from those [16:41] pedronis: Ah, "expose" might be a nicer way to convey it [16:42] niemeyer: "returns further stores that are exposed by this store" ? [16:43] "by" or "through" [16:44] pedronis: Returns stores holding snaps that are also exposed but this one, or something along those lines [16:47] ok [16:47] thx [16:52] niemeyer: changed [16:59] mvo: have you branched again 2.36 or not yet? [17:00] PR snapcraft#2324 closed: plugins: remove the ament plugin when using a base [17:11] pedronis: not yet branched again [17:11] pedronis: once 2.35.4 hits candidate I will push the next beta of 2.36 [17:11] ogra: not sure at all :) any hints appreciated [17:11] mvo: ok, waiting for my main 2.36 left branch to get green [17:12] I got the 2nd 11 [17:12] *+1 [17:12] yay [17:13] mvo, well, do you have /boot/uboot/bcm2710-rpi-3-b-plus.dtb ? [17:13] else it will just automatically use bcm2710-rpi-3-b.dtb ... [17:14] ogra: yes, that file is there [17:15] /proc/device-tree/model also shows the Plus dtb to be used ? [17:16] travis getting 50kb/h from that gce archive [17:16] :-( [17:16] ogra: let me try, I need to hack myself in first, I can't create a user via console-conf right now :/ so give me 5min [17:18] thats why i never use canonical models during development ... system-user assertion FTW ;) [17:19] ogra: heh :) cat /proc/device-tree/model ;echo [17:19] Raspberry Pi 3 Model B Plus Rev 1.3 [17:19] looks fine ... so the dtb is definitely correct [17:20] do you see NICs at all in /proc/net/dev ? [17:21] ogra: yeah, also console-conf shows them, but they are just not working for some strange rseason [17:21] oh [17:22] even for wired which is weird [17:22] (link led is on fwiw on pi and router) [17:23] * mvo pokes some more [17:27] cachio: hey, you were mentioning on the sprint a spread test extending nested vm helpers (if i remember correctly); did you make progress with this? [17:30] pstolowski, no but I could start working on in today [17:30] after the ubuntu cosmic PR is ready [17:31] cachio: ack, thanks [17:32] anyone from the store, my uploads go away as "__all__: The upload does not appear to be a valid package" [17:32] but it installs just fine locally :/ [17:32] any ideas? [17:33] niemeyer: any chance for a re-review of #5759? also, the other 3 hotplug PRs have +1s but need one more review [17:33] PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug