[09:50] <Odd_Bloke> smoser: Yeah, I can't really understand it.
[09:50] <Odd_Bloke> I'm not sure why the failure would only appear once, either.
[09:51] <Odd_Bloke> It's not the only test that uses custom data.
[16:08] <smoser> larsks, i think that fedora 24 (and i'm guessing 25) has a newer httpretty than is released on pypi (0.8.14).
[16:09] <smoser> is that plausible ?
[16:10] <larsks> smoser: I don't think so. I was running from a virtualenv (there is no httpretty package installed on my host).
[16:10] <smoser> well that is odd.
[16:10] <larsks> smoser: I'm going to work on reproducing et al this afternoon.
[16:10] <larsks> Maybe my computer is insane.
[16:10] <smoser> well, i see code in fedora24 that shows this
[16:10] <smoser> and it definitely acts differently than pypi version
[16:11] <larsks> If I were to install the python-httpretty package, I get 0.8.14-1.20161011git70af1f8, so that may be newer than pypi.  But I don't have that installed locally.
[16:11] <larsks> (This is in F25)
[16:23] <smoser> larsks, i updated bug. and opened an httpretty issue
[19:16] <aixtools> quick question: as I do not know enough about python.
[19:17] <aixtools> what actually gets started by python by:
[19:17] <aixtools> #!/opt/bin/python
[19:17] <aixtools> # EASY-INSTALL-SCRIPT: 'cloud-init==0.7.5','cloud-init'
[19:17] <aixtools> __requires__ = 'cloud-init==0.7.5'
[19:17] <aixtools> __import__('pkg_resources').run_script('cloud-init==0.7.5', 'cloud-init')
[19:17] <aixtools> sorry for the multi-line. thought I had cut it down to the last line
[19:19] <larsks> aixtools: that runs cloudinit.cmd.main:main (possibly /usr/lib/python2.7/site-packages/cloudinit/cmd/main.py)
[19:19] <aixtools> so, in the sources - main.py
[19:20] <larsks> Right.
[19:20] <larsks> Specifically, cloudinit/cmd/main.py
[19:20] <aixtools> thx very much.
[19:20] <aixtools> single-step I go...
[19:45] <ssalevan> hey there!  i was wondering if i could ask a quick cloud-init question; if I have an ec2 datasource, is it possible to template out some of that information into a file using the write_files module?
[19:51] <magicalChicken> ssalevan: write_files just writes out specified content, it doesn't have a template system afaik
[19:51] <magicalChicken> ssalevan: there may be other ways to achieve that though, which parts of the config do you need written out?
[19:52] <ssalevan> magicalChicken: right now i basically need to stick eth0's private IP into a JSON configuration file
[19:55] <magicalChicken> ssalevan: I don't know of a good way to handle that that's currently built in, althought someone else may
[19:55] <magicalChicken> One option would be to write a script that handles that and runs after the eni has been written
[19:56] <larsks> ssalevan: for the *private* ip, seems like you could as easily parse the output of 'ip addr'.
[19:56] <larsks> And do that in a runcmd script or something.
[19:56] <ssalevan> ah, good point, could just rig up a bash session
[19:57] <ssalevan> well hey thanks much for your time y'all, much appreciated
[21:46] <ssalevan> i was wondering if i could trouble you for one last question: i've packed up my user-data into a base64-encoded YANL, but cloud-init is returning the following error:  __init__.py[WARNING]: Unhandled non-multipart (text/x-not-multipart) userdata: '---\npreserve_hostname: f...'
[21:46] <ssalevan> i suspect this may be related to a MIME typing issue
[21:48] <larsks> ssalevan: why are you providing a base64-encoded yaml?  Why not just pass in the unencoded yaml?
[21:49] <larsks> Also, does your userdata start with a "#cloud-config" marker? It doesn't look like it from that output...
[21:49] <ssalevan> larsks: so when i try and send up the raw YAML user-data as part of a call to Amazon's RunInstances call, it returns an error that it was unable to encode into base64.  t
[21:49] <ssalevan> ahhh that's probably it
[21:49] <larsks> ssalevan: interesting.  I suspect my second comment is more relevant, yeah.
[21:53] <ssalevan> larsks: that was totally it.  thank you so much!
[21:53] <larsks> Glad it worked!
[21:54] <smoser> larsks, thanks for helping ssalevan
[21:54] <larsks> smoser: sure!


[21:11] <jack_> http://img6.imageshack.us/img6/1944/screenshotrt.png
[21:11] <jack_> ^LOLOLOLOL
[21:12] <holstein> hehe


[03:11] <micahg> infinity: is there a reason why you didn't just make a new backport for precise-backports for debootstrap (apologies if I'm beating a dead horse)
[03:13] <infinity> micahg: Yeah, because re-backporting it every time is silly.
[03:13] <infinity> micahg: Not when people also insist on SRUing it anyway.
[03:13] <micahg> infinity: did you remove the version from backports then?
[03:14] <infinity> Was planning on it.
[03:14] <micahg> it's useful if someone wants features, I assume the backport was for features
[03:14] <infinity> No, the backport was just for the symlink.
[03:14] <micahg> yeah, that should've been an SRU then, <shrug>
[03:15] <infinity> There, removed from backports.
[03:15] <micahg> thanks
[03:15] <micahg> I usually end up with the problem that updating the seeds usually wants a newer debootstrap each time
[03:15] <mfisch> looking at a merge and finding out that it can be a sync is the best part of my day...
[03:16] <micahg> I'm still on precise on my main machine
[03:16] <infinity> I tend to just grab the .deb from the devel release and install it on older releases.
[03:16] <infinity> It's arch_all after all, and Just Works.
[03:16] <micahg> I usually end up with a local backport, but that's probably just as good of a solution
[03:18]  * micahg fires up a trusty chroot
[03:52] <mfisch> micahg: do you get email notifications of new packages in the repos?
[03:52] <micahg> yes
[03:53] <mfisch> micahg: where do you sign up for that?
[03:53] <micahg> https://lists.ubuntu.com/mailman/listinfo/trusty-changes
[03:55]  * mfisch checks the archive
[03:55] <mfisch> so I've managed 3, only 487 more to go to catch up with Colin ;)
[03:56] <ScottK> mfisch: Worry more about making them good than how many there are.
[03:56] <mfisch> ScottK: heh, I'm not worried either way, I just enjoy doing it
[14:12] <dereck> where do I submit bugs for the arm64 compiler on launchpad?
[14:13] <mitya57> dereck: What do you mean by "arm64 compiler"? We have the same compiler everywhere i.e. gcc.
[14:14] <dereck> that is to day that a build on launchpad failed with an 'internal compiler error: Segmentation fault'
[14:14] <dereck> and it asked to submit a bug report, but doesn't mention where :)
[14:14] <cjwatson> dereck: Don't submit bugs for those, they're hardware problems
[14:15] <cjwatson> dereck: Just give us the .../+build/... URL and we'll sort it out - or alternatively you can ignore it and we'll sort it out in bulk once arm64 has caught up
[14:15] <dereck> 10-4, thanks
[14:16] <dereck> it's not particularaly important to me, but I thougth i'd report it in case someone cared: +build/5150148
[14:17] <cjwatson> dereck: I'd need the full URL
[14:20] <dereck> cjwatson: http://goo.gl/T450jj
[14:21] <cjwatson> dereck: retried, thanks
[14:21] <cjwatson> (in fact I had mail about that, I just hadn't processed it yet)
[14:22] <dereck> Just for curiosity's sake, you say it's a hardware issue?
[14:22] <cjwatson> Yes
[14:23] <dereck> do you have a link to more info on what casues that, or do you know what it is by chance?
[14:23] <cjwatson> I'm not able to talk about the hardware in question right now
[14:24] <cjwatson> Suffice to say it's pre-release and occasionally a bit shaky
[14:24] <dereck> :D fair enough.
[14:24] <dereck> I'm surprised launchpad doesn't just use cross-comppilers rather than native builds. why is that, if I may?
[14:24] <cjwatson> A retry is usually sufficient; failing that, birch is a slightly newer model and does better
[14:25] <cjwatson> dereck: About a third of packages in Ubuntu main can be cross-compiled cleanly
[14:25] <cjwatson> dereck: This is a massive step up from where we were five years ago, but it's still very far from where we'd need to be to use it across the board
[14:25] <cjwatson> dereck: And even at that, some packages can't be cross-built without leaving some things out - anything that builds executables and then attempts to run them as part of its build, which is a lot more common than you'd think
[14:26] <cjwatson> dereck: For example, gtk-doc generation currently requires running the built binaries in a special mode
[14:26] <cjwatson> (AIUI; I haven't looked closely at that particular case but it comes up a fair bit)
[14:26] <dereck> That's quite interesting, thanks. :)
[14:26] <cjwatson> dereck: Oh, and of course you often can't run test suites during the build if you're cross-compiling, which would be a serious problem for QA
[14:27] <cjwatson> dereck: So I don't expect we'll ever use cross-compiling in the general case, although we'll probably make more use of it in some special cases as time goes on
[14:27] <dereck> once KVM supports arm64, could you run the build process in there with a performance hit?
[14:27] <cjwatson> In short, not practical for a full distribution
[14:28] <cjwatson> dereck: User-mode qemu is very shaky in our experience; for example anything that uses threading tends to fall over, so the stack above Qt loses badly
[14:28] <cjwatson> dereck: We might use that for PPAs, but not for the primary distribution
[14:29] <dereck> good to know :)
[14:29] <cjwatson> In any case, the hardware we're building on now is pretty nice when it isn't segfaulting; it should be great once the bugs have been shaken out
[14:29] <cjwatson> I'm not keen to go back from that to qemu
[14:31] <dereck> I agree hardware is the best option, I was only curious. :) And surprised that you have access to it honestly. :)
[18:19] <dereck> Is there anything I can do to help advance bug 1243310
[19:09] <dereck> Is there anything I can do to help advance my pet bug 1243310?
[19:10] <Laney> dereck: There's no source package called libaria2 - do you mean libaria?
[19:11] <Laney> What you need to provide us with is confirmation that the package you want to backport builds (without chanages), installs cleanly and runs on the target releases.
[19:16] <dereck> Laney: I fixed up the request, does that look better?
[19:17] <dereck> I also built the package locally and it's working fine. But cjwatson applied a patch to the ubuntu source that he says is required.
[19:17] <Laney> dereck: We backport from Ubuntu releases.
[19:17] <dereck> I don't really know much about that patch honestly.
[19:17] <Laney> So we can't take a Debian package (and it probably wouldn't work due to this patch).
[19:18] <Laney> You need to check the package from trusty builds/installs/runs as I just outlined
[19:19] <dereck> Ah, that makes sense then. I need to grab the Trusty source and build it locally then?
[19:19] <Laney> yeah
[19:19] <Laney> on all the releases you want to backport to (chroots can help you here)
[19:19] <Laney> possibly together with a PPA
[19:19] <Laney> the backportpackage script can help you prepare the package
[19:19] <Laney> s
[19:20] <dereck> ok, now that I have a better idea of what needs doing I'll hammer at it ^.^ Thanks@
[19:20] <Laney> No problem
[19:41] <lfaraone> Laney: wow, the backports team is fast :)
[19:41] <Laney> you got us on a good day :P
[19:41] <lfaraone> yesterday too!
[19:41] <lfaraone> much appreciated.
[19:41] <Laney> when requests are well-formed straight off it's so much easier
[19:41] <Laney> I have much less energy to chase up bad ones
[19:47] <dereck> Laney: this backportpackage script rocks! :3 Thanks for the tip~
[20:24] <dereck> Laney: I have finished building on each target distor without any problems, I think it's solid.
[20:24] <Laney> dereck: okay, please check it works a little bit too (light testing) and then post your results to the bug report
[20:25] <dereck> what's the best way to do that? It's a robot interface library, so I would have to install each distro on a robot to test really?
[20:26] <dereck> I have been using this code on raring for a couple days without any problem, is that good 'nuff?
[20:28] <Laney> dereck: Just post up what you've got and we'll see :-)
[20:42] <dereck> Laney: Updated with my results *fingers crossed*
[22:53] <jalcine> Question about packaging:/b 105


