[00:18] Matthew-S: yes, Ubuntu package names today [00:21] okay, thanks. Another question, if that's the case, how can I go about debugging why an executable behaves differently inside the snap than it does when apt-get installing it? [00:34] Specifically, I'm trying to get `git` to work inside the snap, but it's complaining with `fatal: Unable to find remote helper for 'https'1 [01:03] Matthew-S: https://git-scm.com/docs/git-remote-helpers [01:03] looks like git doesn't know where to find those [03:07] Just reproduced this one: https://bugs.launchpad.net/snapcraft/+bug/1695882 [03:07] Bug #1695882: cleanbuild loses scripted version [04:55] morning [04:57] o; [04:57] o/ [05:03] zyga: hey [05:03] 2nd time in a row i saw google:ubuntu-core-16-64:tests/main/snap-repair fail on master, looking into it [05:05] real failure or logging issue? [05:05] looked like real failure, the test lists the timers and one it's looking for was not there [05:06] zyga: https://paste.ubuntu.com/p/8GYQR6z49D/ [05:17] mmmm [05:17] yeah [05:17] looks like it is really broken [05:22] but it doesn't reproduce :/ [05:22] good, it won't spread ;) [05:23] like all races [05:23] it's a whack-a-mole [05:25] my son stays at home today [05:25] it's so good not to have to wake him [05:26] and drag him off to school [05:26] mborzecki: can you please look at https://github.com/snapcore/snapd/pull/5281 [05:27] it's 7 lines and has +1 from jamie [05:27] PR #5281: snap: reject more layout locations [05:31] mborzecki: can I restart the PR where snap-repair failed? [05:33] which one is it? [05:33] 5282 [05:34] zyga: yeha, go ahead and restart it [05:35] wonder if it has something to do with sequence of jobs [05:36] oh [05:36] probably yes [05:37] + systemctl is-active snapd.snap-repair.timer [05:37] inactive [05:37] on unrelated branch [05:37] more of the log https://www.irccloud.com/pastebin/3hQc0OMj/ [05:41] PR snapd#5281 closed: snap: reject more layout locations [05:59] good morning mvo [06:04] zyga: good morning [06:05] zyga: 5274 should have some answers for you :) [06:05] looking :") [06:06] PR snapd#5282 closed: interfaces/raw-usb: also allow usb serial devices [06:06] mvo: approved [06:06] zyga: \o/ [06:06] for clarity about canConfigure [06:06] I recently wrote functions like this: https://github.com/snapcore/snapd/pull/5278/files#diff-4480ffd44957efa3395867c929f88014R99 [06:07] PR #5278: cmd/snap-update-ns: add IsTrustedTmpfs and tests [06:07] PR snapd#5274 closed: configstate: deny configuration of base snaps and for the "snapd" snap [06:07] and it made me think about giving a yes-or-no answer [06:07] zyga: looking, I need to do a followup anyway [06:07] and being able to say "error" as a third option [06:07] I'm not saying you need to do the same [06:07] but I just wanted to show how encoding "no" in a an error may or may not be natural, depending on context [06:07] (and my PR needs changes too, I'm on that now) [06:07] zyga: right, in this func its just two states: configuration is ok or there is some error that needs reporting [06:09] * mvo gets breakfast [06:10] mvo: hey [06:18] zyga: thanks for the extra review feedback on my PR. The SUSE failure is due to package naming (I checked the website for the most recent version, which differs from what we're running in Spread). I'm doing some tests to see why it is failing on 14.04 [06:18] jamesh: as for suse, I will open a PR to see if we can use tumbleweed [06:19] tumbleweed is a better indication of things working or not working in upcoming releases of leap so it will be very useful for testing [06:19] zyga: I was looking at OpenSUSE Leap 15 (which is newer than Leap 42.3) [06:19] yeah :-) [06:19] if you want to test on one machine, use tumbleweed [06:19] it's still close to leap and it stays current [06:25] jdstrand: just fyi, I cherry picked "interfaces/raw-usb: also allow usb serial devices" [06:25] jdstrand: I think its a really nice fix [06:28] PR snapd#5283 opened: snapstate: get rid of needsMaybeCore [06:28] suggestions on how to pass a name for parallel installation when installing with `snap install --dangerous foo.snap` ? [06:29] interesting [06:29] snap install --dangerous foo.snap --as foo_prod [06:29] --instance prod [06:30] but also foo_prod.snap [06:30] hm afaict we ignore the name of the *.snap file and only look at the contents [06:30] we should be careful in case someone builds a snap like foo-2_amd64.snap [06:31] snap install --dangerous foo.snap:foo_prod maybe? slightly unintuitive [06:31] --as sounds nice === chihchun_afk is now known as chihchun [06:33] zyga: btw. that snap-repair.timer did not reproduce when running with the same seed as travis, so maybe it's not the order of tests after all [06:33] but if we ignore the filename and use meta/snap.yaml name [06:33] then --instance feels more appropriate [06:33] --dangerous foo.snap --instance foo_bar? [06:34] I'd just say --instance prod [06:34] as we would ignore the foo_ part anyway [06:37] we do enforce single snap installation when using *.snap file, so --instance/--as might be ok [06:40] mborzecki: then the only remaining issue is that "snap install foo bar --instance ..." is perhaps confusing [06:40] and should be disallowed === pstolowski|afk is now known as pstolowski [06:57] mornings [06:58] hej pawel [06:58] hey pstolowski and mborzecki [06:59] I use ubuntu and onlyoffice. But i can not use local printers. only print2pdf is available. any suggestions? [07:01] OlofL: it _may_ be unsupported [07:05] OlofL: can you please open a terminal and run "snap interfaces | grep cups" and paste that here [07:06] :cups-control - - notepad-plus-plus:cups-control - onlyoffice-desktopeditors:cups-control [07:11] sorry, can you please paste that to pastebin.ubuntu.com [07:11] the newlines matter and I cannot see them clearly here [07:12] pedronis: thank you for your review on 5253 [07:16] zyga: https://pastebin.ubuntu.com/p/TPrkrb8JF9/ [07:16] right [07:16] thank you [07:16] this says that the snap is _not_ connected to cups-control interface [07:16] I would suggest you do [07:16] sudo snap connect onlyoffice-desktopeditors:cups-control [07:17] and restart the application [07:17] this should give it access to your printers [07:21] mborzecki: hi, I have not finished though as I wrote, I will list some of the areas I mentioned also in the topic [07:21] * pedronis breakfast [07:21] pedronis: thanks! [07:27] zyga: is google:ubuntu-core-16-64:tests/main/ubuntu-core-services known to be flaky, or is that likely to be something from my PR? [07:27] jamesh: perhaps flaky, mborzecki is investigating a failure today [07:28] zyga: okay. That's the only one failing on my PR, and I can't think of how it'd be related. [07:28] that said, changing "snap run" has the potential for unintended side effects ... [07:30] heh, ran the whole ubuntu-core test suite twice now, not reproduced :/ [07:47] zyga: it worked. Only to discover onlyoffice print options just suck. it ended up printing 1 A4 page to 6 pages! [07:47] well, little by little, there's some progress :) [07:47] meh. :P Installed libreoffice instead. CBA with all the issues [07:50] PR snapd#5284 opened: data/systemd/snapd.run-from-snap: ensure snapd tooling is available [07:51] PR snapd#5285 opened: tests/main/{snap-repair,ubuntu-core-services}: add debug information [07:52] let's see if it reproduces in this one ^^ [07:54] pedronis: do you think it would be helpful if i shove the changes that make use if instance key in snapsup into the current PR? [08:01] mborzecki: yes, it would be definitely more consistent (given that is using the original fields atm) [08:01] ok [08:15] all, please let me know if you see econnreset test failure again; the PR that adds extra debug was merged yesterday so we might see some more info [08:16] mborzecki: I added the notes I had in mind to the topic, let me know if you have questions, I'm not sure you are familiar with some of things I mention there [08:19] pedronis: thanks, well i will have questions :) [08:20] mborzecki: :), I suspect working on this is a bit of a crash course in all things snapd, I mean *all* things [08:21] pedronis: yup, but it's fun [08:39] mborzecki: then you hit a kernel bug and the fun continues on level 2 [08:48] PR snapd#5286 opened: snapstate: fix assumptions about core in setup phase2 [09:16] * zyga -> short walk [09:16] 5176 needs a second review [09:16] should be (hopefully) simple [09:22] Hi guys, I have a java program that list the Serial-port in my Ubuntu 16.4 LTS system, its working fine, listing all the serial ports in my system . Then I created the snap of the same project as per the snapcraft instruction, after install the snap in my Ubuntu 16.4 LTS system , its not list the serial ports. As per the documentation I also create custom gadget snap. But when iI install the gadget. snap it shows error,"cannot insta [09:22] Please someone help me to solve this... [09:32] back [09:32] way too hot todaty [09:32] newbee: you cannot install gadget snaps on normal systems [09:33] newbee: since you ask this question over and over I will respond clearly: you cannot make this work on a regular (laptop/desktop) system yet [09:33] newbee: you must run unconfined for now (use --devmode) [09:33] newbee: eventually it will work but the work on hot plug devices is just beginning [09:34] newbee: your snap would work on a dell edge gateway for example [09:34] newbee: where it would get serial port definitions from the gadget [09:34] newbee: because that system is a "core" system (unlike a classic system that most people run) [09:34] and as a core system it has a gadget snap pre-installed [09:38] mborzecki: https://api.travis-ci.org/v3/job/389629553/log.txt [09:38] pstolowski: ^ [09:38] econreset failed [09:38] as well as ubuntu-core-services [09:38] ty! [09:38] jackpot [09:40] very nices, DEBUG: Not retrying: &net.OpError{Op:"dial", Net:"tcp", Source:net.Addr(nil), Addr:(*net.TCPAddr)(0xc8203b8e70), Err:(*os.SyscallError)(0xc82042cb80)} [09:40] *nice [09:40] woah, syscall error [09:40] @Zyga : Ok, Thanks... [09:41] that syscall error is ... probably.. EINTR [09:41] but hard to know [09:41] is there something more that shows it? [09:42] I woudl expect the go runtime to handle EINTR [09:42] indeed [09:43] seems we need more debugging code, to extract those things [09:45] or just retry if on op error = dial, there is no harm in retrying is it? [09:53] zyga: could you please set the series to "xenial" forhttps://code.launchpad.net/~canonical-foundations/+snap/pc-i386 ? [09:53] zyga: and the same for pc-amd64 ? [09:53] zyga: and rebuild both? [09:54] mhm [09:54] hmm [09:54] * zyga looks for any edit controls [09:55] I cannot [09:55] mvo: I gave this up to foundations and no longer control it [09:55] slangasek: ^ [09:55] zyga: oh, you no longer own that - ok [09:56] sil2100, slangasek could you please set https://code.launchpad.net/~canonical-foundations/+snap/pc-i386 and (-amd64) to series "xenial" and build again? we landedhttps://github.com/snapcore/pc-i386-gadget/pull/5 and would like to update the gadget with that in the store [09:56] PR pc-i386-gadget#5: grub.cfg: allow customizing the menuentry via a new "snap_menuentry" [09:58] mvo: I'll be on it in a few! [09:59] sil2100: thank you [09:59] sil2100: but no rush, its not OMGnow priority :) [10:06] @Zyga Once again thanks.. Now I am able read the serial-port in ubuntu 16.04 LTS system using snap application. [10:06] newbee: I understand this is frustrating, I suspect you will be able to use fully confined application with serial ports on 16.04 in 2-3 months from now [10:08] a second review for 5176 would be great, that would unblock a new 2.33 upload [10:09] mvo: is the nack from gustavo fixed? [10:11] mvo: asked one wrench-in-the-gear question [10:12] mvo: or in other words, reboot your router and run the connectivity check [10:17] caution to anyone doing self-review... browser session in the tool times-out in very annoying manner, if you hit save after a long period of inactivity on the page, it logs you out and whatever you typed is lost! best to prepare it in a text editor first... [10:18] thanks pawel [10:18] I haven't done mine yet so I will use this for sure [10:39] zyga: I think the gustavo nack is resolved [10:41] zyga: and answered the question :) [10:43] mvo: ping is not a good example as it is a synchronous process doing the test [10:43] I can approve this but my gut feeling says it should be async [10:43] and AFAIK we cannot change the API later because users [10:44] zyga: maybe I'm not understanding, but what is the concern about this being sync? that the user waits for some seconds on a reply? [10:45] it can take very long to respond [10:45] zyga: for a consumer script an async interface is more work, it would be "snap debug connectivity; snap changes --last=debug; snap list etc" [10:45] and we don't do long things in a sync way [10:45] not quite, the command could poll [10:45] the UX could stay the same [10:45] (though it could get smarter as well, e.g. by reporting progress in real time) [10:46] zyga: is the concern about the server side that its sync there? [10:46] but my main gripe is with the call me and wait for unbound amount of time for a response [10:46] yes [10:46] this feels the same like install [10:46] and I fear that changing it later would suck [10:46] (for complexity) [10:46] zyga: don't we run this inside a goroutine? the request handling? and we unlock the state while doing this [10:47] perhaps but the client may just time out waiting [10:47] perhaps pedronis should decide [10:47] as I said, if you feel strongly about it I can approve [10:48] the code looks okay otherwise [10:48] zyga: its fine, I am just trying to understand the concern [10:49] zyga: a bit of a shame that chipaca is not around today, he knows this probably best [10:53] zyga: I just checked the code, we don't do a timeout in the client for sync methods. and I added a 30s delay (just to test things) and snapd is fine, both responsive and no observable issue on the client side [10:54] zyga: but maybe pedronis has an opinion about whether "debug connectivity" should be a sync or async reply - just to ensure that we carefully looked at this [10:54] zyga: or we can talk during the standup. thanks for your review in any case :) [11:09] pedronis: is it intentional that when store.SnapAction.Action == "refres" the Name field is not used? [11:09] mborzecki: yes [11:10] refreshes are purely instance-key and snap-id based [11:12] pedronis: is it ok if i pass name nonetheless? i need to construct unique instance keys, snap-id is the same, so appending name would give me the unique part [11:12] mborzecki: pass where? [11:12] down to store.SnapAction() [11:12] mborzecki: as I wrote we have two options with the store interface [11:12] either we make all the store apis take instance names [11:13] or we tweak SnapAction to take instance keys explicitly [11:13] and deal with things one level up [11:13] i'm tweaking SnapAction :) [11:14] mborzecki: I think tweaking SnapAction is less magic so probably easier, but both are ok, as long as we consistent [11:14] mborzecki: but as I said if you tweak SnapAction is not a matter of passing name [11:14] pedronis: so basically suggesting is to extend store.CurrentSnap with InstanceKey explicitly? [11:14] mborzecki: yes [11:14] and action too [11:14] pedronis: right [11:15] mborzecki: if we start passing down instance keys, we need to do the same with the info stuff [11:15] but I can see pros and cons for both [11:15] you need to see a bit [11:16] mborzecki: btw probably a good time to kill a couple of left overs apis that are not used [11:16] pedronis: i'm doing the changes right now, so we'll see in a bit whether this feels ok or not [11:17] pedronis: which ones? [11:17] ListRefresh and LookupRefresh [11:17] they should be unused now [11:17] (SnapAction took over) === chihchun is now known as chihchun_afk [11:18] pedronis: ok, let me note that down and i'll look into it [11:18] mborzecki: probably best done on its own branch, but especially if you decide to pass in instance names [11:18] then you don't want to have to fix those [11:19] ack [11:21] mborzecki: to be clear they are still there because the switch to SnapAction happened late in 2.32, and there was a chance to have to revert it, also it would have a lot more late churn to remove them [11:21] mborzecki: but 2.33/2.34 is a good time to remove them, now that we known happy with SnapAction [11:22] ok [11:23] i'm off for a while, bbl, will miss the standup today, see the note in the forum === pstolowski is now known as pstolowski|lunch [11:39] mvo: Heya [11:40] mvo: Haven't seen the updated PR, but as a minor, if you implemented a restricted language, I suggest just sticking to the field names we use in the API [11:40] mvo: So we have a single set of those to keep promises on [11:43] PR snapd#5287 opened: testutil: syscall sequence checker [11:44] mvo: thanks! I wasn't sure if it could make it into 2.33 :) [11:47] jdstrand: hey, could you please look at https://github.com/snapcore/snapd/pull/5278 [11:47] this would unblock the next chunk [11:47] PR #5278: cmd/snap-update-ns: add IsTrustedTmpfs and tests [11:47] one new function with tests and docs [11:48] jdstrand: also (though not security sensitive so no need to use your time) 5287 will aid in writing tests [11:49] but it's Friday so .. maybe :) [11:51] * cachio afk [11:56] zyga: I started looking at 5278 yesterday and I was trying to imagine who the consumers of the API will be [11:57] this is the trespassing issue again [11:57] with a richer fix that works in containers [11:57] zyga: I guess I'm slightly uncomfortable with the word 'trusted' [11:57] the rule is that we allow writing to read-only filesystems (mounted ro or squashfs) [11:57] and the tmpfs'es that we have mounted ourselves [11:57] and since none of the tmpfses that we mount are visible outside, we trust that they don't show up in the host [11:58] IsSnapdCreatedTmpfs? [11:58] I can rename it, sure no [11:58] *no problem [11:58] isSnapdCreatedPrivateTmpfs? [11:58] even better [11:58] let's see how many words we can cram into the variable :P [11:59] any, but they must fit in 8 characters ;) [11:59] ShouldWriteToTmpfs? [11:59] iscpt() [11:59] is cape town? [11:59] hee [11:59] haha [12:00] anyhoo, I'll trust you on a rename. trusted is perhaps unsurprisingly a loaded word for me [12:00] understood :) [12:01] I'll add 5287 too [12:01] :w [12:08] afaik so far we use it only in the contest of assertions for the root keys/accounts === chihchun_afk is now known as chihchun [12:26] woah [12:26] a fire extinguisher just exploded downstairs [12:27] PR snapd#5288 opened: tests: econnreset/retry tweaks [12:27] zyga: woah, i thought it was only possible in duke nukem when you shot them ;) [12:27] we are just as surprised [12:28] jdstrand: heh, today is the day for final tweaks for 2.33, this one was just too nice to pass up [12:31] mvo: aha, so should I be expecting some test results soon then? === pstolowski|lunch is now known as pstolowski [12:32] pedronis: do you happen to have an opinion about the sync/async reply (zyga question in 5176). I would love to do something about this one as its the last piece misisng for 2.33 [12:32] cwayne: yeah, hopefully a new beta later today, one open PR though that has some discussion right now :) [12:32] mvo: thanks for the review! i wonder if it would be better to log %#v instead of "Retrying because of: %s" for all retried errors [12:32] cwayne: but I hope it can go all the way from beta->candidate today (if not Monday is fine as well) [12:33] mvo: we don't have set a timeout on daemon response right? given that is a debug command I think sync is fine, unless it would break, we are not keeping the lock [12:33] pedronis: yeah, no timeout for sync responses. great, I think we are in agreement. [12:33] zyga: ^- thanks again for raising/discussing this! if the PR is otherwise ok I would love to move forward with it [12:34] mvo: +1 then [12:34] mvo: sounds good, I'll make sure we're on the lookout for results [12:36] zyga: ta [12:36] cwayne: ta to you as well :) [12:41] PR snapd#5176 closed: many: add `snap connectivity-check` command [12:49] uh [12:49] the dust is so irrating [12:49] the air filter has gone crazy [12:49] 269 PM2.5 [12:49] like in the suburbs in the winter ;) [13:01] Hey there [13:02] Stopped for a cuppa [13:02] cachio: How's Travis? [13:02] mvo: All good on the front of the format thing? Not sure if you saw the earlier note [13:03] Happy standup :) [13:22] PR snapd#5289 opened: cmd/snap-update-ns: fix a leaking file descriptor in MkSymlink [13:24] jdstrand: ^ trivial leak fix [13:24] PR snapd#5290 opened: packaging: use official bolt in the errtracker [13:26] jdstrand: also interesting that unit tests that mock the system call level help to find issues like that [13:29] mvo: the PR I talked about when we started the standup - #5215 [13:29] PR #5215: ifacestate: improved conflict and error handling when creating autoconnect tasks === chihchun is now known as chihchun_afk [13:42] mvo, about the symliinks test [13:42] it is needed a fix for that yet [13:43] could you reproduce it? [13:46] cachio: I couldn't but let me try again. what was the link to your script again ? the one you use to build the image? [13:46] cachio: I will try to reproduce in a clean VM this time [13:47] cachio: to ensure no contamination :) [13:54] mvo, https://github.com/sergiocazzolato/validator/blob/master/create.sh [13:54] cachio: ta [13:55] mvo: kicked the builds now (sorry for the wait!) [13:55] * zyga goes out until the dust is filtered/vented [13:56] mvo: I'm always available on telegram/irc and I can return earlier if needed [13:56] zyga: thanks, should be fine. see you [13:57] cachio: channel is beta, right? [13:57] more errors with snap-repair [13:57] https://api.travis-ci.org/v3/job/389723922/log.txt [13:57] mvo, yes [13:58] cachio: ok, on it (in a fresh vm) [13:59] mvo, great, thanks [14:02] cachio: I tried in a clean vm, installed ubuntu-image using apt, installed snap via snap install --beta core and the created image has symlinks [14:02] huh, store authorization failure for the pc-* snaps [14:03] token needs refresh most likely [14:03] there is a LP UI for that [14:03] Doing that, was surprised as I didn't see that before [14:03] Maybe I'm not using LP to build snaps enough [14:03] yeah, happens very rarely (but happens) [14:04] mvo, I don't do that [14:04] mvo, I create the beta image with this script [14:04] the I create a vm with this image [14:04] then I login and I dont see the symlinks [14:05] kvm -snapshot -smp 2 -m 2000 -redir tcp:8022::22 -nographic -serial mon:stdio [14:05] cachio: if you run "which ubuntu-image" - what do you get? [14:05] I create the vm with this command [14:06] this /usr/bin/ubuntu-image [14:06] cachio: ok, this looks fine. and snap version? [14:06] cachio: how big is the image file? ls -lh for the amd64 image? [14:07] mvo, 3,0G may 29 14:49 pc.img [14:08] sil2100: there's (unfortunately, out of LP's control) a hard one-year expiry on store macaroons [14:08] sil2100: so that can make you have to reauth even if you use it frequently [14:09]