[00:32] <swluo> helo?
[00:32] <swluo> anyone here?
[00:46] <swluo> hello?
[00:56] <oky> hi swluo
[00:58] <swluo> hey
[00:58] <swluo> i was wondering if you could help me out with some library issues that i've been having
[00:59] <swluo> is there any ways of editing the default SNAP_LIBRARY_PATH
[00:59] <swluo> i'm getting errors when trying to load my shared libraries
[01:09] <swluo> hey qengho
[01:10] <swluo> hey jjohansen
[01:10] <jjohansen> hey swluo
[01:11] <swluo> hey man i was wondering if you can quickly help me out
[01:11] <swluo> do you know if you can edit the default path of the SNAP_LIBRARY_PATH
[01:11] <swluo> i'm having issues loading shared libraries
[01:12] <jjohansen> swluo: sorry that is one I don't know
[01:12] <swluo> mhmm thanks
[01:12] <swluo> too bad
[01:13] <swluo> the documentation could be a lot better for snap
[01:13] <swluo> is it because its soo new?
[01:13] <jjohansen> swluo: is this on trusty?
[01:13] <swluo> nah 16.04
[01:13] <swluo> like i can run it from command line just fine
[01:14] <jjohansen> swluo: yeah snap is a moving target, so its hard to get good docs just yet
[01:14] <swluo> but when i use the snap command it gives me library not ffound
[01:14] <swluo> ahah yeah true true fair enough.
[01:15] <swluo> "cannot open shared object file: No such file or directory."
[01:15] <swluo> and i can't even make symlink for the default path with is annoying as well
[01:16] <jjohansen> oh yes, confinement is great until it gets in the way, and then its at a minimum annoying, and usually a right pita
[01:17] <oky> swluo: it's a symlinked binary and you have the libraries (shared objects) also being packaged?
[01:17] <swluo> well ok like in the .yaml
[01:18] <swluo> i've delcared build-packages: [libsdl2-dev]
[01:18] <swluo> which should give me the proper libraries that it needs
[01:18] <swluo> so i didn't package it together
[01:18] <swluo> will that work?
[01:18] <oky> i wouldn't know if it does or not. maybe you can look at what is in $LD_LIBRARY_PATH from inside your env
[01:19] <swluo> aha its funny cause i tried that
[01:19] <oky> if you open your snap, does it have the .so files that you'd expect?
[01:19] <swluo> from the docs "snap run --shell <snap>.<command>"
[01:19] <swluo> this commant should let me look at the env. but it also gives me errors
[01:19] <swluo> no it does not. because i'm assuming its already downloaded
[01:21] <oky> swluo: well, in most system, 'build packages' would not be included in the final output
[01:21] <oky> for example, in debian, you have build deps which are only required for building the package (but not required for installing it), i might check if that is what is happening here
[01:22] <oky> swluo: just fyi, i am new to snap, so i am not a reliable source of ideas / debugging
[01:22] <swluo> yeah no worries
[01:22] <swluo> anything helps
[01:22] <swluo> just need to bounch ideas off someone
[01:22] <swluo> like do you think it possible to just bundle the library with the snap?
[01:22] <swluo> and somehow refer it then
[01:23] <oky> swluo: can you check if it is building a statically linked binary or a dynamic library?
[01:23] <swluo> its a dynamic library
[01:23] <swluo> like i can't run it using the snap command
[01:23] <swluo> but if i use the absolute path
[01:23] <swluo> it runs just fine
[01:23] <swluo> "concentration  /snap/concentration/x13/run: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory"
[01:24] <swluo> so if i go "/snap/concentration/x13/run" it works
[01:25] <oky> swluo: in your command wrapper, dump env using 'env' command and inspect the vars. compare your current LD PATH and see if where libSDL2 resides now is in the snap's paths
[01:25] <oky> are you running as root or regular user? and is this a snap you are running via the 'try' command or is it installed?
[01:27] <swluo> i'm regular user
[01:27] <swluo> and its being installed everytime
[01:28] <oky> swluo: i just did a search on google for 'snapcraft libsdl2' and came across your SO question, lol
[01:28] <swluo> yeah ahaha!
[01:28] <swluo> i'm at a hackathon soo time is kinda important
[01:29] <mup> PR snapcraft#1106 opened: tests: check the CLA on all the commits <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1106>
[01:29] <swluo> anyways how do you do a dump?
[01:29] <swluo> from the command wrapper
[01:29] <oky> swluo: add the line 'env'
[01:32] <oky> swluo: ok, so: can you check to see if your stage/ has the library files? if it does (and the prime/ does not), you need to manually specify that they are copied over into the prime/
[01:32] <swluo> i don't have any stage library files
[01:32] <oky> where do they exist at all? how is it building?
[01:33] <swluo> so i think i might need to manually copy it into prime
[01:33] <swluo> its building all from parts
[01:33] <swluo> its all building from just one make file
[01:33] <oky> yeah, at each stage, you can specify which files to copy over to the next (or something like that)
[01:34] <swluo> interesting yeah ok i'll try that thanks
[01:34] <swluo> so basically we're back to the original idea of just shipping the library file with teh snap then
[01:34] <swluo> ahah
[01:34] <oky> that's how it would have to be done, though...
[01:34] <oky> unless you are creating a statically linked binary
[01:35] <swluo> mhmm ok maybe i'm just understanding it inocrrectly then
[01:35] <oky> i think (and i'm not certain) that snaps are supposed to be runnable standalone (as though all necessary libraries are included with them)
[01:35] <swluo> mhmm no that makes sense let me try some things out
[01:35] <swluo> you've been great
[01:35] <swluo> cheers
[01:38] <oky> swluo: plz let me know if you get it working, good luck at the hackathon!
[01:38] <swluo> yeah i'll update it here
[01:38] <swluo> are you a fulltimer or a student?
[01:40] <oky> swluo: fte
[01:41] <swluo> where you working? i'm coop at blackberry rn ahahahah
[01:41] <oky> swluo: at one of those big companies that no one likes
[01:42] <oky> there are so many of them, now that i think about it
[01:42] <swluo> ahahaha would you do something else if you could?
[01:43] <oky> swluo: why do you ask?
[01:43] <swluo> idk if this is the stuff i want to do in the future
[01:43] <oky> swluo: i'm in charge of my self, atm, so i'm fine with how things are - i would not trade it, perhaps excepting for 50 mil
[01:43] <swluo> like i'm good at it and its good money
[01:44] <swluo> but i "love it"
[01:44] <swluo> don't*
[01:44] <oky> swluo: take your computer to a relationship counselor
[01:44] <oky> tell the counselor that you've fallen out of love and need to rekindle the spark
[01:44] <swluo> and like i'm just starting sooo its aiiyaaah
[01:44] <swluo> mhmm rando strangers on the internet that my mom says i shouldn't talk to?
[01:45] <oky> swluo: you should read "Disciplined Minds: A Critical Look at Salaried Professionals and the Soul-battering System That Shapes Their Lives"
[01:46] <oky> or at least the wiki page on it
[01:46] <swluo> damn the first review on amazon hit me like a truck.
[01:46] <swluo> thanks for the advice ahah
[01:46] <oky> actually, nvm - wiki page is terrible
[01:47] <swluo> i just brought the book
[01:47] <swluo> ... see this is what happens when you have too much money and no girlfriend to spend it
[01:57] <swluo> btw oky thanks
[01:58] <swluo> i figured it out you're right
[01:58] <swluo> i included all the libraries using a stage
[01:58] <swluo> https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/
[01:58] <swluo> cheers
[02:00] <oky> haha, awesome
[03:01] <diddledan> just updated corebird-diddledan to corebird-1.4.2
[07:19] <mup> PR snapd#2788 closed: store,osutil: use new osutil.ExecutableExists(exe) check to only use deltas if xdelta3 is present <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2788>
[07:31] <mup> PR snapd#2780 closed: tests: increase snap-service kill-timeout <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2780>
[07:36] <mup> PR snapd#2760 closed: merge release 2.22.1 into master <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2760>
[08:10] <mardy> pstolowski: hi! Got a minute to talk about interface hooks?
[08:12] <pstolowski> mardy, hi! sure
[08:13] <mardy> pstolowski: so, I finally succeeded in getting my hook invoked :-)
[08:14] <pstolowski> mardy, great! :)
[08:14] <mardy> pstolowski: now the next question is, how to get information about the client, from within the hook of the socket
[08:15] <mardy> pstolowski: I tried with "snapctl get", but it failed to read the attributes set on the plug
[08:16] <mardy> pstolowski: I'm running this: snapctl get --plug :online-accounts manifest
[08:17] <mardy> pstolowski: where "online-accounts" is the name of the interface, and manifest is an attribute set on this interface in the plug
[08:18] <pstolowski> mardy, can you show me a complete hooks/ content?
[08:18] <mardy> pstolowski: and I get this on stderr, when connecting: error: cannot add authorization: open /home/mardy/.snap/auth.json: permission denied
[08:19] <pstolowski> mardy, that should generally work in my branch (i've a spread test with similar setup)
[08:19] <mardy> pstolowski: I'll push the branch in a minute, I'll ping you
[08:21] <mardy> pstolowski: bzr branch lp:~mardy/webapps-core/iface-hook-test
[08:22] <mardy> pstolowski: the socket is snap/amazon/snapcraft.yaml
[08:22] <mardy> pstolowski: the plug is snap/facebook/snapcraft.yaml
[08:23] <pstolowski> mardy, socket == slot ;)
[08:23]  * pstolowski was slightly confused for a moment
[08:23] <mardy> pstolowski: indeed :-)
[08:31] <pstolowski> mardy, no hooks files there, did you forgot to commit them?
[08:32] <mardy> pstolowski: ehm... :-)
[08:35] <mardy> pstolowski: ok, please pull again
[08:37] <mup> PR snapd#2791 opened: store: use xdelta3 from core if available and not on the regular system <Created by mvo5> <https://github.com/snapcore/snapd/pull/2791>
[08:52] <pstolowski> mardy, ok
[08:52] <pstolowski> mardy, so, the problem is
[08:53] <pstolowski> mardy, you want plug and slot names there, not the interface names; so this will be 'oa', not online-accounts. that applies both to the :names you pass to snapctl, and to the names of the files under hooks/
[08:56] <pstolowski> mardy, or rename oa to online-accounts
[08:56] <mardy> pstolowski: right, makes sense
[08:57] <mardy> pstolowski: thanks a lot, I'll try that
[08:58] <pstolowski> mardy, np. see my test snaps under tests/lib/snaps/basic-iface-hooks-* (in my MP) if in doubt
[08:59] <mardy> pstolowski: btw, would it be possible to get an implicit attribute with snapctl, which is the name of the connecting snap?
[09:00] <mardy> pstolowski: I mean, suppose that that plug doesn't declare any attributes; could the slot hook still infer some info about who's trying to connect?
[09:01] <mardy> pstolowski: the use-case is that we want to make sure that the client really is what it claims to be
[09:02] <pstolowski> mardy, i see what you mean. yes that's easy to do, i wonder if env variables would be good for that. i'll bring it up with niemeyer
[09:03] <mardy> pstolowski: thanks
[09:53] <mup> PR snapd#2763 closed: store: retry on 502 http response as well <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2763>
[10:04] <mup> PR snapd#2761 closed: vendor: move gettext.go back to github.com/ojii/gettext.go <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2761>
[11:22] <adamlove> hi
[11:44] <mup> PR snapcraft#1106 closed: tests: check the CLA on all the commits <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1106>
[11:47] <mup> PR snapcraft#1105 closed: tests: rename the integration test snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1105>
[11:56] <mup> PR snapcraft#1099 closed: catkin plugin: don't pass args to setup.sh <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1099>
[12:05] <mup> PR snapcraft#1107 opened: meta: correct the deprecation for `setup/gui` use <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1107>
[12:33] <lool> ogra_: heya
[12:33] <ogra_> lool, yo
[12:33] <lool> ogra_: what's the cleanest way to put a GRUB config snippet (override kernel cmdline) with the x86 images?
[12:34] <ogra_> create your own gadget
[12:34] <lool> is there no local way?
[12:34] <ogra_> well, you asked for the cleanest :)
[12:34] <lool> (I need it to survive upgrades)
[12:34] <ogra_> you can surely just hack up /boot/grub/grub.cfg
[12:34] <lool> ogra_: hehe, yes
[12:34] <ogra_> we dont update bootloader configs on gadget upgrade currently
[12:35] <ogra_> so whatever you do there should persist
[12:35] <lool> ogra_: would you have an upboard by any chance?
[12:35] <ogra_> nope, never heard of it
[12:35] <lool> kind of a rpi from intel
[12:35] <lool> http://www.up-board.org/
[12:36] <lool> v2 isn't out yet
[12:36] <ogra_> ah
[12:38] <lool> some guys using it have trouble forcing the CPU to max freq, I'm trying to let them set cmdline options to disable it
[12:41] <ogra_> lool, wont work ... we force the ondemand governor
[12:41] <ogra_> from an ancient init.d script
[12:42] <ogra_> (see /etc/init.d/ondemand )
[12:42] <lool> ogra_: well unless we disable it from the kernel cmdline, no?
[12:42] <ogra_> so the CPU will always scale down .. what they could do is build their own kernel with only performance in it
[12:43] <lool> I was actually thinking of disabling the underlying implementation rather than the governor, /me digs the name
[12:43] <ogra_> the script reads /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
[12:43] <lool> intel_pstate=disable
[12:43] <ogra_> if you can make it not appear there it should work
[12:44] <lool> ogra_: for some reason, they can't even set the "performance" governor on this board (it appears, but can't be selected)
[12:44] <lool> my devices here use ACPI, but they have a more recent Intel embedded CPU which does this pstate stuff
[12:44] <ogra_> hmm, thats weird ...
[12:45] <ogra_> yeah, i'm not very familiar with pstate vs cpufreq yet ... i'd ask cking
[12:46] <ogra_> (i dont really have newer intel systems here, only ARMs :) )
[12:47] <lool> well ARM is the new Intel!
[12:47] <lool> soon we'll be looking at some other architecture which is more embedded and wants to displace ARM!  ;-)
[12:47] <ogra_> hehe
[12:50] <zyga> lool: let's skip mips and go to risc ;-)
[12:50] <ogra_> no risc, no fun
[12:51] <zyga> but low-risk risc is fun
[12:52] <davmor2> lool: just get a reflex hammer and strike arms elbow that'll displace it
[12:54] <lool> zyga: I was thinking something lower tech like stones
[12:54] <lool> take two piles of stones together to make an addition
[12:54] <lool> remove stones to make a substraction
[12:54] <lool> throw stones to make a function call
[12:54] <zyga> ubuntu for forests and quarries?
[13:04] <mup> PR snapd#2792 opened: tests: add spread test for delta downloads <Created by mvo5> <https://github.com/snapcore/snapd/pull/2792>
[13:28] <mup> PR snapd#2779 closed: tests: gruntwork backend and suite; task for sync snapd with vendor <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2779>
[13:49] <zioproto> hello #snappy. Can I get help here in pushing packages to the Ubuntu Store ? I have this package with confinement classic that I cant push
[13:59] <zioproto> anyone can help me with this ? :) https://myapps.developer.ubuntu.com/dev/click-apps/6815/rev/4/
[14:00] <uijnoinompo> join
[14:41] <popey> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662181 is this expected behaviour? People have to enable each alias individually?
[14:41] <mup> Bug #1662181: Aliases didn't enable out of the box <snapd (Ubuntu):New> <https://launchpad.net/bugs/1662181>
[14:42] <popey> zioproto: hello, i think jdstrand is the one to ask about that - I note he already replied to one of your uploads though.
[14:43] <morphis> ogra_: when did we drop ppp from the core snap?
[14:43] <morphis> ogra_: we have a dependency on it from the modem-manager snap
[14:43] <morphis> that is why we created the ppp interface
[14:44] <zioproto> popey, do you mean 'This snap is using 'classic' confinement. At this time we have the technical implementation for how to implement classic confinement but the processes for when to grant acceptance in the store is still being worked out. This is actively being discussed and we'll get back to you once the store acceptance policies are defined.'   ????
[14:44] <zioproto> popey, that is a bot answering
[14:45] <popey> zioproto: no, jdstrand is a person :)
[14:46] <popey> ooh, speak of the devil
[14:46] <popey> jdstrand: when you have a moment, zioproto is asking about https://myapps.developer.ubuntu.com/dev/click-apps/6815/rev/4/
[14:54] <jdstrand> popey: that is actually something for ev
[14:56] <popey> ah okay.
[14:56] <popey> thanks
[14:56] <jdstrand> np
[15:04] <zioproto> who is ev ?
[15:05] <zyga> zioproto: evan, why?
[15:05] <popey> zioproto: I'm discussing with him, I'll get back to you asap
[15:05] <zioproto> okay
[15:06] <zyga> jdstrand: hey, I'm ill today; if you have some time please look at C patches, otherwise I'm semi-useless and not making much code
[15:06] <zyga> jdstrand: I know that the kernel has a way to convey bind mounts to userspace now
[15:06] <zyga> jdstrand: I'm coding a routine that does that
[15:11] <mup> PR snapd#2793 opened: Add Maliit input method interface <Created by Elleo> <https://github.com/snapcore/snapd/pull/2793>
[15:11] <mup> PR snapcraft#1103 closed: meta: support for the environment keyword <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1103>
[15:14] <jdstrand> zyga: hope you get better soon
[15:16] <zyga> thanks
[15:17] <mup> PR snapcraft#897 closed: pluginhandler: use an alternate location to organize <Created by josepht> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/897>
[15:17] <mup> PR snapcraft#1064 closed: pluginhandler: support colliding with directories <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1064>
[15:19] <jdstrand> mterry: hey, working through the unity8-session store reviews. note that until the PR lands, I don't think we should issue a snap declaration for unity8 (I'm not sure of the side effects that would have on systems without unity8). I see you already are using only 'mir', and I issued a snap declaration for that
[15:20] <mterry> jdstrand: sorry, you mean allowing unity8-session snap to have those slots?
[15:20] <jdstrand> mterry: I also see that you are using top-level 'slots'. This gives all commands PermanentSlot policy for the mir server. I'm quite sure you do not want this. Please add 'slots: [ mir ]' to the command that needs it
[15:20] <mup> PR snapcraft#904 closed: cleanbuild: use pylxd instead of lxd command line <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/904>
[15:21] <jdstrand> mterry: unity8-session is now allowed to use slot mir
[15:21] <jdstrand> mterry: I think we should wait for it to slot unity8 until the PR lands
[15:21] <mterry> jdstrand: yeah that was because I needed to talk to tedg_ about which of the commands actually need it, but noted
[15:21] <mterry> jdstrand: yah agreed -- I took out the slot
[15:24] <jdstrand> mterry: you are going to receive a few rejection emails until we hit the upload that only slots mir
[15:25] <mterry> Huh...  I was under the impression I had already built and uploaded one of those
[15:25] <jdstrand> it's going to take a few minutes
[15:25]  * mterry rebuilds a new snap
[15:25] <mterry> I mean, I did that on Friday
[15:26] <jdstrand> mterry: you did, but the way the store works is this is a queue of uploads. I need to reject each one that is queued before it
[15:26] <mterry> oh ah
[15:26]  * mterry doesn't build a new snap then
[15:27] <jdstrand> it'll be a few minutes before we are there (fyi, the store team will be improving this process for reviewers)
[15:35] <ogra_> kgunn, http://imgur.com/a/ddqjQ Pi2 ubuntu-core running the unity8-session snap !!!
[15:36] <ogra_> (right monitor)
[15:36] <kgunn> nice!
[15:37] <ogra_> there are font issues and the top panel is completely transparent .... tha console is also spilled with lots of failing/respawning  upstart jobs
[15:37] <kgunn> ogra_: i didn't think pi2 had the right stuff for gpu...
[15:37] <ogra_> but its the first time i get something on display with that snap
[15:37] <kgunn> only pi3
[15:37] <kgunn> very cool
[15:37] <ogra_> i made sure both do now :)
[15:37] <ogra_> after all the changes were identical
[15:37] <kgunn> and yeah, lots of spew
[15:37] <kgunn> re upstart jobs
[15:37] <ogra_> yep
[15:56] <jdstrand> nessita: fyi, bug #1662218
[15:56] <mup> Bug #1662218: Please email store reviewers with changes to classic confinement <Software Center Agent:New> <https://launchpad.net/bugs/1662218>
[15:56] <jdstrand> nessita: and hi!
[16:00] <nessita> jdstrand, hi! I would have thought we did that already, but let me check and/or raise the issue. Thanks!
[16:00] <nessita> roadmr, ^
[16:01] <jdstrand> nessita (roadmr): if you look at the 'Package declaration update' email, it lists plugs, slots, auto-aliases and refresh-control, but not classic. I can't recall ever seeing and email for changes to classic confinement
[16:01] <roadmr> right nessita jdstrand maybe we did that for the other things and not classic... ugh sorry
[16:04] <cory_fu> jdstrand: Thanks for the approval on the juju-crashdump snap.  I had a question re: your comment about LP builds.
[16:05] <cory_fu> I tried to have it build on LP, but it's failing except on ppc64el: https://code.launchpad.net/~johnsca/+snap/juju-crashdump
[16:06] <jdstrand> cory_fu: that seems like a question for the LP team based on, for example, https://launchpadlibrarian.net/305075153/buildlog_snap_ubuntu_xenial_arm64_juju-crashdump_BUILDING.txt.gz
[16:07] <cjwatson> known bug
[16:07] <cjwatson> https://bugs.launchpad.net/launchpad-buildd/+bug/1650946
[16:07] <mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <launchpad-buildd:Triaged> <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1650946>
[16:08] <cory_fu> cjwatson: Ok, thanks
[16:09] <cory_fu> How long after releasing a snap to the stable channel should I be able to see it in `snap find`?  Is there something I can run locally to force a refresh?
[16:09] <cjwatson> Planning to attack that later this week; just need to get an ack from Sergio on the basic approach first
[16:13] <balloons> nessita, might you be able to transfer ownership of the juju snap between ubuntu one accounts?
[16:13] <nessita> balloons, hello! yes, I can do that. What would be the target account?
[16:14] <nessita> balloons, also, please send me an email with the request so I can keep track of the transfers, I'd need source account and target account, with some consent from the target account in there
[16:17] <balloons> nessita, will do. I'll cc both accounts and yourself so you can see consent
[16:18] <nessita> balloons, thank you!
[16:28] <aisrael> stokachu, here
[16:28] <stokachu> whats the best way to get someone who is has ubuntu-core snap installed migrated to the latest core snap?
[16:29] <stokachu> they're on snapd 2.21
[16:29] <stokachu> he can't remove the ubuntu-core snap and snap refresh/install does not seem to handle upgrading from ubuntu-core to core
[16:30] <stokachu> would a simple apt-get remove snapd and reinstall work?
[16:34] <stokachu> zyga, ^ any idea here?
[16:35] <aisrael> stokachu, I removed and reinstalled and now I can install core (previously installed snaps were gone)
[16:35] <stokachu> aisrael, ok cool
[16:35] <stokachu> may be worth trying to reinstall conjure-up now
[16:35] <stokachu> before you do a build
[16:36] <stokachu> aisrael, ^
[16:36] <ogra_> stokachu, yes, that works but removes all already installed snaps alongside ... so handle with care ;)
[16:37] <stokachu> ogra_, is there any upgrade path?
[16:37] <aisrael> stokachu, There were a few leftover symlinks in bin I had to remove. With those gone, conjure-up installed and works
[16:37] <stokachu> aisrael, \o/
[16:37] <ogra_> mvo works on that ... not sure whats the target release for it though
[16:42] <mvo> stokachu: you want to transition ubuntu-core to core?
[16:42] <stokachu> mvo, yea we had a user aisrael who still had ubuntu-core on his system
[16:42] <ogra_> they already did by reinstalling snapd ...
[16:43] <stokachu> mvo, yea he reinstalled snapd which wasn't an issue for him but i was curious what the upgrade path is
[16:43] <mvo> stokachu: please try the snapd from -proposed or run "snap refresh --candidate ubuntu-core" for re-exec magic
[16:43] <stokachu> mvo, ah ok, ill make a note if anyone else runs into that
[16:43] <mvo> stokachu: thank you, please do. keen to get feedback on the auto-migration :)
[16:43] <stokachu> mvo, is there a way i can manually reproduce?
[16:44] <stokachu> can i snap install ubuntu-core on a fresh xenial system with 2.21?
[16:44] <mvo> stokachu: so far it works well but it seems relatively few people are astill having ubuntu-core
[16:44] <stokachu> mvo, yea this was the first case i ran into where someone was still on ubuntu-core
[16:44] <mvo> stokachu: yes, if you have nothing installed you can snap install ubuntu-core
[16:44] <stokachu> mvo, cool ill give it a shot and let you know if i run into an issue
[16:44] <mvo> stokachu: then you can upgrade your snapd or install a newer ubuntu-core that contains the re-exec magic and it will auto-transition you
[16:44] <mvo> stokachu: great, thank you
[16:45] <stokachu> mvo, ah so his issue was he couldnt snap install ubuntu-core
[16:45] <stokachu> or snap refresh ubuntu-core
[16:45] <mvo> stokachu: ohh
[16:46] <stokachu> mvo, snap refresh just told him no updates available
[16:46] <mvo> aisrael: hey, if you were affected by the problem with not being able to install/refresh ubuntu-core, could you please pastebin "journalctl -u snapd" (or mail that output to me). that hopefully gives me a clue why the system behaved strangely
[16:47] <mvo> stokachu: snap changes should show a transition, it may take up to 10min though to start
[16:48] <stokachu> mvo, oh i learned a new command
[16:48] <mvo> stokachu: please paste the snap --version output here so that I can check if the version you have supports the auto migration already
[16:48] <stokachu> snap    2.21
[16:48] <stokachu> snapd   2.21
[16:48] <stokachu> series  16
[16:48] <stokachu> ubuntu  16.04
[16:48] <mvo> stokachu: snap changes is cool, you can also see the individual changes via "snap change N" (with N being the one you want to see)
[16:49] <mvo> stokachu: aha, that is not recent enough, you will need 2.22.X, either from xenial-proposed or "sudo snap refresh --candidate ubuntu-core"
[16:49] <mvo> stokachu: with either one of those the next snap --version output should be higher
[16:49] <stokachu> mvo, ah that is it then
[16:49] <stokachu> yea we're both on 2.21 still
[16:50] <mvo> stokachu: aha, ok. the journal output for snapd from the broken system should have hints what went wrong. i need to leave for dinner now but you can mail it to me at mvo (at) ubuntu.com
[16:51] <mvo> and I have a look (or I will read scrollback when I return :)
[16:51] <stokachu> mvo, sure ill get another system going
[16:53] <test__> ping elopio: test from quassel-webserver snap
[17:04] <stokachu> mvo, https://gist.github.com/battlemidget/e55498a759f14b865c2bfe1e410a022c thats where i ended up at
[17:08] <mvo> stokachu: thanks, lets talk tomorrow but I think snapd 2.22.X will fix it automatically for you
[17:08]  * mvo waves and leaves for dinner
[17:08] <mup> PR snapcraft#1108 opened: Add support for LTS Channels <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1108>
[17:09] <stokachu> yea installing snapd 2.22 from proposed cleaned up my core snaps without an issue
[17:09] <stokachu> doh he left already
[17:16] <cory_fu> I released my snap to the stable channel a couple of hours ago, but still can't install it.  Re-released via snapcraft per the docs and it still doesn't work.  http://pastebin.ubuntu.com/23942129/  Any suggestions?
[17:17] <ogra_> cory_fu, did you check on the store page ?
[17:18] <cory_fu> ogra_: I originally released it via https://myapps.developer.ubuntu.com/dev/click-apps/6876/ and it still says that it's published
[17:18] <ogra_> and it is published in the stable channel ?
[17:18] <cory_fu> ogra_: Yes (see pastebin)
[17:19] <cory_fu> ogra_: NB: it is a classic snap, if that makes a difference
[17:19] <ogra_> oh, it surely does ... i think classic snaps need manual approval in the sotre
[17:19] <ogra_> *store
[17:19] <cory_fu> ogra_: It was approved by jdstrand
[17:20] <mhall119> jdstrand: browser-support is triggering a manual review for a daemin app, I believe I needed it for NodeJS (or somethingJS) that's used by the daemon
[17:20] <mhall119> is there a security concern about allowing that interface for daemons without review?
[17:21]  * mhall119 thinking back, I believe it wasn't NodeJS itself, but something else couchdb does with js, so maybe there aren't that many cases where this will happen
[17:36] <cory_fu> ogra_: Any other advice?  :/
[17:36] <ogra_> cory_fu, well, if the version shows a green box in the UI and you have a channel listed in the details of the version then i dont know
[17:42] <cory_fu> ogra_: Oh, I figured it out!  I had only released the ppc64el version that had managed to successfully build on LP, so it wasn't showing up for me due to arch mismatch
[17:42] <ogra_> aha !
[17:42] <ogra_> yeah, i see it :)
[17:43] <ogra_> congrats !
[17:43] <cory_fu> ogra_: Thanks, and thanks for your help
[17:43] <ogra_> the store UI is an adventure game at times :)
[17:44] <cory_fu> :)  It told me the info I needed, but it just wasn't very prominent
[17:44] <ogra_> yep
[18:02] <mup> PR snapcraft#1109 opened: LP #1662240 (define post-stop-command) <Created by elespike> <https://github.com/snapcore/snapcraft/pull/1109>
[18:06] <jdstrand> mhall119: note, this is a warning, not an error (no difference for human review of course). the browser-support interface is a transitional interface for full-on web browsers (eg, chrome, firefox, webbrowser-app, etc) and it would be unusual for a server to embed a complete web browser. can you remove 'browser-support' and show me the denials?
[18:17] <mup> PR snapcraft#1107 closed: meta: correct the deprecation for `setup/gui` use <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1107>
[18:22] <jdstrand> mterry: ok, all revisions with only slots: mir are approved but not released
[18:22] <jdstrand> (and the other rejected)
[18:23] <mhall119> jdstrand: = Seccomp =
[18:23] <mhall119> Time: Feb  6 13:22:11
[18:23] <mhall119> Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=32209 comm="couchjs" exe="/snap/couchdb/x15/rel/couchdb/bin/couchjs" sig=31 arch=c000003e 141(setpriority) compat=0 ip=0x7f465ca61177 code=0x0
[18:23] <mhall119> Syscall: setpriority
[18:23] <mhall119> Suggestion:
[18:23] <mhall119> * add one of 'browser-support, process-control' to 'plugs'
[18:23] <mterry> jdstrand: I don't think I have access myself to the store page -- will future auto-uploads pass through without the manual review process?
[18:23] <mhall119> fwiw, it's only happening when I try to run couchdb's builtin health check
[18:23] <mterry> jdstrand: (thanks for clearing the queue btw)
[18:24] <jdstrand> mterry: yes. if you want, I think I can press the 'release' button
[18:24] <mterry> jdstrand: sure that saves a rebuild, thanks!
[18:25] <jdstrand> mhall119: use process-control instead, not that 2.23 will have policy that may allow you to drop process-control
[18:25] <jdstrand> s/not/note/
[18:27] <mhall119> thanks jdstrand
[18:28] <linuxhiker> Is there a way to see what platforms a particular snap is available for?
[18:29] <jdstrand> mterry: ok, released all to 'edge'
[18:30] <mterry> cheers
[18:36] <linuxhiker> Would that be a no?:D
[18:41] <mup> PR snapd#2784 closed: image: check kernel/gadget publisher vs model brand, warn on store disconnected snaps  <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2784>
[19:05] <balloons> stokachu, did you see my note about bash completion with your snap?
[19:13] <stokachu> balloons, nah
[19:13] <stokachu> balloons, you get it working?
[19:13] <balloons> stokachu, I couldn't get what you'd check in to build, but I believe it will work with the addition I made
[19:14] <stokachu> balloons, you got a diff or PR for me?
[19:14] <balloons> stokachu, sure. Let me find the repo
[19:17] <stokachu> balloons, if we get this working are we advertising pure snaps for the next release announcement?
[19:17] <balloons> it has my vote stokachu
[19:17] <stokachu> yay
[19:17] <stokachu> balloons, im getting a testsuite done this week too
[19:20] <stokachu> balloons, ill take a diff to whatever is easier for you
[19:20] <stokachu> or just the entire file and ill merge it
[19:21] <balloons> stokachu, basically you are missing the bash completion file for 'juju'. It needs to be named 'juju'
[19:21] <balloons> as that is what it will go looking for. The 2 bins we're shipping (well, one bin for you I guess?) is juju and juju-2
[19:21] <balloons> found the diff
[19:22] <balloons> stokachu, https://pastebin.canonical.com/178372/. You can see I had trouble with the source dump location. But I trust the rest more or less makes sense
[19:22] <balloons> stokachu, essentially cp etc/bash_completion.d/juju-2 $SNAPCRAFT_PART_INSTALL/usr/share/bash-completion/completions/juju
[19:23] <balloons> I *think* that will make it work
[19:24] <stokachu> ah i think i did that earlier
[19:24] <stokachu> lemme double check
[19:26] <stokachu> balloons, building again but i did already do this one min
[19:26] <stokachu> balloons, make sure you're using snapcraft from master
[19:26] <stokachu> just git clone https://github.com/snapcore/snapcraft; and access snapcraft/bin/snapcraft
[19:28] <stokachu> balloons, once you do that then clone https://github.com/conjure-up/conjure-up and try to build again
[19:28] <stokachu> that should work
[19:31] <balloons> stokachu, ahh, the snap/snapcraft is supported now
[19:31] <stokachu> yea
[19:32] <balloons> cool, so I can play more if needed
[19:32] <stokachu> yea im building the latest now and going to test it again
[19:45] <stokachu> balloons, yea that change didnt work either :(
[19:45] <stokachu> no idea what im missing
[19:46] <Blu2> ohmygiraffe update :D
[19:46] <stokachu> anyone else familiar with bash completion inside a snap?
[19:47] <mcphail> stokachu: I've been wondering how to implement that!
[19:47] <stokachu> we copy our files here: https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml#L63-L65, and source them https://github.com/conjure-up/conjure-up/blob/master/snap/wrappers/juju#L8-L9
[19:47] <stokachu> mcphail, yea we're hitting some kind of issue even after we source the completion
[19:48] <stokachu> mcphail, ^ should give you some kind of idea of how we're doing it if youre curious
[19:48] <stokachu> just doesn't work quite yet
[19:48] <mcphail> stokachu: cheers! I'll have a look
[19:49] <mcphail> stokachu: that way isn't going to work, though, is it? Surely that will just source the completion from the subshell, rather than the shell you're using to call the program?
[19:50] <stokachu> mcphail, ah
[19:50] <stokachu> yea bash completion would need access to the binary and not the wrapper
[19:51] <stokachu> hmmmm, what if i put it in /etc/bash_completions.d/
[19:51] <mcphail> stokachu: completion is done by the shell you use to call the snap. But completion isn't loaded into that shell. You'd need access to a completions directory, as you say
[19:52] <mcphail> (and that isn't allowed, afaik)
[19:52] <stokachu> mcphail, we use a classic snap so maybe we can?
[19:52] <mcphail> stokachu: aah. I haven't looked at classic snaps yet
[19:53] <stokachu> does bash completion have a ENV variable we can alter?
[19:53] <Blu2> I noticed that snaps are not allowed to link to a website using the default browser
[19:53] <stokachu> i couldnt find anything in the docs about it
[19:54] <mcphail> stokachu: you know /etc/bash_completions.d/ is deprecated for all packages anyway?
[19:54] <stokachu> mcphail, ah i do now :)
[19:54] <mcphail> `pkg-config --variable=completionsdir bash-completion
[19:54] <mcphail> should give the up-to-date one
[19:55] <stokachu> ah perfect
[19:55] <stokachu> so we put those completion in that directory now
[19:55] <stokachu> but that's within the snap
[19:56] <mcphail> Yes. Nothing useful is going to see that
[19:57] <stokachu> and there doesn't seem to be a way to make bash completion look in an alternative directory
[19:57] <mcphail> I think there needs to be a hook for completions
[19:58] <balloons> stokachu, I also got the snap built, but it's not providing juju
[19:58] <stokachu> balloons, you gotta run snap alias
[19:59] <stokachu> balloons, and make sure you dont have the deb juju installed otherwise it'll make you think you got it working :)
[19:59] <balloons> stokachu, sorry snap lied: snap list aliases error: no matching snaps installed. Trying again, I suddenly see the aliases for conjure-up and lxd
[19:59] <stokachu> balloons, ah
[20:01] <balloons> stokachu, nothing in /usr/share/bash-completion/completions/
[20:01] <balloons> so the hook didnt work. this is the problem I had
[20:01] <stokachu> balloons, yea they would be in $SNAP/usr/share/bash-completion/completions
[20:01] <balloons> they can't go there. They need to be in the right place
[20:02] <stokachu> so you could try taking out $SNAPCRAFT_PART_INSTALL
[20:02] <stokachu> it'd have to go in a different hook though not the install
[20:03] <stokachu> i think mcphail is correct though there needs to be a hook for it
[20:04] <stokachu> they have to live outside of the snap
[20:04] <stokachu> balloons, we could put it in the hooks/configure script
[20:04] <balloons> stokachu, yes, I was trying in the configure hook
[20:05] <balloons> I thought you were too
[20:05] <stokachu> oh lemme check
[20:05] <stokachu> maybe i did
[20:05] <balloons> I just hit build, I've no idea :p
[20:06] <stokachu> building now i didnt have it in there
[20:10] <stokachu> balloons, pushed a new update to the master branch
[20:10] <stokachu> that copies the files to the hosts system
[20:11] <stokachu> balloons, so that section where it's detecting which juju binary to use
[20:12] <stokachu> balloons, https://github.com/juju/juju/blob/staging/etc/bash_completion.d/juju-2.0#L339-L350
[20:12] <stokachu> balloons, do you need to add the /snap/bin/juju path too?
[20:13] <stokachu> balloons, yea changing the last line's path to /snap/bin/juju makes it all work
[20:14] <balloons> for realz?
[20:14] <stokachu> balloons, yep
[20:14] <balloons> woot
[20:14] <stokachu> balloons, so if you could get the updated completions pushed to branch 2.1 ill rebuild with it all
[20:14] <stokachu> or i can just include it as a file in the snap
[20:15] <stokachu> i can also make a new section and just pull from juju master for the completion stuff
[20:15] <mup> PR snapcraft#1101 closed: misc: consistently use a dash for copyright years <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1101>
[20:16] <balloons> stokachu, hmm, let's have a think
[20:16] <balloons> I need the same for the juju snap
[20:17] <stokachu> balloons, yea
[20:21] <stokachu> balloons, worse case i can do some sed magic to replace /usr/bin/juju with /snap/bin/juju
[20:23] <balloons> stokachu, ok, so it's what I was thinking. We should just add a check for /snap/bin/juju as well
[20:23] <balloons> It checks $gopath as well for example
[20:25] <stokachu> balloons, yea
[20:26] <mup> PR snapd#2789 closed: overlord/devicestate: backoff between retries if the server seems to have refused the serial-request <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2789>
[20:28] <balloons> stokachu, awesome. So we have a complete snap story then?
[20:28] <stokachu> balloons, yep just as soon as you update the bash completion in the upstream code
[20:28] <stokachu> i can pull that down and install it
[20:28] <balloons> I'll make a PR with it and the tweaked snap
[20:29] <stokachu> balloons, cool once that lands we'll be in good shape
[20:29] <balloons> stokachu, did you push what worked for you for conjure-up?
[20:29] <stokachu> ill create a seperate section to pull from master for it as well unless you think it'll make it into the beta5 branch?
[20:29] <stokachu> balloons, yea thats pushed upstream
[20:30] <mcphail> stokachu: you got it working?
[20:30] <stokachu> mcphail, yea, basically what you said we had to put it in the hooks/configure in the snap build
[20:30] <stokachu> and install it to /usr/share/bash../
[20:31] <mcphail> stokachu: aah. Is tehre any way to clean it up if the snap is removed? Thinking we really do need some form of hook
[20:33] <stokachu> mcphail, unfortunately there isn't a cleanup hook for snaps, it has been asked a few times to incorporate that so i think that discussion is ongoing
[20:33] <stokachu> a uninstall hook would be nice
[20:33] <stokachu> i think the fear is making building snaps to complicated by going down that road
[20:33] <mcphail> stokachu: shame. Would be nice to have that. I'll need to check out these classic snaps. Seems to give more freedom
[20:34] <stokachu> mcphail, yea tons of freedom though at a cost like what you see here
[20:34] <mcphail> Ideally, it would be good to have a hook to deal with completions/man pages etc
[20:35] <stokachu> mcphail, so i think mayb esomething like https://github.com/snapcore/snapd/wiki/Content-Interface
[20:36] <stokachu> though i don tknow if that addresses the issue of putting it outside the $SNAP
[20:39] <mcphail> stokachu: Don't think that is a complete solution, but is certainly a start. Would be interesting to have a virtual filesystem overlaid on the completions directory which would give access to these slots
[20:40] <stokachu> that would be cool
[20:41] <stokachu> balloons, ping me when you get a pr up so i can subscribe to it
[21:02] <Fohlen> heya there. I have an application that builds a binary folder with plenty of assets it as well needs to start the executable in the bin* folder. I didn't yet understand how am I supposed to copy the folder from my parts into the stage and the command does not ship a make install command
[21:03] <mup> PR snapd#2794 opened: tests/lib/fakestore/refresh: some more info when we fail to copy asserts <Created by pedronis> <https://github.com/snapcore/snapd/pull/2794>
[21:04] <qengho> Fohlen: Hi! Is the build system unique?
[21:05] <Fohlen> qengho: it's conan
[21:05] <Fohlen> and produces cmake in the end
[21:05] <Fohlen> https://www.conan.io/
[21:05] <qengho> Ah, I know cmake.
[21:05] <Fohlen> basically what I would like snap to do is copy the bin folder and make it executable
[21:07] <qengho> Fohlen: Put your snapcraft.yaml in a pastebin so we can see. Someone, perhaps not me, might have an idea what you need to do.
[21:08] <Fohlen> http://pastebin.com/HEb3z1Sv
[21:12] <mup> PR snapcraft#1110 opened: Show error messages for snap processing errors <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1110>
[21:15] <robert_ancell> Is ./run_checks no longer used for snapd? It's reporting bad formatting in master
[21:25] <qengho> Fohlen: Hi. First, you probably don't need your "stage-packages" as staged packages, because those are ones that go into your snap. You only need most of those for building. That's a different object, "build-packages:", I think.
[21:26] <qengho> Fohlen: Then, your filesets: object doesn't do anything. That just gives some things a name "binaries", and you don't use that name anywhere.
[21:30] <Fohlen> qengho: http://pastebin.com/Dfebej1d
[21:30] <Fohlen> trying this now.
[21:39] <mup> PR snapd#2795 opened: Only add aliases field when we have aliases <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2795>
[21:48] <mup> PR snapd#2794 closed: tests/lib/fakestore/refresh: some more info when we fail to copy asserts <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2794>
[21:48] <oky> which org is behind snapcraft, btw?
[21:49] <oky> is it canonical? what is yocto?
[21:51] <mup> PR snapcraft#1111 opened: tests: rename the waf test snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1111>
[22:21] <kyrofa> oky, indeed, canonical is behind snapcraft
[22:27] <oky> kyrofa: ok, interesting. is there a discussion of the potential downsides of snapcraft that i can refer to? just things to know before i use it
[22:27] <oky> (common pitfalls would be useful, too)
[22:28] <kyrofa> oky, all the docs are on snapcraft.io
[22:28] <oky> i think i've read a lot of them, curious to find things like project philosophy and motivation
[22:28] <oky> (i do see snapping philosophy doc, don't worry)
[22:29] <kyrofa> oky, perhaps its README would be helpful? https://github.com/snapcore/snapcraft
[22:30] <oky> kyrofa: it is, yes - but it seems like perhaps there were a lot of design docs or internal discussion that
[22:30] <oky> is unavailable
[22:31] <kyrofa> oky, I'm not really sure what you're looking for then, I'm sorry
[22:32] <oky> kyrofa: things like: "what is current support on other distributions", "what are potential downsides of using snaps", "how do pin a snap to a specific version", "who is doing the vetting"
[22:32] <kyrofa> oky, snapcraft is only a packager of snaps. It sounds like you're looking for the philosophies behind snaps themselves
[22:32] <oky> i really like what i am seeing about snaps, they appear to be recipes that create statically installable packages akin to .dmg files
[22:32] <oky> kyrofa: yes, that must be it
[22:33] <kyrofa> That's like expecting pbuilder to document the rational behind the deb format
[22:33] <oky> kyrofa: so, there's a seperate site for docs on snaps?
[22:33] <oky> kyrofa: i'm not blaming or accusing, just looking for more info - and yes, i am confused about the two names. i've seen snappy, snap, snapd and snapcraft. the only docs i've read are the snapcraft ones
[22:34] <kyrofa> oky, there isn't one place that answers all your questions, but I can point you in a few different directions to obtain answers
[22:34] <oky> kyrofa: thanks!
[22:35] <kyrofa> oky, first of all, the current distro support matrix is here: https://github.com/snapcore/snapd/wiki/Distributions
[22:36] <mup> PR snapcraft#1112 opened: core: setup core to support classic confinement <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1112>
[22:36] <kyrofa> oky, as far as potential downsides, there are a few AskUbuntu questions about them but the answer is really opinion-based
[22:37] <kyrofa> oky, there are a few downsides I can list off: dependencies are bundled so they tend to be larger than, say, a deb would be. Developing them can be a little different because, as you noted, they are read-only images with defined writable areas and not all software is used to working that way
[22:39] <kyrofa> I'm not sure pinning is supported, but there are some features coming that will get you closer
[22:39] <kyrofa> As far as who is doing the vetting, I'm not quite sure I understand the question
[22:40] <oky> kyrofa: the concern with 'pinning' is regarding having a set of packagers with expertise vetting their work vs. anyone self publishing. with packagers, its a little more assured that new version should not break things, but self publishing leads to weirdness with deps between parts, etc
[22:40] <kyrofa> oky, there are no dependencies with snaps, at least not in that sense
[22:40] <oky> pinning (or custom repos) appears to be a compromise to sticking to a specific version (and having that version available at some later data, ideally), which is why i asked about it
[22:41] <oky> kyrofa: even if there are no direct deps or compile time, there inevitably will be deps or linked packages (imo)
[22:41] <kyrofa> oky, of course, but they're contained within the same snap
[22:41] <oky> kyrofa: interesting, ok - so, the store would have many different versions for each package depending on the config desired
[22:42] <oky> kyrofa: thanks for taking the time
[22:43] <kyrofa> oky, that depends on the package I suppose
[22:43] <kyrofa> oky, for example, there's a Nextcloud snap that bundles mysql and apache. There is _not_ a nextcloud snap that uses nginx instead
[22:44] <kyrofa> Nothing is stopping that, but nextcloud only supports that one setup
[22:44] <oky> kyrofa: i'm thinking of an example more like: package + data dependencies. maybe there is a package of geoip data and you can buy addon packs
[22:45] <oky> anyways, it's all tangential - not that important to my other questions
[22:46] <kyrofa> oky, that's probably a use-case for the (very limited) sharing that can happen between snaps. That's called the `content` interface
[22:46] <oky> it seems like the snaps should ideally prevent lots of bugs and make it so that security flaws in out dated libraries are still contained in what damage they can do
[22:46] <kyrofa> Indeed
[22:46] <oky> so in the end, its still an improvement in security (maybe)
[22:46] <kyrofa> That's the idea anyway
[22:47] <oky> i was trying to imagine what happens when the next large networking bug comes along and threatens a bunch of packages
[22:50] <kyrofa> oky, well, let's walk through that using the Nextcloud example
[22:51] <kyrofa> oky, let's say the bug was so bad as to grant a shell with the Apache permissions
[22:51] <bdmurray> lsb_release crashes on Ubuntu Core 16 - where should that be reported?
[22:51] <kyrofa> Which is pretty much as bad as it can get
[22:51] <kyrofa> What happens?
[22:52] <bdmurray> http://pastebin.ubuntu.com/23944029/
[22:52] <oky> kyrofa: how does nextcloud enforce that the user is 'apache' user?
[22:52] <oky> i'm looking through https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml to see how they manage permissions
[22:52] <kyrofa> oky, nope, it's root
[22:53] <kyrofa> oky, however, even though it's root it's still under confinement
[22:53] <kyrofa> oky, which means they can access the network and the writable areas of the snap
[22:53] <kyrofa> oky, they can't alter anything contained within the snap because it's by definition read-only
[22:53] <oky> kyrofa: and the confinement is via SElinux? ima? app armor?
[22:54] <kyrofa> appamor, seccomp, and cgroups
[22:54] <kyrofa> oky, the worst they can do is mess with the data of the nextcloud snap. They can't touch the rest of the system
[22:57] <kyrofa> oky, and there's nothing they can do to prevent the next snap update from happening, which would hopefully contain a fix
[22:57] <oky> kyrofa: and does app armor support integrity checks via hardware? (TPM, for example)
[22:58] <kyrofa> That I don't know
[22:58] <oky> ok, it's also tangential
[22:58] <mup> PR snapd#2796 opened: Fix checks failing on code formatting <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2796>
[22:59] <kyrofa> oky, also, to clarify terminology: snapd is the daemon behind the snap format. It's in charge of mounting snaps into place, running their services, handling updates, etc
[22:59] <oky> kyrofa: thanks for all the info, i'm looking forward to seeing wider adoption on other platforms
[22:59] <kyrofa> oky, snapcraft is a packager. It allows one to create snaps
[22:59] <kyrofa> oky, "snappy" is just referring to the whole system
[22:59] <oky> kyrofa: ok, i'll try to remember their distinct usages
[23:18] <mup> Bug #1662357 opened: Can't use lsb_release on Ubuntu Core 16 <Snappy:New> <Snappy Ubuntu Core:New> <lsb (Ubuntu):New> <https://launchpad.net/bugs/1662357>
[23:30] <mup> PR snapcraft#1111 closed: tests: rename the waf test snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1111>


[09:00] <crevette> hey tseliot
[09:00] <tseliot> crevette: hi
[09:01] <crevette> tseliot, I've been said to contact you by seb128 about bluetooth upload, that's true ?
[09:01] <tseliot> crevette: bluetooth?
[09:02] <crevette> yes
[09:02] <tseliot> maybe you should talk to superm1 about it
[09:02] <crevette> excpet if I've been mistaken
[09:02] <crevette> okay
[11:32] <tjaalton> https://blueprints.edge.launchpad.net/ubuntu/+spec/xorg-jaunty
[12:10] <crevette> tjaalton, you're at UDS?
[12:12] <crevette> tjaalton, does usplash is compatible with KMS or there is nothing related?
[12:46] <tjaalton> crevette: plymouth will replace usplash
[12:47] <crevette> Okay, so plymouth would be a dependency for this spec
[12:47] <tjaalton> probably
[19:47] <bryce> tjaalton: any ideas on bug 303177?  I've been able to reproduce the issue on one of my dev boxes
[19:50] <tjaalton> bryce: well, the version in experimental built against drm-snapshot does get that dependency, but I couldn't find anything special about drm-snapshot which would explain it
[19:51] <bryce> is it strictly an issue of the dependency not getting picked up?  can we force it in the -intel Depends?
[19:53] <tjaalton> we sure can
[19:58] <bryce> I'll give that a try then
[20:00] <bryce> huh that worked
[20:01] <tjaalton> surprise?
[20:04] <bryce> wasn't expecting for it to be quite so easy
[20:05] <bryce> guess I overestimated the bug reporters' troubleshooting capabilties ;-)
[20:07] <bryce> feels like we're missing something though.  Wouldn't debian have needed the depends as well?
[20:08] <tjaalton> no, the libdrm-dev/intel1 shlibs/symbols should ccover this
[20:08] <tjaalton> -c
[20:09] <bryce> alright, Depends uploaded.
[20:09] <bryce> we can revert that once the libdrm symbols are fixed up
[20:10] <tjaalton> yep
[20:11] <bryce> heh, I'd allocated most of the day to work on that ;-)
[20:11] <bryce> tjaalton: oh hey, last night I started working on a new launchpadlib tool, to retarget bugs filed against xorg
[20:12] <bryce> so like, if they mention intel in the title --> xserver-xorg-video-intel
[20:12] <bryce> or if they mention "crash|freeze" --> xorg-server
[20:13] <bryce> problem is that launchpad doesn't have an api routine for actually re-targeting a bug
[20:13] <bryce> I could add a new bug-task, and then invalidate the xorg one, but that seems sloppy
[20:14] <tjaalton> yeah, and might break email filtering
[20:14] <tjaalton> for me it would :)
[20:14] <bryce> anyway, I filed a bug against launchpadlib for the feature.  we'll see if that comes
[20:15] <bryce> in my dry runs, it was targeting around 200 bugs to be moved
[20:15] <tjaalton> cool
[20:15] <bryce> one unsolved issue is that most bug reporters don't seem to know to distinguish between -nvidia/-nv and -ati/-fglrx, so in those cases it's sort of ambigious where to move them to
[20:16] <bryce> but I figure even putting them into the wrong queue would be better than leaving them ignored in xorg ;-)
[20:18] <tjaalton> heh, right
[23:15] <bryce> which nvidia package maps to NVIDIA GLX Module  169.12 ?  Is that -177?
[23:18] <tjaalton> 168.12 :) (nvidia-glx-new in hardy)
[23:18] <tjaalton> make that 169
[23:19] <bryce> ahh
[23:19] <bryce> ok, I misfiled some bugs against -177 then.  but hopefully someone can catch those
[23:19] <bryce> (just 2-3)
[23:20] <tjaalton> what the.. banshee lost the ability to sync my ipod
[23:21] <tjaalton> duh
[23:21] <tjaalton> no new music for the trip then
[23:26] <bryce> wow that sucks
[23:26] <bryce> what airline are you flying?
[23:26] <bryce> NWA international flights have nifty linux-based seat-back movie player thingees
[23:26] <tjaalton> Finnair & British Airways
[23:28]  * bryce finishes retargeting xorg crash bugs
[23:28] <tjaalton> I've got a book about polymer tech. and some handouts to read :)
[23:29] <bryce> knocked xorg down by a few dozen.  mostly moved to xorg-server, some to drivers
[23:30] <crevette> tjaalton: you can use rhythmbox
[23:30] <bryce> sad how many crash bugs don't have full backtraces.  I really need to get that signal handling support hooked up.
[23:31] <bryce> I wish X's automatic traces provided full info
[23:32] <crevette> good night
[23:32] <tjaalton> rb does not support syncing
[23:33] <tjaalton> bryce: 1.6 should do that already AIUI
[23:33] <bryce> oh??  8-)
[23:33] <bryce> let's get 1.6 in then!  :-)
[23:35] <tjaalton> yeah, next week :)
[23:35] <tjaalton> right, thanks rb, I really want to get 4568 duplicates on my ipod
[23:35] <tjaalton> and no way to stop that from happening
[23:40] <tjaalton> oh well, 4h before I have to wake up and get to the airport..
[23:41] <tjaalton> see you at the hotel then :)
[23:46] <bryce> have a good flight tjaalton, see you there :-)


[20:52] <stgraber> highvoltage: I'm dropping arkose for 14.04, so I removed the slide, the seed entry and I'm about to file an archive removal bug.


[07:51] <jamespage> gnuoy, based on your +1 of my wily python bootstrap fix yesterday, are you ok for me to land the same change across all of the charms with appropriate unit/lint/amulet +1's?
[07:51] <jamespage> I could give you all of the MP's but there are quite a few
[07:51] <gnuoy> jamespage,RS +1 for the rest
[07:51] <jamespage> gnuoy, ta
[07:51]  * jamespage goes todo some landing
[14:04] <jamespage> thedac, coreycb, ddellav, gnuoy: working through action upgrade landings pm today
[14:05] <coreycb> jamespage, ah great thanks
[14:06] <coreycb> jamespage, wolsen's been reviewing too. note that we can't call register_configs() in the action, we need to import CONFIGS instead so some of the mp's need updates.
[14:07] <jamespage> coreycb, so like - https://code.launchpad.net/~thedac/charms/trusty/swift-storage/action-managed-upgrade/+merge/272046
[14:07] <jamespage> that's ok right?
[14:07] <coreycb> jamespage, yep that one's good
[14:15] <jamespage> coreycb, ok - I still see some ones need updating
[14:28] <thedac> jamespage: swift-storage is good. The rest of mine still need fixing. I got stuck yesterday on nova cc. I can't quite figure out what I need to mock to allow importing of the openstack_upgrade. I may skip this one and get the others ready.
[14:29] <jamespage> thedac, ack - and where did you guys get to last week on service status stuff?
[14:29] <jamespage> (just catching up)
[14:30] <thedac> The CH bits are landed. And I demonstrated to our team but no further. Action upgrades was the priority
[14:38] <thedac> openstack-dashboard should be good now
[14:41] <thedac> and neutron-gateway should have started with those. :) Now back to the grind with nova cc
[16:10] <thedac> jamespage: nova-cloud-controller done. I finally looked at the git_install example which layed out exactly what I needed. :p
[17:19] <cholcombe> anyone know if you can deny juju storage from detaching a disk?
[17:20] <rick_h_> cholcombe: hmm, does storage support blocks?
[17:21] <cholcombe> i have no idea
[17:21] <cholcombe> i'm thinking when a disk is being detached i might want to prevent it until i know it's safe
[17:22] <cholcombe> rick_h_, if i'm down to 2 out of 3 disks in my replica set and another disk is being detached i want to stop that
[17:22] <cholcombe> rick_h_, that reminds me i need to create another task for myself
[17:22] <rick_h_> cholcombe: if you could it would be a block https://jujucharms.com/docs/1.24/juju-block
[17:23] <rick_h_> cholcombe: I just noticed I don't have the PPA and 1.25 on this machine thuogh so not able to test that list out
[17:23] <cholcombe> i'm running 1.24.x
[17:23] <rick_h_> cholcombe: if not, might be worth a juju email thread.
[17:23] <rick_h_> alexisb: ^
[17:24] <rick_h_> cholcombe: yea, storage is a feature flag in 1.24 though right?
[17:24] <cholcombe> rick_h_, thanks.  If we can block that will prevent possible disasters
[17:24] <cholcombe> rick_h_, i believe so
[17:25] <rick_h_> cholcombe: yea, not seeing it in the list and it's not part of the general config block-able stuff https://jujucharms.com/docs/1.24/config-general#alphabetical-list-of-general-configuration-values
[17:25] <alexisb> cholcombe, there were many improvements to storage in 1.25
[17:25] <alexisb> cholcombe, I can send you a list
[17:26] <alexisb> and your best expert on this is axw
[17:26] <rick_h_> cholcombe: alexisb I think the question is does storage support or plan on supporting blocks on it
[17:26] <cholcombe> alexisb, ok yeah i was chatting with him last night.  he's on aussy time
[17:26] <cholcombe> alexisb, i'll see if i can catch him later today
[17:26] <rick_h_> cholcombe: if you chat with him let me know what you find out
[17:27] <cholcombe> rick_h_, will do :)
[17:27] <cholcombe> rick_h_, this will necessitate functions to tell whether it's safe to remove a disk.  That's tricky with ceph
[17:27] <rick_h_> cholcombe: well what would happen is yo'd block it and if someone tried to do something that killed it it would stop and say no
[17:28] <rick_h_> cholcombe: and you'd have to manually remove the block to continue
[17:28] <cholcombe> right
[17:28] <cholcombe> rick_h_, it's best effort right?  people can still just yank the disk
[17:28] <rick_h_> cholcombe: yes, this is all only within juju
[17:28] <firl> Any openstack charmers on?
[17:29] <marcoceppi> firl: there are dozens of us! I'm not one, but I'm dangerous enough to answer questions. Best to just ask
[17:29] <firl> haha thanks marcoceppi
[17:29] <firl> I specifically want to branch / know the best way of getting mellanox support into the trusty/juno stack for neutron,nova, and ceph
[17:33] <marcoceppi> firl: well first off, all the core openstack charms are the same codebase, so the charms in trusty, vivid, precise, wily, etc are the same and that same code base models strategies for Icehouse -> Liberty
[17:34] <firl> it’s all in bazaar too?
[17:34] <marcoceppi> firl: the development workflow is modeled here: https://wiki.ubuntu.com/ServerTeam/OpenStackCharms
[17:35] <marcoceppi> firl: it's all in bzr atm, but they are moving to include the charms in git, not sure the process of that beisner coreycb jamespage ^?
[17:36] <firl> thanks marcoceppi for the link, I don’t know the best way to integrate the mellanox side. I figured I would just make it a boolean config value with sane defaults to start
[17:37] <coreycb> firl, marcoceppi: james is working on moving the charms to git but I don't think we're there yet.  so I'd use bzr for now.
[17:37] <firl> kk
[17:38] <coreycb> firl, jamespage or gnuoy would be best to ask about mellanox but you might need to hit them up earlier tomorrow since they're probably EOD now
[17:38] <firl> gotcha
[18:29] <marcoceppi> bcsaller cory_fu I've got some questions about the charm gen/layers stuff around best practices
[18:29] <cory_fu> Sure
[18:29] <bcsaller> go for it
[18:29] <bcsaller> I am sure there are some things we can do to make it easier
[18:30] <marcoceppi> bcsaller cory_fu so this is my first stab https://github.com/marcoceppi/mysql-charm-layer
[18:31] <marcoceppi> one thing I tried to do was create a helpers directory in the reactive dir to house my charm specific code that I didn't want cluttering my mysql.py file in reactive
[18:31] <marcoceppi> but that didn't work for imports, so I put it in lib/helpers, though I can see this as being potentially a problem/conflict
[18:32] <marcoceppi> so I was curious if there was a pattern already for where to house this code, the idea being that they're generic MySQL helpers (install_mysql, create_database) that other layers could utilize via importing
[18:32] <marcoceppi> there are almost things that were once in charmhelpers.contrib.mysql actually
[18:33] <cory_fu> I think lib makes sense, then.  Maybe lib/helpers/__init__.py could be created in base, if that's a common namespace, though you could also have used mysql_helpers
[18:34] <marcoceppi> I despise underscores in general, so I just used a directory to namespace, but to your point I could creaet mysql_helpers.py in lib?
[18:34] <bcsaller> marcoceppi:  off the top of my head there are a few ways this could play out. One, we talked about namespaces for newer charm helpers, so they can be different repos but still packaged and pushed to pip. I that case you might add a pip import trigger to your layer in /lib for example
[18:34] <bcsaller> marcoceppi: you can see the base layer does this to include its deps
[18:35] <bcsaller> I wouldn't mind if CH made its own namespace and other packages added to that
[18:35] <marcoceppi> bcsaller: I did see that, these aren't actually in the contrib library, and while somewhat generic they are verioned/released with the layer which is why I opted to have it as an included dep
[18:35] <bcsaller> ahh ok
[18:35] <marcoceppi> embeded*
[18:36] <cory_fu> marcoceppi, bcsaller: We could certainly have a lib/charms/ namespace directory in base so that layers could easily add packages to that namespace without creating a separate, external library
[18:36] <bcsaller> cory_fu: or allow layers a helper that could help adjust the python path, but that might be too much
[18:36] <marcoceppi> cory_fu: so I could just have lib/charms/mysql ? alongside reactive?
[18:36] <cory_fu> Right
[18:36] <marcoceppi> that sounds interesting
[18:37] <cory_fu> Actually, with how the libs are pulled in from pypi, I don't think we'd even need to change the basic layer
[18:38] <cory_fu> I think it would probably just work if you created those folders in your mysql layer
[18:38] <bcsaller> yeah, it should
[18:38]  * marcoceppi tries that
[18:39] <cory_fu> marcoceppi: So, just change lib/helpers to lib/charms and drop lib/helpers/__init__.py
[18:40] <marcoceppi> cory_fu: I mean, it worked
[18:40] <marcoceppi> let me change the import calls and deploy
[18:42] <marcoceppi> I love charm inspect
[18:42] <bcsaller> cool
[18:43] <cory_fu> I would love it more if we could get it to work with paging (e.g., less) ;)
[18:43] <cory_fu> Even if the paging was built-in
[18:43] <marcoceppi> bcsaller cory_fu yeah, that worked great, upgrade charm ran cleanly so new imports worked etc
[18:43] <marcoceppi> not sure if we want to document that as a best practice or not?
[18:43] <bcsaller> cory_fu: I could patch that I think, blessings does tty detection (which less fails) but you can disable that
[18:44] <cory_fu> bcsaller: Maybe a "--force-color" option that disables the auto-detect?
[18:44] <bcsaller> yeah, I can look into that
[18:44] <cory_fu> marcoceppi: I think that seems like a good practice, yeah
[18:44] <marcoceppi> cory_fu bcsaller I also noticed there are some patches in 1.6 branch for compose not released, should those be another patch release?
[18:45] <marcoceppi> or do youy have more you wish to land first?
[18:45] <bcsaller> marcoceppi: there will have to be, one is an important bug fix, but we still might want to wait for the bikeshed on naming to resolve
[18:46] <bcsaller> marcoceppi: I have a branch with the current naming in it, but I will also try to make inspect page better, we'll call it minor papercuts
[18:48] <cory_fu> bcsaller: Is the bike-shedding not already resolved from on-high?  ;)
[18:48] <cory_fu> bcsaller: And at any rate, just make aliases
[18:49] <marcoceppi> yes, aliases with "deprecation" notice? and then never deprecate
[18:49] <bcsaller> they are just aliases in setup.py now
[18:49] <marcoceppi> you never truly finish bikshedding
[18:50] <bcsaller> https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality but I do agree names can be important
[19:42] <wolverineav> hey, this is openstack keystone related query - for HA, it mentions this: "VIP is only required if you plan on multi-unit clustering (requires relating with hacluster charm). The VIP becomes a highly-available API endpoint."
[19:42] <wolverineav> i don't know what is the hacluster charm in this context. is it 'haproxy'?
[19:44] <rick_h_> wolverineav: https://jujucharms.com/hacluster/
[19:45] <wolverineav> ah, thanks rick_h
[19:45] <rick_h_> wolverineav: np, good luck!
[19:46] <wolverineav> somehow when you search 'hacluster' in charmstore, this one is not in the top 10
[19:48] <rick_h_> wolverineav: ah, it's not fully gone through the review process so it's demoted.
[19:48] <rick_h_> wolverineav: I'll look into that. thanks for the heads up
[19:49] <wolverineav> rick_h_: that explains it :)


[02:10] <ajbrandt1> good evening
[02:32] <ajbrandt1> Anyone have info on music playing in background?
[03:20] <slangasek> popey: fwiw, the QT_QPA_PLATFORM setting traces back to /etc/profile.d/qpa_plugin.sh, which sets either QT_QPA_PLATFORM=ubuntumirclient or QT_QPA_PLATFORM=ubuntu, depending on whether MIR_SOCKET is set in the environment... which it obviously won't be when connecting over adb.  So that seems to be a regression in ubuntu-touch-session.
[03:22] <slangasek> ogra_: ^^ ubuntu-touch-session 0.88 breaks at least some autopilot use cases over adb; how was this tested before upload?
[03:22] <slangasek> ogra_: i.e., nothing sets $MIR_SOCKET, so the shell environment gets set up wrong over adb
[05:07] <lotuspsychje> http://www.omgubuntu.co.uk/2014/01/several-ubuntu-phones-release-2014
[05:07] <lotuspsychje> lets hope they come fast
[06:12] <dazoe> so, nexus 7 (2012), i installed touch on it using the manual instructions on https://wiki.ubuntu.com/Touch/Install and it boots past google logo but sits on a black screen
[06:12] <dazoe> how far back should i go to find one that works
[06:12] <dazoe> ?
[09:12] <nocomp> hi folks
[09:12] <nocomp> i try to get the source on my box
[09:12] <nocomp> for dev a rom
[09:12] <nocomp> i am having prob with the repo sync
[09:12] <nocomp> when i run
[09:12] <nocomp> phablet-dev-bootstrap code/
[09:13] <nocomp> it stopp
[09:13] <nocomp> i gonna dig
[09:20] <nocomp> solved
[09:20] <nocomp> just been stupid
[09:39] <ogra_> slangasek, yes, on all devices with SF and Mir i wonder why they worked then (the landing took 8 weeks for this, but i dont think that specific part of autopilot tests changes within) ... thanks for the upload
[09:40] <ogra_> *changed
[10:36] <nocomp> hi folks
[10:36] <nocomp> i try to compile a rom for i9300
[10:36] <nocomp> galaxy s3
[10:36] <nocomp> any idea why this is not working?
[10:36] <nocomp> nocomp@pirebox:~/ubuntutouch$ breakfast i9300
[10:36] <nocomp> Couldn't locate the top of the tree.  Try setting TOP.
[10:36] <nocomp> bash: build/tools/roomservice.py: No such file or directory
[10:36] <nocomp> ** Don't have a product spec for: 'cm_i9300'
[10:36] <nocomp> ** Do you have the right repo manifest?
[10:36] <nocomp> nocomp@pirebox:~/ubuntutouch$
[10:38] <srujan> http://www.omgubuntu.co.uk/2014/01/how-to-dual-boot-android-ubuntu-touch-on-nexus
[10:39] <srujan> i tired to install ubuntu dual boot on my nexus 4 using the above tut
[10:39] <srujan> but call and wifi functionality are not working
[10:40] <popey> srujan: did it have android 4.4 on it?
[10:40] <srujan> yes
[10:41] <popey> i believe that may be why
[10:41] <popey> https://wiki.ubuntu.com/Touch/DualBootInstallation#Getting_phone_calls_to_work_in_Ubuntu_and_Android_4.4
[10:43] <srujan> Thanks popey
[10:51] <popey> srujan: np
[12:07] <FuLgOrE> hi guys. How is the status about 4.4 rebase?
[12:08] <FuLgOrE> Is it possible to see the status somewhere?
[12:15] <popey> FuLgOrE: i believe it's due to land at the end of the month
[12:58] <FuLgOrE> popey: thank you
[12:59] <FuLgOrE> popey: Is it possible to monitor the status somewhere? I don't want to bother you with my questions
[13:06] <vthompson> all, I'm having issues upgrading click 0.4.12 from the ubuntu-sdk-team ppa. Could anyone help me? http://paste.ubuntu.com/6779871/
[13:31] <popey> vthompson: lemme see if i can reproduce that here
[13:31] <popey> FuLgOrE: i dont know. but the target is end of month, keep an eye on the ubuntu-phone list as we're sending out weekly status updates for various things there
[13:33] <popey> vthompson: oddly I already had that version of click from somewhere
[13:33] <popey> http://paste.ubuntu.com/6779992/
[13:36] <joeashin> is there a release for nexus 5?
[13:37] <popey> joeashin: not yet
[13:37] <joeashin> thx.
[13:43] <shiggitay> ...
[13:51] <vthompson> I resolved my issue by adding a new user "phablet" on my desktop.
[13:53] <popey> oof
[13:53] <popey> thats a bug imo
[13:55] <vthompson> I'll go and file one. I only recently added the ubuntu-sdk-team ppa to my system
[14:04] <sergiusens> popey, https://code.launchpad.net/~sergiusens/reminders-app/cmake_common/+merge/202215
[14:04] <sergiusens> popey, I see you are around ;-)
[14:05] <sergiusens> I was aiming on directly creating a fat package, but it seems to be missing some pieces still
[14:42] <popey> sergiusens: thanks
[14:45] <popey> sergiusens: do i click-buddy it directly on the device or will it work on laptop?
[14:51] <sergiusens> popey, will work on laptop, but will build x86
[14:51] <sergiusens> popey, still need to integrate it with click chroot
[14:51] <sergiusens> popey, although, if you have a working click chroot; doing click chroot click-buddy ... should work ;-)
[14:54] <popey> so probably easier to build on device right?
[14:54] <popey> (I don't have a chroot, and want to test on arm, not x86)
[14:54] <sergiusens> yup
[14:55] <popey> ta
[14:55] <popey> will do a bit later
[15:26] <vthompson> I've been really good at breaking things today. I upgraded my phone to r136 and now it won't boot up with a welcome screen, but I can still "adb shell" to the device. Anyone having similar issues?
[15:35] <popey> vthompson: mine is on #134, will update now and see what happens
[15:36] <vthompson> popey, god speed
[15:36] <popey> hah
[15:36]  * popey voluntarily breaks his phone... for the greater good
[15:40] <popey> vthompson: mine boots to desktop okay
[15:40] <vthompson> popey, hm, maybe I'll reflash
[15:52] <vthompson> popey, reflash worked. I must have been low on battery while upgrading... or some other hiccup
[18:37] <ybon> Getting on first install on Nexus4: "ERROR:phablet-flash:Installation is taking too long or an error occured along the way" (command was "phablet-flash ubuntu-system --channel devel --no-backup") Should I just try again? Thanks :)
[18:39] <ybon> Ah, maybe with --pending
[18:40] <ybon> ah, no
[18:41] <ybon> "phablet-flash: error: unrecognized arguments: --pending" seems this option doesn't exist anymore
[18:44] <cwayne_> ybon, hm, try with -b instead of --no-backup
[18:45] <ybon> cwayne_: thanks :)
[18:46] <ybon> cwayne_: I've clicked on "get back" on the device
[18:46] <ybon> which has now rebooted
[18:46] <cwayne_> ybon, np! hope it helps :)
[18:46] <ybon> and it seems on Ubuntu \o/
[18:50] <cwayne_> woo!
[18:51] <ybon> Trying to connect on the cellular network now :)
[19:01] <ybon> Humm, no cellular connection (even after unlocking the SIM card) and no wifi connection, should I try installing "stable" instead of "devel"?
[19:12] <cwayne_> plars, huh, any idea whats going on? there were a bunch of builds and they're all failing pretty hard
[19:12] <cwayne_> thomi, ping
[19:13] <thomi> cwayne_: hey
[19:14] <cwayne_> thomi, hey, im getting a lot of failures, seems to be something with autopilot introspecting failing to load platform plugin 'ubuntu'
[19:14] <thomi> hmm, got a link?
[19:15] <cwayne_> http://ci.ubuntu.com/smokeng/trusty/touch_custom/mako/134:20140118:20140115.1/6136/ubuntu-ui-toolkit-autopilot/680527/
[19:15]  * thomi reads
[19:16] <thomi> cwayne_: autopilot hasn't changed in a while now. This looks to me like the process we try and launch exits with -6
[19:16] <thomi> probably due to the missing 'ubuntu' platform
[19:16] <thomi> I imagine that platform is provided by the qtubuntu package?
[19:16] <thomi> but I'm just guessing there
[19:16] <cwayne_> looks like there's a lot of issues with the regular touch test cases too
[19:16] <cwayne_> like 0 passes on mako
[19:16] <cwayne_> something is incredibly broken
[19:17] <thomi> ? where do you see that?
[19:17] <thomi> I see 90% pass rate for mako...
[19:18] <thomi> except for this: http://ci.ubuntu.com/smokeng/trusty/touch/mako/20140119%20%3F/6152/ where nothing ran
[19:18] <thomi> so... nothing failed either :)
[19:18] <cwayne_> well, that's still incredibly broken :)
[19:19] <cwayne_> http://ci.ubuntu.com/smokeng/trusty/touch/
[19:19] <thomi> agreed, but there's nothing there for me to look at :)
[19:20] <cwayne_> fair enough :)
[19:20] <thomi> on this run, for example: http://ci.ubuntu.com/smokeng/trusty/touch/mako/20140119%20%3F/6152/ all the console logs are totally empty
[19:50] <jose> hey guys, I cannot sync contacts between syncevolution and google contacts, external transport failure (local, status 20043) is what I get
[19:50] <jose> any ideas?
[20:20] <kflx-mako> hi all, I'm trying to install Ubuntu os on my nexus 4. but i don't know which mako files to download. and can i use cwm to install?
[20:52] <ulkesh> Any word yet on when a build of Ubuntu Touch will be available for the Nexus 7 (2013)?
[20:55] <plars> cwayne: you are talking about the latest mako failure on image 136 I guess?
[20:56] <plars> cwayne: looks like we had a device fall over - I'll swap it out in the configs, and rfowler will need to take a look when he's back in the office again
[20:57] <plars> cwayne: or are you talking about the custom builds? the latest seems a lot beter on those, but the two previous images were pretty bad it seems - nothing changed on the ci side with those
[20:58] <vthompson> balloons, or anyone following the Terminal app's Backspace/Enter bug. I entered a comment with some steps I was able to do to get the app to recognize the keys. The bug is probably an OSK issue and the Konsole plugin author can probably stand down on investigating.
[21:13] <ulkesh> Any word yet on when a build of Ubuntu Touch will be available for the Nexus 7 (2013, called razor I believe)?
[21:15] <sergiusens> popey, yay :-)
[21:16] <popey> sergiusens: thank you
[21:16] <popey> vthompson: thank you
[21:16] <popey> ulkesh: end of the month, hopefully
[21:16] <ulkesh> popey: awesome, thanks a bunch!
[21:17] <sergiusens> popey, we don't really have the infra to build on jenkins yet; but I can build local and upload and discuss the rest with fginther tomorrow
[21:18] <sergiusens> eom -/+ 1 week
[21:20] <popey> great, thanks
[21:23] <sergiusens> popey, if you have the cycles, care to take a stance onto that click-buddy mr? :-)
[21:26] <popey> sergiusens: done, for what my comment is worth ☻
[21:57] <ybon> Ah, seems that my Android version was too recent (4.4.2_r1), do I need to restore Android, then downgrade, or is there a way to downgrade from desktop command line even when Ubuntu Touch is already installed?
[22:05] <ybon> ah, maybe https://wiki.ubuntu.com/Touch/DualBootInstallation#Android4.4Radio
[23:48] <rulip> hello


[07:45]  * RAOF -> EOW
[10:19] <seb128> ricmm, hey, could you look at https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1306465 ?
[10:20] <seb128> settings abrt() in QUbuntuIntegration::QUbuntuIntegration(QUbuntuInputAdaptorFactory*) () at ../../../../../src/platforms/ubuntu/ubuntucommon/integration.cc:75
[10:21] <seb128> we had other sigabrt in qtubuntu showing on e.u.c, could be the same issue (e.g I don't think it's specific to settings)
[10:21] <seb128> ricmm, Saviq thrown your name as maybe a good candidate to look at it since that seems a qtubuntu issue (could be mir though)
[10:22] <Saviq> ricmm, or at least bounce it to someone who owns qtubuntu these days...
[10:23] <seb128> the log seems to have a "could not create application instance" error
[10:24] <seb128> Saviq, ricmm: ogra_ is saying that there is a known mir issue fixed in trunk, could be it
[10:26] <ogra_> well, not sure thats exactly the same one ...
[10:33] <ricmm> seb128: Saviq if the instance is failing to be created
[10:33] <ricmm> it means that unity is disallowing the connection
[10:34] <ricmm> seb128: is this reproducible with steps?
[10:34] <ricmm> this kind of bug needs to be reproducible to fix it, with steps
[10:35] <ricmm> because it deals with a couple processes talking to each other
[10:35] <seb128> ricmm, can you ask psivaa on #ubuntu-ci-eng, seems to happen during touch tests
[10:35] <ricmm> and u-al-l inthe middle
[10:36] <seb128> ricmm, he says that it happens during unity8 tests
[10:40] <ricmm> seb128: yup im in the channel
[10:40] <seb128> ricmm, saw that, thanks
[13:10] <josharenson> racarr__ Are you at Bluefin today?


[10:30] <jpatrick> LjL: I put botijo in #ubuntu-co?
[10:30] <no0tic> hi jpatrick
[10:31] <jpatrick> hey no0tic
[10:35] <jpatrick> "Channel #ubuntu-pe is private" hmm
[10:36] <no0tic> uhm..
[10:36] <no0tic> pe?
[10:36] <no0tic> perù?
[10:37] <jpatrick> yeah, LjL said they wanted the bot
[10:37] <jpatrick> @syn
[10:37] <botijo> ACK!
[10:38] <no0tic> jpatrick, why spanish channels are private in some way? ubuntu-es has private access list, pe is whole private..
[10:39] <jpatrick> no0tic: ask pelicano, I have no clue
[10:39] <no0tic> jpatrick, did you know that we have a new op on -es?
[10:39] <jpatrick> nop, I have no internet at home...
[10:39] <no0tic> jpatrick, ah, right...
[10:40] <jpatrick> who is the poor bloke?
[10:40] <no0tic> jpatrick, he's RoAkSoAx aka ^AnDr3s or something lamer
[10:40] <jpatrick> ...
[10:42] <jpatrick> and I thought my nick was bad
[10:43] <no0tic> I thought mine was
[10:43] <no0tic> and probably _is_
[10:45] <no0tic> I was thinking about changing it, but by now everybody know me as no0tic...
[10:46] <jpatrick> yeah, everyone complained what I changed mine
[10:46] <no0tic> jpatrick, you changed cloak too?
[10:46] <jpatrick> nop
[10:47] <jpatrick> just linked
[10:49] <gioppo> jpatrick, this is my to be nick
[10:49] <jpatrick> thi is to be my nick*
[10:49] <jpatrick> s/thi/this
[10:49] <gioppo> uhm..
[10:49] <gioppo> jpatrick, this is my "to be nick"
[10:49] <gioppo> jpatrick, ?
[10:50] <gioppo> but my cloak doesnt change..
[10:50] <jpatrick> ahhh
[10:50] <jpatrick> not yet definate
[10:50] <no0tic> anyway..
[10:51] <no0tic> I don't think I'm going to change it sooner
[10:51] <no0tic> jpatrick, did you understand what I wanted to do saying "my to be nick?"
[10:52] <jpatrick> yeah
[10:53] <no0tic> I wanted "to be" to be an adjective
[10:54] <jpatrick> yeah, I got it wrong
[10:54]  * jpatrick off to school
[10:55] <no0tic> jpatrick, bye
[15:29] <jpatrick> hola RoAkSoAx
[15:29] <RoAkSoAx> hola jpatrick
[15:30] <jpatrick> RoAkSoAx: he puesto botijo en #ubuntu-pe como me havian dicho
[15:30] <RoAkSoAx> jpatrick, si ya lo vemos gracias :)
[15:31] <jpatrick> de nada :)
[15:31] <RoAkSoAx> ;)
[15:33] <LjL> ah jpatrick
[15:33] <LjL> magicfab asked for it too for #ubuntu-co
[15:33] <jpatrick> LjL: did it
[15:33] <LjL> right i didn't check, thanks
[15:34] <jpatrick> I thought I pinged you in the channel too :)
[15:34] <RoAkSoAx> jpatrick, botijo is based on supybot ???
[15:34] <LjL> jpatrick, i was probably not connected
[15:34] <jpatrick> RoAkSoAx: yes
[15:35] <jpatrick> LjL: ah ok


 Meeting Doodle … https://beta.doodle.com/poll/mt2day3u6i566s4n
 Oops ^ This is poll for a meeting to discuss KubuntuCI and Hosting - Technical Architecture discussion
[10:56] <RikMills> elisa music player is now in Eoan
[11:06] <RikMills> I will build that for backports later
 $ elisa  … elisa: error while loading shared libraries: libvlc.so.5: cannot open shared object file: No such file or directory
 @myfenris, on startup? I don't see that here
[12:41] <BluesKaj> Hey folks
 @RikMills, Yeap
 The following packages were automatically installed and are no longer required: …   libkf5mediaplayer-data libkf5mediaplayer5
 that is ok. the dep was dropped
 👌🏻 thanks


[01:11] <yoshi435> Hi
[15:28] <smartboyhw> AlanBell, 2 1/2 hours? I thought it should be 4 1/2 hours
[15:35] <AlanBell> hmm, interesting smartboyhw
[15:35] <AlanBell> I may have got that wrong
[15:36] <AlanBell> or got something wrong
[15:37] <AlanBell> http://fridge.ubuntu.com/calendars/fridge/ says it is at 18:00 UTC I think
[15:38] <smartboyhw> AlanBell, you said 20:00 UTC in your mail-.-
[15:38] <AlanBell> yeah, I did
[15:40] <AlanBell> I think the later time is probably better for more people
[16:00] <jose> AlanBell: ping
[16:20] <jose> IRCC: would you like me to change the fridge calendar meeting time to 20 for this meeting or for all future meetings?
[16:57] <AlanBell> jose: yes please :)
[16:57] <jose> AlanBell: for this one or all future meetings?
[17:01] <AlanBell> this and all future please
[17:02] <jose> done
[17:13] <AlanBell> thanks jose :)
[17:13] <jose> sure :)
[17:18] <AlanBell> is that right? looks like 19:00 UTC to me
[17:18] <jose> hmm, /me double chekcs
[17:19] <AlanBell> time now in UTC is 17:19
[17:19] <jose> oh, fixed
[17:19] <AlanBell> that looks better now :)
[17:19] <jose> it was using London's time
[17:21] <jose> AlanBell: could you please let us know when it looks messed up? I've tried to fix it but gcal plays with DST
[17:24] <AlanBell> ok, well it looks fine to me now jose, thanks for your help
[17:24] <jose> no worries
[19:02] <AlanBell> cprofitt: sorry about the list moderation, we need to sort out more people with the password :)
[19:03] <TheLordOfTime> AlanBell, meeting still on for.. 57 minutes from now?
[19:14] <TheLordOfTime> AlanBell, any plans to actually discuss the whole IRC logs thing?  Or is that just a big "not sure we're going to discuss it, yet" thing?
[19:14] <TheLordOfTime> (for the IRCC meeting)
[19:23] <AlanBell> meeting is still on, and sure, we can discuss it, I just didn't know if anyone wanted to discuss it, but I suspect there might be a few people, I will add it to the agenda
[19:27] <AlanBell> I am not expecting any particular decision to be made at this time on the subject, but it is good to discuss IRC related issues that are first raised on the mailing list on IRC when it seems appropriate to do so
[19:27] <AlanBell> if that makes sense
[19:30] <topyli> generally, i think we should discuss whatever someone brings up :)
[19:30] <topyli> if it's on topic that is
[19:30] <Fuchs> cookies!
[19:30] <TheLordOfTime> AlanBell, i think that it needs at least a basic discussion
[19:31] <topyli> Fuchs: ubuntu irc cookies, in particular
[19:31] <TheLordOfTime> because some people might show up to the meeting and discuss it, rather than post on the ML about it
[19:31] <Myrtti> I didn't miss the meeting?
[19:32] <topyli> Myrtti: nope
[19:32] <Myrtti> wohey!
[19:32] <TheLordOfTime> Myrtti, meeting time moved -> 20:00 UTC
[19:32] <TheLordOfTime> according to the last message i saw from ALan on the ML
[19:33] <Tm_T> I do miss, I developed elephant-size headache
[19:33] <Tm_T> AlanBell: count me out, sorry
[19:33] <Fuchs> Tm_T: get better soon :(
[19:38] <TheLordOfTime> get better soon, Tm_T
[19:39] <topyli> Tm_T: drugs and sleep!
[19:45] <AlanBell> TheLordOfTime: we discuss anything people put on the agenda (it is a wiki) I was being a bit proactive and pulling it onto the agenda, and hoping I wasn't going to end up discussing it all by myself :)
[19:46] <TheLordOfTime> AlanBell, you'll get my two cents on it
[19:46] <Unit193> Looks like a pre-meeting meeting to me..
[19:46] <TheLordOfTime> but i haven't replied to the ML because i don't have access to send from my @ubuntu.com on my phone (gmail web view lets me, but not throug the phone)
[19:46] <TheLordOfTime> Unit193, heh
[19:47] <AlanBell> Unit193: you think we should jump straight into the premeeting without a premeeting planning session first?
[19:47] <TheLordOfTime> s/the premeeting/the meeting/ ?
[19:58] <AlanBell> cprofitt: you should be able to send to the list from either address now
[20:00] <Myrtti> nice, my dinner is done just in time
[20:00] <AlanBell> oh goodie, whats for dinner Myrtti ?
[20:01] <Myrtti> chicken-broccoli-massaman curry with pearl barley
[20:01] <AlanBell> gosh, that sounds nice
[20:06] <Fuchs> bon app
[21:05] <TheLordOfTime> AlanBell, do we need to follow up on the email on the ML to state the general community opinion on that whole privacy thing?
[21:05] <TheLordOfTime> or will the minutes do for that.
[21:12] <AlanBell> just sent it
[21:13] <TheLordOfTime> ah, it must not have gotten to my inbox yet (i'm checking my email with my phone xD)
[21:13] <TheLordOfTime> there it is :)