[03:54] PR snapcraft#1524 opened: Yarn lock record [06:28] good morning [06:29] mvo: my network is better than ever, I've reinstalled xenial [06:29] mvo: if you want to have that call I'm available and eager to test [06:33] zyga-ubuntu: hey, good morning - please check the latest bits I wrote in 3625, I'm available in some minutes (just want to finish two small review feedback tasks) [06:35] mvo: great, I'll read your feedback and grab a coffee, let's chat soon [07:10] mwhudson: hello, I made git happy, shall I dput or do you want to do that yourself? [07:20] mvo: let me take your branch and look at some possiblity to make it more uniform, I won't push to your PR but will have something as a base for discussion, ok? [07:20] * zyga-ubuntu is still sleepy, needs to transition to waking up at 6AM [07:21] zyga-ubuntu: sure [08:10] ogra_: hey, I'm having trouble bringing up Mir on the edge/daily RPi3 image (and I tried your images too, no diff). I'm suspect https://pastebin.ubuntu.com/25443549/ Is this a known issue? [08:10] pedronis: this might be interessting for you: httputil/logger.go:108: assignment copies lock value to transport: net/http.Transport contains sync.Mutex (from go vet 1.7) [08:21] mvo: that is annoying, the rule is A Mutex must not be copied after first use, I think the current code isn't quite right, even reasonably code will not make vet happy there :/ [08:21] though [08:24] mvo: more correct code would be like this: https://pastebin.canonical.com/197306/ don't think it make vet happier though [08:27] pedronis: yeah, I think there is a open bug about that vet is not smart about this :/ [08:28] pedronis: the alternative of creating a transport with the same values as default trnasport is very much not DRY, so maybe best to ignore/silence this vet message [08:29] that's what I had the problem is that the exact params change between 1.6, 1.7, 1.8 [08:29] so params are new in each [08:29] so we would need multiple versions of that code [08:34] mvo: I don't think there's a way to supress single warnings [08:34] unless we do it from the outside? [08:38] mvo: what's your thinking? [08:41] pedronis: yeah, I was thinking to grep -v on the outside [08:41] zyga-ubuntu: ready when you are, sorry that things took a bit longer [08:42] mvo: this is how they look in the versions btw: http://pastebin.ubuntu.com/25443642/ [08:42] pedronis: meh, really annoying [08:52] mvo: we can probably get away with 2 version 1.6 and 1.7+ at least for a bit [08:57] greyback, that output looks normal to me (these bind errors have always been there IIRC) [08:58] ogra_: ok. I'll try to figure out why Mir is sad then. [08:58] i guess /dev/dri/card0 exists ? [08:58] ogra_: yep [08:58] then he device should technically be initialized properly ... [08:59] there was a change regarding famebuffer handling in the kernel though [08:59] ogra_: is it a custom kernel? [09:00] it is based on our 4.4 tree i think with broadcom patches on top ... you have to ask ppisati for more details ... mir worked fine in the past though ... [09:00] the framebuffer thing is https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1708417 [09:00] Bug #1708417: Board hangs with 'dtoverlay=vc4-kms-v3d' while writing to /dev/fb0

