[00:23] on my rpi3 after I snap install pulseaudio I don't see any cards/sinks, anything I need to do to set that up? [01:05] morphis: I think I'll crash and burn if someone suggests double LSM again as a solution [01:37] Is anyone interested in helping me create a snap for Rapid Photo Downloader? [01:40] perhaps if you ask a specific question :) [01:41] but im actually about to go for the day [01:43] Croepha, I'm a bit confused about the relationship between getting something from pip via the requirements.txt and that thing requiring dependencies to be present beforehand [01:44] outside of a snap environment, one has to apt install all the build requirements first, naturally [01:44] are you using the python plugin in snapcraft? [01:44] I don't know if I should be or not [01:45] it's a python program, but it's dependencies are not trivial [01:46] if you want to do the equivalent of an apt-install for a snap, you can do something called "stage-packages" [01:47] but, that usually isn't the best for python requirements [01:48] im not very familiar with the python plugin, but I think it expects a properly structured python package source, and it will bundle requirements that are specified in the setup.py [01:48] One thing i can't get a handle on is how do you make changes to a snap app? I i'll use Hexchat as an example,I usually change the colors in it by changing some config files. Snap is a read only file system,so i am a bit lost here.. [01:49] gregl: everything that needs to be variable, should be located in one of the writable directories [01:49] ok thanks Croepha I'll look into it some more [01:50] gregl: use https://snapcraft.io/docs/reference/env [01:50] gregl: you could also look at the users home directory for settings files, but that isn't a snap supported thing to do [01:50] but it works [01:51] Croepha, Ok thanks,I did find the writeable folders.. [01:51] Cool .I will look a bit more.. [02:57] ok, i must be doing something obviously wrong. given the following yaml: http://paste.ubuntu.com/24364688/ i want the run.sh in snap/run.sh in the same git repository as the main part to be included in the built snap as the application. Basically, add a custom wrapper that is in the same repository [03:05] PR snapcraft#1250 opened: Fixed links to doc [03:06] but when i use the builders on launchpad, i just get errors consistently about being unable to find run.sh [03:58] ah, i might be being bit by LP: #1663534 ... i wonder why `snapcraft cleanbuild` on my 17.04 machine at home doesn't complain, though? [03:58] Bug #1663534: Dump plugin can't copy files from snap/ [05:12] PR snapcraft#1251 opened: internal: remove empty lines in the unclean parts message [05:46] I've got revision 9 of a snap published in the stable channel in the store that I can install with 'sudo snap install wal-e --classic'. However, doing that in an lxd container on the same box is getting revision 6. [05:47] I suspect it is a permissions issue, and the difference is the lxd container is not logged on at all. But I can't see where it is screwed up. [05:49] oh, got it. The scripted install in the container was using the wrong channel. === chihchun_afk is now known as chihchun [05:53] * stub wonders if 'snap list' and 'snap refresh' should mention channels [06:09] PR snapd#3178 closed: Release 2.24 [06:14] Son_Goku: you mean AppArmor and SELinux in parallel? [06:32] PR snapd#3180 opened: many: fixes for `go vet` in go 1.7 [06:51] jdstrand: hey, I heard rumors that there is an issue with the renamed snap-confine apparmor profile in 2.24/2.23.6 - if you have more details I would love to hear them [06:55] mvo: it looked like the ADT tests for the kernel would uninstall the 2.22.6 snapd (without purging and without uninstalling snap-confine) and then later install snapd 2.23.6. Because of that, I think the postrm bit to remove the old snap-confine profile wouldn't get triggered. [06:56] So both versions of the profile would exist after the "upgrade". [06:58] sbeattie: aha, thank you. let me try that [06:59] sbeattie: do you happen to know if there is a log or a bug available for this? [07:00] mvo, jdstrand: I'm not sure a bug got filed for it [07:00] mvo: log is at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-hwe-edge/20170410_201241_f4dfd@/log.gz [07:01] sbeattie: ta! [07:01] mvo: I'm not honestly sure if it's a snapd bug or an ADT bug. [07:02] but I can file one in case you decide to upload something on the snapd side to fix/work around it. [07:02] sbeattie: definitely worth persuing, I suspect that we left a file behind (/etc/apparmor.d/usr.lib.snapd.snap-confine) in some upgrade screnario [07:06] good morning [07:06] hey zyga, morning! [07:09] hey hey [07:09] sorry, overslept [07:09] how's everything? [07:09] mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1682023 [07:09] Bug #1682023: snapd/snapd-confine leaves behind /etc/apparmor.d/usr.lib.snapd.snap-confine on upgrade [07:11] thanks sbeattie [07:11] hey zyga and pstolowski [07:11] and good morning fgimenez_ :) [07:12] fgimenez_: I added a forum topic and invited for you, not sure if that works [07:12] mvo: zyga pstolowski good morning [07:12] mvo: sure, already ack'ed with a hearth :) [07:13] sbeattie: apw figured out that on purge the apparmor profile is removed from disk but not unloaded from the kernel. not sure if that is expected behaviour ? maybe a precaution to ensure that running binaries that are removed from disk but still in memory are still protected? in any case it explains the error but its a bit unclear what we can do about it [07:13] mvo: i'm currently involved in core validation at candidate too, as soon as that is sorted i'll put hands on the sru [07:14] fgimenez_: thank you, no problem, I just got asked about it via irc and with a forum topic its much easier for me, I can just point people to that :) [07:14] sbeattie: if you purge snap-confine does that go away? [07:15] mvo: totally, the forum is a huge improvement for that [07:15] aha [07:15] it didn't purge [07:16] o/ [07:16] zyga: yeah, I suspect we need a dpkg-mainthelper to remove the conffile on the snap-confine package as well [07:17] mvo: the package gets removed on purge [07:17] mvo: I tested this when we were working on the .real workaround [07:18] i think the suggestion is you have old snapd + fat snap-confine installed [07:19] you now purge snapd only [07:19] and then install the -updates snapd [07:19] i am trying to get into that situation here [07:21] zyga, apw: http://paste.ubuntu.com/24365745/ might be all we need - but first we need to reproduce :) [07:22] * zyga looks [07:22] mvo: thank you [07:22] * zyga is still sleepy [07:22] * mvo hugs zyga [07:28] mvo, ok reproduced [07:29] apw: I think I did so as well and the mainthelper did help me, could you pastebin your steps so that I can double check? [07:30] mvo, just doing it again with a transcript to be sure i did it sane [07:32] PR snapd#3181 opened: debian: add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine [07:43] mvo, ok reproduced and documented: http://paste.ubuntu.com/24365841/ [07:43] mvo, shall i add that to the bug as well [07:44] PR snapd#3182 opened: store: tests for unexpected EOF [07:46] apw: \o/ #3181 should help, I wonder what the easiest way for you to double check might be (if you are still interessted). I could do a PPA build for you? or I just reproduce all your steps once its in master and it gets into our daily edge ppa. [07:47] when trying to run the anbox snap in fedora, i get "execv failed: No such file or directory" - is that a problem of snapd or the snap? [07:47] mvo, if you have a .deb set i thnk i can legitimatly test those by hand to confirm [07:50] all this because people are not doing upgrades right, sigh [07:51] apw: http://people.canonical.com/~mvo/tmp/for-andy/ [07:51] apw: this one is hopefully good [07:53] mbriza: hey, perhaps snapd, can you please tell me which release are you on? [07:54] Removing obsolete conffile /etc/apparmor.d/usr.lib.snapd.snap-confine ... [07:54] mvo, ^ i assume that is a good sign [07:54] and i have only the .real [07:55] so i call that fixed in your packages [07:55] zyga: looks like today is happy we-update-all-distros-with-2.24-day :-) [07:57] morphis_: indeed [07:57] morphis_: congratulations on android box :) [07:57] morphis_: did you try it on fedora, mbriza above said there is something fishy [07:57] zyga: thanks, that was a long overdue thing [07:57] zyga: no, not yet but I know people tried [07:58] zyga: it will be a bit harder as we don't have dkms packages for the binder/ashmem kernel drivers there yet [07:58] morphis_: aha [07:59] morphis_: how does the snap work? [07:59] zyga: devmode-only :-D [07:59] zyga: and https://github.com/anbox/anbox/blob/master/scripts/container-manager.sh#L31 [08:00] aha [08:00] morphis_: I think you could detect if you have apparmor around you and skip aa-exec [08:00] morphis_: but I bet this will come with time [08:00] mbriza: ^^ [08:01] zyga: yes, for non-apparmor enabled systems we have [08:01] zyga: https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1647168 [08:01] Bug #1647168: /dev/ashmem and /dev/binder not usable inside confinement [08:02] that was the initial reason for the aa-exec call [08:02] didn't investigated that further yet [08:02] apw: \o/ [08:03] apw: if you could comment in https://github.com/snapcore/snapd/pull/3181 that would be great [08:03] PR snapd#3181: debian: add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine [08:07] mvo, am just making sure i did the test right (i am sure i did) and scipting it [08:07] mup, ok that worked and i am happy i am sure it did :) [08:07] apw: I apologize, but I'm pretty strict about only responding to known commands. [08:07] mvo, ok that worked and i am happy i am sure it did :) [08:08] \o/ again! [08:10] mvo, is that sufficient (as a comment) [08:10] apw: absolutely, thank you [08:17] ogra_, I have flashed latest rpi3 image, but I am not able to connect to the store from console-conf, is that a known issue? It hangs in "Contacting store..." [08:17] abeato, Bug #1638537 [08:17] Bug #1638537: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 [08:19] ogra_, not sure if it is the same, I can enter console-conf, it fails when trying to contact the store [08:21] like ... with an error ? [08:21] or does it just sit there ? [08:22] if the latter ... give it time ... if not, thats something different then [08:22] ogra_, sits there, although it has just entered in the end... took really long :/ [08:22] yep, there is a fix ... but not landed yet [08:22] weird... [08:22] ok, good to know [08:22] it generates the device gpg key [08:23] ogra_, another thing, which is the recommended way to get wifi working on rpi3? [08:23] and go's routine for that is extremely resource consuming ... [08:23] configure with wired ... ssh in, run: sudo console-conf ... disable wired, enabled wlan, reboot [08:24] the wlan only has issues on the very first boot [08:24] ogra_, hm, is disabling wired needed? [08:24] not really ... just the german in me that wants it cleaned up :P [08:25] lol [08:25] thanks! [09:02] zyga, hey, do you have a moment to review #3182? it's just a test and I need 2nd review [09:04] pstolowski: yes, looking [09:10] pstolowski: stopped mid-way, brb [09:20] re [09:21] pstolowski: so, not sure I understand what's going on there, I'll ask a few questions if that's okay [09:23] how do I get the ownership of a snap transferred to a different user/namespace? [09:24] nottrobin: I think you can file a bug in the store [09:24] http://launchpad.net/snapstore [09:24] ta [09:25] fun fact: scaleway offers ubuntu without 'updates' repository enabled [09:25] so just security [09:25] and main [09:26] I just installed snapd 2.0.2 /o\ [09:26] bug filed: https://bugs.launchpad.net/snapstore/+bug/1682063 [09:26] Bug #1682063: Transfer documentation-builder from nottrobin to canonicalwebteam [09:27] zyga, hmm, we should probably make a deal with the security team to push it to -security in parallel (like kernels) ... that setup is surely not uncommon [09:32] pstolowski: commented [09:32] ogra_: yes, I agree [09:32] ogra_: but I also wonder if ubuntu is certified there [09:37] zyga, thanks! [09:38] zyga, well, disabling updates and leaving security on is not uncommon on servers i think === pbek_ is now known as pbek [09:43] ogra_: we only push kernels to security when we know of security issues fixed in them; alas, that happens 90% of the time. But we do push non-security toolchain things to security (to fix security builds or boot issue breakages), I suspect snapd would fall under this area. [09:44] sbeattie, yeah [09:44] given the amount of apparmor and seccomp changes each release has :) [09:44] ogra_: aha, I didn't know that [09:45] ara: hey, certification question, do we (as canonical) give any guarantee what it means to run "ubuntu" wrt updates? are you expected to have updates disabled when you install ubuntu? [09:46] zyga, not sure I understand the question [09:46] ara: the case is that scaleway offers xenial images but the sources.list file only lists xenial-security and custom scaleway repo [09:46] ara: you boot an ubuntu xenial instance from some cloud provider [09:46] zyga, by default they are always on ... but you can indeed preseed installs [09:46] ara: is it still ubuntu if they disabled updates by default? [09:47] zyga, well, I think you are able to just keep xenial-security (kernel udpates go to the security pocket) [09:47] zyga, that's why those are different pockets [09:47] zyga, in case you just want security-updates but not bug fixes [09:48] zyga, so I guess the answer might be "yes, that's still 'ubuntu'" [09:48] ara: aha, I see, thanks for clarifying that [09:48] ara: do you know if we certify scaleway images? [09:49] zyga, no idea, you can ask that question to patricia, she may know [09:49] zyga, (Gaughen) [09:49] thank you! :) [09:50] gaughen: do you know if we certify scaleway xenial images? [09:50] this multiple-services-in-one-snap demo thing is proving to be a trove of fails [09:51] e.g., install it, installation fails because one of the services doesn't start, installation undoes, random services left running [09:52] Chipaca: smells like 2.25 bugfix [09:52] if i can get to the bottom of it all in time, sure [09:52] :-) [09:52] those two random branches yesterday were a part of it [09:52] (and there's more weirdness in 'snap try', but i'm leaving that for later) [09:54] Chipaca: I kind of like EnsureDir approach [09:54] Chipaca: so we "ensure" service files are in place [09:54] Chipaca: or that they are fully gone [09:54] Chipaca: problem with stranded services is also interesting but separate [09:55] Chipaca: did we forget to kill them [09:55] Chipaca: or did they just refuse to die for some reason? [09:55] the service files go away as is appropriate [09:55] the services themselves don't [09:55] if i had answers to your questions i'd be a day ahead of where i am :-) [09:56] Chipaca: :-) [10:00] Chipaca: we have a few things that have an undo, but not a undo what we did if we fail in the middle [10:00] Chipaca: you can look at doLinkSnap for something that tries to do that properly [10:01] pedronis: idea [10:01] pedronis: not sure if good but still [10:01] pedronis: let's add a "cleanup stack" to a change [10:02] pedronis: any task can register cleanup actions that only get ran if we fail [10:02] ? [10:02] pedronis: then if we fail we run the undo handlers and the cleanup list [10:02] well we have cleanup [10:02] nowadays for some stuff [10:02] pedronis: the reason is that this way each task can have fine-grained elements that get added as the task progresses [10:02] oh? [10:02] there's a cleanup task [10:02] so something like this exists? [10:02] not like this [10:02] aha [10:03] I was thinking along the lines of: [10:03] I'm mostly worried about the multiplication of concepts [10:03] (inside one task) [10:03] doA() [10:03] we have undos [10:03] if not error, cleanupOnFailure(undoA) [10:03] doB() [10:03] if not error, cleanupOnFailure(undoB) [10:03] ... [10:03] what we are not good at is dealing with the task that errored itself [10:03] aha [10:03] but there's defer and stuff for that in theory [10:03] well [10:04] I worry that some of those concepts span one task [10:04] so a chain of tasks in one change assumes some structure [10:04] well [10:04] anyway, just an idea [10:04] I'm looking forward to see what Chipaca comes up with [10:04] well if undoing one error span tasks [10:04] then those tasks are not quite right [10:05] pedronis: I think we are in this situation now still [10:05] that's a different kind of bug [10:05] not a reason to add complexity [10:06] PR snapd#3174 closed: interfaces,overlord: log interface auto-connection failures [10:06] right, I agree [10:06] thank you mvo! [10:06] * zyga considers upgrading to 17.04 to run polaris as IRC client [10:06] anyone doing that [10:06] it has nice UI and nice notification [10:07] zyga, refactored 3182 test per your commnet [10:07] Chipaca: that's that don't manipulate state too much can usually be fixed by calling their undo manually on their failure path [10:07] s/that's/tasks/ [10:07] zyga: 17.04 ftw! [10:08] mvo: are you on it? [10:09] assuming they are correctly idempotent [10:11] Chipaca: we basically need quite a few integration undo tests [10:12] mmh, not undo [10:12] error and undo to be precise [10:12] zyga: my workstation, works very well [10:12] morphis_: yes [10:14] pstolowski: thank you! [10:14] pstolowski: checking [10:17] pstolowski: commented [10:18] zyga, looking, thanks [10:23] mvo— on unity 8? :-) [10:29] Chipaca: *cough* [10:31] zyga, ok, updated [10:38] pstolowski: https://github.com/snapcore/snapd/pull/3183 :) [10:38] PR snapd#3183: interfaces/mount: add parser for mountinfo entries [10:38] pstolowski: (replied to your PR, just add a comment there and +1) [10:38] pstolowski: have a look, you reviewed -1 in this series already [10:39] PR snapd#3104 closed: tests: fix unity test [10:39] PR snapd#3183 opened: interfaces/mount: add parser for mountinfo entries [10:39] pstolowski: not sure if I should parse mount and super-block options or optional fields deeply [10:39] Chipaca: go-ness review appreciated ^^ [10:43] mvo: you have a typo in your release notes [10:43] I think you mean "joystick" instead of "joystrick" [10:43] Son_Goku: autsch, thank you! I will fix it [10:44] mvo: The 2.24 packages should synchronize out to updates-testing in Fedora in a few hours, so you can probably simultaneously mention Fedora and Ubuntu in the 2.24 release announcement [10:46] Son_Goku: awesome! you rock! [10:46] Son_Goku: awesome work! :) [10:47] * zyga might consider switching to Fedora 25 for daily work [10:47] mvo: I don't know if you make the release announcement usually before or after it is approved to go into ubuntu updates, so if you usually do it after, then I think we should probably push for people to test the Fedora package updates first [10:47] zyga: :D [10:47] Fedora master race :D [10:48] Son_Goku: I draft the release annoucement (its in the forum) and JamieBen_ is now handling the announcing, but usually we announce when its in -proposed === JamieBen_ is now known as JamieBennett [10:49] speak of the devil :P [10:49] :) [10:50] but yeah, I submitted the updates to be released to updates-testing yesterday [10:50] (especially if someone asks me to work on selinux) [10:50] I need to spend some time at the forum today [10:50] so they should go out in a couple hours or so [10:50] people are also now asking about being able to craft Fedora-based snaps too [10:54] Son_Goku: this is a compound question, we can craft a snap that uses fedora bits on top of the current ubuntu-based core snap or a fully fedora based "base" snap that we don't support yet [10:54] yeah, I know [10:54] Son_Goku: I think we should get base snaps first [10:54] Hello. I am building gadget snap myself. One of the things I modify is few options of config.txt (gpu_mem and couple of other options). But when I run the resulting image all my options are commented out in config.txt. What does that and how do I prevent that behavior? [10:54] Son_Goku: btw. you want to push 2.24 to stable already now? [10:55] zyga: well we can't do either right now, because snapcraft needs work [10:55] Son_Goku: then we will be able to do what people are really asking for: snapd not tied to ubuntu "base" [10:55] zyga: yes [10:55] Son_Goku: note that snapcraft is not the only way to make snaps [10:55] I know, but it's what we're pushing [10:55] Son_Goku: I think initially it is fine to just hand-craft snaps :) [10:55] (I love that hame) [10:55] name* [10:55] Son_Goku: one thing I talked with zyga about earlier today was that we wait for the official release date as everyone is having it just as candidate right now [10:55] Son_Goku: I think snapcraft can only really be done when we have base snaps [10:55] yes [10:56] morphis_: what *is* the official release date? [10:56] 4/24 [10:56] April 24?! [10:56] for 2.24? [10:56] yes === morphis_ is now known as morphis [10:56] yes [10:56] wow, that's two weeks from now [10:56] Son_Goku: that's confusing [10:56] Son_Goku: that is the regular candence time period for a snapd release [10:56] the reality is this: [10:56] 2.24 is in candidate/beta channel now [10:56] through those two weeks it goes through all kinds of QA [10:56] it's not a stable release [10:57] it's a source tarball release [10:57] + invitation to test the binary [10:57] since we have channels and are actively using them [10:57] the term "release" is not the same [10:57] as we traditionally are used to [10:57] I think we need to write this down [10:57] and use clear terminology all the time [10:57] zyga: but if you take the original "release" term, the release date is April 24 and what we have today is more of a 2.24-rc1 [10:58] and attach a short summary to each announcement [10:58] wow, there was literally no point in me pushing 2.24 at all, then [10:58] Son_Goku: there is! [10:58] morphis: exactly so [10:58] Son_Goku: we need to send calls out for testing in the community [10:58] morphis: the problem is that if I'm ahead of Ubuntu, things are going to be broken [10:58] VERY broken [10:58] a bodhi request is fine but it should land until th real 2.24 is out [10:58] Ubuntu moves too slowly in almost every regard when it comes to this [10:59] but if we're going to hold back the final release, I better turn off the autopush [10:59] Son_Goku: why would they be broken? [10:59] Son_Goku: yes, please turn off autopush for this [11:00] because the core snap is always broken on classic distros when it has an older snapd than what I run [11:00] Son_Goku: are you sure/ [11:00] Son_Goku: why would it be broken? [11:00] * Son_Goku shrugs [11:00] * zyga tries to understand [11:00] Chipaca: thanks for the feedback [11:00] Chipaca: I think I'll leave the int parsing asis [11:00] it's not worth debugging because it's a spaghetti of interface things and weird errors [11:01] Chipaca: but I was wondering about OptinalFlds [11:01] Chipaca: and mount and super-block option [11:01] Son_Goku: I mean, what error did you see [11:01] mainly non-existent interface errors [11:01] Chipaca: should I call it OptionalFields and make it []string that I really parse? [11:01] they have no practical effect on Fedora now, since interfaces mean nothing [11:01] Son_Goku: which interface specifically? [11:01] Son_Goku: this may be an unrealted bug that I need to fix [11:01] (same happens on ubuntu now) [11:02] well, I don't remember, since this was a week ago [11:02] is it about network-bind or core-support? [11:02] zyga— ah, i might be the wrong person to talk with about names. OptionalFields is probably better than OptionalFlds though [11:02] core-support, I think [11:02] if so this is a harmless note and I do need to correct that [11:02] there's a branch that's pending merge and it will be in 2.25 [11:02] zyga— about whether to leave it as an array, depends what you use it for [11:02] though it might have also been network stuff *shrugs* [11:02] in any case, it has no appreciable affect in Fedora [11:02] Son_Goku: both are expected [11:02] since confinement is broken [11:02] Son_Goku: it's not really related to confinement this time :) [11:03] Son_Goku: it is the thing where we renamed plugs and there's no nice method to forget old connection [11:03]