[00:14] <mup> PR snapcraft#998 closed: plugins: update gulp plugin to use get_build_properties() and get_pull_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/998>
[02:12] <liuxg> has anyone got the alias working on the snapcraft 2.24? I just found that example code at https://github.com/snapcore/snapcraft/blob/master/integration_tests/snaps/alias/snapcraft.yaml. when I run it, I get the error like "/snap/my-alias/x3/command-hello.wrapper: 5: exec: /snap/my-alias/x3/hello.sh: Permission denied". I tested it on 16.04 desktop
[02:12] <nholloway> Hi,. guys. I just installed Ubuntu Core in a QEMU/KVM, and can anyone tell me why I can't run 'sudo passwd' without getting an authentication token manipulation error?
[03:35] <mup> PR snapcraft#995 closed: plugins: update kernel plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/995>
[04:15] <nholloway> Hi, guys, I'm trying to set up LXD in Ubuntu Core. It tells me lxd is not found. I'm in the lxd group (that I had to create), and it still fails when I run 'sudo lxd init'. Can anybody help me out?
[04:17] <mup> PR snapcraft#1020 opened: Change hello.sh to be executable <Created by liu-xiao-guo> <https://github.com/snapcore/snapcraft/pull/1020>
[04:18] <mup> Bug #1635584 changed: "snap interfaces" output hides some magical, essential package name <Snappy:Expired> <https://launchpad.net/bugs/1635584>
[05:52] <liuxg> does anyone know how to enable alias for snap application? thanks
[08:27] <zyga> liuxg: hey
[08:27] <zyga> liuxg: do you mean the new aliases feature?
[08:28] <liuxg> zyga, yeah, I just figured it out.
[08:28] <zyga> liuxg: ah, great, I haven't used it yet
[08:28] <liuxg> zyga, I have to enable it using commands, and I wrote a blog for it at http://blog.csdn.net/ubuntutouch/article/details/53839566
[08:29] <liuxg> zyga, thanks for answering :)
[08:44] <mup> PR snapd#2530 opened: tests: use MATCH in install-remove-multi <Created by zyga> <https://github.com/snapcore/snapd/pull/2530>
[09:17] <mup> PR snapd#2531 opened: tests: make debug-each succeed if DENIED doesn't match <Created by zyga> <https://github.com/snapcore/snapd/pull/2531>
[09:22] <mcphail> http://termbin.com/rv2u - this curses-based app prints garbage extra characters to the terminal when run as a snap, but works fine when run from stage/usr/local/bin/sneakers . Any idea what I need to tweak or add to get a curses app to work properly?
[09:22] <zyga> mcphail: perhaps it cannot access terminal profiles under hardcoded path in /usr/lib or /usr/share
[09:23] <zyga> as they are most likely in the core snap
[09:23] <mcphail> zyga: do you know of any workarounds?
[09:24] <zyga> mcphail: patch ncurses in your snap to look for those profiles elsewhere
[09:25] <mcphail> zyga: hmm. Would be better to have a more generic solution for curses apps, dont you think?
[09:25] <zyga> mcphail: such as?
[09:26] <zyga> ideally curses upstream would understand and use the $SNAP environment variable
[09:26] <mcphail> zyga: perhaps a "curses" snap interface which exposes the correct directories?
[09:27] <zyga> mcphail: exposes them from where?
[09:27] <mcphail> zyga: from the host os
[09:28] <zyga> mcphail: the host os can be just snappy core, then you don't have them
[09:28] <zyga> mcphail: or they can be in a wrong format (different major version of curses)
[09:28] <zyga> mcphail: I think they have to be in the snap
[09:28] <mcphail> zyga: surely snappt core has them as well?
[09:28] <zyga> mcphail: if it did you'd have no problems
[09:28] <zyga> mcphail: as your app works against the core snap today
[09:29] <zyga> mcphail: perhaps the core has some basic profiles but I bet it doesn't have all the various profiles people get with extra packages
[09:29] <mcphail> zyga: aah. I see
[09:29] <zyga> mcphail: the overmount interface can be of some help
[09:29] <zyga> mcphail: but that's a hack IMHO
[09:30] <mcphail> zyga: ok. Thanks. That gives me something to explore
[09:30] <zyga> mcphail: https://github.com/snapcore/snapd/pull/2524
[09:30] <mup> PR snapd#2524: Overmount <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2524>
[09:30] <ogra_> mcphail, https://github.com/ogra1/nethack ... (old but most likely still relevant)
[09:30] <zyga> mcphail: that's not merged yet
[09:30] <mcphail> ogra_: cheers. Will have a look
[09:30] <ogra_> :)
[09:31] <mcphail> ogra_: I'll try adding those stage-packages. The names sound promising!
[09:32]  * ogra_ notes that most of his snaps need updating ... but i try to stay away from my computer during vacation 
[09:32] <ogra_> mcphail, also look at the wrapper
[09:32] <longsleep> ogra_: moin folks, i just built a snappy edge image and only get RuntimeError: nl_get_multicast_ids failed: -2 when trying to configure - http://paste.ubuntu.com/23672389/ - known bug?
[09:32] <ogra_> longsleep, not to me ... sounds like a missing bit in the netwrok interface
[09:33] <ogra_> oh, sorry ... i should hav clicked the paste first ... definitely a bug !
[09:33] <longsleep> ogra_: ok, is there anything i can do to access the thing to get some more debug?
[09:33] <zyga> longsleep: report it on subiquity please
[09:33] <ogra_> yeah
[09:33] <longsleep> zyga: subiwhat? :)
[09:34] <longsleep> i had to google that :P
[09:34] <ogra_> if its an arm board with SD there should be subiquity debug logs
[09:34] <ogra_> you could pull them off the SD
[09:34] <longsleep> ah yeah, its on sd
[09:35] <ogra_> in /var/log/console-conf/
[09:35] <ogra_> (on the writable partition obviously)
[09:36] <longsleep> zyga: but now that zyga is there, please tell me that that the apparmor confinement changes have landed in snapd and are already released in stable channel :)
[09:36] <longsleep> then i might be able to actually release a useful snappy image today for pine64
[09:36] <ogra_> candidate should surely have everything in the latest iteration ...
[09:37] <ogra_> not sure about stable ... i think the last snapd still waits for $people_coming_back_from_vacation
[09:38] <longsleep> ogra_: ok i will try candidate channel next then
[09:38] <ogra_> (the deb is definitely only in -proposed atm)
[09:38] <longsleep> ogra_: searching for logs on on this subiquity - should it be in syslog?
[09:38] <ogra_> in /var/log/console-conf/ like i said above
[09:39] <longsleep> oh sorry
[09:39] <ogra_> :)
[09:39] <longsleep> ogra_, zyga: http://paste.ubuntu.com/23672411/ full log
[09:40] <ogra_> my guess is an ipv6 issue ... thats mwhudson territory though
[09:41] <ogra_> file a bug with the log attached for starters
[09:41] <longsleep> ogra_: where should i file the issue? https://github.com/CanonicalLtd/subiquity/issues
[09:41] <ogra_> launchpad ...
[09:41] <longsleep> ogra_: or some place launchpad?
[09:41] <ogra_> there is a subiquity package
[09:42] <ogra_> and the snappy project (see topic)
[09:42] <ogra_> open tasks against both
[09:42] <longsleep> ok
[09:42] <zyga> ogra_: hmm, are you sure? id just file it against subiquity
[09:42] <zyga> anyway
[09:42] <zyga> longsleep: you can now file bugs on snappy on github too AFAIK
[09:43] <ogra_> for non snapd projects ?
[09:43] <ogra_> i thought only snapd wernt on its own
[09:43] <ogra_> *went
[09:44]  * ogra_ hasnt heard anything about foundations owned projects using GH issues 
[09:44] <ogra_> (and i highly doubt they'd move)
[09:44] <mup> PR snapd#2532 opened: tests: port refresh-all-undo to MATCH <Created by zyga> <https://github.com/snapcore/snapd/pull/2532>
[09:46] <longsleep> ogra_: all right, i tried my best in getting the meta data right, https://bugs.launchpad.net/snappy/+bug/1652262
[09:46] <mup> Bug #1652262: subiquitycore exception in controller.run <snappy> <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1652262>
[09:47] <ogra_> looks good
[09:47] <mup> Bug #1652262 opened: subiquitycore exception in controller.run <snappy> <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1652262>
[09:52]  * ogra_ is off 
[09:54] <zyga> ogra_: enjoy your holidsys :)
[09:54] <zyga> holidays*
[09:56] <longsleep> ogra_: yes have fun away from computers :)
[09:56] <longsleep> zyga: issue also happens on candidate channel, so it might be either my network or the device
[09:56]  * longsleep removes wifi
[09:58] <longsleep> mhm did not help :(
[10:00] <longsleep> also when LAN is not connected ever its the same issue
[10:00] <longsleep> means no snappy image for xmas :)
[10:02] <mup> PR snapd#2533 opened: tets: improve snap connect test <Created by zyga> <https://github.com/snapcore/snapd/pull/2533>
[10:05] <zyga> longsleep: which device is that?
[10:05] <mup> Bug #1652265 opened: Initialization changes are removed right after first boot <Snappy:New> <https://launchpad.net/bugs/1652265>
[10:18] <mcphail> ogra_: zyga: thanks - got the curses app to work perfectly!
[10:19] <zyga> mcphail: woot, great
[10:19] <zyga> mcphail: what was the key?
[10:19] <zyga> mcphail: maybe we can add a section to snapcraft wiki
[10:19] <zyga> mcphail: and document classes of workarounds there (e.g. the curses workaround)
[10:21] <mcphail> zyga: basically, the extra console-setup-linux, locales and libc-bin stage-packages plus a wrapper script to set up a sane locale on first launch. A bit ugly, but it works. I just copies it from ogra's repo
[10:24] <mup> PR snapd#2523 closed: tests: port additional snap-confine regression tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2523>
[10:38] <longsleep> zyga: pine64
[11:02] <zyga> longsleep: oh, interesting
[11:02] <zyga> longsleep: maybe the wifi driver is broken, which kernel are you using?
[11:15] <mup> Bug #1652273 opened: Ubuntu Core 16.04 Docker Seg Faults 139 <Snappy:New> <https://launchpad.net/bugs/1652273>
[11:34] <mup> PR snapd#2533 closed: tests: improve snap connect test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2533>
[11:35] <mup> PR snapd#2519 closed: tests: skip packaging dir generation for non-git based autopkgtest runs <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2519>
[11:35] <mup> PR snapd#2532 closed: tests: port refresh-all-undo to MATCH <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2532>
[11:36] <mup> PR snapd#2531 closed: tests: make debug-each succeed if DENIED doesn't match <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2531>
[11:47] <longsleep> zyga: 3.10.104, its a tree i maintain at https://github.com/longsleep/linux-pine64
[11:48] <longsleep> zyga: some of the wifi drivers in there are broken by design yes, but wifi works generally
[11:48] <mup> PR snapd#2525 closed: tests: increase wait time for service to be up <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2525>
[11:51] <zyga> longsleep: interesting, where do you keep your gadget and kernel snaps?
[11:51] <zyga> longsleep: I'd like to build a public project hub (on github) for community snappy systems
[11:51] <zyga> a place where one can easily find all the gadges/kernels
[11:51] <longsleep> zyga: its part of my image building gear - https://github.com/longsleep/build-pine64-image/tree/master/snappy
[11:52] <longsleep> zyga: any chance you might be able to help me get my key registered on the store?
[11:55] <longsleep> zyga: i have asked for help a couple of times before in this channel, never found anyone who might be able to do anything. I am always getting "Key registration failed: The account-key-request assertion is not valid."  with snapcraft register-key
[11:55] <longsleep> zyga: i would really like to upload my gadget and kernel snaps to the store :)
[11:56] <longsleep> and be able to sign the model would be cool too
[11:57] <zyga> longsleep: for that I cannot help, you want sergiusens or nessita I suspect
[11:57] <zyga> longsleep: I'd love to have your kernel and gadget in the store too :)
[11:57] <zyga> longsleep: I'm interested in making it easy to find the sources of all the kernels and gadgets that are public
[11:58] <zyga> longsleep: another one in the list is beagleboneblack
[11:58] <zyga> longsleep: (maintained by ogra_)
[11:58] <zyga> longsleep: and I plan to maintain something for beagle c4
[11:58] <longsleep> zyga: yes that would be good
[11:58] <zyga> longsleep: I'll try to make something like this soon
[11:59] <longsleep> zyga: having a meta data reference in the snaps to some repository, similar to docker hup would be cool imho
[11:59] <longsleep> docker hub
[11:59] <zyga> longsleep: yes, that's on sergiusens's roadmap already
[12:01] <ogra_> zyga, well, the bbb kernel is just linux-generic (effectively just an armhf build of the of the pc kernel snap)
[12:01] <ogra_> i just didnt want to steal the name which is why i called it linux-generic-bbb
[12:02] <ogra_> https://code.launchpad.net/~snappy-dev/+snap/linux-generic-bbb
[12:02] <zyga> ogra_: that's fine, what we need are the snapcraft files, the readme's and the place to file bugs
[12:02] <ogra_> i'll set up a project on LP
[12:02] <zyga> ogra_: and a place for everyone to play nice in one community where they can join easily and learn from each other
[12:02] <zyga> ogra_: I'd really prefer github for everything (for various reasons) but I won't stop you as you know :)
[12:03] <ogra_> need to update the stuff too
[12:03] <ogra_> well, i do 99.99% of my bugtracking on LP ... and githubs mail handling (at least for branches) is 100% unusable i do all my bug and branch tracking through mail
[12:04] <ogra_> unless they fix that i'll keep the projects i own on LP for bugs ... sorry
[12:04] <zyga> ogra_: what is the problem with github issue tracking email notifications?
[12:05] <ogra_> dunno, i havent done issue tracking on GH yet ... but the mail tracking for branches is completely unusable ... i simply suspect the issue tracking to not be different
[12:05] <ogra_> but i guess i'll see that soon, once i get snapd issue mails ;)
[12:07] <zyga> ogra_: ah, issue tracking for branches
[12:07] <zyga> ogra_: can you tell me more about that?
[12:07] <ogra_> as long as i have to work with the archive, debs, builds on LP i'll not mive for the bits i dont have to move
[12:07] <zyga> ogra_: I misread your earlier message
[12:07] <ogra_> **move
[12:08] <ogra_> well, the branch tracking simply has no info in the mails (compare them to LP branch changes where you get the diff inside the mail etc) it only has very limited amounts of info in it ... i.e. the conversation
[12:09] <ogra_> it forces me to have another 500 tabs open in my browser since i can only see the diffs via web UI
[12:09] <ogra_> (and i already have 500 tabs ... not really suitable)
[12:10] <ogra_> very rarely someone comments inline where you get a very small snippet of the diff that has been commented on in the mail ... and there seems to be no way to change it in the GH mail settings
[12:10] <zyga> ogra_: so you'd like to get diffs whenver someone pushes to a branch?
[12:10] <ogra_> i'd like to have the same handling i get from LP
[12:11] <ogra_> diffs inline without having to open a browser etc
[12:11] <ogra_> also, it get a mail for every fart someone lets in a branch ... its like 5x the spam i get from LP without any benefit
[12:12] <ogra_> as someone who has to deal with 300-600 mails per day that is simply ineffective
[12:13] <zyga> ogra_: would you get that traffic on from two repos that have a snapcraft.yaml inside, each?
[12:13] <ogra_> if you make any comment or change it sends a mail
[12:13] <ogra_> without anything inside but "zyga made a change ... here is a link to the diff"
[12:14] <ogra_> and that link to the diff just gets me to the web UI frontend ... i still have to click through to the file changes
[12:14] <ogra_> GH just adds a lot more steps to my workflow
[12:14] <zyga> ogra_: note that you'd be the only person that can make changes to those repos
[12:14] <ogra_> where Lp is perfectly effective
[12:15] <zyga> ogra_: I could comment on your repos but other than that, I'd have to open pull requests
[12:15] <ogra_> right
[12:15] <zyga> ogra_: but LP is pretty unsocial and people just don't like it, if I'd like to build a hub for all the open source gadgets and kernels, building thato on LP seems like a bad idea
[12:15] <ogra_> where the above applies ... to see your changes i'D have to do another 5-10 clicks in the browser
[12:16] <ogra_> LP is unsocial ?
[12:16] <ogra_> heh
[12:16] <zyga> ogra_: well, 5-10 is a bit exaggerated IMHO
[12:16] <ogra_> not sure how you get that impression
[12:16] <ogra_> staring from clicking in the mail to seeing the change its at least 5 clicks ...
[12:16] <zyga> ogra_: really? it's usually just one
[12:16] <ogra_> if you have changed multiple files i even need to open multiple tabs
[12:17] <zyga> ogra_: that's not true, if I send you a pull request you just see the diff there
[12:17] <ogra_> the click in the mail only gets you to the PR frontpage
[12:17] <ogra_> anyway, you really wont convince me
[12:17] <zyga> ogra_: with all the files combined, you can click to see individual files and commits
[12:17] <zyga> ogra_: too bad, I reall wish to have a place where all the code is easy to find
[12:17] <ogra_> and as long as i do still distro work LP is my choice for my own projects
[12:17] <ogra_> GH is just way to painful and unfrieendly
[12:18] <ogra_> i'm fine to follow suit where i need to (snapd, snapcraft etc etc)
[12:18] <ogra_> but not for my own work
[12:20] <ogra_> all my image building, deb management, archive work are on LP ... snap stuff is still a very small minority of my day to day work ...  splitting that off to a rather un-userfirendly tool doesnt really help
[12:21] <ogra_> (along with my browser keeping my fans running when i have GH pages open ... tzanks to their use of flash to create zip files on demand)
[12:22] <zyga> ogra_: I have a few doezen github tabs open and 1% cpu use on firefox
[12:22] <zyga> ogra_: maybe check if that's really github that's doing this
[12:22] <ogra_> tell my laptop :P
[12:22] <ogra_> yes it is
[12:22] <zyga> ogra_: can you share link, maybe it's not happening on all pages
[12:22] <ogra_> if you diable flash the "download tarball" button asks you to enable it
[12:23] <zyga> ogra_: and that keeps your CPU busy?
[12:23] <zyga> ogra_: I don't have flash installed
[12:23] <ogra_> its the big green button you get on branches on the top right
[12:23] <ogra_> hmm, probably they dropped that recently
[12:23] <ogra_> anyway, you wont make me a GH fan ... :)
[12:24] <ogra_> i find it as userfriendly as git itself ...
[12:25] <ogra_> along with the fact that there is a team i have direct access to to fix any LP issues in no time for me if i hit any
[12:25] <ogra_> (and i really like to support my colleagues by using in-house stuff too)
[12:27] <zyga> ogra_: that I understand and respect
[12:27] <zyga> ogra_: I really wish lp was nearly as popular as gh, or had similar features
[12:27] <ogra_> haha, i'd state the same sentence the other way around :)
[12:28] <ogra_> (minus the popular but :) )
[12:28] <zyga> ogra_: review tools are way better on gh :/
[12:28] <ogra_> i also dont see how we will ever have any customer projects on GH
[12:28] <zyga> ogra_: I don't use email much so perhaps that's why our views differ
[12:29] <ogra_> i.e. any private stuff
[12:29] <zyga> ogra_: sure but "use the best tool for the job"
[12:29] <ogra_> and i work a lot with these guys every day
[12:29] <zyga> when building a community hub for snappy sources
[12:31] <zyga> ogra_: btw, distro question, how can I get this fix released into xenial-updates (for autopkgtest package):
[12:31] <zyga> https://github.com/zyga/spread-qemu-images/blob/master/autopkgtest-fix.patch
[12:32] <zyga> it's an obvious bug, the URL changed, adt-builvm-ubuntu-cloud doesn't work with zesty or yakkety releases when invoked from zenial
[12:32] <zyga> xenial
[12:32] <zyga> it was a pitti project but I don't know where to send ths to
[12:33] <ogra_> yeah, i dont know where it moved to ... ask infinity perhaps
[12:33] <ogra_> it used to be a branch under his account before
[12:34] <zyga> can I distro-patch this somehow quickly
[12:34] <zyga> it's super annoying that this is broken and the fix is trivial
[12:34] <mup> PR snapd#2530 closed: tests: use MATCH in install-remove-multi <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2530>
[12:34] <zyga> I'll chase infinity after xmas
[12:34] <ogra_> i guess you'd need to SRU it ...
[12:35] <ogra_> so not "quickly"
[12:35] <zyga> I cannot even upload it, what should I do?
[12:35] <ogra_> (but perhaps the autopkgtest package isnt that strict regarding SRUs given it needs to move fast)
[12:35] <zyga> I'm not a core developer
[12:36] <zyga> can you do it somehow?
[12:37] <ogra_> hmm, they seem to actually use backports ... looking at https://launchpad.net/ubuntu/xenial/+source/autopkgtest
[12:38] <zyga> there are backports too, this patch is for the package in xenial-updates
[12:39] <zyga> (the backport is fixed but not everyone is on it)
[12:39] <ogra_> i could surely upload the package but i dont know the process and would not like to cause extra work (i.e. i dont know if you need to commit to bzr or git first etc)
[12:39] <zyga> ogra_: ah, this is a native package
[12:39] <zyga> darn
[12:39] <ogra_> it doesnt look like there were any uploads to xenial-updates ever
[12:40] <ogra_> since release day
[12:40] <zyga> ar, right
[12:40] <zyga> odd
[12:40] <zyga> so?
[12:40] <ogra_> so it seems the backports are used everywhere by default
[12:40] <zyga> but "apt install autopkgtest" doesn't use backports, does it?
[12:41] <zyga> everyone that pulls in this package will get the broken version
[12:41] <ogra_> and the distro package seems to only have been synced from debian around release day
[12:41] <ogra_> it even has "unstable" in the changelog
[12:42] <ogra_> yes, if you just apt install it on your xenial desktop you get the outdated one
[12:42] <ogra_> but who does that ?
[12:42] <zyga> well, everyone that gets it through dependencies or apt-get installs it?
[12:42] <ogra_> adt is part of a bitter infrastructure
[12:42] <zyga> ogra_: it's just broken
[12:42] <ogra_> *bigger
[12:43] <zyga> ogra_: sure but whatever the infra, adt is broken and I want to fix it :)
[12:43] <ogra_> is anyone running it locally (i assume you need a complete local archive for the dependency checking etc)
[12:43] <ogra_> running it at home doesnt seem to make much sense (ICBW indeed)
[12:44] <ogra_> out of the setup it needs to run in at least ... and i would expect the official setup to default to use the backport
[12:45] <zyga> ogra_: you can use it to get `adt-buildvm-ubuntu-image`
[12:45] <zyga> ogra_: and then you can use it locally in many interesting ways
[12:46] <zyga> ogra_: you don't need the archive at home
[12:46] <ogra_> ah, i didnt know that ... i only know atd-run in context of proposed migration in the archive
[12:46] <ogra_> **adt-run
[12:47] <ogra_> (i helped pitti to set up the containers and chroots years ago, but didnt touch it further ... apart from watching the actual run for packages at times)
[12:47] <zyga> ogra_: for some context: https://github.com/zyga/spread-qemu-images
[12:48] <longsleep> zyga: is there a bug tracker somewhere where i can add my failure to register a key on the store, seems the snappy channel is not sufficient to get that resolved :)
[12:48] <zyga> longsleep: I don't know, this is something we should be better at (FAQ somewhere)
[12:48] <zyga> longsleep: report a bug on snappy or snapcraft, we'll move it later when we triage it
[12:48] <ogra_> zyga, well, as long as "install -t ${VERSION_CODENAME}-backports autopkgtest" works ...
[12:49] <longsleep> zyga: ok - will do thanks :)
[12:50] <ogra_> zyga, as a quick hack you could put the first few lines from the code in the readme inside a setul.sh script ... then the user isnt bothered with the apt install stuff ;)
[12:50] <ogra_> *setup.sh
[12:51] <ogra_> i.e: run "./setup.sh" ... then run "make -C ~/spread/qemu"
[12:51] <mup> PR snapd#2534 opened: debian: open 2.21 for development <Created by zyga> <https://github.com/snapcore/snapd/pull/2534>
[12:51] <zyga> ogra_: sure but that's more magic, I wanted to make it transparent as to what is going on
[12:51] <zyga> ogra_: I may end up snapping this, we'll see
[12:51] <ogra_> i assume there is a reason why adt isnt SRUed ...
[12:52] <ogra_> so you will always have that backports bit
[12:52] <zyga> (SRU is a pain)
[12:52] <zyga> that's why
[12:52] <zyga> new features
[12:52] <zyga> nah
[12:52] <ogra_> zyga, you need to trust your colleagues !!!
[12:52] <zyga> get exceptions and stuff
[12:52] <ogra_> :P
[12:52] <zyga> ogra_: I trust them
[12:52] <zyga> but they used this hack, not me ;)
[12:53] <zyga> we all instinctively sidestep distro process issue
[12:53] <zyga> issues*
[12:53] <ogra_> (that was an inside joke referring to mark teasing me in vancouver when i said SRUs arent really an option :P )
[12:54] <zyga> hehe, I assumed it was :)
[12:54] <zyga> but wanted to be honest too
[12:55] <zyga> I got the reference instantly
[12:55] <snapper> hi everyone
[12:55] <longsleep> zyga: https://bugs.launchpad.net/snapcraft/+bug/1652302 created, it would be awesome if you could asign it to someone who might actually be able to help
[12:55] <mup> Bug #1652302: Key registration failed: The account-key-request assertion is not valid. <Snapcraft:New> <https://launchpad.net/bugs/1652302>
[12:55] <ogra_> SRUs *are* a pain ... but as long as we have the package in the distro and need to use it there, there is sadly no way around them
[12:56] <ogra_> i think weven the fast path setup we have for snapd today is awful ... but its the best we can get
[12:59] <ogra_> yay ... my resistor pack finally arrived from the UK ...
[12:59]  * ogra_ will spend christmas with soldering iron and multimeter :)
[13:00] <longsleep> lucky you, today the DHL guy did come without any change so i could not pay customs tax :/
[13:00] <ogra_> crap
[13:00] <ogra_> but i guess you can still pick it up tomorrow at a store, no ?
[13:00] <longsleep> he promised to come later again, but later has been an hour ago :)
[13:01] <ogra_> good luck ... mine was actually supposed to arrive on tue... i didnt even expect it today
[13:02] <longsleep> yeah, but i leave for holidays tonight - so either i leave without my personal tech presents from china or the guy stays true to his promise
[13:02] <ogra_> oh man
[13:02] <longsleep> in any case, i packed my soldering iron already
[13:02] <ogra_> lol
[13:02]  * ogra_ woundlt be able to actually travel with the stuff he builds ... 
[13:02] <ogra_> *wouldn*t
[13:03] <ogra_> http://imgur.com/jnoLQd5
[13:03] <ogra_> the output transformers alone weight ~15kg
[13:03] <longsleep> lol what is that
[13:03] <ogra_> a tube amp
[13:03] <ogra_> old hobby i revived this year
[13:04] <longsleep> for music?
[13:04] <ogra_> yeah
[13:04] <zyga> ogra_: cool, what are you building?
[13:04] <ogra_> too many low voltage boards in my life, i had to do something with 300+ volts again ;)
[13:05] <ogra_> zyga, see above i pasted a pic
[13:05] <longsleep> do those tubes glow when on?
[13:05] <ogra_> its the first time i use a pre-made case though ...
[13:05] <ogra_> usualyl i build the whole thing from a piece of sheet metal
[13:05] <zyga> oh, nice!
[13:05] <ogra_> indeed they glow
[13:05] <longsleep> awesome
[13:05] <ogra_> and they sound awesome ...
[13:06] <longsleep> try it with x-mas songs :P
[13:06] <ogra_> (very expensive though ... what you see in the pic is already in the 800€ range )
[13:06] <ogra_> heh
[13:06] <ogra_> i will
[13:09] <snapper> is it just me, or there is a problem that you cannot find some apps on a ubuntu core system? for example I was trying to search for an app on Rasberry Pi, and I can't find it, but I can find the app when I search on a non-ubuntu core system
[13:09] <ogra_> snapper, how do you try to find it on both systems ?
[13:10] <snapper> snap find <snap_name>
[13:10] <ogra_> also ... is the non pi system x86 ? perhaps the package only exists for x86
[13:10] <ogra_> it is really up to the packager if he wants to offfer his packages for arm
[13:10] <snapper> hum
[13:11] <snapper> the non-pi system I'm using a regular ubuntu
[13:12] <ogra_> https://uappexplorer.com/apps?sort=relevance&type=snappy
[13:12] <ogra_> you can search for it there ...
[13:12] <snapper> I thought that the snaps were universal
[13:12] <ogra_> if you click on the snap there is an "architectures" field in the description
[13:12] <snapper> I'll take a look, thanks :)
[13:13] <snapper> sosorry I have no idea about this, but for the pi, then I would have to pack it differently?
[13:13] <ogra_> snaps are uploaded as binaries ... unlike debs
[13:13] <ogra_> so you need to build the binary for the target arch (or use LP to build it)
[13:13] <ogra_> some uloaders only build for PC ...
[13:14] <longsleep> x-mas is save, DHL just came with change - yay!
[13:14] <ogra_> *uploaders
[13:14] <snapper> i did find it there, it is as amd64 architacture
[13:14] <ogra_> longsleep, yay, congrats !
[13:14] <ogra_> snapper, yeah, then you wont find it on the pi
[13:14] <longsleep> ogra_: thanks, DHL express is pretty awesome
[13:14] <snapper> ok, thanks :)
[13:14]  * ogra_ thinks we should make x86 binaries executable on arm 
[13:15] <longsleep> ogra_: use windows :P
[13:15] <snapper> :)
[13:15] <ogra_> well, i wrote qemu-user-static originally ;) ... there is no reason that shouldnt work the other way around (with limitations for sure, but basics should work)
[13:16] <ogra_> thogh i doubt you could make amd64 work on arm32 ... would have to be i386
[13:19]  * zyga -> lunch
[13:19]  * ogra_ goes afk as well
[13:55] <mup> PR snapd#2535 opened: tests: port more snap-confine regression tests <Created by zyga> <https://github.com/snapcore/snapd/pull/2535>
[16:17] <iliv> what is the difference between stage-package and build-packages? I'm looking at documentation and snapcraft.io and it says stage-packages "support the part creation." whereas build-packages "aid in building the part.".
[16:18] <iliv> this sounds kind of synonymous
[16:18] <iliv> what is exactly "part creation"?
[16:24] <zyga> iliv: hey
[16:25] <iliv> hi zyga
[16:25] <zyga> iliv: the difference is that stage-packages are automatically staged (added) to your snap
[16:25] <zyga> iliv: while build packages are just installed on your systems
[16:25] <zyga> iliv: so that you can build your snap
[16:25] <zyga> iliv: typically you'd see various -dev packages in build-packages
[16:25] <mcphail> iliv: the build-packages are the things which are needed to build the binaries (e.g. the -dev packages), whereas the stage packages are the things needed to run your binaries (the libs)
[16:25] <iliv> are stage-packages essentially runtime dependencies?
[16:26] <mcphail> iliv: yes, I think so
[16:26] <zyga> iliv: it's "add this blob to my package"
[16:26] <zyga> it's not strictly "runtime deps" as nothing apart from unpack is done
[16:28] <iliv> I see
[16:28] <iliv> thank you
[16:36] <mup> PR snapd#2536 opened: overlord/snapstate: use keyed fields on literals <Created by zyga> <https://github.com/snapcore/snapd/pull/2536>
[17:08] <kyrofa> iliv, the important difference is that build-packages get installed on the system building the snap (i.e. they don't go into the snap), whereas stage-packages are unpacked directly into the snap
[17:09] <iliv> got it
[17:09] <kyrofa> iliv, stage-packages are unpacked before pull, however, so they can also be build-time dependencies that you also want in your snap
[17:21] <mup> PR snapcraft#1020 closed: Change hello.sh to be executable <Created by liu-xiao-guo> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1020>
[17:21] <mup> PR snapcraft#1021 opened: integration tests: add alias integration test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1021>
[17:28] <grapestomper> kyrofa - you around?
[17:28] <kyrofa> grapestomper, I am, how can I help?
[17:28] <grapestomper> kyrofa - I looked at the example you gave yesterday - try to run sh as a service
[17:29] <grapestomper> to copy fie at snap install
[17:29] <kyrofa> grapestomper, run into troubles?
[17:30] <grapestomper> I tried but no dice - when I install the snap I cannot find the sh file in the common or usr dir for the service to run
[17:30] <kyrofa> grapestomper, do you have the code pushed anywhere? Let me take a look
[17:30] <grapestomper> just a sec
[17:31] <grapestomper>  I will push to git and send a link
[17:33] <grapestomper> https://github.com/chadyoungdell/Snappy_Ubuntu_Core/tree/master/Snapcraft_2.x/Shell/SystemInfo
[17:34] <kyrofa> grapestomper, alright just looking at the snapcraft.yaml I see something fishy
[17:34] <kyrofa> grapestomper, the organize at the bottom: `copyreadme: $SNAP_DATA`
[17:35] <kyrofa> grapestomper, $SNAP_DATA is only available at runtime for the snap, not at build time (i.e. snapcraft can't put anything there for you)
[17:37] <kyrofa> grapestomper, so you need to put a cp <file> $SNAP_DATA in a script that is run within the snap, when it's installed
[17:37] <grapestomper> hmmm - so thats what I am trying to figure ouy :)
[17:37] <grapestomper> out
[17:38] <grapestomper> where in the snapcraft to I tell it bout that script
[17:38] <kyrofa> grapestomper, you make it an app
[17:38] <kyrofa> grapestomper, so in the nextcloud snap, mysql is an app
[17:38] <kyrofa> grapestomper, a daemon
[17:39] <kyrofa> grapestomper, but mysql isn't run directly, a helper script is called
[17:39] <kyrofa> https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml#L20
[17:39] <mup> PR snapd#2536 closed: overlord/snapstate: use keyed fields on literals <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2536>
[17:39] <grapestomper> but isnt that what is on L23
[17:39] <kyrofa> grapestomper, a script named "start_mysql"
[17:39] <kyrofa> grapestomper, indeed, but copyreadme doesn't do anything
[17:40] <grapestomper> hmm I will take a look again - back in a few min
[17:41] <kyrofa> grapestomper, at the bottom of copyreadme you should do `cp README_systeminfo.md $SNAP_DATA/` or something
[17:51] <mup> PR snapcraft#1022 opened: plugins: update copy plugin to use get_build_properties() <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1022>
[17:54] <grapestomper> Kyrofa - Thank you, I will hack at it some more
[17:59] <matteo> in this snap.yaml, I wish a content interface named control: http://pastebin.ubuntu.com/23674170/
[17:59] <matteo> what hìI have to rename, the inner or out content? I think the first one
[17:59] <matteo> but what about the one in the last line? that's the interface type or the plug name?
[18:00] <kyrofa> matteo, first of all, you don't technically need the `plugs` at the bottom in this case. If it has no plugs it'll get the ones declared globally
[18:01] <kyrofa> matteo, when you talk about having to rename... what do you mean? Why do you have to rename?
[18:02] <matteo> I have created a plug named content
[18:02] <kyrofa> Indeed
[18:02] <mup> PR snapd#2534 closed: tests: debug zesty autopkgtest failures <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2534>
[18:02] <matteo> I want to name it "control"
[18:03] <kyrofa> matteo, ah, easy
[18:03] <mup> PR snapd#2516 closed: tests: cancel the scheduled reboot on ubuntu-core-upgrade-no-gc and restore state <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2516>
[18:03] <kyrofa> matteo, the outer name ("content") in this case can be changed to whatever you like, and that'll be the name of the plug
[18:04] <kyrofa> matteo, however, if you change it away from "content" you need to also specify `interface: content` in the definition
[18:08] <matteo> ah ok
[18:08] <matteo> trying
[18:10] <matteo> kyrofa: great!
[18:11] <matteo> now, when I connect it I should see a bind mount somewhere?
[18:12] <kyrofa> matteo, you asked the bind mount to be on top of $SNAP_DATA. I'm not 100% sure that'll work
[18:12] <matteo> I'll create a subdir then
[18:12] <matteo> maybe sockets/
[18:13] <kyrofa> matteo, I've only used absolute paths (e.g. /bar) that end up being relative to $SNAP
[18:13] <kyrofa> matteo, yeah, whatever you use, make sure that directory exists
[18:13] <matteo> so, just "/sockets" ?
[18:13] <matteo> or $SNAP/sockets
[18:14] <kyrofa> If you use /sockets it'll be relative to $SNAP (I think supporting $SNAP is a relatively new feature, not sure what release)
[18:14] <matteo> ok
[18:14] <kyrofa> so /sockets will be more backward compatible
[18:14] <matteo> I have to create the directory
[18:15] <kyrofa> Yeah, it's a bind mount. It needs to have a mount point
[18:15] <kyrofa> Unless it's advanced beyond that since I played with it (possible)
[18:15] <matteo> ok
[18:16] <kyrofa> Although if it makes its own mount points, you'll have to use a writable area
[18:16] <kyrofa> So I suspect that supported in v2.20
[18:16] <matteo> ok
[18:16] <matteo> I'll go for the readonly one
[18:19] <matteo> cannot mount /var/snap/wifi-ap/x1/sockets at /snap/wifiap-consumer/x1/sockets with options bind: Permission denied
[18:19] <matteo> mmm
[18:19] <kyrofa> What gave you that error?
[18:19] <matteo> snap connect wifiap-consumer:control wifi-ap:control
[18:20] <kyrofa> matteo, and /snap/wifiap-consumer/x1/socket is an existing directory?
[18:20] <matteo> drwxrwxr-x 2 test test   31 Dec 23 18:15 /snap/wifiap-consumer/x1/sockets
[18:20] <matteo> drwxr-xr-x 2 root root 4096 Dec 23 18:18 /var/snap/wifi-ap/x1/sockets
[18:21] <matteo> maybe some directory permissions?
[18:21] <kyrofa> matteo, ah, are you `snap try`ing?
[18:21] <matteo> yes
[18:21] <matteo> I'm spreading
[18:21] <kyrofa> matteo, try actually installing it, I've noticed weird issues with that type of thing as well
[18:22] <matteo> it's installed with dangerous
[18:22] <kyrofa> But you've got it installed via `snap try`, no?
[18:22] <matteo> sorry, plain snap install
[18:22] <matteo>     snap install --dangerous $snapfile
[18:23] <kyrofa> Ah, I misunderstood. Huh, I figured everything would be owned by root there
[18:23] <kyrofa> Oh oh
[18:23] <kyrofa> Did you `sudo snap connect`?
[18:24] <matteo> snap connect wifiap-consumer:control wifi-ap:control
[18:24] <kyrofa> Try it with sudo
[18:24] <matteo> # snap interfaces |grep :control
[18:24] <matteo> wifi-ap:control         wifiap-consumer
[18:24] <matteo> I'm root
[18:25] <kyrofa> matteo, how did you create the `sockets` directory in your snap?
[18:27] <matteo> in the squashfs file
[18:28] <kyrofa> matteo, manually? i.e. not via snapcraft?
[18:28] <matteo> I use mksquahfs
[18:28] <matteo> it's an example snap to test an interface
[18:28] <matteo> the socket dir is in the FS
[18:28] <kyrofa> matteo, ah, probably not with all required parameters
[18:28] <matteo> located at /snap/wifiap-consumer/current/sockets/
[18:29] <kyrofa> matteo, instead of using mksquashfs, use `snapcraft snap <dir>`
[18:29] <matteo> no, I don't have snapcraft in the spread VM
[18:29] <kyrofa> Is this using the snapd codebase?
[18:29] <matteo> it's a spread test
[18:30] <kyrofa> Within snapd?
[18:30] <matteo> no, in wifi-ap
[18:30] <kyrofa> Ah, okay. Let me get you the exact instantiation you need, then
[18:30] <matteo> ok
[18:30] <kyrofa> Because whatever you used looks wrong
[18:31] <kyrofa> Yeah, `mksquashfs -noappend -comp xz -no-xattrs -all-root`
[18:32] <kyrofa> matteo, note that if you can install snapcraft in the spread VM you won't have to track that if it changes again
[18:32] <kyrofa> Just to it in the project-wide prepare
[18:32] <matteo> ok
[18:32] <kyrofa> s/to/do/
[18:36] <matteo> Permission denied
[18:36] <matteo> kyrofa: I want to try to mount it by hand
[18:36] <matteo> mount --bind /var/snap/wifi-ap/x1/sockets /snap/wifiap-consumer/x1/sockets
[18:36] <matteo> it works
[18:37] <kyrofa> matteo, unfortunately snaps have their own private namespace for that stuff
[18:37] <kyrofa> matteo, does syslog say anything when you get permission denied?
[18:37] <matteo> [  216.884517] audit: type=1400 audit(1482518231.065:41): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/snap/wifiap-consumer/x1/sockets/" pid=1807 comm="snap-confine" srcname="/var/snap/wifi-ap/x1/sockets/" flags="rw, bind"
[18:37] <matteo> ah it's snap-confine
[18:38] <kyrofa> Huh. What version of snapd and snap-confine do you have?
[18:38] <matteo> snap    2.20
[18:38] <matteo> snapd   2.20
[18:39] <kyrofa> How about snap-confine?
[18:39] <kyrofa> matteo, also, can you pastebin the slot side?
[18:39] <matteo> yes
[18:40] <matteo> http://pastebin.ubuntu.com/23674393/
[18:42] <kyrofa> matteo, just out of curiosity, what happens if you make that `read`?
[18:42] <matteo> I can try
[18:42] <matteo> but there was a discussion about sockets having to be write
[18:43] <kyrofa> matteo, oh yeah, it'll definitely break
[18:43] <kyrofa> matteo, but I'm curious if the mount succeeds
[18:45] <matteo> it fails
[18:45] <iliv> how long may it take for Launchpad project to import a github repo? I'm looking at 19 minutes already and it seems like something went down wrong somewhere...
[18:46] <kyrofa> iliv, in my experience it checks for updates once every 5 hours or so
[18:46] <kyrofa> iliv, but you can ask it to check sooner
[18:46] <kyrofa> iliv, though if it's the first time you set it up it should be more or less immediate
[18:47] <iliv> yeah, it has been that in my case
[18:47] <iliv> just not this time
[18:47] <kyrofa> matteo, huh, same error message (minus the rw)?
[18:47] <iliv> I see it has finally imported code
[18:47] <iliv> took about 20 minutes this time
[18:47] <kyrofa> iliv, perhaps there was a bit of a backlog
[18:47] <matteo> didn't check the syslog, just the output
[18:47] <matteo> cannot mount /var/snap/wifi-ap/x1/sockets at /snap/wifiap-consumer/x1/sockets with options bind: Permission denied
[18:48] <kyrofa> matteo, huh, I'm afraid you've moved beyond my experience. I suggest emailing the snapcraft list
[18:48] <kyrofa> matteo, most people are on vacation, but we still check the mailing list
[18:49] <matteo> thank you
[18:49] <matteo> I think I'll go on vacations too, starting now :)
[18:50] <matteo> merry christmas, and snappy new year :D
[18:52] <kyrofa> You too matteo!
[18:52] <mup> PR snapd#2535 closed: tests: port more snap-confine regression tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2535>
[19:00] <mup> Bug #1652369 opened: Cannot connect to ubuntu-app-platform package on consecutive installs <Snappy:New> <https://launchpad.net/bugs/1652369>
[19:03] <iliv> hm, I have a build that works locally just fine but Launchpad shows this error message: local source (parts/pgpool/build/src/) is not a directory
[19:03] <iliv> complete buildlog https://launchpadlibrarian.net/299818200/buildlog_snap_ubuntu_xenial_i386_postgresql95-pgpool2-35_BUILDING.txt.gz
[19:03] <kyrofa> iliv, is your code public? May I see it?
[19:03] <iliv> yes
[19:04] <iliv> https://github.com/commandprompt/postgresql95-pgpool2_35-snap
[19:04] <iliv> kyrofa, specifically https://github.com/commandprompt/postgresql95-pgpool2_35-snap/tree/3.5.4
[19:06] <kyrofa> iliv, hmm, we highly recommend keeping parts independent
[19:06] <kyrofa> iliv, using other parts as sources isn't supported
[19:06] <iliv> well, it works locally
[19:06] <kyrofa> iliv, it won't everywhere, and it won't always
[19:07] <kyrofa> iliv, so this pgpool part has extra bits that it doesn't build?
[19:09] <iliv> it's a thing with PostgreSQL projects apparently... they like to have mini sub-projects, in this case pgpool-II extensions. you build pgpool-II, the main application, then if you want/need to build extensions you cd src/sql/$EXTENSION_NAME and run the usual make && make install
[19:09] <kyrofa> iliv, no option to say "build this for me too, please?"
[19:09] <iliv> no, unfortunately
[19:10] <kyrofa> iliv, do the extensions require the built pgpool?
[19:10] <iliv> in fact, PGDG ships these extensions as individual packages in APT repo
[19:10] <iliv> I'm not 100% sure but they might not
[19:10] <kyrofa> iliv, yeah that's normal, but actually having completely separate build systems in the same tree seems odd
[19:11] <kyrofa> iliv, if they don't, the easiest thing to do would be to simply use the same `source` for all the parts
[19:11] <kyrofa> It'll redownload, which is annoying, but it'll work
[19:11] <kyrofa> iliv, oh wait, actually
[19:11] <kyrofa> iliv, what version of snapcraft are you on?
[19:12] <iliv> Launchpad kyrofa
[19:12] <kyrofa> iliv, I assume you're testing locally first, no?
[19:12] <iliv> correct
[19:12] <kyrofa> iliv, if only launchpad, building against xenial and updates pocket?
[19:12] <iliv> $ snapcraft -v
[19:12] <iliv> 2.22.1
[19:12] <kyrofa> iliv, so locally, what version?
[19:12] <kyrofa> Can you update?
[19:13] <kyrofa> v2.24 introduced a new feature you can probably use here
[19:13] <iliv> already updating.. one momen
[19:14] <iliv> moment *
[19:14] <iliv> what is the feature?
[19:14] <Son_Goku> kyrofa: well, given that snapd has gone down this bucket of insanity, why the heck not, eh? >:(
[19:14] <kyrofa> Son_Goku, what are we talking about? :P
[19:14] <Son_Goku> (having multiple build systems inside of a single source tree that are not interdependent)
[19:14] <kyrofa> Son_Goku, ugh
[19:14] <Son_Goku> (but yet nothing works without everything built)
[19:15] <Son_Goku> all I can say is: I tried
[19:15] <Son_Goku> but I was the lone voice for sanity in a sea of crazy
[19:15] <kyrofa> Son_Goku, hahaha
[19:15] <kyrofa> Son_Goku, I gave up long ago
[19:16]  * Son_Goku shrugs
[19:16] <kyrofa> Son_Goku, good effort, though
[19:16] <kyrofa> iliv, alright, sorry, back to you
[19:16] <kyrofa> iliv, I'm making a paste for you
[19:17] <screwed> plz help i lost my administrator password
[19:17] <iliv> $ snapcraft -v
[19:17] <iliv> 2.24
[19:17] <kyrofa> screwed, on what?
[19:17] <screwed> how the hell do i fix this its pissing me off
[19:17] <kyrofa> iliv, alright good deal
[19:18] <screwed> forgot admin password
[19:19] <iliv> screwed, to what?
[19:19] <screwed> i forgot admin password to my laptop
[19:20] <screwed> im running ubuntu
[19:20] <iliv> screwed, wrong channel
[19:20] <iliv> screwed, try #ubuntu or better google "how to reset lost password ubuntu"
[19:20] <kyrofa> screwed, you might try in #ubuntu
[19:21] <screwed> i figured who ever is on here may know enough to help me. ive tried everything i can think of or have access too
[19:21] <screwed> did that
[19:22] <iliv> kyrofa, so what is the feature you mentioned?
[19:22] <kyrofa> iliv, here you go: http://pastebin.ubuntu.com/23674584/
[19:22] <kyrofa> iliv, I'm not tested that, but it should give you the idea
[19:22] <kyrofa> iliv, v2.24 introduced three new keywords: prepare, build, and install
[19:23] <iliv> where can I learn more about them?
[19:23] <kyrofa> iliv, `prepare` runs before the plugin builds, `build` replaces the plugin build/install, and `install` runs after the build/install
[19:23] <iliv> it's a shame snapcraft still doesn't have a man page
[19:23] <kyrofa> iliv, at this point snapcraft needs a book :P
[19:24] <iliv> alright, thank you kyrofa
[19:24] <iliv> I'll try that approach next year :P
[19:25] <iliv> and now is the time for some vacation and winter holidays
[19:25] <kyrofa> iliv, enjoy! I'll be joining you shortly
[19:26] <screwed> no its time to help me
[19:26] <kyrofa> iliv, that sounded creepier than it did in my head
[19:27] <iliv> :)
[19:27] <kyrofa> screwed, did you ask on #ubuntu?
[19:27] <screwed> yes
[19:27] <iliv> I think he may be a troll
[19:28] <iliv> aren't you screwed?
[19:28] <kyrofa> iliv, that's okay :)
[19:28] <screwed> im not a troll
[19:29] <kyrofa> screwed, did you see https://askubuntu.com/questions/24006/how-do-i-reset-a-lost-administrative-password ?
[19:29] <screwed> im dead serious
[19:29] <nacc> screwed: you're in the wrong channel, afaict
[19:29] <screwed> yep i tgried the grub loader thing
[19:30] <kyrofa> screwed, if that doesn't work I'm afraid no one here is qualified to help you. We're all Windows geeks around here
[19:33] <kyrofa> There. Sorry guys
[19:39] <Son_Goku> I'm sad that worked
[20:02] <kyrofa> Son_Goku, what, back in your day trolls put in more effort? ;)
[20:02] <Son_Goku> sadly, yes
[20:02] <Son_Goku> they were heartier trolls!
[20:03] <Son_Goku> and also, they at least read the topic to realize what you said was a flat out lie
[20:05] <kyrofa> :P
[20:12] <mup> PR snapcraft#1022 closed: plugins: update copy plugin to use get_build_properties() <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1022>
[20:48] <mup> PR snapcraft#761 closed: Remove dangling symlink from JDK plugin <Created by gnuoy> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/761>
[20:48] <mup> PR snapcraft#836 closed: Deal with 404 responses from the store's snap status endpoint <Created by thomir> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/836>
[20:54] <mup> PR snapcraft#929 closed: Snap snapcraft (based on pylxd branch) <Created by kalikiana> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/929>
[20:57] <mup> PR snapcraft#1013 closed: Cloudbuild (based on pylxd branch) <Created by kalikiana> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1013>
[21:24] <kyrofa> Alright, EOY for me. Merry Christmas everyone!
[21:33] <mcphail> kyrofa: Merry Christmas :)