[09:01] (the patch is attached there) [09:01] not sure if that can have any impact on mir [09:02] greyback, also ... remembering the forum...did you try a reboot ? :) [09:02] ogra_: yep :) [09:03] ok, well I know where to start, thanks [09:08] greyback, FYI i just installed mir-libs and mir-kiosk from edge and have a mouse cursor now on a pi2 [09:08] ogra_: ack, thanks for that. I didn't think pi3 was that different... [09:09] the kernel and rootfs are identical ... the bootloader setup differs slightly [09:10] (bootloader binaries should also be identical nowadays, it is really only config diffs in the gadget) [09:11] mvo: I'll propose something using the 2 versions [09:12] pedronis: thanks a lot, i have a look [09:26] pedronis, hmm, could your recent changes to serial handling have introduced a race ? i just had the second installl in a week where installing my first snap on a device ended up in installing core first ... (which indicates that firstboot or key setup failed) [09:28] ogra_: that sounds more like a firstboot issue [09:28] k [09:28] serial doesn't play a role there [09:28] I mean you have no core [09:28] sadly the card is already messed up and i'm re-flashing [09:28] serial starts after seeeding [09:28] but i guess that will happen again [09:29] I'm sure there's an issue, don't think it's related to serial [09:29] well, the images were pretty reliable until recently so it is definitely a recent change, serial just came to my mind as first thing here :) [09:30] those changes should not have modified behavior on core [09:30] also as I said they trigger after seed is set [09:31] we need a log [09:32] ogra@localhost:~$ snap changes [09:32] error: no changes found [09:32] ogra@localhost:~$ snap list [09:32] No snaps are installed yet. Try "snap install hello-world". [09:32] ogra@localhost:~$ [09:32] ok ... seems reliably broken [09:32] that seems very broken [09:33] there not even a try to seed [09:34] pedronis, http://paste.ubuntu.com/25443792/ looks relevant [09:35] pedronis, note that i have only seen it on wlan-only boards ... which come up without any networking (because WPA isnt set up indeed) [09:35] you r image as a strange time: 2016/02/11 16:28:15.328983 [09:35] hmm, true [09:35] that's the problem [09:35] damn [09:36] upgrading launchpad-buildd to 148; please let me know if you see new oddities with snap building on LP [09:36] (yes, I'll announce it on the forum once it's done) [09:36] pedronis, thanks, i know wheer to look then [09:37] yea, something with the rtc fixing code or the filesystem times [09:37] right and i just merged abeato's initrd changes at the start of the week [09:37] i guess something broke there [09:39] * zyga-ubuntu has fun with system [09:39] "fun" [09:39] argh ... no, even worse ... [09:39] xenail had a new initramfs-tools superseding ours in the PPA [09:39] ogra_, pedronis, that seems like systemd built date when date is seen by it as older than that [09:40] (systemd changes the date in that case) [09:40] abeato, yeah, sorry, not your fault ... [09:40] not yet probably ;) [09:40] theer were other initrd fixes that the upload to xenial-proposed did override [09:40] in initramfs-tools itself [09:40] hmm [09:41] pedronis, mvo, why is it called “snap-repair.service” and not “snapd-repair.service”? [09:41] because it repairs snaps ? [09:41] or does it repair snapd ? [09:42] snap- is what we use for units associated with a snap [09:42] PR snapd#3836 opened: httputil: more naive per go version way to recreate a default transport for tls reconfig [09:42] snapd. is what we're using for units associated with snapd itself [09:42] so it should probably snapd.repair.service [09:42] Chipaca: I don't know, that's a mvo question [09:43] mvo: #3836 [09:43] PR #3836: httputil: more naive per go version way to recreate a default transport for tls reconfig [09:43] Chipaca: the tool is called snap-repair, we could rename it I guess [09:43] but all our tools are snap- [09:44] ppisati, we have a problem ... fixrtc in the generic initrd is broken, i need to re-upload the fix and re-spin core and then we would need a no-change rebuild of the kernel snaps (for all devices without rtc battery at least) [09:45] Chipaca, mvo: we risk a clash there right? [09:45] mvo: tbh it's probably not a huge deal, we already have snap.mount.service which breaks the pattern [09:46] ah, no, because revision [09:46] mvo: and for this, snap.mount.service needs special treatment -- so i need to do the same for the other i think? maybe [09:46] Chipaca: yeah, its slightly inconsistent but we can fix it still, so maybe we should and rename it if its the only one that sticks out [09:47] ogra_: ok [09:47] missing this fix http://paste.ubuntu.com/23175211/ [09:47] (i really need to SRU this so such issues cant happen anymore :/ ) [09:48] Chipaca: I guess we go all the way and rename snap-repair to snapd-repair as well? [09:48] ogra_: i've been testing 4.13 with ubuntu core, and the serial console is completely trashed [09:49] ppisati, on what devices ? [09:49] ogra_: the funny thing is that, the same exact kernel works fine in ubuntu classic [09:49] ogra_: raspi3 [09:49] ppisati, differences in config.txt ? [09:49] ogra_: on raspi2, the boot doesn't complete, it hangs during usb bus init, again perfectly fine in ubuntu classic [09:49] (and did you copy the dtbs over to the gadget path ?) [09:49] ogra_: uhm, none i think [09:50] mvo: I don't like snapd-repair a lot for the tool, given our snap- pattern there [09:50] ogra_: i would i do that? (copy the dtb to the gadget path) [09:50] *how [09:51] pedronis, Chipaca: hm, hm, snapd-repair.service but snap-repair as the tool sounds also inconsistent to me. so maybe keep as is (snap-repair.service and snap-repair tool)? [09:51] ppisati, well, from the kernel snap /lib/firmware/.../device-tree to /boot/uboot/ (and to the overlays subdir) [09:51] mvo: snapd.snap-repair.service ? [09:51] ppisati, else you will indeed boot with a 4.4 dtb [09:51] (the old issue on the pi) [09:51] ogra_: i thought ubuntu image would pick the dtb from the kernel snap nowadays [09:52] not on the pi3 [09:52] that might explain why i only have problems with ubuntu core [09:52] mvo: should I mark my go vet fix for 2.28 ? [09:52] pedronis: please [09:52] Chipaca: that sounds ok [09:52] the pi bootloader needs the dtb in the toplevel of the vfat and we cant really load it from uboot anymore [09:53] thats why it is still shipped in the gadget unlike on all other boards [09:53] Chipaca: quick (maybe) review to please the go vet gods: #3836 [09:53] PR #3836: httputil: more naive per go version way to recreate a default transport for tls reconfig [09:54] ogra_: me checks that [10:07] hmm, i dont get it ... how did the breakage make it into the current pi2-kernel snap ... the deb only landed yesterday, the broken initrd.img only showed up in todays build of the core snap ... but the kernel snap was built 3 days ago [10:09] Hello, i have a python3 build-dependency which is not on pypi =( it's only a package in ubuntu. I've added "build-packages" stanza, but it seems to me that it is failing to import none-the-less. [10:09] https://launchpadlibrarian.net/335415335/buildlog_snap_ubuntu_xenial_amd64_xnox-subiquity_BUILDING.txt.gz [10:09] Setting up python3-distutils-extra (2.39-1) ... [10:09] are you using the python3 plugin for it ? [10:09] ImportError: No module named 'DistUtilsExtra' [10:09] ogra_, oh, i have "plugin: python" should it be "python3" ? [10:10] it think "python" has a version property [10:10] everything is calling python3 as far as I can see [10:10] let me check the docs [10:10] i think it was python3 earlier, but it's been renamed [10:11] - python-version: [10:11] (string; default: python3) [10:11] The python version to use. Valid options are: python2 and python3 [10:11] so yes i am using python3 [10:13] xnox: I don't know snapcraft well at all, but if it's python i assume the problem is that it's not being included in the snap? as there is no build phase? [10:13] or no compile in the build at least [10:14] xnox: so maybe it should be a stage-package, not a build-package? [10:15] yeah [10:15] Chipaca, no i don't need to stage distutils-extra at all. distutils-extra are helper functions to use in setup.py which build extra things (translations in my case) and is only needed during building [10:15] ah alright [10:16] xnox, if you use snapcraft cleanbuild locally, does it work ? [10:16] Chipaca, my problem is that system installed python modules (from build-packages, normal ubuntu package) are not available inside the pyenv / during the pip call [10:17] xnox: if you wait a little bit, sergiusens would be around [10:17] should, could [10:17] xnox: distutils-extra was a problem until recently at least, as per https://forum.snapcraft.io/t/week-31-of-2017-in-snapcraft/1598/3 [10:18] xnox: maybe kalikiana found how to work with it? [10:21] Chipaca: do you want me to look at the rename of snapd.snap-repair.service after lunch? or are you at it already? [10:21] mvo: I'm not on it, but I can glom it into this huge packaging pr [10:21] mvo: unless it's time-sensitive? [10:22] Chipaca: we should probably do it before 2.28 just to avoid that it hit -updates [10:22] Chipaca: I have a look after lunch [10:22] ok [10:23] mvo: changing subjects, do you remember where it was that you had an io.Reader and you needed to write it atomically? [10:24] * Chipaca is thinking about that while waiting for spread === ShalokShalom_ is now known as ShalokShalom [10:53] Chipaca: I don't remember where this was, sorry. [10:53] no probs [10:55] is there a way for me to see the contents of the just built snap somehow? [10:56] xnox: unsquashfs -ls [10:56] snap info --show-me-contents-like-dpkg-deb-c subiquity_0+git.3c5c5a5-dirty_amd64.snap [10:56] hm, ok. [10:56] xnox: or --lls [10:56] xnox, did you use cleanbuild or did you build natively ? [10:57] xnox: if you're in snapcraft, I think the 'prime' directory is the contents of the snap [10:57] the prime dir should have the conten in the latter case [10:57] *content [10:57] xnox: (and you don't need the snap to try the snap -- 'snap try' can run it, uncompressed, from the prime dir) [10:57] ogra_, i do not understand what you mean; and it sounds too many too similar terms [10:57] i did snapcraft [10:58] so i don't like how things look [10:58] xnox: snapcraft on its own does build, not cleanbuild -- cleanbuild builds it in a vm [10:58] xnox, "snapcraft cleanbuild" is the command you should use to get a build similar to what lp does (in-container, properly using xenial repos) [10:58] xnox, while just calling "snapcraft" will just use your host for all build deps etc [10:58] right..... but why is it a separate command instead of e.g. "build --vm"? [10:59] becuase there is "clean" and "build" subcommands, i assumed "cleanbuild" subcommand does the previous two in order, just an alias/shortcut [10:59] (so running "snapcraft on artful will never get you what lp builds) [10:59] not like a brand new behariouv. [10:59] .. [10:59] anyway [10:59] .. [10:59] clean and build are steps ... [10:59] clanbuild is a special type of building [10:59] *cleanbuild [10:59] my python modules are installed into /lib/python3.5 instead of /usr/lib/python3.5 i find that confusing [11:00] it's as if --prefix=/usr was not passed to setup.py [11:00] is this normal? [11:00] especially when binaries are in /usr/bin/ [11:01] * ogra_ honestly doesnt know ... i usually stay away from pythjon snaps :P ... and i guess you might have better chances to find the snapcrafters in rocketschat [11:02] i'm sure they have a ton of examples you could look at [11:02] my only python snap predates snapcraft ¯\_(ツ)_/¯ [11:02] heh [11:03] (and I think the way it does things is frowned upon :-) ) [11:03] it does result in a 1MB snap though :-D [11:03] arch: all, to boot [11:03] or was it any [11:04] * Chipaca forgets [11:04] * Chipaca goes back to work [11:05] greyback, did you use your pi on a wired network when first booting it ? seems there was actually a bug in the image where the clock is wrong on first boot and thus the snaps are not properly initialized (results in ""core" bein installed if you install the first snap) [11:05] greyback, if your system behaved like this that might cause issues with mir too [11:06] (actually with any snaps) [11:15] pstolowski: ping [11:15] davidcalle, hey! [11:16] pstolowski: hey, I'm working on examples for the hooks doc page, and I'm wondering if you have any [11:16] ogra_: hmm, not in my first tests (those were wifi only), but subsequent tests were on wired, and yes I did see an oddity with core snap update leaving things in a weird state (snapd at 100% cpu too). A reboot seemed to fix it [11:17] that just looks like it fixed it :) [11:17] pstolowski: install hook [11:17] greyback, there are images with rolled back kernel snap in my people.u.c page now ... just re-flash [11:18] pedronis: build failure in your latest Transport branch in debian-unstable and fedora that it cannot find Transport, I guess those already have go > 1.7 maybe? [11:18] ogra_: ack, will test. I didn't bring my Pi3 into my office today, so will try tonight/over weekend [11:18] ah, ok [11:19] davidcalle, not really. install and refresh are very new hooks. but i'm happy to answer any questions. [11:19] niemeyer (and anyone else interessed): i updated 3556 (the license branch) with a slightly different validator, please let me know [11:19] * mvo would love to see this merged [11:19] ogra_: sorry [11:19] davidcalle, nb, install hook is run only on fresh install of a snap [11:19] greyback, heh, what for ... thanks for making me look and finding the bug [11:20] ogra_: well immediate feedback is nice :) [11:20] :) [11:20] pstolowski: ok, so if I create a snap with an "install" hook, a simple sh executable that echoes a string. Here is what happens on snap install "error: cannot perform the following tasks: [11:20] - Run install hook of "playground" snap if present (run hook "install": cannot snap-exec: cannot find hook "install" in "playground")" [11:21] pstolowski: and I can't really make sense of the error message. [11:22] davidcalle, is 'install' actually present in meta/hooks/ ? exec bit set? [11:22] ppisati, initramfs tools fix is in the PPA ... can you re-build the pi2-kernel and dragonboard kernel snaps ? [11:23] ogra_: me kicks a build [11:24] thx [11:24] pstolowski: it doesn't install the snap at all. But it's in my "prime" dir, in meta/hooks with the exec bit set. [11:24] ppisati, did the copying of the dtbs help btw ? [11:25] mvo: is LIBEXECDIR set there for a particular reason? https://github.com/snapcore/snapd/pull/3625#discussion_r136512808 [11:25] PR #3625: many: end-to-end support for the bare base snap [11:25] pstolowski: and if I remove the install file, it installs just fine and the configure hook it ships works [11:31] zyga-ubuntu, why did you mark #3807 blocked ? the fix is in my comment [11:31] PR #3807: cmd/snap-confine,packaging: import snapd-generated policy [11:33] davidcalle, are you running current stable release? [11:33] ogra_: it's blocked for now, I want to try to make that change but would rather not do it for 2.28 (too soon, too uncertain) [11:33] (of snapd) [11:33] ogra_: after 2.28 we can do that and see what happens [11:33] ogra_: it's blocked in the terms that it cannot land yet [11:33] zyga-ubuntu, the fix has to happen in the core snap, not in snapd [11:34] zyga-ubuntu, and it is trivial ... (identical to https://github.com/snapcore/core-build/pull/17 ... i can add your path in the PR if you want) [11:34] PR core-build#17: switch /etc/systemd/system to "synced" mode [11:36] ogra_: right, I know, [11:36] pstolowski: 2.27.5+17.10 [11:36] ogra_: hmm, that's tempting [11:36] ogra_: when do you plan to land that change? [11:36] ogra_: have you tested it? [11:37] davidcalle, good. can you push or email your snap somewhere so I can give it a shot? [11:37] zyga-ubuntu, we use synced in other dirs (and switched them on the fly) so i dont expect any particular breakage ... [11:39] ogra_: in that case, when do you plan to land your PR? [11:39] ogra_: don't get me wrong, I'd love to try [11:39] as soon as it gets appoved :) [11:40] ogra_: did you test upgrades from older layout [11:40] no, thats hat edge is for ... i'd land it and test in edge [11:41] perhaps not today though ... i dont want to have to roll back on the weekend :) [11:41] zyga-ubuntu, how about we land it on monday [11:42] manually upgrading core doesnt really reflect the behaviour so i'd prefer to use the store here [11:43] We're rolling back launchpad-buildd 148 due to some unexpected networking issues with LXD [11:43] mvo: sorry, will fix, build flags are annoying this way [11:44] re, mailman [11:45] ogra_: on monday after mvo branches off 2.28 is fine [11:45] cool [11:45] i'll ping you about it then [11:45] ogra_: I mainly worry about the build logic where it would be good to be able to do 2.28.1 without this change [11:45] ogra_: thank you! [12:18] pedronis: yeah, no worries, just wanted to let you know [12:20] PR snapd#3837 opened: overlord/snapstate: remove superfluous/misleading check from All [12:21] tiny cleanup there with open question [12:23] ta [12:26] pstolowski: sorry, I was in a meeting, yes, sending you something, thanks! [12:27] lool, hey, is there a repo for flash-device or I need a debdiff to submit a patch? [12:28] abeato: I dont think there's an Ubuntu repo; the Debian repo is under d-i project at git.d.o [12:28] lool, ok, should I then submit the change to debian directly? [12:34] abeato: we typically land Ubuntu changes directly in Ubuntu and then send a patch to Debian if applicable there [12:34] lool, alright, will do that [12:34] abeato: what's your change :) [12:34] abeato: seeing version in Ubuntu is ubuntu65, it has not been rebased in a reallllly long time [12:36] pfft ... whats 64 revisions :P [12:36] ogra_: 65! [12:36] we always have ubuntu1 :) [12:36] with a delta already! [12:37] lool, adding one device to the database : http://paste.ubuntu.com/25444576/ [12:37] well, only the maintainer address :) [12:39] mvo: hi! I'm seeing this inside an lxd container (ie, my dev environment is in an lxdcontainer): http://paste.ubuntu.com/25444561/ [12:39] abeato: is it an officially supported flavor in Ubuntu? [12:39] jdstrand: hey [12:39] hey zyga-ubuntu :) [12:39] abeato: in which case, I suggest you add a Kernel-Flavor header as well [12:40] mvo: wondering if there is anything there that might ring a bell [12:40] lool, well, it is for a commercial device [12:40] abeato: if there's no kernel in Debian supporting the hardware, I suggest you only upload it to Ubuntu [12:40] jdstrand: not right now, I can check inside lxd [12:40] jdstrand: to see if I see the same [12:40] lool, I guess not supported by debian, right [12:40] abeato: Kernel-Flavor is basically an extra check to make sure the right kernel unames are allowed and you don't accidentally write a -generic kernel to your flash that wont boot [12:41] so it's a nice safety net if that works for your hardware [12:41] zyga-ubuntu: fyi, re snap-update-ns, I've got an exploratory PR that shuffles some stuff around to address much of the import issues I mentioned in snap-update-ns [12:41] jdstrand: thank you, do you want to talk about it? [12:41] jdstrand: I also added an idea to the PR, to use a remote API to talk to snapd to call update-ns [12:41] zyga-ubuntu: yes, but not right this second. let me finish the tests and send it up [12:41] jdstrand: ok [12:41] jdstrand: thanks, I'll be here, my network works now [12:42] mvo: pushed the rename there [12:42] zyga-ubuntu: oh, that is an interesting idea too [12:42] abeato: I guess it's a for a xenial based install? BTW since this is not snappy specific, we should probably be discussing this somewhere else [12:42] it would add ipc to exec... [12:42] jdstrand: it _might_ be even IPC-less but in a very convoluted way [12:43] jdstrand: but yes, IPC is the way to go [12:43] anyway, let me finish this and send it up [12:43] jdstrand: ok [12:43] pedronis: ta [12:43] mvo: thanks! [12:46] mvo, I updated the pc-kernel snap in staging using the one in prod but seems to bring many issues [12:46] mvo, I see many of this ones https://paste.ubuntu.com/25444618/ [12:47] I need to update the kernel because the lxd test needs a new kernel to work [12:47] mvo, any Idea? [12:47] cachio: hm, device session errorin https://paste.ubuntu.com/25444618/ that might be something for pedronis [12:48] cachio: whick kernel are you on? [12:48] zyga-ubuntu, 4.4.0-83 [12:49] cachio: that's look like a prod snapd trying to talk to staging [12:49] cachio: d-Jc... is a prod key [12:49] pedronis, yes [12:49] cachio: it's definitely not too old IMO [12:49] that doesn't work [12:50] pedronis, so I should build the snap spacially for staging? [12:50] cachio: yes, I think as I said that already, and you need to set the env vars [12:51] you need both [12:52] pedronis, the env vars are already set [12:52] and the tests working but I need to update the pc-kernel snap to make the lxd test pass in stagnig [12:53] well something is not using a snapd for staging or the env var are not set [12:53] that key there is a prod key [12:53] that's why staging says what [12:54] or it might be that we don't switch to staging early [12:54] enough [12:54] that's a new potential problem [12:54] with master [12:54] I ran the cron-job that already was passing for all the tests but now with the new pc-kernel that I got from prod [12:55] the kernel alone shouldn't make a difference [12:55] pedronis, that cron-job was working against staging [12:55] pedronis, I though the same, that's why I updated that [12:56] something else has changed [12:56] but after I updated it a lot of these errors appeared [12:56] how did you update it? [12:56] update it in the store? [12:56] I downloadede manually from prod and uploaded to the staging store [12:57] ok, something else is going on here [13:00] PR snapd#3838 opened: systemd: rename snap-repair.{service,timer} to snapd.snap-repair.{service,timer} [13:01] niemeyer, I'll be few minutes late [13:04] pedronis: standup? [13:04] pedronis: pingous [13:09] mvo: fyi, if I comment out that test, it gets a lot farther, but fails with: http://paste.ubuntu.com/25444693/ [13:09] mvo: SNAP_EXEC is "0" instead of "" [13:09] SNAP_REEXEC* [13:09] oh frak [13:10] I have SNAP_REXEC=0 in /etc/environment. why in the world is that there? [13:11] ok, that does not affect cmd_test.go [13:11] meh, yes it does [13:13] mvo: ok, please disregard. hopefully I didn't waste your time. I had SNAP_REEXEC=0 in /etc/environment. remove that, log out and back in and it is fine. that said, perhaps the testsuite shouldn't be affected by that... [13:13] probably because you added it when testing a snapd deb change [13:13] I don't run snapd in the container. I must have fat fingered something and accidentally added it there [13:15] jdstrand: I think each one of us ran into this since we introduced this feature [13:17] zyga-ubuntu: hehe [13:17] * jdstrand adds to ~/.bashrc: [13:17]