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


[02:47] <mup> Bug #1520669 changed: Upgrade from 1.21.3 -> 1.25.0 got minor errors <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1520669>
[03:02] <mup> Bug #1520669 opened: Upgrade from 1.21.3 -> 1.25.0 got minor errors <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1520669>
[03:05] <mup> Bug #1520669 changed: Upgrade from 1.21.3 -> 1.25.0 got minor errors <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1520669>


[02:32] <johnny101> Think I have this solved by expanding the /etc/subuid range for the LXD daemon user on my system.  Details in the discourse thread.
[11:01] <mup> Bug #1902425 opened: Failed to allocate the required AUTO IP addresses after 2 retries <seg> <MAAS:Confirmed> <https://launchpad.net/bugs/1902425>