[04:40] Bug #1647256 opened: snap create-user cannot add a new user to an existing ubuntu core device [07:10] PR snapd#2400 closed: snap: support for parsing and exposing on snap.Info aliases [07:40] hi, I am interested in knowing how the seccomp profiles for each snap package are generated. Is it done by brute force? or is there a binary analysis tool? [07:42] From the docs here it looks like brute force https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement [07:42] but in that case, one would need tests that achieve 100% path coverage for each package [07:50] hey hey === ahasenac` is now known as ahasenack === ahasenack is now known as Guest64506 [07:54] PR snapd#2386 closed: interfaces/builtin: fix incorrect udev rule in i2c [07:57] PR snapd#2405 opened: fix unhandled error from io.Copy() in download() for 2.18.1 [08:07] ogra_: hey, good morning! just a quick question - are all our kernels up-to-date and ready for candidate? I would love to create a candidate image for qa for testing today and was wondering if there is anything that needs to be done for the kernels === DanChapman_ is now known as DanChapman === sjn__ is now known as sjn [08:37] mvo, morning! please let me know when the images are ready for qa :) [08:39] vigo: thank you! will do, but I expect this afternoon [08:41] bonjello [08:45] mvo, ack [08:59] PR snapd#2406 opened: many: add support for classic confinement [09:33] hi [09:34] i have some questions [09:34] anybody is there? [09:35] mrrpc: just ask if people can answer they will [09:36] i work qt in ubuntu [09:36] i dont know how make package [09:36] i try to read some guild but i didnt get it [09:37] guide* [09:37] how can i turn my qt project to snap package [09:39] ty for your help [09:40] such useful channel [09:43] PR snapd#2407 opened: wrappers: add support for the X-Ayatana-Desktop-Shortcuts= extension === seb128_ is now known as seb128 [10:13] mvo, i think they are [10:52] ogra_: excellent, thank you [10:52] PR snapd#2252 closed: interfaces: add unconfined access to modem-manager === chihchun is now known as chihchun_afk [11:36] PR snapd#2408 opened: daemon: fix crash when `snap refresh` contains a single update [11:38] PR snapd#2409 opened: daemon: fix crash when `snap refresh` is called and there is a single update [11:40] Bug #1647333 opened: adduser misses extrausers support for group management === chihchun_afk is now known as chihchun [12:18] PR snapd#2405 closed: fix unhandled error from io.Copy() in download() for 2.18.1 === hikiko is now known as hikiko|ln [12:52] Bug #1646968 opened: There's something weird about /tmp === hikiko|ln is now known as hikik === hikik is now known as hikiko [13:49] how do i set a static ip address on ubuntu core 16? [13:51] PR snapd#2408 closed: daemon: fix crash when `snap refresh` contains a single update [13:51] via console-conf [13:52] either during the first boot setup wizard or later via "sudo console-conf" [13:57] let me try that [14:08] daker: hey [14:08] er [14:08] zyga: hey :D [14:08] daker: sorry, I didn't mean to target you, bad tab-complete [14:08] but hey :) [14:09] * zyga needs to talk to jdstrand about classic confinement [14:09] zyga: lol yeah i just wanted to say hey too :D [14:14] jdstrand: tl;dr; snap-confine seems to work, one branch on snapd (the older apparmor branch will land as soon as tests go green), snap-confine will land via snapd after the merge; I'll work on snapd merge now [14:15] jdstrand: there's a call with sergiusens today to talk about the snapcraft story [14:15] hey zyga [14:15] jdstrand: hi :) [14:15] zyga: note that the store bits are in the process of landing [14:15] jdstrand: I'm never sure at which time you're around :) [14:15] jdstrand: great, I only tested side loading for now [14:16] jdstrand: but both that and store side shoud be OK from the code POV [14:16] zyga: 1400 UTC in standard time [14:16] jdstrand: offtopic, I've merged the errors branch in anticipation of the merge into snapd, I wanted to see how new files show up [14:16] jdstrand: if you want to make changes to that still, feel free to comment and I'll address that [14:17] jdstrand: but I got two other +1's and it's not used in anything yet [14:17] zyga: actually I should clarify. the review tools part is done and a store pull is being done. there is a store side change for the review tools form and sending classic to the review tools for subsequent uploads that needs to be implemented (the store team is doing that) [14:18] zyga: you mentioned things in the store needing review. I don't see them. did you request a manual review? [14:19] jdstrand: no, I didn't upload my snap yet actualy [14:19] jdstrand: I'll do that later today [14:19] roadmr: hi! fyi, can you pull r809. that's the last one from me for the moment [14:24] jdstrand: sure thing [14:24] mvo, hey, could you publish this package on store under canonical ownership? https://code.launchpad.net/~phablet-team/+snap/ubuntu-notes-app/+build/12605 [14:25] roadmr: thanks! [14:26] renato__: sure [14:31] Hi, I've noticed that some snaps use a different cursor or theme whatsoever (my guess would be because of sandboxing). [14:31] Is there a way to change the cursor theme at least for some apps (like the VLC snap)? [14:46] PR snapd#2384 closed: snap: add snap size to `snap info` [14:47] PR snapd#2393 closed: interfaces/apparmor: use distinct apparmor template for classic [14:58] mterry: any idea why the unity8 snap seems to have access to /etc, I can't seen general /etc access in any snapd interfaces (only to specific files/directories)? [14:58] mterry: see* [14:58] jdstrand: do you want to be at the call in 30 minutes concerning snapcraft and classic? [14:59] zyga: I don't think I need to be there unless someone else does. I gave my update regarding the review tools to you [14:59] cjwatson: I'm still fighting with my armhf branch, but that particular problem seems fixed. [14:59] I'll reply to the rt. [14:59] Elleo: it's an unconfined snap [15:00] mterry: I didn't think unconfined snaps could access the filesystem unconfined though? because it doesn't seem to be able to access /usr [15:00] Elleo: there may be mount points getting in its way with parts of /usr [15:01] elopio: thanks [15:01] mterry: ah, okay [15:01] Elleo: on Classic, it mounts the Core snap on top of system [15:02] * zyga nods [15:02] thanks jdstrand :) [15:02] mterry: the problem I was running into was that with the keyboard in the unity8 snap it reads the presage config from /etc/presage.xml on the host if it exists and so then tries to use the paths in there to access its file in /usr/share/presage instead of the snap paths that we fallback to when /etc/presage.xml isn't there [15:03] Elleo: interesting... Sounds like we need to fix the path so that it doesn't read fro /etc/presage.xml [15:03] Elleo: do you know what reads that? (i'm not familiar with presage) [15:04] PR snapd#2403 closed: store: fix unhandled error from io.Copy() in download() [15:04] mterry: currently we have presage patched so that it'll use an environment variable to fill in its paths if it can't read /etc/presage.xml which works fine on properly confined snaps and systems without presage installed on the host [15:05] mterry: presumably the goal is to fully confine unity8 in the future, so this problem would go away then [15:05] mterry: otherwise I could patch presage further to read its config from a modified path in snaps [15:05] Elleo: maybe... But still. Seems like the patch should unconditionally use $SNAP if it is defined, instead of assuming the read will fail [15:06] Elleo: in future, anytime somebody wants to test some new feature for a bit in u8 and installs with --devmode, they'll hit this bug agian [15:06] mterry: true [15:06] mterry: okay, I'll prepare a new patch for presage do handle things differently [15:10] zyga, is there a bug / issue / place I can follow "classic confinement" work? This is the implementation of utility snaps right. [15:16] noise][: hey, it seems that the tokens for the 2 snaps you posted expired for me as well [15:17] noise][: any hint on getting a new token so that I can report behaviors here? [15:17] it seems that niemeyer just paste the url without checking the token, so that didn't help [15:19] didrocks: i'm not quite following - if you start with a store download URL, e.g. "https://public.apps.ubuntu.com/anon/download-snap/asXOGCreK66DIAdyXmucwspTMgqA4rne_1.snap", that should always work [15:20] it will redirect to CDN url w/a fresh token in the query-string [15:20] noise][: if I curl -v your download URL, I'm getting the 302 [15:20] noise][: ah got it, thanks [15:20] right, and that 302 should come with a Location: header telling you where to redirect to [15:21] but then 403 Forbidden [15:21] let me try with another one [15:21] shouldn't - can you paste the full req w/headers there? [15:22] noise][: curl -v https://068ed04f23.site.internapcdn.net/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap?t=2016-12-06T15:21:25Z returns: http://pastebin.ubuntu.com/23583779/ [15:23] your URL is incomplete - did you miss quoting it? [15:23] and it helps when paste-binning to include the full cmd-line, not just the output [15:23] there should be t=…&h=... [15:24] attente: hello! If your integration test is passing locally, and failing just on the launchpad runners, it must be a proxy issue. It's the only thing that I can think of. [15:24] noise][: oh yeah, my middle paste stripped it, here we go: http://pastebin.ubuntu.com/23583790/ [15:24] noise][: but -L works [15:24] didrocks: if you don't quote that URL it will fail [15:24] because of the & [15:25] noise][: yeah, I went a little bit too fast :) [15:27] elopio: thanks, do you know what i should do to fix that? it's an issue on the github side right? [15:33] balloons, cwayne: https://github.com/zyga/hello-classic [15:43] spineau: ^ [15:44] :) [15:47] mvo, any news about the candidate images? [15:51] vigo: unfortuantely there are some issues with the store currently, we are working on it, might get delayed until later tonight/tomorrow morning, depends on if I can find a workaround or not [15:55] mvo, ack thanks for the update :) [16:15] jdstrand: https://github.com/zyga/hello-classic (if I forgot and pasted this already sorry :) [16:16] cool [16:23] PR snapcraft#917 closed: Fix unittests in armhf [16:23] PR snapcraft#945 opened: Fix unittests in armhf [16:26] didrocks, ping [16:27] didrocks, ng [16:27] hrm, something is wrong with my irc client [16:27] bbiab [16:27] (it's truncating my lines) [16:28] didrocks: ping [16:28] (much better!) [16:31] Chipaca: I fully see the difference :) [16:31] yes? ;) [16:31] didrocks, first time it looked to me like i'd just said "pi" [16:31] happens every so often; haven't had time to hunt it down yet [16:32] didrocks, i was wondering if you'd care to test something for this flaky download thing [16:32] didrocks, test something as in run a binary i gave you [16:32] Chipaca: sure, no worry [16:32] ok, i'll write it up and give you a shout then [16:33] Chipaca: I'm going to leave in ~30 minutes, send me an email if I'm not around and I'll test it before you start your day [16:39] attente: no, the proxy is handled by IS. So an RT. [16:39] elopio: ok, thanks [16:39] it's weird however, because those runners should be open to everything. I don't have a way to try it. === slashd is now known as slashd|lunch === slashd|lunch is now known as slashd [16:44] didrocks, are you on amd64? [16:45] Chipaca: I am, but the binary will be for the Pi, no? [16:45] didrocks, ah, your problem is on the pi? i hadn't noticed [16:45] didrocks, give me a sec [16:46] Chipaca: oh, I got your 'I'd just said "pi"' wrong then :) [16:47] didrocks, https://people.canonical.com/~john/schmurl_arm [16:47] didrocks, https://people.canonical.com/~john/schmurl if you're wanting to run it on amd64 [16:47] this just downloads a thing, discarding it, and computes the sha3-384 [16:47] Chipaca: ok, I guess standard go lib? [16:48] didrocks, sha3 isn't in the stdlib, and i added a funky progress bar, but otherwise yes [16:48] oki [16:48] (Pi rebooting, one sec) [16:48] it *should* look like: [16:48] $ schmurl https://public.apps.ubuntu.com/anon/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap e83c241ece25cbc43f625b37546e2c4f6320d4c58492fa7a1ddb8045d847a8bfc051a4c616cda5ca07a3c272a33e4e61 [16:48] * Wrote 23 MB in 4.22s (5.4 MB/s) [16:48] got sha: e83c241ece25cbc43f625b37546e2c4f6320d4c58492fa7a1ddb8045d847a8bfc051a4c616cda5ca07a3c272a33e4e61 [16:48] OK [16:49] but, you tell me [16:49] * Wrote 1.1 MB in 1.06s (1.0 MB/s)read tcp 10.42.0.14:56162->77.242.195.171:443: read: connection reset by peer [16:50] Chipaca: ^ [16:50] didrocks, and if you try again? [16:50] same, (well after 1.3MB) [16:50] some a few hundreds of kB [16:51] didrocks, interesting [16:51] yeah, matching at least snapd behavior [16:51] didrocks, and on this same box wget doesn't tell you it's resuming stuff? [16:51] Chipaca: no, neither curl [16:52] maybe they are resuming under the cover, or have some longer timeout than the go lib [16:52] (for micro-interruption) [16:53] didrocks, ok, thank you [16:54] didrocks, i won't have time to get you something that retries before you go off (and i should get back to other stuff anyways) [16:54] but maybe later this evening i can cook something up for you to try tomorrow [16:54] Chipaca: sure, thanks for looking at it! [16:54] niemeyer, not sure how relevant the above is to your thoughts on this issue (the 'connection reset by peer' i mean) [16:56] Chipaca: Readling [16:57] Chipaca: Yeah, definitely useful [16:57] Chipaca: woah, thanks for chasing this [16:58] it itched so i scratched :shrug: [16:58] Chipaca: I was planning on handing didrocks actual snap/snapd, but that might be enough [16:58] Chipaca: That might be lack of keep alives [16:58] or excess of them, reading some bugs on github [16:59] Chipaca: Can you enable them and hand didrocks an update? [16:59] niemeyer, he's leaving right about now [16:59] niemeyer, i think the default transport has them enabled anyway; let me confirm [16:59] well, if it's just a flag and for 5 minutes, I can wait [17:00] but yeah, if the issue was a keep alive TLS flag missing, that would make sense [17:00] * niemeyer Chipaca: ``` [17:00] // KeepAlive specifies the keep-alive period for an active [17:00] // network connection. [17:00] // If zero, keep-alives are not enabled. Network protocols [17:00] // that do not support keep-alives ignore this field. [17:00] KeepAlive time.Duration [17:00] Chipaca: From net.Dialer [17:00] niemeyer, yes, and DefaultTrasport has it set to 30 seconds [17:01] niemeyer, and http.Transport has a DisableKeepAlives that defaults to false [17:01] Chipaca: Which DefaultTransport? [17:01] niemeyer, http.DefaultTransport [17:01] FTR, the failure happens suddently (there is no like hangs for multiple seconds before failure) [17:02] niemeyer, the one http.DefaultClient uses [17:02] suddenly* [17:02] didrocks, yeah, it's like you're getting a tcp reset [17:03] didrocks: How long does the download last, usually? [17:03] didrocks: The failing one, that is [17:03] niemeyer, above, ~1s [17:03] niemeyer: I would say ~1s/2s [17:04] Ok, that would be an EXTREMELY short timeout :) [17:04] yep :) [17:04] Even then, Chipaca can we try a super short keep alive, just in case? [17:04] * didrocks has to go now, just send me an email with links to the binaries to try out and I'll do before you start your day [17:05] didrocks: Thanks for your help, let's restart the debug session when you're back [17:05] niemeyer: sounds good! Thanks for looking at it [17:05] PR snapd#2410 opened: store: retry resumed downloads on sha3 [17:09] Chipaca: So yeah, you're right about our keep alives, and I can't see anything obvious [17:09] niemeyer, you want to try with a tiny keepalive? [17:09] was just about to send the mail with that [17:10] Chipaca: It sounds worth, at least to rule that one bit out.. but I think it'd be more productive for us to reunite with didrocks here again instead of over email [17:11] Chipaca: One thing I'm wondering is this: we override the transport with our LoggedTransport [17:11] yep [17:11] Chipaca: But we don't actually use the original one as an embedded field [17:12] yes, we do [17:12] Chipaca: I'm wondering if http is internally looking at some property of the original http.Transport to make decisions [17:12] Chipaca: We do? [17:12] Chipaca: I'm looking at the code right now.. I don't think we do [17:13] niemeyer, https://github.com/snapcore/snapd/blob/master/store/logger.go#L104 [17:13] Chipaca: Exactly.. look at line 56 where this type is defined [17:14] ah, *embedded*, no [17:14] Right [17:14] niemeyer, but my test doesn't use this, fwiw [17:14] I've seen the http package doing such dirty decisions before.. looking at the interface of the thing beyond what it claims to expect [17:14] it's just http://pastebin.ubuntu.com/23584257/ [17:15] (well, that's with the teeny keepalive) [17:15] Chipaca: Ah, even better! Thanks! [17:16] Chipaca: That last timeout feels pretty short at 1 second [17:17] I wonder why it's so short [17:17] I guess we're not using that anyway [17:19] niemeyer, because the client is stuck waiting for a response, i guess? [17:19] expect: 100-continue is rather funky [17:20] basically if you don't get a reply fast enough it's recommended that you try again without that header [17:20] as the only purpose of that header is to make things faster [17:21] but anyway, we're not using it, as you say [17:23] PR snapcraft#946 opened: meta: support classic confinment [17:36] Chipaca: Wonder if we can reproduce that issue using the pi2 image Federico made work under qemu [17:37] niemeyer, i missed that! where is it? [17:37] Chipaca: I think he's been doing that on the fly only, actually.. [17:37] Chipaca: That is, getting the image prepared and run under Linode [17:40] hey folks, snapcraft master is broken for me - cannot snap anything from playpen - exits happlity after two lines https://paste.ubuntu.com/23584339/ [17:40] my git bisect suggest 9212dac broke it [17:43] kissiel, what specifically are you trying to build? [17:43] kyrofa: my bisect was running snapcraft clean && snapcraft snap in hellogl [17:43] from playpen [17:44] kissiel, I'll take a look this morning, thanks for the heads up! [17:44] kyrofa: http://paste.ubuntu.com/23584353/ [17:44] that's how I tested [17:44] \o/ happy to help [18:17] kissiel, hmm... I can't duplicate [18:17] kissiel, any chance you could try the version in proposed instead of from a venv? [18:21] kyrofa: sure, I'll try it out in a bit [18:22] kissiel, I appreciate the help-- definitely would rather not break the next release [18:22] :> [18:28] kyrofa: which proposed? ppa for tools-proposed? [18:28] kissiel, ah, no, just xenial-proposed [18:28] kissiel, are you familiar with that? [18:29] kyrofa: general xenial-proposed (like an archive)? [18:30] kissiel, yeah, but you want to be careful. The proposed archive contains all the brand new packages that are pending a migration to Updates-- not something you want to enable for everything [18:30] kissiel, read this real quick: https://wiki.ubuntu.com/Testing/EnableProposed [18:30] kyrofa: yeah, running in a vm [18:30] Basically, enable it, and then do the "Selective upgrading from -proposed" step [18:30] well snapshoted [18:30] Ah, handy [18:31] kyrofa: I'm asking, b/c the commit that broke it for me was from last friday [18:31] Once you make that file in /etc/apt/preferences.d, you can `sudo apt install snapcraft/xenial-proposed` [18:31] unless you push every landing to proposed... [18:31] kissiel, we don't, but we rolled a new release on Friday that includes that commit [18:32] kyrofa: ok, gimme a few minutes [18:32] kissiel, make sure snapcraft isn't installed by any other means (it's okay if the deb is installed, though) [18:33] roger that [18:34] PR snapd#2409 closed: daemon: fix crash when `snap refresh` is called and there is a single update [18:37] kyrofa: 2.23 from proposed works [18:38] kissiel, huh, odd [18:38] kissiel, but good, because that's what would be released [18:39] kyrofa: am I doing something wrong with my venving? [18:39] kissiel, no, but honestly we don't run from a venv very often-- it's not a well-tested way of running snapcraft [18:39] kissiel, admittedly it should be, and we're trying to make it better [18:40] kyrofa: :[ hacking.md mentions it, and btw. how do you develop? [18:40] kissiel, I just add /bin to my PATH [18:40] kissiel, it takes care of the imports [18:40] kyrofa: right... I've also noticed while working from venv that my changes are ignored unless I rerun ./setup.py [18:41] kissiel, one of the reasons we don't use it [18:41] kyrofa: well, that explains a lot [18:42] kyrofa: zyga just told me that what I was debugging is not a bug, and my whole experience today was a total nightmare because of venv [18:42] that's very Monday [18:42] kissiel, haha, no kidding! [18:43] kissiel, it's potty training day around here, so my Monday isn't so hot either ;) [18:44] kyrofa: TYVM for the explanation; at least my machine nor I are going mad [18:44] kissiel: are you going to hack on snapcraft more? [18:44] zyga: my crystal ball says it's inevitable [18:46] kissiel, any time! [19:07] PR snapd#2411 opened: History [19:09] Hey jdstrand if you have a minute, could you take a look at https://askubuntu.com/questions/857386/snap-cant-handle-app-using-libappindicator-and-ends-up-with-error ? [19:09] PR snapd#2399 closed: Add /dev/uhid to bluetooth-control interface === drizztbsd is now known as timothy === Saviq_ is now known as Saviq === niemeyer_ is now known as niemeyer === FourDollars_ is now known as FourDollars === mpontillo_ is now known as mpontillo === Trevinho_ is now known as Trevinho [19:46] Hey ogra_, you around? [19:53] kyrofa: I think Trevinho would be a better person to answer that question (https://askubuntu.com/questions/857386/snap-cant-handle-app-using-libappindicator-and-ends-up-with-error). He gave an update on the list and knows all the corner cases, etc [19:54] jdstrand, alright, thanks for the redirect :) [19:59] PR snapcraft#945 closed: Fix unittests in armhf [20:41] * Chipakeitor waves [21:30] sergiusens, do you have the power to land this? https://github.com/snapcore/snapcraft/pull/908 I'd like to fork it but it's much easier if it lands before I built a change on top of it [21:30] PR snapcraft#908: Let Rust plugin fetch dependencies in pull === madprops_ is now known as madprops [21:32] actually anyone with merge powers :) ^^ [21:37] icey, speaking of that ^^ would you mind somehow tying the email address you used in those commits back to your LP account? Either commit with @canonical or put your GH email in LP? [21:39] kyrofa: the last commit on https://github.com/snapcore/snapcraft/pull/908 should now have my @canonical email on it [21:39] PR snapcraft#908: Let Rust plugin fetch dependencies in pull [21:40] icey, you know you have two LP accounts, right? [21:41] oh? [21:42] https://launchpad.net/~chris.macnaughton is probably the one you want [21:42] icey, indeed, but your gmail address is registered to chmacnaughton [21:42] icey, if you're going to work with the gmail address, you might consider consolidating, it makes it hard to verify who you are exactly ;) [21:43] done kyrofa [21:43] icey, perfect. cholcombe that PR will be merged as soon as the updated tests pass. Thanks icey :) [21:44] kyrofa, awesome! [22:05] PR snapcraft#947 opened: Add 'aliases' support to 'apps' [22:11] PR snapd#2398 closed: cmd/snap: change terms accept URL following UX review [22:45] sitter: has anyone looked to snap peruse or minuet? [22:45] I'm trying to find your blog post about the shared snap [22:45] snap content [23:43]