[02:27] <holstein> hey WaltherFI
[02:28] <holstein> i would try to isolate
[02:28] <holstein> and make sure its not a hardware issue
[02:28]  * holstein will be in later ... about 3 hours or so...
[19:20] <WaltherFI> holstein: you hilighted?
[19:21] <holstein> yeah
[19:21] <holstein> WaltherFI: your intermittent wifi issues
[19:21] <holstein> i would trh and isolate the problem
[19:21] <holstein> make sure its not hardware
[19:21] <holstein> then, you can look in lspci
[19:21] <WaltherFI> not wifi, cable
[19:22] <holstein> see what device you have
[19:22] <holstein> well, either way
[19:22] <holstein> and go from there
[19:22] <WaltherFI> and it's not hardware, and the problems started wheni went for ubuntustudio
[19:22] <WaltherFI> i guess it is the different networking manager, whatever it is
[19:22] <holstein> i dont know what 'went for' means
[19:22] <holstein> ubuntu = ubuntustudio
[19:23] <holstein> if you want the normal network manager
[19:23] <WaltherFI> i tried installing network-manager but no success
[19:23] <holstein> go for it
[19:23] <holstein> you can get the .deb from the install CD
[19:23] <WaltherFI> it doesn't run as it should
[19:23] <holstein> DVD*
[19:23] <holstein> right
[19:23] <holstein> you can also
[19:23] <WaltherFI> i installed from repositories
[19:23] <holstein> just use ubuntu
[19:23] <WaltherFI> i'm not a complete noob ;)
[19:23] <holstein> and add what packages you wnat to it
[19:23] <WaltherFI> also, i'm not a studio hater
[19:23] <holstein> want*
[19:23] <holstein> cool
[19:24] <holstein> i would look for nm-applet
[19:24] <holstein> and its dependacies
[19:24] <holstein> that should get you all the stuff you are familiar with
[19:24] <holstein> and hopefully fix the issue
[19:24] <WaltherFI> nm-applet is not a separate installable ppackage, it comes with the network-manager package
[19:25] <WaltherFI> also, installed that and now there are two managers, i think, as my internet works as bad as before, but not completely broken, and nm-applet shows no connections
[19:25] <holstein> WaltherFI: maybe you should go for the mailing list
[19:26] <holstein> ive never had that much trouble
[19:26] <holstein> is this 10.10?
[19:26] <WaltherFI> yes
[19:26] <holstein> this really hasnt come up in here in 10.10 yet
[19:26] <holstein> and i dont have that test case running
[19:26] <holstein> im running 10.04
[19:27] <holstein> and a test install of 10.10 and 11.04
[19:27] <holstein> non-studio installs
[19:27] <WaltherFI> i've had no trouble on non-studio
[19:27] <holstein> maybe you can just install what you need in non-studio
[19:28] <WaltherFI> except tha wifi issue on my laptop, but it's realtek's fault
[19:28] <WaltherFI> probably going to
[20:01] <holstein> WaltherFI: im getting ready to head out for the day
[20:01] <holstein> let me know if i can help at all with that issue
[20:02] <WaltherFI> oh, thanks and see you
[20:02] <holstein> i was just saying in another channel how im on the smallest nicotine patch this week ;)
[20:02] <holstein> i dont mean to be rude
[20:06] <WaltherFI> oh, congratulations
[20:06] <WaltherFI> hope you get off it soon
[20:07] <WaltherFI> especially the withdrawals :D
[20:07] <holstein> im going to make it this time
[20:07] <holstein> its attempt 2
[20:07] <holstein> its been since the end of november
[20:07] <holstein> so hopefully its about over :)
[20:08] <WaltherFI> hopefully yes


