=== chihchun_afk is now known as chihchun [06:12] Bug #1705985 opened: snaps fail to install on juju1 deployed lxc container [06:27] o/ [06:27] good morning everyone [06:46] mvo: how are you doing? [06:47] zyga-ubuntu: hey, good morning. doing fine, how are you? [06:47] just finishing my coffee, good; today will be a nice day (for protests) [06:49] PR snapd#3592 closed: interfaces: opengl support pci device and vendor === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:15] !!! [08:15] kissiel: duda vetoes! [08:15] \o/ [08:16] zyga-ubuntu: you know it's because they voted for the wrong one? [08:16] zyga-ubuntu: the one pushed was not the one they wanted [08:16] it's a mess [08:16] kissiel: well, they could have paper-wrapped that [08:16] kissiel: but it seems he's not totally corrupt and spineless [08:16] kissiel: this is a major step forward [08:17] we'll see === JamieBen_ is now known as JamieBennett [08:41] zyga-ubuntu: thank for the reviews! [08:44] PR snapd#3612 closed: vendor: update go-flags to address crash in "snap debug" === chihchun is now known as chihchun_afk [08:45] Chipaca: my pleasure [08:45] PR snapd#3610 closed: snap: do not always quote the snap info summary === chihchun_afk is now known as chihchun [08:45] if it wasn't for the political turmoil I'd be pushing my branch for review so if you want to look at the query -> result API similarity I'd love your review [08:45] but [08:45] there's a lot of hope now [08:46] after the week of protests the president just announced he will not sign the controversial law [08:46] Chipaca: sorry, how have you been? :-) I keep talking about .pl lately [08:46] * zyga-ubuntu is reviewing 3594 [08:50] zyga-ubuntu: sounds like you're back into .pl politics big time [08:50] Chipaca: hard to ignore such changes [08:50] Chipaca: during the sprint mvo, gustavo and me went for a walk and we passed by the presidential palace, having walked past 1000s of people peacefully protesting [08:51] Chipaca: it's not over but there's a lot more hope now than during the last few days [08:54] PR snapd#3605 closed: packaging: have Ubuntu snapd package recommend squashfuse === chihchun is now known as chihchun_afk [09:08] zyga-ubuntu: mvo: Chipaca: hi [09:09] pedronis: hey, how are you doing? :) [09:09] ok === chihchun_afk is now known as chihchun [09:26] Chipaca: re tab-completion (forum) profile.d file - is that something you want me to look into? I am keen to get it for 2.27 [09:26] fgimenez: any word from CE yet about the 2.26.14 stable core? I would love to release that today if JamieBennett is ok with it too [09:30] mvo: I believe we are OK to release, lets leave it until this afternoon when our US colleagues come online to confirm. [09:30] hey mvo, not yet, looks like they are running smoke test on it, according to the thread the results should be available today [09:30] fgimenez, JamieBennett: thank you both! [09:30] * zyga-ubuntu keeps fingers crossed for an open path to 2.27 [09:39] zyga-ubuntu, congrats (nice president ...) [09:41] ogra_: nice is too strong but it seems he's waking up [09:51] mvo: partially reviewed 3594 [09:54] zyga-ubuntu: ta, nice === Kamilion is now known as |{amilion === |{amilion is now known as Kamilion [11:11] Chipaca: tab completion question [11:12] Chipaca: snap command --optio$ argument [11:12] Chipaca: if I hit tab when cursor is indicated at $, should it complete --option [11:12] Chipaca: as a user I'd say, sure [11:12] but it doesn't [11:12] er [11:12] sorry [11:12] reverse that [11:13] Chipaca: snap command arg$ --option [11:13] Chipaca: I try to tab complete "argument" [11:13] both normally work but when cursor is not at the end, things misbehave [11:22] ppisati, any idea about https://forum.snapcraft.io/t/wifi-and-bluetooth-on-snappy-ubuntu-on-a-dragonboard/1297 ? [11:30] Chipaca: I think 3399 is ready for review now [11:33] ogra_: replied [11:36] zyga-ubuntu: sorry, was away [11:36] Chipaca: no worries at all [11:36] zyga-ubuntu: yes it should [11:37] zyga-ubuntu: doing that is possible [11:37] zyga-ubuntu: but, i have yet to see a completer that does it [11:37] aha [11:37] so it's just harder to do and requires some extra features in go-flags? [11:38] zyga-ubuntu: not necessarily go-flags [11:39] zyga-ubuntu: it's harder to do, and involves looking at some bash variables [11:39] zyga-ubuntu: go-flags carefully avoids looking at bash variables i think [11:44] zyga-ubuntu: by this i mean: it's probably the snapd completion snipped that needs the extra work, not go-flags [11:45] aha [11:45] snippet* === chihchun is now known as chihchun_afk [11:53] ppisati, thanks! [12:03] ppisati, hmm, i wonder if that guy in the forum uses an oldish "build a dragonboard" tutorial or what [12:04] * zyga-ubuntu is hungry [12:04] time for something that resembles breakfast and includes not just coffee [12:05] Good morning all [12:05] Good afternoon to the other all [12:06] niemeyer: hey, how was the trip back? [12:06] zyga-ubuntu: Heya! [12:06] It was event-less ;) [12:07] Chipaca: if I want to test my profile.d complete.sh integration, what is the best snap to test that with? do we have a test-snapd-with-completion in the store? [12:07] niemeyer: please have a look at 3399 when you have a moment [12:07] zyga-ubuntu: ack [12:07] niemeyer: I think all the major issues are resolved and we should either land it or iterate on some details and land it [12:07] niemeyer: after eating something I'll start working on layouts [12:07] niemeyer: unless I forgot something and there's some catch up from last week, I'll review my nots [12:07] noteS* [12:08] zyga-ubuntu: Sounds great! [12:08] niemeyer: and on the upside, president vetoed (2/3 bill) so +1 for democracy :) [12:08] zyga-ubuntu: Wow, \o/ [12:08] zyga-ubuntu: Close call.. :) [12:09] yes, not over but everyone is very suprised and enthusiastic, it was commonly assumed he would just sign it [12:10] mvo: I don't think we have it in the store; there's tests/lib/snaps/complexion/ [12:14] Chipaca: thank you [12:18] Chipaca: ok, I have complexion now installed, what is the easiest test to see if tab completion for it works? [12:19] Chipaca: pardon my ignorace, I can dig into the tests to figure it out if you are busy [12:28] morning all [12:29] zyga-ubuntu, did you manage to fix the snap-seccomp failure on 32-bit arches? [12:30] flexiondotorg, "Once upgraded to stretch I ran sudo snap install snapd " ?? [12:30] (did you mean apt install ?) [12:30] flexiondotorg: thanks a bunch for the details - I'm back so I can try this now too. we tried it during the sprint but couldn't reproduce the issue [12:31] mvo No problem. [12:31] ogra_ Yes, I'll edit. Thanks, [12:31] I type snap more than apt these days. Muscle memory is replaced :-) [12:34] yeah, i know what you mean :) [12:39] Son_Goku: not yet, I'll look at it after lunch [12:39] Son_Goku: just finished PR 3399 [12:39] PR#3399? [12:39] oh, right... snapd#3399 [12:39] PR snapd#3399: many: add the interface command [12:39] nope [12:39] what's the magic thing to make the bot tell us stuff? [12:41] ogra_ Is now a good time to make an introduction? [12:41] as good as any time :) [12:45] PR snapd#3616 opened: cmd/snap-repair: implement Runner.Verify and use it to check signatures of repairs from Next [12:53] ogra_ I like to introduce you to ikey [12:53] * ikey bows [12:54] ogra_ ikey is the lead for Solus. A from scratch Linux OS. [12:54] ikey ogra_ is, well, a bit a legend around here ;-) [12:54] :] nice to meet ya. [12:54] O.o [12:54] ogra_ As discussed last week ikey is interested in enabling snapd in Solus. [12:54] ikey, hello [12:54] wait, wut [12:55] really? [12:55] hey ikey ! [12:55] howdo :] [12:55] Son_Goku, gotta adapt. i wont be the HD-DVD in this battle. [12:55] well, I guess that's fair [12:55] * ikey figures its not appropriate to use tape comparisons anymore [12:55] that's why I have ze snapd in Fedora :) [12:56] ogra_ From my discussion with ikey he would like someone on hand to answer questions regarding landing AppArmor (plus our patches) in the kernel Solus ship. [12:57] well, happy to help, thought we might need some help from kernel guys like ppisati or jj [12:57] *though [12:57] ikey I think you'll generally be OK packaging snapd itself, but should you need any clue ogra_ can either assist or get the right people involved. [12:57] yeah [12:57] sounds good to me [12:57] you will need the appramor patches but also some kernel config defaults (for seccomp cgroups etc) [12:58] ogra_ Yes, JamieBennett did suggest that p_pisati and j_j might be needed. [12:58] yup [12:58] are the apparmor patches contained anywhere .. sane? [12:58] ogra_ ikey I'll consider you two introduced and bow out. [12:58] by sane i mean "not a hidden kernel team ppa on launchpad that i cant access" [12:58] But I'm happy to be tagged here and brought back into the discussion. [12:58] which has been my experience so far .. [12:58] cheers flexiondotorg [12:59] ikey, like http://kernel.ubuntu.com/git/jj/linux-apparmor-backports/ ? [12:59] anyways im not gonna be able to get snapd packaged for a couple of days yet, got a bit of a workload to get through myself [13:00] looks legit [13:00] cheers [13:00] * ikey bookmarks [13:00] :) [13:00] hmm [13:01] well, if it's not all merged by 4.14, then I'll probably have to use some part of this too :/ [13:01] ikey, so i'D suggest you just start once you have time for it and bomb me with questions as they come up :) [13:01] * Son_Goku bookmarks [13:01] thanks :] [13:05] Son_Goku: We are trying to get everything upstream by 4.14, it is down to the kernel upstream gods though [13:05] JamieBennett, with AppArmor, aren't you guys the upstream gods too? [13:06] Son_Goku: Yup but we rely on code flowing upstream to the kernel [13:06] i.e. Linus [13:14] hey folks. I've been trying to run nginx in strict confinement, but the setgroups(2) syscall is not allowed. The only interfaces I have are network and network-bind [13:14] is there another interface I can request to be able to do this [13:14] squid also has this issue, fwiw [13:15] snap services run as root ... try to reflect that in your config [13:15] (i.e. if there is a user/group option in the config, point it to root) [13:15] ogra_, yep, have done already [13:16] still seems to want to setgroups stuff [13:16] it runs as root fine in devmode [13:29] bloodearnest: not yet, but this is going to be implemented soonish [13:29] bloodearnest: we desiged how it would work [13:29] bloodearnest: as there are a few snaps that are affected already [13:30] zyga-ubuntu, thanks for the info [13:31] * ogra_ tickles zyga-ubuntu with https://github.com/snapcore/pi3-gadget/pull/11 again ... [13:31] PR pi3-gadget#11: build uboot from source, pull blobs from upstream, use dtbs from archive [13:32] (i have pending stuff that waits for it to land ...) [13:34] ogra_: I'll check today for sure, sorry, I'm getting back to "what shall I do" after all the backlog [13:35] zyga-ubuntu, thanks ... as i said before it has all been tested in and out and my local images all run with it already ... just needs a second ack so i can move on and apply the same to pi2 and cm3 [13:36] the resulting binary snap is identical... [13:37] excellent [13:42] * mcphail wonders when we'll be seeing zyga-solus..? [13:46] mcphail: I don't have enough desk space :) [13:47] heh :) [13:53] Chipaca: going to have a break and then will look at your open PRs I think instead of starting something new [13:54] pedronis: that sounds like an objectively stupendous idea [13:57] mvo: the title of bug #1690083 should be set to .14 instead of .10, right? [13:57] Bug #1690083: [SRU] 2.26.10

