[00:18] Does snap confinement affect dlopen() calls at all? My library is not getting found despite being in the LD_LIBRARY_PATH directory [00:22] mcphail: is it in the snap's squashfs? [00:25] nacc: yes. Also trying using "snap try" in uncompressed filesystem [00:30] code as per http://paste.ubuntu.com/23209466/ with the libglide2x.so file within the same directory with all the other libs, as per the LD_LIBRARY_PATH variable. Works OK when I set the same variable but run outside snap confinement [00:48] PR snapcraft#815 closed: Replacing deprecated API for searching snaps [00:48] PR snapcraft#817 closed: lxd: use built-in image streams [01:00] PR snapcraft#814 closed: Make source-depth a parameter and opt-in [01:02] "snapcraft keys" reports that my default key is not enabled. I've somehow managed to botch registering it by attempting to register multiple keys. Is there a UI or API I can use to de-register or replace keys registered with the store? [01:08] zyga: uploaded the thing [01:08] mdye: Unfortunately not yet, though registering multiple keys should work fine. [01:10] mdye: 2am here, so maybe send mail to the snapcraft list if you can't disentangle it? [01:12] cjwatson: alright; I've tried this "snapcraft -d register-key" after generating a new default key and snapcraft failed to register: snapcraft.storeapi.errors.StoreKeyRegistrationError: Key registration failed: Failed to save account-key-request assertion for account_id JmtGtPclFB8St7FNhFmDZ3ijMqEQIbl8: Unexpected response while processing assertion: {"detail":"could not add assertion (revision 0 is already the current [01:12] revision)","error_list":[{"code":"invalid-revision","message":"invalid revision: could not add assertion (revision 0 is already the current revision)"}],"status":409,"title":"invalid revision","type":"assertions:v1:invalid-revision"} [01:12] happy to post to the list if that seems like the right place to ask given the time [01:14] Wow that's an ugly error. Suggests it's already registered, though. [01:15] right, 409 conflict; I assumed b/c of the name? (default), not b/c of the GPG key's ID [01:15] Unless it doesn't like it being called default. [01:15] right [01:16] You could always call it something else. [01:16] so can I generate my own key (instead of using snapcraft for it), register that, then still use the snap tools to sign with it? [01:17] You can just use "snap create-key some-other-name", "snapcraft register-key some-other-name". [01:17] (from memory) [01:17] great, thx [01:18] and thx for the tools, guys. (zyga, others) [01:18] We'll have revocation soonish, but still needs some design work (outside of emergency handling) [03:43] PR snapd#1953 opened: Pass through screenshots from snap store === fginther is now known as fginther|away === fginther|away is now known as fginther [04:31] mwhudson: o/ [04:31] mwhudson: thank you, I will work on getting it verified [04:52] Hi [04:53] I'm wondering if a snap package is a good fit for a problem I'm trying to solve... the problem is, I have a bunch of older PHP (Drupal sites) to manage, and a CLI tool to manage them (drush), but this is not happy on Ubuntu 16.04 [04:53] I run the actual sites in Docker containers, with an older version of PHP bundled in that Drupal 6 can handle -- these sites have way too many deprecated function calls that have been removed in PHP 7, which is in 16.04 [04:54] that all works great, but when I go use the shell tools, running those under php 7 fails completely. I know I can bundle my shell tools in single-run Docker containers, but I was wondering if a snap package might be a good alternative [04:55] can you easily bundle older (or newer) versions of things like PHP (or gtk bindings, for another problem I'm trying to solve) in a snap package? === cpaelzer_ is now known as cpaelzer [05:42] zyga: well you need to get an SRU team member to release it first :) [05:56] PR snapd#1954 opened: Add store.requestOptions.ExtraHeaders so that individual requests can customise headers [06:05] mwhudson: hmm? I don't fully recall the process but AFAIK it gets into proposed and then is verified to be pushed to updates [06:45] good morning [06:47] good morning dholbach [06:47] salut didrocks [07:13] Does snap confinement affect dlopen() calls at all? My library is not getting found despite being in the LD_LIBRARY_PATH directory [07:24] zyga, is https://github.com/ubuntu/snappy-playpen/pull/205 something you wanted to take a look at or validate? it looks like Cemil pinged you as well. [07:24] PR ubuntu/snappy-playpen#205: Mesa demos [07:24] dholbach: looking [07:26] cool, thanks [07:28] PR snapd#1955 opened: docs: fix formating of HACKING.md "Testing snapd" [07:30] I am getting error: cannot find signatures with metadata for snap while installing any snap package build on my system, System Information: Snapcraft Version: 2.17, Ubuntu 16.0.1. Even Demo Snap are also not working. Any help with how to resolve this issue. [07:31] subh94: can you please try "sudo snap install --dangerous snap-file.snap" ? [07:31] subh94: you now need to pass the --force-dangerous flag [07:33] zyga: it doesn't get into proposed immediately, it sits here first: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= [07:33] PR snapd#1244 closed: snap: show snapname before the progress download [07:37] what is the status of support on fedora? [07:43] zyga, I think it's good to go from a playpen perspective [07:54] techtonik: zyga wil know the details but AFAIK its available in the fedora devel series [08:35] PR snapd#1956 opened: many: show snap name before the download progress bar [08:45] hey didrocks :) have a minute? [08:46] fgimenez: I can make a minute :-) [08:46] didrocks, great :) i'm trying to write a test for the gsettings interface, this is what i have so far https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1 [08:47] I get the following app armor problem when running an updated version of the nodered snap. Did not have this with the version that did not have nodes installed. What is this? Sep 21 07:56:24 ubuntu ubuntu-core-launcher[17194]: STARTING NODE-RED - /snap/nodered/x1/bin/node-red /snap/nodered/x1/settings.js /root/snap/nodered/x1 [08:47] Sep 21 07:56:25 ubuntu kernel: [56451.987557] audit: type=1400 audit(1474444585.481:4450): apparmor="DENIED" operation="open" profile="snap.nodered.red" name="/run/resolvconf/resolv.conf" pid=17199 comm="node" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [08:47] didrocks, the idea is to install a test snap declaring a plug on gsettings, try to read/write a value with the plug connected and do the same with the plug disconnected, checking the error in that case [08:48] fgimenez: ok, making sense [08:48] I see that you are aware you need the home interface to be able to read the changed value [08:48] didrocks, so far no luck however, i'm not sure if the test snap is properly defined, could you please take a look? [08:48] (otherwise, you only get defaults) [08:48] oh? I quickly browsed, and it seems ok… [08:49] what doesn't work? [08:50] you don't need the export in set/get if you are using the desktop-launcher normally [08:50] didrocks, i'm getting this in the read operation http://paste.ubuntu.com/23210600/, this value seems to come from inside the snap because outside the value of that key is different [08:50] didrocks, ah ok thanks good to know [08:51] didrocks, what is worst is that the get operation works with the plug disconnected [08:51] fgimenez: yeah, it's using the default [08:52] ok, let me try to build the snap [08:52] didrocks, ok thanks a lot [09:04] mvo: hi, do you have any suggestions for how i might validate a snap.yaml file for a gadget snap? [09:04] mvo, what happened to your pastebinit snap, would be really helpful to have it on images again [09:04] joc_, you coudl show it to someone how knows them ;) (like me) [09:05] ogra_: ha, the manual approach [09:07] fgimenez: same with glib-compile-schemas, you don't need them, the launcher does it for you on first run [09:10] didrocks, ok thanks, i was getting "No schemas found" without it, maybe the exports were meesing things up [09:12] joc_, in general the snap.yaml is pretty empty nowadays http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/meta/snap.yaml [09:12] all valuable info moved to the gadget.yaml [09:13] ogra_: yeah this is really a slots issue i think, but it is tricky to validate the yaml if the slots are for interfaces that are Core or Gadget snap only [09:13] fgimenez: you are missing dconf-gsettings-backend stage package [09:13] oh, yeah [09:13] fgimenez: I didn't add it by default as I'm unsure about adding it in the glib-only profile, then some people like ogra tells the launcher is pulling too many dependencies :) [09:14] and glib-only is really minimal for that purpose [09:14] the rest is ok [09:14] didrocks, i didnt say that since agess :P [09:14] ahah, you told it enough for a whole year at least! :) [09:14] didrocks, ah ok, let me try that [09:15] well, i still think it is overkill in cases where i only want font support to pull in a whole toolkit :) [09:16] glib isn't a toolkit [09:16] well or a library stack ... whatever [09:21] Chipaca, hey [09:21] you pung ? [09:22] ogra_: on the subject of gadget yaml, if you wanted to add some "content:" to the generic pc gadget (all snaps image) and you wanted the target to be a file under /etc that should be visiable when everything is mounted, how would you modify the gadget.yaml file to do that? [09:23] joc_, i fear you cant ... the gadget will copy everything under /boot/$bootloader/ currently (thats a bug i think) [09:23] iirc mvo wanted to bring that up with niemeyer (omeone else had that prob too iirc) [09:23] +s [09:24] ogra_: it might have been woodrow, i was trying to help workout how to get a watchdog config file in to place [09:24] sounds like content in the gadget yaml won't be able to do that [09:24] joc_, well, on that one i have to defer to mvo [09:25] right, but it shoudl [09:25] ack [09:25] but that means "snap prepare-image" (which ubuntu-image calls) needs to support this [09:28] yeah understood, i was wondering if we needed to add some explicit spec of the writable partition to the gadget.yaml and try copying in to there [09:28] assume the tools dont support that though [09:29] not sure if you could try a relative path ... like "target: ../../writable/system-data/etc/foobar.conf" [09:30] PR snapd#1957 opened: many: add support for installing/removing multiple snaps [09:30] but i guess snap prepare-image will reject that ... [09:33] didrocks, ok, i've pushed the fixes to the test snap https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1, rebuilt and reinstalled, but something seems to be missing yet http://paste.ubuntu.com/23210700/ [09:36] ogra_, hey, i pung [09:36] so you did :) [09:36] ogra_, just idle thoughts to poke at the python slowness on bbb [09:36] replace it with a small shell script ? [09:36] :P [09:39] fgimenez: /home/fgimenez/.last_revision -> did you install your snap properly? It seems you are setting $HOME to real user home [09:39] you shouldn't export any variable [09:39] or compile schemas [09:40] ogra_, yeah :-) no wait it was actually trying to see if running it with -SI made it faster, and having you run it with -vv to see if it was imports slowing it down [09:40] Does anyone know if dlopen() calls get changed or intercepted within snap confinement? I'm trying to work out why a library under LD_LIBRARY_PATH isn't being found [09:41] Chipaca, ah ... well, the binary and startup scripts are inside the squashfs ... that's some work to set up ... but good idea ... perhaps mwhudson could add it to the package for a while (and drop it before next beta) [09:41] didrocks, i think so, no more export nor compile schemas, the source is at https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1, after "snapcraft clean && snapcraft" i install it with "sudo snap install --dangerous ./test-snapd-gsettings-consumer_1.0_amd64.snap" [09:42] fgimenez: ~/.last_revision, is what the launcher is using [09:43] fgimenez: snap run --shell test-snapd-gsettings-consumer.get [09:43] $ echo $HOME [09:43] /home/didrocks [09:43] -> it seems that $HOME isn't set to SNAP_USER_DATA anymore? [09:44] fgimenez: zyga: do you know about this? ^ [09:44] ogra_, wrt -vv, is there a better way to timestamp stderr than, from bash, 2> >(while read l; do printf "%s %s\n" "$(date -uIns)" "$l"; done) ? [09:44] ogra_, you could run it by hand once the system is booted and lets you log in, surely? [09:46] not sure ... i know it falls over when a user exists .. but only later ... [09:46] ogra_, answering myself wrt better way: yes, redirect the while loop to /tmp/stderr makes things a lot better [09:47] i.e, python3 -vv /path/to/thing 2> >(while read l; do printf "%s %s\n" "$(date -uIns)" "$l"; done > /tmp/stderr) [09:47] tadaa, timestamped import log [09:48] we have a timestamped log ... but that only starts writing stuff once the app started ... we need omething in the systemd that writes a start timestamp [09:48] *in the systemd unit [09:48] * ogra_ hass to dig into the setup of the subiquity package ... i think there is a wrapper script somewhere that replaces getty [09:50] didrocks: i noticed that $HOME change too, i was confused as to why our checkbox snap was storing .config/.cache folders outside of snap folder suddenly [09:50] yeah, it's weird… I think that's known thanks to our testsuite? :) [09:51] PR snapd#1958 opened: snap: remove extra newline after progress is done [09:55] joc_: yeah, what ogra_ said, its not possible to populate anything outside of the boot partition currently with gadget.yaml [09:56] joc_: if that is something we need it should be raised with niemeyer (just for context for niemeyer, the question is if gadget.yaml could support content outside of the boot partition, e.g. to setup bits in /etc) === jamespag` is now known as jamespage [10:20] ogra_: re keymap> if the keyboard-configuration package is enough that only adds ~600kb or so to the image (unless there is more missing but it looks ok from a quick glance) [10:20] mvo, yeah, if thats enough, then i'm fine ... as long as it doesnt pull in megabytes of font encodings and whatnot [10:22] ogra_: worth a shoot IMO, if its more than that we can pull it out again [10:28] mvo: thanks for the summary [10:29] ogra_: so how am I supposed to add keyboard-configuration now? via the system-image seed ? [10:30] ogra_: IOW via bzr ? [10:30] mvo, we will definitely need to be able to add files ... i.e. some USB NICs (like the onboard one on the beaglebone) require sysctl files that are board specific to make the NIC work right [10:30] mvo, just grab the ubuntu-core-meta packagefrom the PPA [10:30] then add it to the different system-image-$arch files [10:31] ogra_: oh, manually? ok [10:31] mvo, yeah, no way to edit the seed [10:31] ogra_: I'm not sure that is really progress if I need to add that now N times instead of a single time [10:34] ogra_: anyway, uploaded, lets see how bad the resulting size increase is and we can revert if it is too terrible === hikiko is now known as hikiko|ln [10:35] well, it is the only way [10:35] mvo, we could perhaps do an out-of-distro seed to centralize it and keep it editable, but i dont know if germinate would like that, thats a cjwatson question [10:36] I don't know what an "out-of-distro seed" would be [10:37] some random bzr branch under snappy-dev [10:37] our seed currently lives inside the official ubuntu one [10:38] as "system-image" [10:40] You can run germinate (specifically in this case germinate-update-metapackage) from whatever input you like; it doesn't care [10:40] ogra_: well, its fine for a one-off edit, but when I need to touch this next I will write some script and a system-image.common thing that includes all the common things so that I only need to touch a single file [10:40] (or do something else, but not edit N files again :) [10:41] well, i'm happy with anything you do, just tell me about it :) [10:41] ogra_: heh :) nothing for now until I touch this next time [10:41] * ogra_ is kind of used to doing it that way, we do it on the phone since years [10:42] mvo, but perhaps moving to a separate seed file makes more sense ... [10:46] PR snapd#1959 opened: many: use unique plug/slot names in tests [10:51] Chipaca, so using -SI makes it fall over with imports ... i guess i need to do a bit more here [10:57] Chipaca, btw, running 'time python -v -c ""' (i.e. just firing up the interpreter) already takes 2sec [11:06] ogra_, that's python2, not python3 [11:07] err, sorry ... wrong paste ... i actually called python3 [11:07] ogra_, what does 'time python3 -v -c ""' say, and what does 'time python3 -IS -v -c ""' say [11:07] https://bugs.launchpad.net/snappy/+bug/1625698/comments/5 [11:07] Bug #1625698: console-conf on beaglebone takes unbearable long [11:08] ogra_, also, the -v there is skewing your metric [11:08] Chipaca, -IS cuts it by half [11:08] ogra_, :-) [11:08] but if i add it to the shebang in the script it doesnt find any of its imports [11:08] so i guess there is more needed [11:10] also ... i'm not sure thiss will help at all,. given the CPU alone is saturated for a min or two still ... working on bg processes while the script tries to start [11:12] we can surely catch some low hanging fruits here when poking at it on the idle board ... but i guess the boot context will still make it super slow ... we only have one core and that is under high load when it runs in its real context [11:13] (after ten years of battling with python on arm32 i'm rather pessimistic) [11:15] * mwhudson hands ogra_ a nickel [11:15] buy another core! [11:16] lend me your soldering iron too ! [11:16] (and some pliers) [11:17] heh [11:18] ogra_: i guess if you boot the bbb and let it sit there for 10 minutes before hitting enter, it all happens much more smoothly? [11:18] i'll have to try, but i bet so too :) [11:18] seems like it really is down to the single core [11:18] hum [11:18] * mwhudson goes to bed rather than trying to be useful [11:18] should we just add a "sleep 6000" ? [11:19] :) [11:20] mwhudson, we had similar probs with the old snappy that was written in python ... insstalling a nap with it on the bbb took minutes ... [11:20] *a snap [11:20] it went down to seconds with the initial switch to the go binary [11:21] ogra_: well maybe we'll do that here, i'm not signing up to get it done by GA though! [11:21] yeah, i know :) [11:21] ogra_: also snap create-user takes 15 mins and that's written in go [11:22] true [11:22] but thats also generating keys, no ? [11:22] er no, misread [11:22] several minutes, let's say [11:22] yes [11:22] ogra_: no, it's just making an api request and calling adduser & friends [11:23] the log is a bit tricky regarding the timetamps because it get a new ntp time in the middle [11:23] oh, i thought it also put a public key in place [11:23] for the store [11:23] also the timestamps are at minute resolution ffs [11:24] ogra_: no, it puts stuff in ~/.ssh/authorized_keys but it's not generating anything [11:24] ah, k [11:24] unless that's changed since i last looked but i don't think it has [11:30] zyga: ping [11:30] mectors: you need to 'plugs: [ network ]' in your 'red' command [11:30] mvo, joc_: That sounds slightly strange, but it'd be good to clarify what these bits are to be sure.. [11:31] jdstrand, I have the following: red: [11:31] daemon: simple [11:31] command: bin/launch [11:31] plugs: [11:31] - network-bind [11:31] - network [11:31] - network-observe [11:31] - bluez [11:31] - bluetooth-control [11:31] - pulseaudio [11:31] niemeyer, typically files in /etc/sysctl.d (we discussed them at the sprint even iirc), additional ystemd job files etc [11:31] In general, we don't want images to diverge in what they contain based on arbitrary bits inserted into the filesystem out-of-band [11:32] jdstrand, https://github.com/mectors/nodered.snap === hikiko|ln is now known as hikiko [11:32] ogra_: Yeah, that sounds like content that should go through official means, inside a snap [11:32] niemeyer, i wanted to put them into the kernel snap and you said they should rathetr be a gadget thing [11:32] especially the sysctl bits are very board specifc [11:33] mectors: does 'snap interfaces' show it as connected? [11:33] i.e. USB NICs might need per board cache sizes you can manage via a sysctl value [11:33] (and awfully enough the majority of arm boards uses builtin USB NICs) [11:34] jdstrand no [11:34] ogra_: This might be handled as configuration, which the gadget snap can ship as a default system configuration [11:34] ogra_: handled as kernel configuration, that is [11:34] niemeyer, right, i think that were your words at the sprint too ;) [11:34] or core configuration, actually [11:34] mectors: ok, so that is your problem. however, I don't know why it wasn't autoconnected, cause it should have been. curious, did you install this via a gadget snap? [11:35] ogra_: Ah, I'm glad there's agreement between me and myself.. sometimes that's not the case [11:35] you cant handle that in the kernel if the NIC needs different values per board and you dont want tio maintain a kernel for each board [11:35] jdstran, no via snap install --force-dangerous [11:35] i.e. not via a compile time config [11:35] jdstrand, no via snap install --force-dangerous [11:36] our generic kernel supports something like 20 boards currently ... i'D like us to have gadgets in the store for them in the long term ... using the same kernel snap [11:36] mectors: I suggest filing a bug. give 'snap list' output, the snapcraft.yaml you used and how you installed it, show snap interfaces output and that you expected it to be autoconnected [11:36] but for that runtime tweaking needs to be possible [11:37] niemeyer, where would that core config live ? not in the gadget snap ? [11:37] ogra_: We can if it's a kernel _config_.. but I think core is better nevertheless [11:38] ogra_: The configuration option/setting/handling would live in the core [11:38] but we dont have that today [11:38] ogra_: The gadget will have the ability to ship default configurations for all snaps in the system [11:38] ah, k [11:38] ogra_: Not today, no.. we're working on it [11:38] well, that doent sound like GA though [11:38] is that on the plan ? [11:38] (for GA) [11:39] ogra_: Yes, I hope it is [11:39] ogra_: (ready by then..) [11:39] ogra_: With some luck, in the next two weeks [11:39] especially that watchdog thing is a requirement i think ... we just talked these guys into using systemd watchdog and dropped the universe watchdog package ... [11:39] mectors: and indicate if snap connect nodered:network ubuntu-core:network works around the issue [11:40] ok, then we're fine i guess [11:40] We're _hopefully_ fine ;) [11:40] heh [11:40] niemeyer, mvo, another thing iss the GL stuff ... we need to discuss where that lives and how we handle it in regard to the arm boards [11:41] i imagine the libs should go into the kernel snap ... but we dont support that today [11:41] (and some bind mount love to put them into ,... what was it ? /usr/lib/gl ? ) [11:43] (for later (regarding ubuntu-pd) i guess we also need to ship the android container inside the kernel snap and put the right bits in the right places) [11:43] (not sure what the exact plans are for that one) [11:44] but i guess the latter bit is something we can talk about at the sprint ... not that urgent [11:56] PR snapd#1959 closed: many: use unique plug/slot names in tests [12:03] PR snapcraft#818 opened: Fix trunk [12:13] zyga: ping [12:14] PR snapd#1951 closed: interfaces/builtin: improve testability and add regression test for LP: #1625291 [12:23] PR snapd#1954 closed: store : add requestOptions.ExtraHeaders so that individual requests can customise headers [12:30] PR snapd#1960 opened: revert 'allow mmaping pulseaudio buffers' [12:31] zyga: fyi ^ [12:31] zyga: oh, you are fast :) [12:34] PR snapd#1961 opened: many: avoid snap.InfoFromSnapYaml in tests [12:47] trying to install dekko from the store... [12:47] sudo snap install dekko.dekkoproject --channel=edge [12:47] error: cannot install "dekko.dekkoproject": snap not found [12:48] any idea what's going on there? [12:48] it's published, in the edge channel [12:49] Bug #1626082 opened: Fedora 24 install fail with snapd 2.14 [12:49] PR snapd#1955 closed: docs: fix formating of HACKING.md "Testing snapd" [12:58] popey maybe snap install dekko --edge [12:58] popey . is a store artifact [12:58] error: cannot install "dekko": snap not found [12:59] popey do you have the link to the store for the snap? [12:59] snap install --devmode --edge dekko just worked for me. [12:59] https://myapps.developer.ubuntu.com/dev/click-apps/5980/review/rev/5/ [12:59] wat [12:59] that works here too === petevg_afk is now known as petevg [13:00] i can haz dekko [13:00] \o/ [13:01] popey oh right, if it requires devmode it needs to be stated [13:13] There is a dekko snap? Nice. I can stop fixing my build errors in my snapcraft.yaml then :-P [13:14] Tho I'd be curious how you got oxide working [13:14] PR snapd#1962 opened: interfaces: drop ErrUnknownSecurity [13:17] kalikiana, I just disabled oxide's sandboxing `export OXIDE_NO_SANDBOX=1`. Not ideal but at least there is still some protection from snap confinement [13:17] Oh, good find [13:19] pcoca: hi! do you have a moment to work through bug #1613572 ? [13:19] Bug #1613572: sandbox denials for snaps on BTLE device [13:20] PR snapd#1960 closed: revert 'allow mmaping pulseaudio buffers' [13:21] jdstrand, OTP. Is OK to talk in 40 min? [13:22] PR snapd#1958 closed: snap: remove extra newline after progress is done [13:22] dholbach: (replying from yesterday) corebird snapped by github.com/diddledan/corebird-snap in devmode launches but cannot open browser windows to login to twitter with error: Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files [13:23] diddledan, that's probably https://bugs.launchpad.net/snappy/+bug/1580740 [13:23] Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link

[13:25] dholbach: ok, I'll test the proposed snapd to see if that fixes it [13:26] *cross fingers* [13:32] ok, it still fails after installing snapd. I am going to reboot to ensure the state is updated fully. [13:33] right, it still fails after a reboot. shall I mark the verification-failed tag on the bug or just comment with my attempt? [13:36] diddledan, yeah, best to just comment - let me see who to ping about this [13:37] attente, ^ here's probably a test-case for bug 1580740 [13:37] Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link

[13:39] thanks dholbach [13:39] anytime [13:39] I love our community :-) [13:39] * diddledan cuddles "the community" [13:39] haha :-) [13:39] * dholbach hugs diddledan back :) [13:39] \o/ [13:42]