[02:18] When i run "snapcraft", it runs on one processor. How do I let it run on multiple processes? [02:18] PR snapcraft#2140 closed: lp 1768233 workaround for plainbox_provider plugin [02:40] PR snapcraft#2142 opened: Release changelog for 2.42.1 === epod is now known as luk3yx === chihchun_afk is now known as chihchun [03:07] is there a list of accepted architectures snapcraft build?s === chihchun is now known as chihchun_afk [03:56] What are the differences between a snap revision and a snap version? [05:02] morning [05:52] PR snapd#5173 closed: snap: some doc comments fixes and additions === chihchun_afk is now known as chihchun [05:58] mvo: #5075 is simple an can be landed now, niemeyer requested changes before, but those have been addressed, can you do a review? [05:59] PR #5075: snap/env: fix env duplication logic [06:15] mborzecki: yes, will do in a little bit [06:15] https://github.com/ubuntu/snapcraft-desktop-helpers/issues/117 I have found the commit that causes the regression [06:16] dunno how to fix though... [06:32] How can I build a snap package that runs executable jar? [06:33] gohan: Packs an Java runtime into it? [06:36] @Lin-Buo-Ren how to do it can you please guide us to do that? [06:37] @lLin-Buo-Ren if there is any example for that please share us. [06:42] gohan: I don't know any Java snaps as of now [06:45] @Lin-Buo-Ren : ok, thanks... [06:45] PR snapd#5075 closed: snap/env: fix env duplication logic [06:45] gohan: Check out https://forum.snapcraft.io/t/snapcraft-plugin-jdk-java-runtime-app-error/1403/3 [06:45] mvo: a bunch of PRs is stuck waiting for re-review after changes were requested [06:45] gohan: Here's an example that claimed working: https://github.com/ogra1/jtiledownloader [06:46] mborzecki: yeah, I will do a re-run this morning [06:47] I would like to request reviewing two trivial PRs on ubuntu/snapcraft-desktop-helpers: #119, #121 [06:47] PR #119: Do not export dirs.snappyDir [06:47] PR #121: Add built-in capabilities to the daemon [06:47] i can look info fixing #5081 while zyga is on vacation [06:47] PR #5081: interfaces/apparmor: add chopTree [06:47] Mornings [06:47] @Lin-Buo-Ren : ok.. [06:48] niemeyer: adjusting to new timezone already? [06:48] https://github.com/ubuntu/snapcraft-desktop-helpers/pull/119 ; https://github.com/ubuntu/snapcraft-desktop-helpers/pull/121 [06:48] PR ubuntu/snapcraft-desktop-helpers#119: Makefile: Honour CC, CFLAGS [06:48] PR ubuntu/snapcraft-desktop-helpers#121: Prepend $SNAP/share to XDG_DATA_DIRS [06:48] mborzecki: A bit early for that :-) [06:49] Just catching up.. yesterday was a bit hard to focus, so gave up and decided to do it early today [06:53] mborzecki: sure but please check if the expression from Jamie actually works [06:54] zyga: Heya [06:54] I was somewhat surprised on 2nd read [06:54] Hey [06:54] zyga: Before I forget, remind me to ask you about the parallel install feature [06:54] Holidays are fun but not when kids become ill [06:54] Ack, will do [06:55] How to make a snap from a .jar files, and how to make the snapcraft.yaml for that ?.. [06:55] niemeyer: why are you up so early? Are you in Europe? [06:55] zyga: No, just shifted today to catch up with reviews a bit === pstolowski|afk is now known as pstolowski [07:09] morning [07:10] pstolowski: hey [07:12] damn, spilled coffee :/ [07:35] mborzecki: ouch [07:44] What is the filepath to see where plugs and slots connects. I'm unsure where to point "target" of my content plug interface [07:59] moin moin [08:02] hey Chipaca [08:03] mvo: 'sup [08:03] Chipaca: reviews mostly and a bit of core18 work. I'm also looking for a volunteer who wants to work on the snapd snap :) [08:03] Chipaca: 'sup on your side? [08:04] mvo: the snapd snap sounds fun :-) but not sure i'll have the space today to learn where it fits in the dance [08:04] mvo: if you're still looking on Monday, hit me up [08:05] Chipaca: sounds great. monday is a public holiday here but I can still hit you :) [08:05] today, physio (unless things are on fire), then into London for lunch, otherwise snapshots (if i get a review) or warnings (if not) [08:05] mvo: tuesday is also good [08:06] maybe i should take monday off to discourage you from working it [08:06] that sounds quite nice actually [08:09] pedronis: you got a review on #4497.. LGTM once that's considered [08:09] PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it [08:09] mvo: You have a review request there too ^ [08:09] Chipaca: Moin [08:10] niemeyer: getting used to gmt? [08:10] Chipaca: No, just catching up on reviews.. feeling bad for my lag there [08:11] Still a couple of months away from the shift [08:12] niemeyer: don't run yourself into the ground [08:12] niemeyer: we call 'em sprints, but they're marathons [08:13] Chipaca: Thanks, and yeah.. the more it grows the heavier the burn is to get it down [08:13] how to access extenal jar file in snap? [08:13] gohan: Heya [08:14] gohan: The forum is usually a better place for that sort of question as you'll get more eyes there, and the ability for them to answer on their appropriate time without your question getting lost to the logs [08:15] gohan: The general answer is that the jar needs to ship with the snap [08:15] gohan: But your question probably has more context than this [08:28] PR snapd#5176 opened: many: add `snap connectivity-check` command [08:29] Chipaca: the above PR is a bit of an RFC - if you could have a look and check that the approach makes sense that would be cool, then I can clean it up properly [08:40] niemeyer: thanks [08:42] 5175 is an easy win [08:51] #5175 [08:52] PR #5175: systemd: mock useFuse() so testsuite passes in container via lxd snap [08:52] zyga: https://paste.ubuntu.com/p/THFBWKbZzD/ [08:54] PR snapd#5175 closed: systemd: mock useFuse() so testsuite passes in container via lxd snap [09:17] mborzecki: #4504 unblocked [09:17] PR #4504: snap, wrappers: systemd WatchdogSec support [09:17] niemeyer: thanks! [09:17] np [09:24] niemeyer: can you take a look if the approach in #4551 is now ok? it was re-worked after your initial review and after I had a discussion with zyga [09:24] PR #4551: ifacestate: do not auto-connect manually disconnected interfaces [09:25] PR snapd#4538 closed: interfaces/builtin: Add new steam-support interface [09:35] mvo: #4600 re-reviewed [09:35] PR #4600: configstate: validate known core.* options [09:35] niemeyer: thank you! [09:35] mvo: np, and thanks! nice feature! [09:36] pstolowski: Yeah, the tab for that one was even open already :) [09:36] niemeyer: that's already a good start :) thanks [10:01] mvo: thanks for the review, I'll work through the comments after lunch [10:03] pedronis: thank you, nice PR, this will make it much more usable [10:04] 5174 is also probably an easy win [10:06] mvo: i'm looking at #5176 now, but will be offline for a little bit [10:06] PR #5176: many: add `snap connectivity-check` command [10:07] ttfn [10:21] leaving #5081 for now, did the change but it feels a bit fishy around edge cases, probably best if zyga takes a look at it [10:21] PR #5081: interfaces/apparmor: add chopTree [10:21] zyga: conflicts on #4996 [10:21] PR #4996: overlord/ifacestate: store and use revision with security profiles set [10:25] pstolowski: #4551 reviewed, thanks! [10:25] PR #4551: ifacestate: do not auto-connect manually disconnected interfaces [10:26] niemeyer: ty! [10:45] hi [10:46] anyone know how I can configure the apparmor policy for chromium to allow it to talk to u2f security key ? [10:46] :q [10:46] or is there an interface for a u2f key ? === chihchun is now known as chihchun_afk [11:05] tatramaco, thats probably better suited as question to the forum (see channel topic) [11:07] I had already tried there and nada [11:07] tatramaco: Please ping me there and I'll go after it [11:08] Taking a break now to rest a bit before the standup [11:19] mvo, hey, about the comment you did on the #4416 [11:19] PR #4416: tests: performance measurements for basic snapd commands [11:19] with the question this way we avoid mixing stdout with the performance results? [11:19] I don't get what you are proposing === pstolowski is now known as pstolowski|lunch [11:53] Hi folks, why is 2.32.9 tagged in the snapd repo but there's no release notes to it and no vendor tarball? I was expecting it to be merely a matter of time, like a few hours a day at most, but it's been two days and there's still no release notes. Did someone just accidentally tag it, or something? [11:56] mvo: ^^ [11:58] pedronis: can you take a look at #4996 ? i've pushed some changes [11:58] PR #4996: overlord/ifacestate: store and use revision with security profiles set [12:00] i'm off to pick up the kids, coming back for the standup [12:09] mborzecki: hey, is 'daemon-notify' ready for re-review now? [12:12] PR snapd#4551 closed: ifacestate: do not auto-connect manually disconnected interfaces [12:40] fusion809: hey, sorry for this. .9 is only autopkgtest fixes which are very ubuntu specific, however I see that this is confusing and will add a page on GH [12:41] mvo: thank you for clarifying. [12:44] re [12:44] just a quick pop in to let y'awl know I'm going to miss the standup, as I'll be on the underground going back home then [12:47] fusion809: updated, thanks for letting us know! [12:51] mvo: happy to bikeshed the location, but not bothered by what's there (beyond this command not being debug -- the problem is we've always said debug commands were guaranteed not stable) [12:52] mvo: for ex: i'd say this is slower/more expensive but still system info-ish, so as such we could have a select= on sysinfo do it [12:52] Chipaca: yeah, that sounds reasonable. sysinfo works for me [12:53] Chipaca: I won't be in the meeting today but please relay that I want to branch 2.33 early next week (Monday hopefully) [12:53] Chipaca: we are a bit behind with this one already [12:53] mvo: neither will i [12:53] Chipaca: aha, ok [12:54] niemeyer: I won't be in the meeting today but please relay that I want to branch 2.33 early next week (Tuesday hopefully, monday is a public holiday here). we are already a little bit behind with 2.33 [12:55] pedronis: is there anything we could do to hit the right cdn with something cheap, say a HEAD request, that'd get redirected appropriately? [12:56] Chipaca: you ask the right questions :) [12:56] Chipaca: we could do details on something well known and do HEAD on the download url === pstolowski|lunch is now known as pstolowski [12:56] pedronis: yes we could, but i'd be happier if we weren't making the db do extra work for a connectivity check :-) [12:57] the cdn might vary [12:57] and the download urls are not documented [12:58] in theory if we had a canary snap with just one revision its download url before redirects would be fixed (until thing change and ignoring the enterprise proxy) [12:58] so not sure how not to ask the store for a download url [12:59] if we care [12:59] jdstrand: yes [12:59] pedronis: maybe we should chat with our store buddies :-D [12:59] * Chipaca disappears into the tubes [12:59] Heya [13:00] Running late but omw [13:18] mvo: Ack, thanks [13:30] pedronis: what was that download URL thing in reference to, or the use-case i mean? [13:33] noise][1: mvo is implementing a connectivity check for snapd, to see if it can access the main api domain, but there's a question how to check that download are accessible [13:33] noise][1: wip PR is here: https://github.com/snapcore/snapd/pull/5176 [13:33] PR #5176: many: add `snap connectivity-check` command [13:33] s/domain/domains/ [13:34] jdstrand: thanks for the review [13:35] pedronis: makes sense, thx [13:41] noise][1: so we wonder if we care about having something better that doing /details on a snap and HEAD on the download url (following redirects) [13:44] ullo ullo [13:44] pedronis: that should be a reasonable start [13:45] ooh, ooh [13:45] yea, think so [13:45] pedronis: noise][1: are you talking about the connectivity check [13:45] make sure we pass the headers [13:45] in case of cloud images [13:46] * Chipanaut on the move, hoping the webchat works better than actual irc on iffy networks [13:48] noise][1: a question I have is whether HEAD will always redirect, or if we should do a plain GET and then drop it [13:48] of course the boss check would be to download and check the hash, but that's taking it a bit far [13:49] * Chipanaut is suspicious of the silence in the channel [13:49] Chipanaut: yes we were talking about that [13:51] the HEAD should get your the redirect, but best to double check it :) [13:51] noise][1: it does today [13:51] noise][1: my question is whether we can rely on it, as CDNs come and go :-) [13:52] the redirect comes from the API [13:52] d'oh [13:52] we control it [13:52] i'll go get a dunce hat, brb [13:53] we can add spread test [13:53] and also one in the store itself if needed to keep that working if we start relying on it [13:53] pedronis: same headers, but narrowing fields would be a'ight, yes? [13:54] Chipanaut: yes, but my point is that we need to send headers also for the download, not just the details [13:54] mvo: mind if I push a commit to #5176 ? [13:54] PR #5176: many: add `snap connectivity-check` command [13:54] pedronis: gotcha [13:54] the actual relevant headers are consumed at that point [13:54] pedronis: hardcoding the download url is tempting [13:55] but i'll be brave and resist [13:55] Chipanaut: that is not a good idea because of the enterprise proxy [13:56] pedronis: well, I had reasons for it not being a good idea before :-) but yeah [13:56] the current code does the right thing wrt that afaict [13:56] https://bugs.launchpad.net/snapcraft/+bug/1772027 [13:56] Bug #1772027: Pull stage of a unspecified part is unexpectedly cleaned by snapcraft [13:56] pedronis: wrt headers and HEAD? [13:57] Chipanaut: no, I meand wrt to using the right helper to use if the eproxy url if it's set [13:57] ah, k [13:58] Chipanaut: also my other comment silly, we can just use the GET details instead of the current endpoint GET [13:58] not doing the former only if the latter work [13:58] yeap [14:00] pedronis: I'm about to go offline again for a bit, but I'll work on this [14:00] 's fun [14:00] ok, thx [14:00] :) [14:00] * Chipanaut steals the fun work out from under mvo's feet [14:08] mborzecki: thanks for sticking with that PR. it was a loooong time coming :) [14:09] Chipanaut: fyi, I responded in the PR regarding classic and signals [14:10] jdstrand, we can debug the issue here, since it's going to be faster (re: qt/vlc/debian) [14:10] I think I also reproduced the same behaviour on newest ubuntu though [14:11] but we can focus on debian for now [14:12] PR snapd#4504 closed: snap, wrappers: systemd WatchdogSec support [14:17] thresh: for the moment I think it makes sense to discuss in the forum since we may handoff [14:20] jdstrand, mvo, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1771858 does this sound reasonable to you? and will you be able to ship effectively a one line shell script? [14:20] Bug #1771858: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH Bionic):Won't Fix> [14:21] jdstrand, gotcha [14:22] xnox: I have no objections since it is appended to PATH [14:22] cc mvo ^ [14:23] jdstrand, mvo - btw this is an actual bug for foundations, we can't integrate preseeded snaps on classic in clouds =) [14:25] thresh: what is the output of 'snap info vlc' [14:26] thresh: on Ubuntu, what kernel were you using? [14:29] jdstrand, snap info vlc: https://gist.github.com/thresheek/28e1e1fea148f32648a2022bc8400ee3 [14:35] jdstrand, re ubuntu: my 18.04 does not boot for some reason, but the same happens on 16.04, using 4.13.0-36-generic, `XDG_CURRENT_DESKTOP=KDE snap run vlc -vvv`. snap/snapd 2.32.6. same vlc (337). [14:37] thresh: to be clear, that snap info was done on the debian system? [14:38] jdstrand, correct. coal is my debian machine. [14:39] thresh: I'm going to try to reproduce this. in your Debian testing machine, what do you install to get a typical KDE environment? [14:39] thresh: apt-get install ...? [14:40] ugh, tough question [14:40] on regular 16.04 ubuntu it's enough to reproduce that issue with XDG_CURRENT_DESKTOP=KDE snap run vlc -vvv [14:41] thresh: I didn't know if there was some meta package there [14:41] without any kde stuff installed afaict [14:41] thresh: the difference on 16.04 will be strict mode though... [14:42] I mean, it could be the same underlying issue, just trying to distill this down a bit [14:42] I mean you don't really need to run under KDE, setting that env var should be enough to tell Qt5 you're on KDE. [14:43] I understand. but Debian vs Ubuntu will change the system confinement [14:43] kde-plasma-desktop I guess [14:43] anyway, I'll figure it out [14:43] is the name of the package [14:43] thanks [14:57] pedronis: mvo: should the connectivity check retry? [14:57] eg should it do client.Get, or httputil.RetryRequest [14:58] Chipaca: should probably retry but a bit less agressively, less max time than normal? [14:58] bah, there's two axes: client.Get vs store.doRequest (which could refresh a macaroon etc), and direct vs httputil.RetryRequest [14:59] the refresh macaroon bit is annoying [15:00] it's less an issue with SnapAction though [15:00] Chipaca: I think more than /details we probably want the new not existing action for download [15:00] pedronis: it's more of an issue for details than for snap action? [15:00] Chipaca: if the macaroon is expired /details will 401 on you [15:01] SnapAction will still return a result [15:01] but tell btw [15:01] so you can ignore the refresh macaroon bit [15:01] (which is a bit odd to do in here) [15:02] pedronis: the problem is the device macaroon, right? [15:02] device session? [15:02] yes [15:02] ye [15:03] basically if we use /details for now [15:03] we need all the dance [15:03] later we can do what we will do for download/prepare-image [15:03] and cut some of the code [15:03] ah, for the days of yore, when men were men and everything was plaintext [15:04] pedronis: so I'll use retry with a doRequest, and add a TODO to move it to the new thing explaining why [15:05] Chipaca: basically later we should be able to use some variant of Store.snapAction (the internal helper that doesn't refresh on itself) [15:06] hmmm [15:06] maybe [15:06] it's trade offs [15:06] what's https://dashboard.snapcraft.io/dev/api/ [15:06] ? [15:06] in particular, what's that license list [15:07] I don't know [15:08] it doesn't seem ideal to hit though [15:12] Chipaca: it's api metadata [15:13] and the license bit seems buggy [15:13] pedronis: yes [15:14] it hits the db (lightly) [15:14] channel and release come from the db afaict [15:14] anyway not completely ideal [15:16] it's cached though afaict [16:24] eeep [16:24] rabbitholes === pstolowski is now known as pstolowski|afk [16:31] Chipaca: haha, yeah, steal the fun, thats fine. more fun Tuesday when you work on the snapd snap :) [16:32] xnox: thanks, I saw the bug I will have a look Tues (Mon is a holiday here) [16:41] __ 62221 [16:46] . [16:48] * cachio__ afk === cachio__ is now known as cachio [17:28] PR snapd#5177 opened: interfaces/builtin: allow access to libGLESv* too for opengl interface [17:46] PR snapd#5178 opened: interfaces/builtin: initial version of the anbox-support interface [20:07] popey: where does vim' snap packaging live ? (is uploaded by snapcrafters) [20:08] and the current version apparently does not work [23:31] om26er: no idea! dunno who uploaded that [23:31] om26er: sergio