Committed> [13:57] fgimenez: yes [13:58] fgimenez: eh, one sec [13:58] fgimenez: actually we only release 2.26.10 as a deb, the other fixes were all re-exec releated so not releavant for the deb itself [13:58] fgimenez: but if you feel it should be in sync I can do that too [14:01] mvo: np not needed at all, then there won't be a 2.26.14 deb release, right? [14:03] fgimenez: correct [14:04] mvo: cool thx [14:05] mvo: when you reproduced the problem on raspbian, which versions did you have and what did system logs say? [14:06] zyga-ubuntu: I started with 2.21 and when to stable (2.26.10). the configure hook was in defunct state in ps afx [14:07] zyga-ubuntu: no denials AFAICS in the system logs, but let me double check that [14:08] zyga-ubuntu: also subsequent dpkg --purge snapd; apt install snapd; snap install core worked so something is either racy or setup on first deb install or something, I'm running this in a loop now (except that it takes forever so the loop iteration is ~2 or so so far) [14:08] aha [14:08] interesting [14:09] raspbian should just switch to ubuntu core :P [14:09] reading about hours for upgrading always makes me think that [14:11] niemeyer, so, should i leave 1 worker for fedora? [14:12] I have merged with trunk and testing new tests within fedora, I'll be pushing soon [14:17] mvo, did you see bug 1705708 ? ... fun fact ... having the same core on two different machines here (laptop vs desktop) and using the same gui snap , on one machine opening urls does actually still work, the other doesnt ... [14:17] Bug #1705708: latest change to xdg-open not applied to the unity7 interface [14:17] (both run core 2381) [14:34] ogra_: something something armel something [14:34] Chipaca, hmm ? [14:35] ogra_: re raspbian should just switch to ubuntu core :P [14:35] ah [14:35] yeah [14:35] we need a v6 build [14:59] niemeyer, it is ready PR 3505 [15:00] merged with latest changes in trunk and running with 1 worker for fedora [15:02] cachio: Thanks! [15:09] The report is out: [15:09] https://forum.snapcraft.io/t/weeks-24-29-of-2017-in-snapd/1421/1 [15:14] Chipaca: posted some first pass comments on two of the PRs [15:16] pedronis: i saw them, thank you! haven't replied yet though [15:28] Snapcraft Office Hours is starting in a few minutes here - https://www.youtube.com/watch?v=xPtPiaHIghs [15:29] I'm there, thanks flexiondotorg === matteo` is now known as matteo === JanC is now known as Guest39739 === JanC_ is now known as JanC [16:29] Chipaca, if you have some time, could you please take a look to this one PR 3505 [16:29] Chipaca, it is almost ready to lunch [16:32] cachio: hungry lapsus there? [16:32] Chipaca, hehehe, land, sorry :) [16:34] Chipaca, my stomach betrays me :) [16:34] cachio: question for you: why dropping the call to MountDir() in snapEnv? [16:35] ahhhh [16:35] because of inside vs outside [16:36] this is going to get confusing :-( [16:38] cachio: anyway, you have two +1's already, go for it [16:41] Chipaca, yes [16:41] also we could join dirs.CoreSnapMountDir, info.MountDir() [16:46] That ruby plugin looks good. I'm sure there was a ruby app I was going to try to snappify. If I could only rememebr what it was... [16:46] niemeyer, do you think the fedora PR is ready to be landed? [16:46] cachio: Which one? [16:46] 3505 [16:50] niemeyer, once that is merged, I'll push the changes on the opensuse one [16:54] cachio: "The snap is leaving in $SNAPMOUNTDIR the .sh, and in $SNAP_INSTALL_DIR the commands." [16:54] cachio: The question is why SNAP___INSTALL___DIR vs. SNAPMOUNTDIR. [16:59] niemeyer, looking [17:04] niemeyer, as I see, both can be used [17:05] $SNAP_INSTALL_DIR/bin/sh or $SNAPMOUNTDIR/bin/test-snapd-tools.sh [17:06] cachio: Do you see the clear difference in syntax in those two variables? [17:06] cachio: Although they look *extremely* alike? [17:07] niemeyer, between which ones? [17:07] niemeyer, SNAPMOUNTDIR and SNAP_INSTALL_DIR? [17:07] cachio: My obsessive-compulsive disorder is extremely bothered by the fact you can't even see what I'm talking about :P [17:09] cachio: Of course.. isn't that why I just asked above [17:09] cachio: The question is why SNAP___INSTALL___DIR vs. SNAPMOUNTDIR. [17:09] cachio: See the underlines? [17:09] yes [17:09] cachio: SNAP***INSTALL**DIR [17:09] cachio: SNAP**MOUNT**DIR [17:09] niemeyer, you mean, why we are not using underscores? [17:10] for SNAPMOUNTDIR [17:10] cachio: I don't really care so much about which way we go.. the first question is why do we have those two conventions side by side instead of one [17:10] and we are using for SNAP_INSTALL_DIR [17:11] niemeyer, well, agree we should have a convention for that [17:11] Phew ;) [17:12] for example, TESTSLIB has not any _ [17:13] so, the convention seem to be "no _" [17:13] cachio: I'd be fine with that.. it also doesn't have to be done in this PR [17:13] cachio: We just need to ack the conflict and have a plan to eventually converge [17:14] niemeyer, sure, I'll take a look to see in which places we have this divergence [17:15] niemeyer, so if the change is so big, we can discuss it in the forum [17:16] otherwise I'll create a PR to unify it [17:16] cachio: Thanks [17:17] cachio: We should evaluate which way is more clear [17:17] cachio: Wehavesomelongstringsandingeneralreadingthingslikethisbecomeshard [17:17] niemeyer, yes, I prefer with '_' [17:18] but, it would be a big change [17:18] cachio: We don't need to rush this.. at first just making sure we don't have such obvious divergences would be easy [17:18] SNAP_MOUNT_DIR, for example [17:19] niemeyer, sure [17:29] niemeyer, doing a fast check, just TESTSLIB, SNAPMOUNTDIR and LIBEXECDIR are without _ [17:30] niemeyer, then, all the variables that we use for the environment and spread are using _ [17:32] niemeyer, the change is really easy but the diff will be huge, I could split it by variable [17:35] cachio: If that's the only change, even if it's huge it's easy to review [17:36] cachio: #3505 is in [17:37] niemeyer, thanks [17:37] PR snapd#3505 closed: tests: enable main suite on fedora === cachio is now known as cachio_afk === jkridner|pd is now known as jkridner [18:48] zyga-suse: hey, I have a fix for gary's https://github.com/snapcore/snapd/pull/3587 [18:48] PR snapd#3587: Using udev tagging for snap interfaces [18:49] zyga-suse: iirc, we can commit to other branches. what is the trick to doing that? [18:49] jdstrand: hey [18:49] jdstrand: oh, that's intereting [18:49] jdstrand: the trick is to add a remote and just push to the branch directly [18:49] jdstrand: git remote add adglkh git@github.com:adglkh/snapd [18:50] jdstrand: that should do it [18:50] jdstrand: then git fethc adglkh [18:50] jdstrand: then git checkout udev_tagging [18:50] jdstrand: then do whatever you want and "git push adglkh" [18:50] jdstrand: quick question, I actually joined to ask you one :) [18:50] jdstrand: location control is not constrained to core snap but the interface talkes about unconfined peers [18:50] jdstrand: missing check? [18:51] (well, partially talks about unconfined, maybe I'm mistaken) [18:54] zyga-ubuntu: location-control is written to only be available as an app snap (ie, no deb) [18:55] zyga-ubuntu: I assume you are talking about the rule at line 66? [18:55] zyga-ubuntu: that should have a comment above it, but the idea is that unconfined is allowed to talk to location-service [18:56] jdstrand: yes, I understand my mistake now [18:57] zyga-ubuntu: sigh, I did what you said for adglkh but the review is all messed up. see https://github.com/snapcore/snapd/pull/3587/files [18:57] PR snapd#3587: Using udev tagging for snap interfaces [18:57] jdstrand: let me look [18:57] zyga-ubuntu: eg, arch/arch.go. that isn't a change he made [18:58] note that you can always push --force to undo your changes [18:58] jdstrand: I refreshed the diff [18:58] jdstrand: I cannot see any changes to arch.go [18:59] * zyga-ubuntu goes to get some tea [18:59] jdstrand: I'll be back shortly [19:00] zyga-ubuntu: https://github.com/snapcore/snapd/pull/3587/files [19:00] PR snapd#3587: Using udev tagging for snap interfaces [19:00] zyga-ubuntu: first thing shows arch/arch.go [19:02] tyhicks: hey, can you help me with a git thing? [19:02] jdstrand: what's up? [19:03] tyhicks: can you read backscroll between me and zyga? basically, I want to do the 'you can always push --force to undo your changes' [19:05] tyhicks: I want to get this back to 8401774d3b2f5fa2d7e59120d56988b92e5995c6 in the remote branch [19:06] jdstrand, create a new branch based on that commit: `git branch my-new-branch 8401774d3b2f5fa2d7e59120d56988b92e5995c6` [19:06] jdstrand, then force-push it back to the branch in the PR [19:07] `git push adglkh my-new-branch:udev_tagging --force` [19:07] (assuming your adglkh remote is called that) [19:07] I'd expect `git push --force adglkh 8401774d3b2f5fa2d7e59120d56988b92e5995c6:udev-tagging` to also work [19:07] Man that is so hard to type [19:08] neither works [19:09] ah, I typoed something [19:09] PR snapd#3587 closed: Using udev tagging for snap interfaces [19:09] now all the changes are gone [19:09] jeez [19:10] and it says I closed it [19:10] maybe I picked the wrong commit [19:10] Hahaha, you still have your modified branch around I assume? [19:10] I do [19:11] Yeah, make sure you grabbed the right commit [19:12] "adglkh:udev_tagging was force-pushed and no longer has any new commits." [19:12] "Pushing new commits will allow the pull request to be re-opened." [19:13] I can help you with how to use git to do what you want to do but I'm not as much help in knowing what the result will be in the github web interface :/ [19:13] well, at this point I just want to go back to what he had [19:14] jdstrand: what's the name of the local branch representing his last changes? [19:14] jdstrand, can you push that branch to your fork? [19:17] tyhicks: ok. I have a local branch called adglkh.udev_tagging [19:17] jdstrand: it sounds like `git push adglkh adglkh.udev_tagging:udev_tagging` (try without --force first) will get the web ui back into shape [19:18] tyhicks: this was created with: git checkout -b adglkh.udev_tagging upstream/master ; git pull git@github.com:adglkh/snapd.git udev_tagging [19:18] kyrofa: no need for a branch [19:18] tyhicks: that has a merge from master and a fix to opengl_test.go. ie, where I was before I tried to undo things [19:18] hmm [19:18] I see some things happened since I made tea [19:18] (disclaimer, my lovely wife made tea and I just found it) [19:19] jdstrand: note that you stil have the full history locally in your machine in reflog [19:19] git reflog [19:19] it sounds like he already has a branch with full history so I didn't want to steer him towards reflog just yet [19:19] To git@github.com:adglkh/snapd [19:19] ! [remote rejected] adglkh.udev_tagging -> udev_tagging (permission denied) [19:19] jdstrand: I am only a bot, please don't think I'm intelligent :) [19:19] error: failed to push some refs to 'git@github.com:adglkh/snapd' [19:20] that is from inside a checkout of adglkh.udev_tagging [19:21] I'm confused how you were able to write to that branch before if you're getting a permission denied error now [19:22] (I did think it was odd that you could write to someone else's branch but I wasn't sure how github branch perms work) === cachio_afk is now known as cachio [19:22] tyhicks, github magic [19:22] tyhicks, when creating a PR there's a checkbox saying "allow modifications from maintainers" [19:23] ah [19:23] github seems to know that I don't know what I'm doing and took that away from me :P [19:23]