[00:35] Bug #1638425 changed: The documentation to install snapd in archlinux doesn't mention that the socket needs to be started === JanC_ is now known as JanC [00:41] Bug #1639095 opened: On archlinux, /snap/bin is not added to the $PATH [00:46] uh [00:46] i apparently can't download snaps [00:46] i get 500s from the cfn [00:46] *cdn [00:47] heh working now [03:39] First boot is not accepting my Ubuntu Store login credentials... [03:41] Ok, so I have to login via SSH first... [03:41] Never mind... [05:41] PR snapd#2264 opened: Reinstate delta download [06:19] ogra_, ping === chihchun_afk is now known as chihchun [06:55] ogra_, ping [07:01] 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] 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] bonjello [09:45] PR snapd#2265 opened: Fix build failure on call to UbuntuArchitecture [10:00] PR snapcraft#887 closed: Cache apt related files (config, packages) in 'apt' parent directory [10:07] 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] Pharaoh_Atem: hey, I'm heading home but I have an idea [10:08] Pharaoh_Atem: can we detect via getenforce if selinux is on and just print a big fat warning [10:08] Pharaoh_Atem: and release the package as is [10:08] Pharaoh_Atem: it's better than keeping it siloed [10:09] Pharaoh_Atem: and more eyes == better [10:09] Pharaoh_Atem: perhaps someone will figure out how to actually fix the remaining warts [10:12] PR snapcraft#881 closed: Catkin plugin: Python nodes require gcc/g++ too [10:13] niemeyer: Any idea? ^^ [10:18] thomi: looks odd, we definitely land stuff all the time [10:18] zyga: that's what I figured - perhaps you stopped using travis for some reason? [10:18] PR snapcraft#671 closed: Add initial snapcraft manpage [10:18] PR snapcraft#879 closed: The latest icon definition is deprecated [10:18] thomi: look at pull requests [10:19] hmmm, well that's odd [10:19] but at least I see some green builds. Thanks zyga ! [10:20] 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] but that looks like a very slow cycle [10:21] PR snapcraft#661 closed: Added a test Jenkinsfile [10:21] PR snapcraft#674 closed: Add reference.md [10:21] PR snapcraft#736 closed: Disable internet access during unit tests [10:21] thomi: I think those are master builds on push that we've disabled [10:21] thomi: we test PRs instead [10:21] thomi: as we don't just push to master willy nilly [10:23] 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] PR snapcraft#874 closed: Remove the debian packaging [10:27] 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? === devil is now known as Guest43423 [10:47] how do i remove stuff i've added with snap try? [10:49] tsdgeos, "snap remove " [10:49] dholbach: but that removes everything [10:50] 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] tsdgeos, I'm not sure I understand... what would you like to remove and what would you like to keep? [10:50] i want to remove the two copies added by try [10:50] and just be left with the one i actually installed [10:51] [remove command options] [10:51] --revision= Remove only the given revision [10:51] I've never tried it, but ^ maybe that? [10:52] i can try thta i guess [11:00] tsdgeos, --revision should work [11:00] tsdgeos, btw, why are you wanting to remove 'em? [11:00] Chipaca: because space? [11:00] tsdgeos, they aren't copies [11:01] Chipaca: doesn't seem to work or i can't pass the correct revision number [11:01] tsdgeos, unless your app creates a lot of data [11:01] oh? [11:01] let me look [11:01] $ ls /snap/unity8-session/ [11:01] current x1 x2 [11:01] how do i remove x2 ? [11:01] PR snapd#2265 closed: Fix build failure on call to UbuntuArchitecture [11:02] ah i have to revert and then remove [11:02] tsdgeos, snap remove --revision x2 unity8-session [11:02] Chipaca: no that didn't work without reverting first [11:02] tsdgeos, ah, if it's current, yes [11:02] tsdgeos, that's why the help says "revert first" :-D [11:02] not the help, the error message [11:02] with a ? [11:02] doesn't make one very confident [11:03] well, it's not a mind reader [11:03] whether or not it's the right thing to do depends on what you're wanting to do [11:03] well i told it to remove the thing [11:03] for example, you might not *want* to remove the current revision [11:03] then remove the thing [11:21] dholbach: will you join our call in 11.5h? I would appreciate your input. [11:22] 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. === chihchun is now known as chihchun_afk [11:36] PR snapd#2130 closed: store: retry store ops (phase 1) === Guest43423 is now known as devil_ === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === hikiko is now known as hikiko|ln [11:58] PR snapd#2266 opened: tests: run autopkgtests [12:04] bzoltan: okay! :) [12:20] elopio: thanks for the unit test example [12:20] I was able to add another test based on that one, so there's two tests now [12:20] bzoltan, 11.5h? [12:21] 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] bzoltan, but yeah [12:21] dholbach: ohh... a typo :) in 11.5h i will be in my pyjama and sleep like a baby [12:21] +1 === hikiko|ln is now known as hikiko [13:19] Bug #1639234 opened: docs/rest has not url for install (refresh, revert, remove) example [13:33] kalikiana_: ack [13:51] is there a way for snapcraft to use a local deb instead one from the archive? [13:51] when building the snap file? [13:52] tsdgeos: Yes! [13:52] tsdgeos: You know the file path? [13:52] qengho: for the deb i want to use? [13:53] i can know it, yes [13:56] or i guess i can dpkg -x into the prime folder? [13:58] tsdgeos: Not merged yet, but you could use it anyway. https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin/+merge/266650 [14:24] 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] sure, hang on [14:42] Do we have any way of knowing when snapcraft builder for launchpad-hosted snap building is updated? [15:50] Bug #1639284 opened: Cant start any snap application on Xenial [16:15] 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] i.e. is deb postinst run? [16:16] 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] ok [16:45] PR snapd#2267 opened: Release version 2.17.1 [17:08] PR snapd#2253 closed: interfaces/builtin/mir: allow slot to make recvfrom syscalls [17:14] sergiusens: I'm working on it now [17:14] but I'm having a problem [17:14] I don't know why this unit test is failing [17:14] the code it's failing on is exactly the same as the deb source code [17:14] by all rights, it should work [17:14] I don't know why it isn't [17:15] 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] _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] well, if you set devmode you also need --devmode for snap install and snap refresh ... [17:26] 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] 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] Where should I file about about the official disk images' compression scheme, xz? [18:26] That is, I want to ask for images to be gz compressed too. MEMDISK doesn't support xz. [18:33] Bug #1639328 opened: Snappy Ubuntu Core images are not in a format readable by MEMDISK [18:35] 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] elopio: ping [19:05] Hey, how can I understand what snap versions are available in each channel? [19:05] 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] I was expecting snap refresh --list to give me that info... [19:05] but... [19:05] it doesn't seem to do [19:06] I can only snap refresh --edge and see what will happen, but not get those inofs without changing [19:09] I mean something similar to snapcraft status for your pkgs... === kenvandine_ is now known as kenvandine === JanC is now known as Guest51811 === JanC_ is now known as JanC [19:50] Trevinho: I believe we intend to make a `snap info foo` command to provide that information, but is not available yet [20:07] Trevinho: can't you do snap refresh --list --edge? [20:12] 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] jdstrand: awesome! Sure, I'll give it a whirl in a sec [20:12] roadmr: I have one more thing to implement for completeness, but it isn't used anywhere yet [20:20] noise][: yeah, I was wondering why that isn't available too... [20:20] jdstrand: ok [20:20] dobey: I tried the same, but no... It says --list does not take mode nor channel flags [20:21] 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] noise][: I hope so. Thanks for the info about `info` tho :-) [20:25] 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] 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] 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] roadmr: but again, yes, we'll be giving the errors a once over [20:39] jdstrand: thanks, that'll be quite useful [20:39] reviewers are humans too \o/ [20:48] 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] Pharaoh_Atem: doesn't make a lot of sense. It's the same code as the other test ¯\_(ツ)_/¯ [21:41] let me finish my travis builds, and I'll try to debug it. [21:41] okay [21:42] * Pharaoh_Atem is starting to feel really frustrated with this particular test [21:42] I was tempted to just delete the test, but that feels like cheating... [21:43] 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] elopio: I wanted it to make it into the next version of snapcraft [21:53] but I think it just went out today [21:55] hmm, went out two days ago [21:58] kyrofa: why do you think you'll get to avoid SRUs with snaps? [21:58] 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] SRU is a way to control the rollout in the repository; snaps are controlled by the developer independently, no? [21:59] nacc: sure, but if you're the developer...? [21:59] you better have a process for ensuring things are worth releasing [21:59] * nacc lacks context [22:00] but i think it's just saying that there is no such thing as the SRU process for snaps [22:00] you just push fixes [22:00] with your own CI [22:00] presumably [22:00] and QA [22:00] 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] PR snapcraft#880: Remove license concepts [22:00] 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] SRU and various other tools require that you go through a formal process [22:01] yes [22:01] run by the SRU team [22:01] there is no such process for snaps [22:01] there probably will be eventually [22:01] you as the end developer can push whatever version you want to whatever stream [22:01] sure [22:02] but you (as Canonical) would have a process for pushing updates to your own snaps [22:02] i'm not so sure; the lack of SRU is meant to be one of the pros :) [22:02] just as I (as a dumb human) would have a process for ensuring what I push is halfway decent [22:02] well for canonical owned snaps, they'd figure something out, i'm sure [22:02] i'm not sure what that has to do with SRU [22:03] imho, tools cannot eliminate processes [22:03] 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] only people can eliminate processes [22:03] nobody said you *have* to have an SRU process for Ubuntu repos [22:03] 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] but breaking people's world is generally not a good idea and something you probably don't want to do [22:04] so that would require implementing a process to ensure you don't do that [22:04] how would you break their world? [22:04] well, at least in this example (PR880), they broke snapcraft.yaml files that used the license stuff because they removed it [22:04] 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] Pharaoh_Atem: i don't know the specific context, sorry [22:06] * Pharaoh_Atem shrugs [22:06] the general point I'm making is that tools don't necessarily get rid of processes [22:06] only people do [22:07] if you want a lighter process, you change the process to be so === JanC_ is now known as JanC [23:34] PR snapcraft#888 opened: Always respect go-buildtags