[00:35] <mup> Bug #1638425 changed: The documentation to install snapd in archlinux doesn't mention that the socket needs to be started <snap-docs> <Snappy:Fix Released by fgimenez> <https://launchpad.net/bugs/1638425>
[00:41] <mup> Bug #1639095 opened: On archlinux, /snap/bin is not added to the $PATH <archlinux> <Snappy:New> <https://launchpad.net/bugs/1639095>
[00:46] <mwhudson> uh
[00:46] <mwhudson> i apparently can't download snaps
[00:46] <mwhudson> i get 500s from the cfn
[00:46] <mwhudson> *cdn
[00:47] <mwhudson> heh working now
[03:39] <DSS> First boot is not accepting my Ubuntu Store login credentials...
[03:41] <DSS> Ok, so I have to login via SSH first...
[03:41] <DSS> Never mind...
[05:41] <mup> PR snapd#2264 opened: Reinstate delta download <Created by absoludity> <https://github.com/snapcore/snapd/pull/2264>
[06:19] <liuxg> ogra_, ping
[06:55] <liuxg> ogra_, ping
[07:01] <liuxg> I am now using kvm to launch ubuntu core, when I am trying to login using "ssh -p 10022 USER@localhost", it prompts me a password. May i know what password should it be? is it the one for the Ubuntu One account or the ssh keys? thanks
[07:41] <liuxg> what should be the correct password for logging into a kvm ubuntu core system? I have tried to use the Ubuntu One password, but it fails. thanks
[07:49] <foxmask> bonjello
[09:45] <mup> PR snapd#2265 opened: Fix build failure on call to UbuntuArchitecture <Created by stolowski> <https://github.com/snapcore/snapd/pull/2265>
[10:00] <mup> PR snapcraft#887 closed: Cache apt related files (config, packages) in 'apt' parent directory <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/887>
[10:07] <thomi> Hi snappy devs, we're considering deploying a new search.apps.u.c today, and wanted to check the state of snapd integration tests, but https://travis-ci.org/snapcore/snapd/builds seems to think nothing has landed in the last 17 days. Am I looking in the wrong place?
[10:08] <zyga> Pharaoh_Atem: hey, I'm heading home but I have an idea
[10:08] <zyga> Pharaoh_Atem: can we detect via getenforce if selinux is on and just print a big fat warning
[10:08] <zyga> Pharaoh_Atem: and release the package as is
[10:08] <zyga> Pharaoh_Atem: it's better than keeping it siloed
[10:09] <zyga> Pharaoh_Atem: and more eyes == better
[10:09] <zyga> Pharaoh_Atem: perhaps someone will figure out how to actually fix the remaining warts
[10:12] <mup> PR snapcraft#881 closed: Catkin plugin: Python nodes require gcc/g++ too <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/881>
[10:13] <thomi> niemeyer: Any idea? ^^
[10:18] <zyga> thomi: looks odd, we definitely land stuff all the time
[10:18] <thomi> zyga: that's what I figured - perhaps you stopped using travis for some reason?
[10:18] <mup> PR snapcraft#671 closed: Add initial snapcraft manpage <Created by tsimonq2> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/671>
[10:18] <mup> PR snapcraft#879 closed: The latest icon definition is deprecated <Created by liu-xiao-guo> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/879>
[10:18] <zyga> thomi: look at pull requests
[10:19] <thomi> hmmm, well that's odd
[10:19] <thomi> but at least I see some green builds. Thanks zyga !
[10:20] <tsdgeos> what's the optimal workflow for integrating changes into a snap to see if they fix a bug? the only thing i can think of is, but MR in launchpad, make bileto create a ppa, add ppa to my system, rebuild the snap
[10:20] <tsdgeos> but that looks like a very slow cycle
[10:21] <mup> PR snapcraft#661 closed: Added a test Jenkinsfile <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/661>
[10:21] <mup> PR snapcraft#674 closed: Add reference.md <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/674>
[10:21] <mup> PR snapcraft#736 closed: Disable internet access during unit tests <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/736>
[10:21] <zyga> thomi: I think those are master builds on push that we've disabled
[10:21] <zyga> thomi: we test PRs instead
[10:21] <zyga> thomi: as we don't just push to master willy nilly
[10:23] <kalikiana_> stgraber: jdstrand FYI conflicts resolved and the branch has got the latest definitions - I think it works, but by design, apparently, I can't actually test it... so how do we proceed from here? Not quite sure how this will work in the end
[10:24] <mup> PR snapcraft#874 closed: Remove the debian packaging <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/874>
[10:27] <sergiusens> Pharaoh_Atem hey, I want to land your RPM support to make it go into the next release, will you have time to do the catching up in the branch?
[10:47] <tsdgeos> how do i remove stuff i've added with snap try?
[10:49] <dholbach> tsdgeos, "snap remove <snap-name>"
[10:49] <tsdgeos> dholbach: but that removes everything
[10:50] <tsdgeos> dholbach: the thing is, if i have the snap, then i "try" twice, i end up with 3 copies of the snap in /snap
[10:50] <dholbach> tsdgeos, I'm not sure I understand... what would you like to remove and what would you like to keep?
[10:50] <tsdgeos> i want to remove the two copies added by try
[10:50] <tsdgeos> and just be left with the one i actually installed
[10:51] <dholbach> [remove command options]
[10:51] <dholbach>           --revision= Remove only the given revision
[10:51] <dholbach> I've never tried it, but ^ maybe that?
[10:52] <tsdgeos> i can try thta i guess
[11:00] <Chipaca> tsdgeos, --revision should work
[11:00] <Chipaca> tsdgeos, btw, why are you wanting to remove 'em?
[11:00] <tsdgeos> Chipaca: because space?
[11:00] <Chipaca> tsdgeos, they aren't copies
[11:01] <tsdgeos> Chipaca: doesn't seem to work or i can't pass the correct revision number
[11:01] <Chipaca> tsdgeos, unless your app creates a lot of data
[11:01] <Chipaca> oh?
[11:01] <Chipaca> let me look
[11:01] <tsdgeos> $ ls /snap/unity8-session/
[11:01] <tsdgeos> current  x1  x2
[11:01] <tsdgeos> how do i remove x2 ?
[11:01] <mup> PR snapd#2265 closed: Fix build failure on call to UbuntuArchitecture <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2265>
[11:02] <tsdgeos> ah i have to revert and then remove
[11:02] <Chipaca> tsdgeos, snap remove --revision x2 unity8-session
[11:02] <tsdgeos> Chipaca: no that didn't work without reverting first
[11:02] <Chipaca> tsdgeos, ah, if it's current, yes
[11:02] <Chipaca> tsdgeos, that's why the help says "revert first" :-D
[11:02] <Chipaca> not the help, the error message
[11:02] <tsdgeos> with a ?
[11:02] <tsdgeos> doesn't make one very confident
[11:03] <Chipaca> well, it's not a mind reader
[11:03] <Chipaca> whether or not it's the right thing to do depends on what you're wanting to do
[11:03] <tsdgeos> well i told it to remove the thing
[11:03] <Chipaca> for example, you might not *want* to remove the current revision
[11:03] <tsdgeos> then remove the thing
[11:21] <bzoltan> dholbach: will you join our call in 11.5h? I would appreciate your input.
[11:22] <bzoltan> popey: mhall119:dholbach: I have added a doc to the invitation.. if you can spare few minutes to review that would make our call more efficient.
[11:36] <mup> PR snapd#2130 closed: store: retry store ops (phase 1) <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2130>
[11:58] <mup> PR snapd#2266 opened: tests: run autopkgtests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2266>
[12:04] <popey> bzoltan: okay! :)
[12:20] <Son_Goku> elopio: thanks for the unit test example
[12:20] <Son_Goku> I was able to add another test based on that one, so there's two tests now
[12:20] <dholbach> bzoltan, 11.5h?
[12:21] <Son_Goku> I'll have to play with the code to see if I can make a cpio archive with "./" at the beginning of the path, as well as one with "/" at the beginning too
[12:21] <dholbach> bzoltan, but yeah
[12:21] <bzoltan> dholbach: ohh... a typo :) in 11.5h i will be in my pyjama and sleep like a baby
[12:21] <dholbach> +1
[13:19] <mup> Bug #1639234 opened: docs/rest has not url for install (refresh, revert, remove) example <Snappy:New> <https://launchpad.net/bugs/1639234>
[13:33] <jdstrand> kalikiana_: ack
[13:51] <tsdgeos> is there a way for snapcraft to use a local deb instead one from the archive?
[13:51] <tsdgeos> when building the snap file?
[13:52] <qengho> tsdgeos: Yes!
[13:52] <qengho> tsdgeos: You know the file path?
[13:52] <tsdgeos> qengho: for the deb i want to use?
[13:53] <tsdgeos> i can know it, yes
[13:56] <tsdgeos> or i guess i can dpkg -x into the prime folder?
[13:58] <qengho> tsdgeos: Not merged yet, but you could use it anyway. https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin/+merge/266650
[14:24] <bzoltan> dholbach: popey: once again, thank you for your time. I have edited and format a bit the minutes. Would you please take a quick look at it and call me an idiot if i missed something or interpreted something wrong?
[14:26] <dholbach> sure, hang on
[14:42] <qengho> Do we have any way of knowing when snapcraft builder for launchpad-hosted snap building is updated?
[15:50] <mup> Bug #1639284 opened: Cant start any snap application on Xenial <Snappy:New> <https://launchpad.net/bugs/1639284>
[16:15] <tsdgeos> so the unity8-session snap is missing some symlinks that are created by the deb " using the alternate system", i guess snapcraft doesn't run those steps?
[16:16] <tsdgeos> i.e. is deb postinst run?
[16:16] <qengho> tsdgeos: Correct. There is no post-install. post-install runs have to be done at "stage" or "snap" time, when fabricating a snap package.
[16:17] <tsdgeos> ok
[16:45] <mup> PR snapd#2267 opened: Release version 2.17.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2267>
[17:08] <mup> PR snapd#2253 closed: interfaces/builtin/mir: allow slot to make recvfrom syscalls <Created by albaguirre> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2253>
[17:14] <Pharaoh_Atem> sergiusens: I'm working on it now
[17:14] <Pharaoh_Atem> but I'm having a problem
[17:14] <Pharaoh_Atem> I don't know why this unit test is failing
[17:14] <Pharaoh_Atem> the code it's failing on is exactly the same as the deb source code
[17:14] <Pharaoh_Atem> by all rights, it should work
[17:14] <Pharaoh_Atem> I don't know why it isn't
[17:15] <Pharaoh_Atem> I think I may not understand how this test is supposed to be written, but... :/
[17:21] <_markfeatherston> Hello, I'm trying to build a kernel for ubuntu core and I'm running into troubles (Failed downloading ubuntu-core/edge).  Is anyone here familiar with this error?
[17:21] <_markfeatherston> Error: https://paste.ee/p/PjiEd
[17:21] <_markfeatherston> yaml: https://paste.ee/p/pW24W
[17:22] <ogra_> _markfeatherston, looks like there is a store problem currently
[17:22] <_markfeatherston> Ahh, good to know.  I'll hold off a bit on this then.  Thanks!
[17:24] <_markfeatherston> Actually I do have other questions in the meantime.  I'm looking at the 96boards kernel as a reference.  It has "confinement: strict" in the yaml.  I think I understand what this means in context of an application, but does the confinement do anything with kernels?
[17:25] <ogra_> well, if you set devmode you also need --devmode for snap install and snap refresh ...
[17:26] <ogra_> beyond that i dont think it does anything actively atm (it probably will)
[17:26] <_markfeatherston> ok, makes sense
[17:28] <_markfeatherston> the example kernel yaml also had "kdefconfig: [defconfig, distro.config]".  What is the distro.config in this case?  Is that ubuntu core's kernel config options?
[17:30] <ogra_> i think thats a question for the kernel team :) ppisati might be your man, but he is at the plumbers conference
[17:31] <_markfeatherston> Ok, I'll check back later for that or just experiment when the store comes back up.  thanks :)
[18:24] <qengho> Where should I file about about the official disk images' compression scheme, xz?
[18:26] <qengho> That is, I want to ask for images to be gz compressed too. MEMDISK doesn't support xz.
[18:33] <mup> Bug #1639328 opened: Snappy Ubuntu Core images are not in a format readable by MEMDISK <Snappy:New> <https://launchpad.net/bugs/1639328>
[18:35] <pippo_> ho installato ubuntu core ma ad un certo punto mi chiede un email address "from your account in the store": di quale account si tratta ?
[19:04] <Pharaoh_Atem> elopio: ping
[19:05] <Trevinho> Hey, how can I understand what snap versions are available in each channel?
[19:05] <Pharaoh_Atem> elopio: I removed the pull() call, but it's still breaking, and I'm not sure why... https://travis-ci.org/snapcore/snapcraft/jobs/173348023
[19:05] <Trevinho> I was expecting snap refresh --list <snap> to give me that info...
[19:05] <Trevinho> but...
[19:05] <Trevinho> it doesn't seem to do
[19:06] <Trevinho> I can only snap refresh --edge <snap> and see what will happen, but not get those inofs without changing
[19:09] <Trevinho> I mean something similar to snapcraft status for your pkgs...
[19:50] <noise][> Trevinho: I believe we intend to make a `snap info foo` command to provide that information, but is not available yet
[20:07] <dobey> Trevinho: can't you do snap refresh --list --edge?
[20:12] <jdstrand> roadmr: hi! please feel free to test r791. that has the fix for bools as strings as well as everything for parsing the base declaration and applying overrides with --plugs/--slots
[20:12] <roadmr> jdstrand: awesome! Sure, I'll give it a whirl in a sec
[20:12] <jdstrand> roadmr: I have one more thing to implement for completeness, but it isn't used anywhere yet
[20:20] <Trevinho> noise][: yeah, I was wondering why that isn't available too...
[20:20] <roadmr> jdstrand: ok
[20:20] <Trevinho> dobey: I tried the same, but no... It says --list does not take mode nor channel flags
[20:21] <noise][> Trevinho: i think just didn't make the cut in the rush to the UC 16 release but I suspect will get added before long
[20:21] <Trevinho> noise][: I hope so. Thanks for the info about `info` tho :-)
[20:25] <roadmr> jdstrand: it works! so if I pass a --plugs plugs.json with a payload allowing e.g. lxd-support, my snap which uses it gets auto-passed; if I just change the interface name in the payload, it gets flagged for manual review
[20:27] <roadmr> jdstrand: the message is a bit cryptic (if accurate): "not allowed by 'allow-installation' in base declaration" doesn't hint that it could also be allowed in a --plugs or --slots override. But I think it's fine like this and we can tweak if we get confusion
[20:39] <jdstrand> roadmr: we are going to give the messages an overhaul. the message is meant to convey what denied it, not how to override it since a reviewer will presumably know that
[20:39] <jdstrand> roadmr: but again, yes, we'll be giving the errors a once over
[20:39] <roadmr> jdstrand: thanks, that'll be quite useful
[20:39] <roadmr> reviewers are humans too \o/
[20:48] <Trevinho> sergiusens: hey... Is there any way to make the version in the snapcraft.yaml to be more dynamic? I.e. to add a cvs revision or something similar?
[21:41] <elopio> Pharaoh_Atem: doesn't make a lot of sense. It's the same code as the other test ¯\_(ツ)_/¯
[21:41] <elopio> let me finish my travis builds, and I'll try to debug it.
[21:41] <Pharaoh_Atem> okay
[21:42]  * Pharaoh_Atem is starting to feel really frustrated with this particular test
[21:42] <Pharaoh_Atem> I was tempted to just delete the test, but that feels like cheating...
[21:43] <elopio> it's almost done. I just feel bad that we were so slow to review it. Hopefully we get faster now that there are no sprints and no big releases.
[21:53]  * Pharaoh_Atem shrugs
[21:53] <Pharaoh_Atem> elopio: I wanted it to make it into the next version of snapcraft
[21:53] <Pharaoh_Atem> but I think it just went out today
[21:55] <Pharaoh_Atem> hmm, went out two days ago
[21:58] <Pharaoh_Atem> kyrofa: why do you think you'll get to avoid SRUs with snaps?
[21:58] <Pharaoh_Atem> if anything, I think the SRU process would transfer over to snaps, since it'd be more important with the coarser dependency logic
[21:59] <nacc> SRU is a way to control the rollout in the repository; snaps are controlled by the developer independently, no?
[21:59] <Pharaoh_Atem> nacc: sure, but if you're the developer...?
[21:59] <Pharaoh_Atem> you better have a process for ensuring things are worth releasing
[21:59]  * nacc lacks context
[22:00] <nacc> but i think it's just saying that there is no such thing as the SRU process for snaps
[22:00] <nacc> you just push fixes
[22:00] <nacc> with your own CI
[22:00] <nacc> presumably
[22:00] <nacc> and QA
[22:00] <Pharaoh_Atem> yes, but in https://github.com/snapcore/snapcraft/pull/880, kyrofa makes the comment that pushing major version updates will not have an SRU process
[22:00] <mup> PR snapcraft#880: Remove license concepts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/880>
[22:00] <Pharaoh_Atem> I'd argue that you'd likely be forced to be more careful, because there's literally no way to check and guard against breakage at all
[22:01] <nacc> SRU and various other tools require that you go through a formal process
[22:01] <Pharaoh_Atem> yes
[22:01] <nacc> run by the SRU team
[22:01] <nacc> there is no such process for snaps
[22:01] <Pharaoh_Atem> there probably will be eventually
[22:01] <nacc> you as the end developer can push whatever version you want to whatever stream
[22:01] <Pharaoh_Atem> sure
[22:02] <Pharaoh_Atem> but you (as Canonical) would have a process for pushing updates to your own snaps
[22:02] <nacc> i'm not so sure; the lack of SRU is meant to be one of the pros :)
[22:02] <Pharaoh_Atem> just as I (as a dumb human) would have a process for ensuring what I push is halfway decent
[22:02] <nacc> well for canonical owned snaps, they'd figure something out, i'm sure
[22:02] <nacc> i'm not sure what that has to do with SRU
[22:03] <Pharaoh_Atem> imho, tools cannot eliminate processes
[22:03] <nacc> that's more a statement that if you change something, test it and make sure it doesn't break anything -- SRU is a specific implentation of that
[22:03] <Pharaoh_Atem> only people can eliminate processes
[22:03] <Pharaoh_Atem> nobody said you *have* to have an SRU process for Ubuntu repos
[22:03] <nacc> Pharaoh_Atem: dunno; i think the point in there was that SRUs are generally not meant to be major version bumps -- but snaps make that easier to deleiver
[22:03] <Pharaoh_Atem> but breaking people's world is generally not a good idea and something you probably don't want to do
[22:04] <Pharaoh_Atem> so that would require implementing a process to ensure you don't do that
[22:04] <nacc> how would you break their world?
[22:04] <Pharaoh_Atem> well, at least in this example (PR880), they broke snapcraft.yaml files that used the license stuff because they removed it
[22:04] <Pharaoh_Atem> making those files that used it now invalid
[22:06] <_markfeatherston> Is this at all still relevant for ubuntu core 16? https://developer.ubuntu.com/en/snappy/guides/porting/
[22:06] <nacc> Pharaoh_Atem:  i don't know the specific context, sorry
[22:06]  * Pharaoh_Atem shrugs
[22:06] <Pharaoh_Atem> the general point I'm making is that tools don't necessarily get rid of processes
[22:06] <Pharaoh_Atem> only people do
[22:07] <Pharaoh_Atem> if you want a lighter process, you change the process to be so
[23:34] <mup> PR snapcraft#888 opened: Always respect go-buildtags <Created by stgraber> <https://github.com/snapcore/snapcraft/pull/888>