[01:30] <mup> PR snapcraft#1139 closed: plainbox-provider plugin: filter out sitecustomize <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1139>
[01:31] <mup> PR snapd#2843 opened: cmd/snap-confine: look for PROCFS_SUPER_MAGIC <Created by zyga> <https://github.com/snapcore/snapd/pull/2843>
[01:39] <mup> PR snapd#2844 opened: dirs: differentiate between "distro" and "core" libexecdir <Created by zyga> <https://github.com/snapcore/snapd/pull/2844>
[01:42] <mup> PR snapd#2845 opened: dirs: use the right snap mount dir for the distribution <Created by zyga> <https://github.com/snapcore/snapd/pull/2845>
[01:43] <mup> PR snapd#2846 opened: cmd: autoconf for centos <Created by zyga> <https://github.com/snapcore/snapd/pull/2846>
[02:20] <mup> Bug #1664427 opened: thefuck snap gets an apparmor denial even in classic confinement <classic> <Snappy:New> <https://launchpad.net/bugs/1664427>
[02:37] <zyga> Pharaoh_Atem: around?
[02:50] <mup> PR snapd#2846 closed: cmd: autoconf for centos <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2846>
[02:53] <Son_Goku> zyga: hm?
[02:54] <Son_Goku> oh, btw, I think the Fedora EPEL buildroots are actually RHEL systems
[02:54] <Son_Goku> though I'm not sure about that
[02:54] <Son_Goku> so you'll need to add "redhat"
[02:54] <Son_Goku> and "rhel"
[02:55] <Son_Goku> actually, I think the identifier is just "rhel"
[02:55] <Son_Goku> yep, rhel
[03:16] <Son_Goku> zyga: you need to add "rhel" otherwise snap-confine won't build right in epel
[04:17] <mup> Bug #1650187 changed: Can't run any snap application on Mint 18 <Snappy:Expired> <https://launchpad.net/bugs/1650187>
[06:25] <liuxg> ogra_, ping
[06:28] <liuxg> ogra_, I cannot console-conf my pi3 device. it just shows that (Client.Timeout exceeded while awaiting headers).  error: while creating users: cannot create use 'xxxxx". I have sent an email titled with "Currernt config hook implementation scales very badly". There are some attached picttures there. how can I resolve this problem?
[06:28] <liuxg> ogra_,  sorry, the email was tittled with "Issue with ubuntu OS snap first time boot."
[07:14] <liuxg> lool ping
[08:30] <mup> PR snapd#2515 closed: snap run: create "current" symlink in user data dir <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2515>
[09:16] <mup> Bug #1664484 opened: Missing interface to record audio from pulseaudio <Snappy:New> <https://launchpad.net/bugs/1664484>
[09:27] <ogra_> liuxg, how is that related to the config hooks ?
[09:29] <zyga> Pharaoh_Atem: hey, I've sent a few patches that make the code work on fedora/centos/rhel
[09:29] <zyga> Pharaoh_Atem: I'll refresh the package once 2.23 which includes those fixes is out
[09:59] <liuxg> ogra_,  ping
[09:59] <ogra_> yes
[09:59] <ogra_> i'm here :)
[10:00] <didrocks> he is here \o/
[10:03] <ogra_> lol
[10:04] <liuxg> ogra_, currently I cannot get my pi3 device console-conf I just reported a bug at https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1664471
[10:04] <mup> Bug #1664471: Creating user failed when doing console-conf for raspberry pi3 device <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1664471>
[10:04] <liuxg> ogra_, is that a network problem?
[10:04] <ogra_> liuxg, sounds like a store bug to me
[10:05] <ogra_> or do you have some proxy in place
[10:05] <liuxg> ogra_, interestingly, my pi2 device can get the job done.
[10:05] <ogra_> both through wired lan ?
[10:05] <liuxg> ogra_, no, I do not have any proxy. my colleague in shanghai did get the work done.
[10:05] <liuxg> ogra_, yes.
[10:05] <ogra_> and through the same lan specifically ?
[10:06] <liuxg> ogra_, exactly, the same cable.
[10:06] <ogra_> and it is properly plugged ? :)
[10:06] <liuxg> ogra_, I think so. otherwise, it cannot go the last step.
[10:06] <ogra_> true, you wouldnt get an IP
[10:06] <ogra_> (or do you use static ?)
[10:07] <liuxg> ogra_, I tried it for the whole morning. I did not set anything, I think.
[10:08] <liuxg> ogra_, I just attached the syslog file in the bug report.
[10:29] <lool> liuxg: pong
[10:30] <lool> ppisati_: Hi!
[10:30] <lool> ppisati_: one of the MWC demos is on RPis, and it breaks with a kernel backtrace when refreshing snaps:
[10:30] <lool> https://bugs.launchpad.net/snapd/+bug/1664368
[10:30] <mup> Bug #1664368: snap refresh hangs on arm architecture <snapd:New> <https://launchpad.net/bugs/1664368>
[10:30] <liuxg> lool, I am now having a problem on console-conf my pi3 device. I reported a bug at https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1664471.. ogra_just now helped me to answer me.
[10:30] <mup> Bug #1664471: Creating user failed when doing console-conf for raspberry pi3 device <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1664471>
[10:31] <lool> ppisati_: would you mind scheding some light ont his?
[10:31] <lool> *this
[10:31] <lool> liuxg: oh cool, sorry for the delay
[10:31] <lool> hadn't opened IRC since yesterday morning
[10:32] <liuxg> lool, it is ok. :)
[10:32] <ogra_> liuxg, your syslog looks fine, i really bet its a login.ubuntu.com issue
[10:33] <liuxg> ogra_, yeah, it is a little bit weird. my colleague also experienced the same problem. but he tried a few times more, then it became successful..
[10:33] <liuxg> ogra_, lool another colleague didrocks got 10 mins to configure a device.
[10:34] <didrocks> (that was in december, under the same network that I'm complaining snapd to regularly fail)
[10:34] <ogra_> yeah, thats rather normal ... still being researched (part of it is that the initial snapd configuration eats all CPU cores at 100% for a while)
[10:34] <didrocks> liuxg: btw, I know ogra_ and lool for years (almost 10), no need to present me :)
[10:35] <lool> isn't it a nice thing though?
[10:35] <ogra_> the system is under high load and very slow at that point ... sometimes you are lucky and it is fast ... but thats rather the exception
[10:35] <ogra_> lool, well, your CPU is completely eaten ... not sure IO nicing would change that
[10:36] <lool> haha
[10:36] <lool> it took me a while to even get the joke, tells you how fried my CPU is
[10:36] <ogra_> bug 1632124 btw
[10:36] <mup> Bug #1632124: snapd pegging cpu at 100% <Snappy:Expired> <https://launchpad.net/bugs/1632124>
[10:37] <ogra_> oh, mvo closed it ...
[10:37] <didrocks> I think you are mixing the snapd network issue with this, but yeah, it could be 2 separated things
[10:37] <ogra_> didrocks, if it succeeds it is the systerm load most likely
[10:37] <didrocks> (when snapd disconnect, it's really due to the network/snapd interactions, even when io load and CPU are next to 0)
[10:38] <mvo> ogra_: it expired, looking at it again it looks like for the wrong reasons
[10:38] <ogra_> yeah
[10:39] <ogra_> i know someone dug into it (Chipaca ?) ... but i dont remember it being fixed
[10:40] <zyga> o/
[10:40] <zyga> hey guys, I've been here just busy with meetings
[10:40] <ogra_> stop having meetings then !
[10:40] <ogra_> :)
[10:40] <zyga> I moved all of them to one day
[10:41] <zyga> (next step is to take a day off on that day) ;-)
[10:41] <ogra_> do you call it the pain-day ? :)
[10:52] <ppisati_> lool: replied to that lp bug and assigned to me
[10:53] <lool> ppisati_: <3
[10:57] <ogra_> didrocks, mvo, hah, my bug search actually failed me ... i was actually meaning bug 1638537 above
[10:57] <mup> Bug #1638537: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1638537>
[10:58] <ogra_> the classic does 100% cpu one is indeed in the works
[10:58] <ogra_> (silly me, was just searching for "100% CPU" and hit the wrong one)
[11:03] <didrocks> ogra_: oh btw, is your classic snap a chroot or a lxd container?
[11:04] <didrocks> I was aked when reading the tutorial, I was telling it's a container
[11:05] <ogra_> chroot
[11:05] <ogra_> we dont have lxd support in the core snap by default
[11:05] <ogra_> (you need the lxd snap)
[11:08] <didrocks> ogra_: ok, thanks for the clarification :)
[11:18] <mup> PR snapcraft#1127 closed: Release changelog for 2.27 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1127>
[11:35] <mup> PR snapd#2775 closed: cmd: add functions to load/save fstab-like files <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2775>
[11:35] <zyga> jdstrand: hey, can you please try to review https://github.com/snapcore/snapd/pull/2827/files today
[11:35] <mup> PR snapd#2827: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827>
[11:36] <zyga> jdstrand: it's based on the earlier mount work and is very small (doesn't get used in snap-confine yet, just adds the library functions)
[11:36] <zyga> jdstrand: using this I can propose nice chunks of update-ns next
[11:53] <mup> PR snapd#2588 closed: cmd/snap: add shell completion to connect <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2588>
[12:01] <mup> PR snapd#2251 closed: interface hooks: support for setting/getting slot/plug attributes with snapctl (step 3) <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2251>
[12:03] <mup> PR snapd#2421 closed: tests: add basic test for docker <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2421>
[12:12] <mup> PR snapd#2475 closed: tests: nested image testing <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2475>
[12:36] <mup> PR snapd#2654 closed: i18n: look into core snaps when checking for translations <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2654>
[12:41] <mup> PR snapd#2626 closed: interfaces: relax path requirements for serial <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2626>
[12:42] <mup> PR snapd#2847 opened: tests: enable docker test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2847>
[13:20] <mardy> pstolowski: hi! Quick question: if an interface is auto-connectable, and then I manually disconnect and reconnect it, will the interface hooks be run at this last step?
[13:22] <pstolowski> mardy, hey. interesting question, I think they will be run, but to be 100% sure I'd need to check the code
[13:22] <pstolowski> mardy, btw, my branch #3 landed
[13:22] <mardy> pstolowski: I saw, great stuff! :-)
[13:23] <mardy> pstolowski: should I file a bug to track when the interface hooks will be run for auto-connectable interfaces, or do you already have a task for that?
[13:26] <pstolowski> mardy, no need for bug, it's on my list I shared with alecu and i've it on my whiteboard at home ;)
[13:27] <mardy> pstolowski: send a pic
[13:27] <mardy> pstolowski: joking ;-)
[13:27] <ogra_> he cant, he has all his passwords written there too ;)
[13:28] <pstolowski> autoconnect is going to be the most complex of all changes, since this code is currently kind of a special case which doesn't work the way connect does
[13:32] <pstolowski> mardy, http://imgur.com/a/hILGi ;)
[13:32] <pstolowski> mardy, see, i'm not making this up ;)
[13:32] <mardy> pstolowski: :-D
[13:49] <mup> PR snapd#2848 opened: cmd/snap-update-ns: add compare function for mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/2848>
[14:10] <jdstrand> zyga: historically setuid executables are attacked in their failure conditions
[14:12] <jdstrand> zyga: everything is typically fine when things go right, but when they go wrong, there may be latent bugs. that is mitigated somewhat on Ubuntu because of the apparmor profile (though it necessarily allows a lot), but many distros don't have that
[14:13] <zyga> jdstrand: I understand that, we could make the debug code somewhat more paranoid (e.g. we could quote the paths and filesystem type)
[14:13] <jdstrand> zyga: I thought I was quite clear weeks ago that lots of string handling code (ie, a greater attack surface) would not be used in production, only debug
[14:13] <jdstrand> zyga: and I thought all the new code I was reviewing was working towards that
[14:13] <zyga> jdstrand: I think that right now we still do logging and (and do so less carefully) and this PR was aiming to fix that
[14:14] <zyga> jdstrand: no that wasn't clear, I though you wanted that to be off by default (hence the lazy compute of the command)
[14:14] <zyga> jdstrand: at some point without code like this the debug / die messages are useless
[14:14] <jdstrand> zyga: I didn't think anything was using sc_mount_cmd yet, as it was only added to the library
[14:14] <zyga> jdstrand: if you want to remove those we need a plan on how the app will be debuggable
[14:14] <zyga> jdstrand: nothing is using it yet, only thew two new calls added in this PR
[14:15] <jdstrand> zyga: env var aside, it isn't off by default if when you die() you run through all the code
[14:15] <zyga> jdstrand: yes, and I did that on purpose
[14:15] <jdstrand> I'm confused then
[14:15] <jdstrand> you just said "I though you wanted that to be off by default" and then you said "I did that on purpose"
[14:15] <zyga> jdstrand: I misunderstood you earlier and I implemented the lazy code so that we don't do it usually
[14:16] <zyga> jdstrand: but we do compute it when the message is needed (either because debug is on or because we need to die)
[14:17] <zyga> jdstrand: if you are saying I cannot, under no conditions, compute the message in production then that's fine
[14:17] <zyga> jdstrand: but what is the app going to do then
[14:17] <zyga> jdstrand: I think this is a reduction in functionality compared to what we have now (hand-made message in each case)
[14:17] <jdstrand> zyga: I expected the die() to have a simpler must_snprintf hand-made message
[14:18] <zyga> jdstrand: then the whole point of this branch is lost
[14:18] <jdstrand> no it isn't
[14:18] <jdstrand> someone trying to reproduce can use it with debugging enabled
[14:18] <jdstrand> or
[14:19] <jdstrand> you make this config file option
[14:19] <jdstrand> and the config file is root owned
[14:19] <jdstrand> or
[14:19] <jdstrand> you permanently drop privileges
[14:19] <zyga> jdstrand: nobody will do any of those things when they report a bug with  a message they got, for debugging done by an experienced person various things are possible
[14:19] <zyga> jdstrand: actually
[14:19] <zyga> jdstrand: how about that last idea?
[14:19] <zyga> jdstrand: I have a branch for that
[14:20] <zyga> jdstrand: adds library function for dropping/raising/permanently dropping privs
[14:20] <zyga> jdstrand: I did that after the sprint
[14:20] <jdstrand> zyga: what inexperienced person is going to debug the finer points of snap-confine's mount operations?
[14:20] <zyga> jdstrand: after tyler's suggestion
[14:20] <zyga> jdstrand: exactly, nobody
[14:20] <zyga> jdstrand: so they will just throw a bug with a message that they get
[14:20] <zyga> jdstrand: the point of this branch is to have that message as good as we can use
[14:20] <jdstrand> zyga: yes, so, an experienced person could flip a setting in a config file
[14:21] <zyga> jdstrand: well, you assume you can reproduce, that's not always the case
[14:21] <jdstrand> anyway, there is also dropping privileges
[14:21] <zyga> jdstrand: (weird kernel/setting)
[14:21] <zyga> jdstrand: I'd much rather drop privs
[14:21] <zyga> jdstrand: and for the config, that's more parsing (but we can explore that as it would have some value)
[14:21] <zyga> jdstrand: so if you are +1 on doing this after dropping privs then I'll just do it
[14:22] <jdstrand> if we *permanently* drop privileges, I have no problem
[14:22] <zyga> perfect
[14:22] <zyga> jdstrand: thank you and I'm sorry for the confusion
[14:22] <zyga> jdstrand: I recall we spoke about this as an option (compile time choice)
[14:22] <zyga> jdstrand: but I didn't think we agreed on that
[14:22]  * jdstrand shrugs
[14:22] <zyga> jdstrand: it's just been in review and iteration for too long and I must have forgotten (the whole mount code change)
[14:23] <zyga> jdstrand: I'll get right to it :)
[14:23] <zyga> jdstrand: oh
[14:23] <jdstrand> one way to reduce attack surface is to not have the code compiled
[14:23] <zyga> jdstrand: can you review a 3 line difff?
[14:23] <zyga> for the next release tomorrow: https://github.com/snapcore/snapd/pull/2843
[14:23] <mup> PR snapd#2843: cmd/snap-confine: look for PROCFS_SUPER_MAGIC <Created by zyga> <https://github.com/snapcore/snapd/pull/2843>
[14:23] <jdstrand> zyga: I was going to that when you pinged me
[14:23] <jdstrand> the release is tomorrow?
[14:23] <zyga> jdstrand: this makes snap-confine functional on the 3.10 kernel
[14:23] <jdstrand> jeez
[14:23] <zyga> jdstrand: I think it is, I'm not sure
[14:24] <zyga> jdstrand: especially with the state of reexec being in the middle
[14:24] <zyga> jdstrand: but mvo mentioned that deadline is tomorrow
[14:24] <jdstrand> I thought it was always on thursday
[14:24] <zyga> jdstrand: probably what mvo meant was EOD tomorrow is when master feezes
[14:25] <zyga> s/probably/possibly/ (or maybe)
[14:25] <mvo> jdstrand, zyga: 2.23 is EOD tomorrow, I plan to make the 2.23 release in my morning on Thursday
[14:26] <mvo> (not having any more context, I assume this is what you asked?)
[14:26] <zyga> mvo: what is the state of reexec code?
[14:26] <zyga> mvo: yes
[14:26] <zyga> mvo: I think we wanted to polish that to the point where we can reenable everything I removed from the policy
[14:26] <popey> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662181 # this bug is blocking a couple of snaps - can we get a plan of record on that bug? zyga ?
[14:26] <jdstrand> zyga: you requested that https://github.com/snapcore/snapd/pull/2749 not land until snap-confine is executed from the core
[14:26] <mup> Bug #1662181: Aliases didn't enable out of the box <isv> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662181>
[14:26] <mup> PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
[14:26] <jdstrand> zyga: but there are 3 or 4 PRs that already landed that use arg filtering
[14:27] <jdstrand> zyga, mvo: does that mean https://github.com/snapcore/snapd/pull/2749 won't be in 2.23?
[14:27] <zyga> popey: that's something for pedronis I think
[14:27] <zyga> jdstrand: I see
[14:28] <mvo> jdstrand: I added it to the 2.23 list, at least it will get priority this way
[14:28] <jdstrand> also, I thought that snap-confine executed from core was going to land Friday-ish
[14:28] <jdstrand> I thought I saw it merged, I'm I mistaken?
[14:28] <zyga> mvo: I think that we need to have a clear story on how this is going to affect 2.23, I think it's fine to delay for next week if that is required, otherwise we'd have to do more changes (negative) to the security profiles
[14:28] <Son_Goku> zyga, I left a comment on https://github.com/snapcore/snapd/pull/2845
[14:28] <mup> PR snapd#2845: dirs: use the right snap mount dir for the distribution <Created by zyga> <https://github.com/snapcore/snapd/pull/2845>
[14:29] <mvo> jdstrand: snap-confine from core is still under review, I hope we can get this in
[14:29] <zyga> jdstrand: I gave +1 on one of the branches but that will break debian/14.04 I'm sure
[14:29] <zyga> Son_Goku: hey
[14:29] <mvo> zyga: ok, if its fine to delay, w edelay
[14:29] <zyga> Son_Goku: thank you
[14:30] <jdstrand> let me see if there is anything else that would break. quota and ioctl were the two we undid. I thought there were others
[14:30] <zyga> Son_Goku: replied
[14:32] <zyga> jdstrand: it's not merged yet: https://github.com/snapcore/snapd/pull/2810
[14:32] <mup> PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
[14:33] <Son_Goku> zyga: replied ;)
[14:35] <zyga> Son_Goku: replied, also given the merge window closing I think the more elaborate checks will have to wait a few weeks
[14:35] <Son_Goku> okay
[14:37] <zyga> Son_Goku: did you see my tweet last night?
[14:37] <Son_Goku> do we need https://github.com/snapcore/snapd/pull/2844 when https://github.com/snapcore/snapd/pull/2845 already has its commit?
[14:37] <mup> PR snapd#2844: many: differentiate between "distro" and "core" libexecdir <Created by zyga> <https://github.com/snapcore/snapd/pull/2844>
[14:37] <mup> PR snapd#2845: dirs: use the right snap mount dir for the distribution <Created by zyga> <https://github.com/snapcore/snapd/pull/2845>
[14:37] <Son_Goku> zyga: I did
[14:37] <jdstrand> zyga, mvo: the other one I was thinking of was 'setpriority PRIO_PROCESS 0 <=19', but that isn't a problem because PRIO_PROCESS has been in snap-confine for ages
[14:38] <jdstrand> mvo: it it help if I rebased https://github.com/snapcore/snapd/pull/2749 on https://github.com/snapcore/snapd/pull/2810? is there another way in github to say that one branch depends on another?
[14:38] <mup> PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
[14:38] <mup> PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
[14:38] <jdstrand> s/it it/would it/
[14:39]  * jdstrand remove the netlink rule from https://github.com/snapcore/snapd/pull/2842 since if we allow it, it will be with arg filtering
[14:39] <mup> PR snapd#2842: interfaces: misc updates for network-control, firewall-control, unity7, x11 and default policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2842>
[14:40] <mvo> jdstrand: maybe, but let me try to get a review for #2810
[14:44] <Cynerva> zyga: you available to help me figure out permission errors on the kubelet snap?
[14:50] <balloons> Can you guys have a look at https://bugs.launchpad.net/juju/+bug/1660273 ? It seems like /snap/bin is missing from PATH
[14:50] <mup> Bug #1660273: /etc/environment does not include /snap/bin in $PATH <cloud-images:Invalid> <juju:New> <Snap Layer:Fix Released> <snapd:New> <https://launchpad.net/bugs/1660273>
[14:50] <jdstrand> mvo: can you add https://github.com/snapcore/snapd/pull/2842 to the 2.23 list? I reverted the commit that zyga, tyhicks, tsdgeos and I were discussing. the rest has a +1 from zyga
[14:50] <mup> PR snapd#2842: interfaces: misc updates for network-control, firewall-control, unity7 and default policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2842>
[14:50] <jdstrand> mvo: so just need another +1
[14:51] <zyga> Cynerva: hey
[14:51] <zyga> Cynerva: can you tell me more about the problem please
[14:51] <zyga> Cynerva: I'll try to help but I'll be also coding on a few other branches while we speak
[14:52] <zyga> balloons: I just did, can you be more specific please
[14:54] <Cynerva> zyga: cool, thanks. we're working on a kubelet snap, we have it working with classic confinement, but trying to make it strict
[14:55] <balloons> zyga, ty. /snap/bin is missing from PATH in /etc/environment. This means non-login shells don't have PATH set properly for snaps
[14:56] <Cynerva> zyga: we're hitting permission errors on several files i can't find an interface for - a bunch related to cgroups, like /proc/self/cgroup, /sys/fs/cgroup/memory, and several others
[14:56] <Cynerva> zyga: full list is here https://gist.github.com/Cynerva/9150f379cdf1d41aac9ae233597c1f64
[14:57] <zyga> balloons: I don't think we can add it there, we only add it through /etc/profile.d/apps-bin-path.sh
[14:57] <Cynerva> zyga: it looks like it's also trying to move the docker pid in /var/run/docker.pid (we have the docker snap installed and connected from stable channel)
[14:58] <zyga> Cynerva: for everything apart from docker: do file a bug report on launchpad.net/snapd, tag it with snapd interface
[14:58] <zyga> Cynerva: snapd-interface (with a dash)
[14:59] <zyga> Cynerva: there's no interface for cgroups that I'm aware of and snapd also uses cgroups in some ways some please describe as much as you can what the app is doing and why
[14:59] <ryebot> nessita: are you available to discuss snap store namespaces? I'm wondering if there's a way to either transfer a snap to another namespace, rename a snap, or delete a snap.
[15:00] <zyga> Cynerva: for the /var/run/docker.pid, can you tell me what's going on there? why would the app move it?
[15:00] <nessita> ryebot, hi! yes we can do first and last option
[15:00] <nessita> ryebot, renames are not a thing yet
[15:00] <nessita> ryebot, what's the snap?
[15:00] <balloons> zyga, I think we want PATH to be consistent
[15:00] <zyga> balloons: want != can
[15:00] <ogra_> balloons, where is that ? classic ?
[15:01] <zyga> balloons: whatever we want is done somehow, there's no way that we know of that would let us stick an item in path other than /etc/environemt
[15:01] <Cynerva> zyga: okay, will do on the others, thanks :) as for the docker pid, i really have no idea, but i can look into it
[15:01] <ryebot> nessita: ah, that's excellent, thanks! There's three of them: kube-apiserver, kube-controller-manager, and kube-scheduler
[15:01] <zyga> balloons: and there are plenty of small places that keep a copy of "vanilla path" that still break
[15:01] <nessita> ryebot, let me check a few things first
[15:01] <zyga> balloons: I'd like to know why the current approach that we do doesn't work in the places that were mentioned in the bug
[15:01] <ryebot> nessita: I think just deleting them would be fine
[15:03] <nessita> ryebot, I can certainly delete them, but may I ask what's the reason?
[15:03] <pedronis> popey: we are likely changing how aliases work, so that bug won't be quite the same
[15:04] <ryebot> nessita: I posted them to the store for testing purposes, but we'll be making a namespace for them in the future and I didn't want the tests to be in the way. Poor choice of name the first time around, basically.
[15:04] <zyga> nessita: my suggestion would be to take advantage of the new project for the store and route all such requests through bugs there
[15:04] <ogra_> balloons, note that this is a bash "feature" ...
[15:04] <zyga> nessita: you'll get free accountability and tracking
[15:05] <nessita> zyga, did those messages are truly for me?
[15:06] <zyga> nessita: yes,
[15:06] <nessita> zyga, ah, I see what you mean :-)
[15:06] <zyga> nessita: all the store request are informal / on irc; I think it would be a good idea, for transparency to request that they are filed as bugs on the store
[15:06] <pedronis> popey: anyway short story both now and in the future you need to ask on snapcraft list or a reviewer to get the aliases enabled
[15:06] <balloons> ogra_, zyga, perhaps it's better in /etc/bash.bashrc?
[15:06] <nessita> zyga, sounds good, thanks for the suggestion
[15:06] <pedronis> popey: through a store mechanism
[15:07] <balloons> and you are right.. ksh or other users are busted too :-)
[15:07] <ogra_> balloons, i thin thats not read if you have ~/.bashrc ... which we cant midify
[15:07] <ogra_> *modify
[15:07] <balloons> mm.. Indeed
[15:07] <ogra_> (and which is created by default usually when a user is created)
[15:07] <ogra_> balloons, where do you have that issue ? on classic
[15:08] <nessita> ryebot, following the suggestion from zyga, would you mind filing a bug-request at https://bugs.launchpad.net/snapstore with the delete request? then I can execute asap
[15:08] <balloons> ogra_, I imagine you would have it for all non-login shells
[15:08] <ogra_> note that we have a bit more freedon regarding /etc/environment on the core images
[15:08] <ryebot> nessita: Not at all, thanks a ton!
[15:08] <balloons> ogra_, but yes this is on non-core ubuntu images
[15:08] <ogra_> and the last edge images actually have that path in /etc/environment
[15:08] <zyga> nessita: \o/ thank you, I think this is very important
[15:09] <ogra_> for all other setups you need to add a snippet to your bashrc to source profile.d
[15:09] <ryebot> nessita: https://bugs.launchpad.net/snapstore/+bug/1664601
[15:09] <mup> Bug #1664601: Please remove kube-apiserver, kube-controller-manager, and kube-scheduler from the store <Snap Store:New> <https://launchpad.net/bugs/1664601>
[15:10] <mup> PR snapd#2849 opened: cmd: don't reexec on RHEL family <Created by zyga> <https://github.com/snapcore/snapd/pull/2849>
[15:10] <zyga> mvo: ^^ along with the other branches
[15:10] <ryebot> Out of curiosity, is renaming/deleting/transferring snaps going to be a user-doable thing in the future?
[15:10] <balloons> ogra_, is adding /snap/bin to /etc/environment for non-core images not an option? Do we feel this can't be modified?
[15:11] <ogra_> balloons, right ... you can try to convince foundations if you feel like ... but i guess chances are low they want that :)
[15:11] <nessita> ryebot, excellent! thanks
[15:11] <ryebot> nessita: thank you :)
[15:12] <ogra_> balloons, you cant really modify this file from a package ... snapd isnt necessary always installed everywhere so it shouldnt be in the default path in /etc7environment but instead enhance the path
[15:12] <popey> pedronis: hm, okay. Any chance of a public reply on the bug so we can point people at it?
[15:12] <pedronis> popey: yes
[15:12] <pedronis> will write something
[15:12] <balloons> ogra_, snapd actually has the prominece since xenial. I've assumed it was there akin to apt
[15:13] <ogra_> balloons, debootstrap wont install it for example :)
[15:13] <ogra_> balloons, bring it up with foundations, they own the classic images ... i'Äd happily drop the hack we use for the core images and just inherit their path from the default file
[15:14] <ogra_> but i fear i know the answer when you ask them :)
[15:15] <ogra_> balloons, beyond that: ssh user@host "source /etc/profile; /path/script.sh"
[15:15] <ogra_> that will definitely work around it as a quick hack
[15:16] <balloons> ogra_, ack. Given you are correct in that it's not "always" there, asking for a change seems impossible. However, my bigger fear even assuming the change made sense was getting onto xenial at this point
[15:17] <balloons> thanks for your comments. I'll add them to the bug
[15:17] <ogra_> yeah, /etc/environment is created by the installer iirc ...
[15:17] <ogra_> and usually not modified after install ...
[15:18] <ogra_> i never understood why bash has this special treatment of remote sessions ... but there surely is a valid reason
[15:21] <balloons> yea, it's a bit fun when trying to debug something you can run interactively, but not via cron
[15:21] <ogra_> yup
[15:21] <popey> pedronis: thanks!
[15:26] <mup> PR snapd#2850 opened: config: make helpers reusable <Created by stolowski> <https://github.com/snapcore/snapd/pull/2850>
[15:27] <Cynerva> zyga: looks like it's just reading /var/run/docker.pid, and when that fails, falls back to pidof. so maybe that one's not really a problem
[15:27] <zyga> Cynerva: I see, can you check why it is doing that?
[15:32] <mup> PR snapd#2851 opened: tests: failover test for rc.local crash <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2851>
[15:34] <Cynerva> zyga: ah, looks like it's putting the docker process in a cgroup
[15:46] <mup> PR snapd#2834 closed: release: add galliumos support <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2834>
[15:52] <zyga> Cynerva: I see, ok
[15:52] <zyga> Cynerva: that feels like a separate feature; Can you please report a second bug with the details describing this (why, which cgroup)
[15:53] <Cynerva> zyga: will do, thanks :)
[15:57] <zyga> Cynerva: thank you, we'll get to it but not today
[16:03] <mup> PR snapd#2718 closed: cmd: add non-stub implementation of snap-update-ns <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2718>
[16:05] <mup> PR snapd#2488 closed: interaces: add new boot-config interface <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2488>
[16:06] <zyga> jdstrand: can you have a quick look if this is the kind of API you were thinking about?
[16:07] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/2852
[16:07] <mup> PR snapd#2852: cmd/libsnap: add privilege elevation helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2852>
[16:07] <mup> PR snapd#2852 opened: cmd/libsnap: add privilege elevation helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2852>
[16:10] <zyga> jdstrand: (I will patch the code to actually do the effective == 0 but real != 0 checks as well, this is just for the API itself
[16:28] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/2749 adds a spread test in a location that is not used anymore
[16:28] <mup> PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
[16:28] <zyga> jdstrand: you need to put all the new tests in tests/ at the top of the tree
[16:28] <zyga> jdstrand: I'll move the old tests there one by one, I should have finished that already :/
[16:33] <lazyPower> nessita - can i piggy back on ryebot's bug with my own? https://bugs.launchpad.net/snapstore/+bug/1664634  -- similar situation. i've had this since initial POC and the naming was poor for a test repository
[16:33] <mup> Bug #1664634: Please delete the kubectl snap from the snap-store <Snap Store:New> <https://launchpad.net/bugs/1664634>
[16:37] <mup> PR snapd#2769 closed: snap-exec: support nested environment variables in environment: <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2769>
[16:37] <nessita> lazyPower, sure! will check that out right after my lunch
[16:38] <lazyPower> thanks nessita appreciate the alley-oop
[16:38] <nessita> \o/
[16:39] <zyga> jdstrand: I just pushed to 2852 again, this time with code that I think is real; you can now review both the .h and the .c files
[16:40] <zyga> jdstrand: please suggest tests for this if you feel they are useful (can be done, just costly) otherwise let's land this and use it in the mount branch and in various parts of snap-confine
[16:41] <mup> PR snapd#2850 closed: config: make helpers reusable <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2850>
[16:48] <pedronis> popey: I wrote a comment in that bug
[17:05] <zyga> Pharaoh_Atem: I got an email notifying me about deletion of  golang-github-mvo5-uboot-go-0-0.2.git5927df7.fc23
[17:05] <zyga> Pharaoh_Atem: is tha because f23 if EOLd?
[17:33] <mup> PR snapcraft#1137 closed: Build-depend on git <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1137>
[18:36] <mup> PR snapd#2849 closed: cmd: don't reexec on RHEL family <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2849>
[19:19] <cory_fu> Is there a PPA for getting latest stable snapd on trusty?
[19:49] <kyrofa> ogra_, mwhudson does console-conf place something in /etc/network/interfaces.d/ ?
[19:49] <kyrofa> (after first boot)
[19:50] <kyrofa> Ah, netplan
[19:51] <kyrofa> ogra_, mwhudson so if I wanted to connect to a wireless network after I connected to a wired network, would I put something in /etc/netplan/ or /etc/network/interfaces.d/ ?
[20:06] <mup> PR snapd#2844 closed: many: differentiate between "distro" and "core" libexecdir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2844>
[20:16] <mup> PR snapd#2845 closed: dirs: use the right snap mount dir for the distribution <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2845>
[20:19] <kyrofa> ondra, any chance you're around?
[20:22] <mup> PR snapd#2843 closed: cmd/snap-confine: look for PROCFS_SUPER_MAGIC <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2843>
[20:35] <ondra> kyrofa hi
[20:35] <ondra> jdstrand on holidays, but around for bit
[20:36] <ondra> jdstrand sorry was for kyrofa
[20:36] <ondra> kyrofa what's up?
[20:36] <kyrofa> ondra, ah, no, go away!
[20:36] <ondra> kyrofa lol
[20:36] <kyrofa> ondra, I think I've got it
[20:36] <ondra> kyrofa just tell me
[20:36] <ondra> kyrofa killing a bit of free time here
[20:37] <kyrofa> ondra, okay I'll be quick
[20:37] <kyrofa> ondra, after first boot on ubuntu core, the networking config is done via netplan. Are you familiar with that piece?
[20:38] <ondra> kyrofa as much as changing config on devices
[20:38] <kyrofa> ondra, therein lies my question. Is changing the netplan config the recommended way to change network config?
[20:38] <kyrofa> ondra, or should I be doing that in /etc/network/interfaces.d/ still?
[20:38] <ondra> kyrofa I was hoping so, as I do it on some of my devices quite often
[20:39] <kyrofa> Heh
[20:39] <kyrofa> ondra, okay, so you use netplan as opposed to the old way?
[20:39] <ondra> kyrofa I typically edit /etc/netplan/...yaml
[20:39] <kyrofa> Okay good deal
[20:39] <kyrofa> And then run `netplan apply`?
[20:39] <ondra> kyrofa yeah edit yaml, then netplan generate + apply
[20:40] <ondra> kyrofa yeah generate before apply
[20:40] <kyrofa> ondra, ah, what does generate do?
[20:40] <kyrofa> "backend specific configuration files"
[20:41] <kyrofa> Backend being systemd-networkd?
[20:41] <kyrofa> As opposed to network manager?
[20:41] <ondra> kyrofa let me show you my yaml, as I had case where I have device with 4 ethernet ports and wanted to configure it to share connections
[20:41] <kyrofa> ondra, oh sweet
[20:42] <ondra> kyrofa this is for example I use on my deice http://paste.ubuntu.com/23997012/
[20:43] <ondra> kyrofa not even sure how to configure this one through using /etc/network/interfaces.d/
[20:43] <kyrofa> ondra, yeah fair enough, this is handy. Okay, thanks for the help!
[20:43] <ondra> kyrofa I did try network manager, but even with help of morphis I was not successful
[20:43] <ondra> kyrofa very welcome
[20:44] <kyrofa> ondra, enjoy holidays, and thanks for your time :)
[20:44] <ondra> kyrofa no worries :)
[21:07] <cory_fu> So, my previous question was due to user error, of course.  :)  However, I'm trying to use snapd on Travis and it's failing.  Does anyone know if there's any way to make this work: https://travis-ci.org/juju-solutions/layer-cwr/builds/201647356
[21:08] <kyrofa> cory_fu, no, snaps don't work on travis
[21:09] <cory_fu> :(
[21:09] <cory_fu> Is there any expectation that this could be resolved at some point?  Or is it just not feasible due to how Travis runs builds?
[21:10] <kyrofa> What are you trying to do, exactly?
[21:10] <kyrofa> cory_fu, it's totally up to travis
[21:10] <kyrofa> cory_fu, their kernel, their OS
[21:10] <kyrofa> cory_fu, keep in mind that they JUST moved to ubuntu 14.04
[21:11] <kyrofa> From 12.04
[21:11] <kyrofa> And it's still beta, I thin
[21:11] <kyrofa> k
[21:12] <cory_fu> Yeah, that just makes it difficult to run our tests which depend on projects that have moved to snaps.  This particular instance, charm-tools, has an apt package but it's broken at the moment.
[21:17] <kyrofa> cory_fu, yeah we're going to run into that soon as well. I wonder if elopio has some magic
[21:17] <kyrofa> He's the travis master
[21:22] <elopio> kyrofa: cory_fu: according to the table from zyga, travis should support snaps.
[21:23] <cory_fu> elopio: Table from zyga?
[21:23] <kyrofa> elopio, eh? Really?
[21:23] <elopio> cory_fu: https://github.com/snapcore/snapd/wiki/Distributions
[21:24] <cory_fu> elopio: I don't see Travis mentioned there?
[21:24] <kyrofa> elopio, where are you getting that?
[21:24] <elopio> from that error you are getting, I suppose they still need to enable something in apparmor.
[21:24] <kyrofa> Travis isn't even on there
[21:24] <EEight> on ubuntu 15.04 sudo apt install snapd = package not found!
[21:24] <nacc> EEight: 15.04 is eol
[21:24] <kyrofa> EEight, that's EOL I believe
[21:24] <elopio> kyrofa: cory_fu: no, but the kernel version required to support snaps in trusty.
[21:24] <EEight> But the doc: https://snapcraft.io/docs/core/install
[21:25] <kyrofa> elopio, ah, sure. But yeah, travis still needs to enable it
[21:25] <nacc> EEight: on ubuntu implies supported/current ubuntu of course
[21:25] <EEight> So Ubuntu 14.04 will work but not 15.04?
[21:25] <kyrofa> EEight, indeed as 14.04 is an LTS
[21:25] <EEight> Ok thx
[21:27] <cory_fu> elopio: Do you know what would need to be enabled?  I could file an issue on Travis
[21:27] <ogra_> kyrofa, ssh in and run sudo console-conf ... disable the wired device and configure the wlan ...
[21:27] <ogra_> thats the most trivial approach
[21:27] <kyrofa> ogra_, haha! That's handy
[21:28] <elopio> cory_fu: well, the error says "Kernel needs AppArmor 2.4 compatibility patch." Please file the bug, and we can get zyga or jdstrand to comment there about the details.
[21:30] <elopio> cory_fu: this week I wanted to try running snaps on travis. Now that you have confirmed it fails, my plan b is to try a lxd container.
[21:32] <cory_fu> elopio: A LXD container on Travis?
[21:32] <elopio> cory_fu: yes. I tried that like a year ago and it kind-of-worked. But at that time, lxd didn't support snaps.
[21:33] <cory_fu> elopio: https://github.com/travis-ci/travis-ci/issues/7318
[21:34] <cory_fu> elopio: Wouldn't that run in to the same kernel issue?
[21:34] <elopio> thanks cory_fu.
[21:35] <cory_fu> elopio: Also, I would expect it to hit https://github.com/juju/charm-tools/issues/303#issuecomment-279615158 at least for --classic snaps
[21:35] <elopio> I don't know how lxd works or what it does to support snaps. I thought it's worth a try, but now I don't have high hopes.
[21:37] <elopio> so many details failing everywhere... At least we are finding them, maybe try again next year :)
[21:37] <kyrofa> elopio, yeah, that'll certainly run into the same problem
[21:39] <cory_fu> elopio: https://bugs.launchpad.net/snappy/+bug/1628289/comments/18
[21:39] <mup> Bug #1628289: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Triaged> <squashfuse (Ubuntu):Confirmed for doko> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
[21:39] <cory_fu> That's disheartening
[21:41] <elopio> cory_fu: well, but doesn't that mean that in trusty you get a xenial lxc and it will work?
[21:41] <cory_fu> I suppose so.
[21:45] <mup> Bug #1663060 changed: Add a title field to snap metadata <Developer registration portal:New> <Snappy:New> <gnome-software (Ubuntu):Confirmed> <snapcraft (Ubuntu):Confirmed> <snapd (Ubuntu):Triaged> <snapd-glib (Ubuntu):Confirmed> <https://launchpad.net/bugs/1663060>
[21:48] <EEight> When upload my snap on myapps.dev : You must wait 1 minute before the next snap-name registration for 16. ???
[21:48] <EEight> After 10 mins, cannot do nothing (no option to click)
[21:51] <kyrofa> EEight, sounds like a question for nessita or noise][1
[21:52] <EEight> kyrofa: my first app uploaded well on myapps.dev, but now I don't understand the error
[21:52] <kyrofa> EEight, there's rate limiting on registering new names so no one can go around registering the world. But it sounds like it's been a long time and you're still unable to register?
[21:53] <EEight> Ok, I see another unrelated error: You must register xxxx name for 16 before uploading, meaning that my filename (.snap) is not the same as the name I registered!? (will try)
[21:54] <EEight> That was it...
[21:54] <popey> EEight: are you all set? need help?
[21:55] <EEight> popey: thanks, just a feedback, it is not clear that you need to register a name exactly like the filename of your .snap is...
[21:56] <kyrofa> EEight, you don't, check the snap.yaml
[21:56] <popey> Interesting, I'll test that with a new app to follow the flow and report bugs where necessary. Thanks for the feedback
[21:57] <kyrofa> EEight, or the snapcraft.yaml. Are you sure the name is the same as the one you registered?
[21:58] <EEight> checking!
[22:02] <EEight> Ok I see, well of course the name in the snap is the same as the filename and then needs to be the same as registered in myapps. Cool
[22:07] <kyrofa> EEight, indeed, but the filename doesn't matter, the store checks the snap.yaml contained within the snap (which gets generated from the snapcraft.yaml)
[22:09] <EEight> popey: I am still not listed in Ubuntu Store under Games, is it because I need to add more info in snap.yaml or maybe because on myapps.dev I didn't select Default type: application?
[22:10] <EEight> Would like also to be listed under Games - Education that would be nice
[22:19] <EEight> Feedback, on Ubuntu 14.04 I can install snapd, then snap install myapp, but then I need to reboot (myapp: command not found, and not in the Application menu)?
[22:20] <popey> EEight: which app did you upload?
[22:21] <popey> EEight: feel free to give me the myapps url and I can take a look at it
[22:21] <popey> ok i see it
[22:22] <EEight> I just put the Default type: Application... not sure what it does
[22:22] <popey> what desktop are you using on 14.04?
[22:22] <EEight> both 14.04 & 16.04
[22:22] <popey> ok and did the icon not show up in either right away?
[22:23] <popey> i have seen others report this, but not seen it myself recently
[22:23] <EEight> 2 problems : 1- not in Ubuntu Store; 2- need to reboot to use my app
[22:23] <popey> it's certainly published, because I just installed it with "snap install <appname>"
[22:23] <popey> you saying it doesnt show in ubuntu software, the graphical app?
[22:23] <kyrofa> Note that the reboot is because /snap/bin isn't in the path in the image, and only gets set once snapd is installed. But you already have an environment by then
[22:23] <EEight> popey: exactly the graphical app
[22:24] <kyrofa> popey, it's in the store, just not in the category, I think
[22:24] <popey> yeah
[22:24] <kyrofa> EEight, right? You can see it in the app, but not in the right category?
[22:24] <popey> yes, there is no category
[22:24] <popey> does that need setting in the store or the desktop file?
[22:25] <popey> Categories=Game;Simulation;
[22:25] <popey> for example in the .desktop file
[22:25] <EEight> kyrofa: in the graphical app (ubuntu software) not there at all, I need to search it (only in 16.04)
[22:25] <popey> EEight: just to confirm, on my 16.04 system, once installed I see the icon, so ou have done nothing wrong there.
[22:26] <kyrofa> Oh, that makes sense
[22:26] <EEight> popey: thx, on 14.04 also I see the icon in the Ubuntu menu (that is after rebooting if just installed snapd)
[22:26] <kyrofa> EEight, I don't think the software center in 14.04 will ever have that ability
[22:26] <EEight> kyrofa: ok
[22:27] <kyrofa> popey, don't you agree?
[22:27] <EEight> what about 16.04?
[22:27] <popey> correct
[22:27] <popey> 14.04 software centre has no snap support
[22:29] <EEight> my .desktop have Categories=game
[22:30] <EEight> maybe that is the problem?
[22:30] <EEight> case-sensitive!
[22:32] <popey> checked a steam game I have installed...
[22:32] <popey> Categories=Game;
[22:32] <popey> and it _does_ appear in the category "Games" in the store..
[22:32] <EEight> thank you so much, do I need to bump my version?
[22:32] <popey> no, just fix and re-upload
[22:32] <EEight> excellent, thank you very much!
[22:32] <popey> and I checked, and one of my games is in the games category
[22:33] <popey> with the Category I mentioned above
[22:33] <popey> no problem, anytime
[22:33] <EEight> popey: do you know how to be in Games / Kids ?
[22:34] <EEight> ok got it KidsGame
[22:34] <popey> I expect there is a list of categories somewhere... lets see
[22:34] <EEight> found a post on stackoverflow
[22:35] <popey> https://standards.freedesktop.org/menu-spec/latest/apa.html
[22:35] <popey> looks like a likely candidate
[22:35] <EEight> Hey thanks better
[22:49] <popey> EEight: i just updated your app and note you've added Categories=KidsGame - but I don't see it in Ubuntu Software. I wonder if you need KidsGame;Game;  ?
[22:50] <EEight> popey: Should I try?
[22:50] <popey> let me install someone elses game and see what they did
[22:50] <popey> one moment
[22:51] <EEight> sweet! I have to pay you a beer
[22:51] <popey> no worries :)
[22:51] <popey> Categories=Game;KidsGame;
[22:52] <popey> thats from raincat (whatever that is)
[22:53] <EEight> Excellent updating, and just like that flush 100mb from my Games (I need to be more careful with assets)!
[22:58] <EEight> All right done, let's see tomorrow (fingers crossed)!
[23:10] <popey> EEight: yay :)
[23:52] <mup> PR snapd#2853 opened: cmd: autoconf for RHEL <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2853>
[23:58] <mup> PR snapcraft#1130 closed: catkin plugin: produce build-ready staging area <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1130>