| mwhudson | yay spammers found the forum | 01:20 |
|---|---|---|
| Pharaoh_Atem | murr | 01:32 |
| mup | PR snapd#3413 opened: tests: fix for econnreset test checking that the download already started <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3413> | 05:09 |
| luk3yx | I'm having an issue with building a snap. | 05:46 |
| luk3yx | snapcraft doesn't copy the '.desktop' files across with the 'dump' plugin like it used to. | 05:46 |
| === chihchun_afk is now known as chihchun | ||
| zyga | morphis_: hey | 06:43 |
| zyga | morphis_: just running tumbleweed here, I noticed that none of the desktop launchers work | 06:43 |
| morphis_ | zyga: which desktop launchers do you mean? | 06:43 |
| morphis_ | the ones you get in the gnome shell dash? | 06:43 |
| zyga | morphis_: any made by snaps | 06:43 |
| zyga | morphis_: yes | 06:43 |
| morphis_ | hm, I tried this with krita and I could start | 06:44 |
| zyga | morphis_: we just set PATH | 06:44 |
| zyga | morphis_: in which DE and suse release? | 06:44 |
| zyga | anyway, running gnome tumbleweed, it doesn't work | 06:44 |
| zyga | looking at why now | 06:44 |
| morphis_ | I hope this didn't broke recently, let me check | 06:45 |
| zyga | I don't see the extra variable that points to /var/lib/snapd/desktop | 06:45 |
| morphis_ | ah! | 06:46 |
| morphis_ | could have been that I fixed that locally but never pushed the fix | 06:46 |
| morphis_ | actually this works pretty well on Fedora | 06:46 |
| morphis_ | zyga: I wonder if the profile.d handling is different or has changed | 06:47 |
| zyga | morphis_: what do you have in /etc/profile.d? | 06:47 |
| zyga | I have snapd.sh that has one line (except comments): PATH=$PATH:/snap/bin | 06:48 |
| morphis_ | powering up my suse VM, on Fedora I have what should be there | 06:48 |
| zyga | the 65snappy Xsession thing is not around | 06:48 |
| luk3yx | Why doesn't snapcraft put .desktop files in correctly? | 06:48 |
| zyga | luk3yx: no idea, sorry | 06:49 |
| luk3yx | Okay. | 06:49 |
| morphis_ | zyga: the interesting thing is that the same file on Fedora has the proper XDG_DATA_DIRS vars set | 06:51 |
| zyga | morphis_: separate file | 06:51 |
| morphis_ | nope | 06:51 |
| zyga | morphis_: I think we don't have one thing across the trees | 06:51 |
| morphis_ | /etc/profile.d/snapd.sh sets XDG_DATA_DIRS on Fedora | 06:51 |
| zyga | morphis_: look at etc/X11 in the source tree | 06:51 |
| zyga | right | 06:51 |
| zyga | because that's not the same file | 06:52 |
| morphis_ | on Suse it doesn't | 06:52 |
| zyga | in the source tree we have two files | 06:52 |
| zyga | and in Fedora we use entirely different one (because /snap I suspect) | 06:52 |
| morphis_ | http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n421 | 06:52 |
| zyga | morphis_: exactly | 06:52 |
| zyga | morphis_: and on ubuntu/debian/suse we take etc from the source package | 06:52 |
| zyga | see? | 06:52 |
| morphis_ | that is nasty, we should't differentiate what is in these files across distros | 06:53 |
| zyga | I think it is also somewhat incorrect, that's why we did it this way | 06:53 |
| zyga | someone reported a bug on XDG_DATA_DIRS, let me try to find it | 06:53 |
| morphis_ | /etc/x11/XSession.d isn't support on Suse as it seems | 06:54 |
| zyga | I can only find https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1554563 | 06:54 |
| mup | Bug #1554563: Please support /var/lib/snappy/desktop as an additional desktop directory <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1554563> | 06:54 |
| zyga | yeah, I see | 06:54 |
| morphis_ | ah it's /etc/X11/xinit/xinitrc.d/ instead | 06:55 |
| zyga | heh | 06:55 |
| zyga | shall I prepare a patch? | 06:55 |
| morphis_ | I am on it already | 06:56 |
| zyga | this is what I made | 06:57 |
| zyga | https://paste.opensuse.org/30238446 | 06:58 |
| abeato | zyga, hey, mind taking a look when possible at https://github.com/snapcore/snapd/pull/3353 ? | 06:59 |
| mup | PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353> | 06:59 |
| zyga | abeato: yes, certainly | 06:59 |
| zyga | well | 06:59 |
| zyga | not mind :) | 06:59 |
| morphis_ | zyga: yeah, same here | 06:59 |
| abeato | :) | 06:59 |
| zyga | abeato: can you please ensure that every if / else uses braces fully | 07:00 |
| abeato | zyga, also one-liners? | 07:01 |
| zyga | yes | 07:01 |
| abeato | ok | 07:01 |
| zyga | thank you, sorry for the nitpick but this is the coding style we're using everywhere else | 07:04 |
| abeato | zyga, done | 07:07 |
| morphis_ | zyga: btw. there will be a blog post later this week telling about working lxd/docker on Suse/Fedora | 07:07 |
| abeato | zyga, sure, I had not noticed | 07:07 |
| zyga | abeato: thank you, looking | 07:07 |
| zyga | morphis_: nice, thank you :) | 07:08 |
| zyga | abeato: looks nice, I'll comment in a sec | 07:09 |
| abeato | zyga, great | 07:09 |
| morphis_ | zyga: btw. what do you think about doing an Ubuntu Testing day for snaps on Fedora/Suse? | 07:19 |
| zyga | morphis_: I think this is a good idea | 07:23 |
| zyga | morphis_: we could do a converged one for a few distributions | 07:23 |
| morphis_ | then let me organize that | 07:23 |
| morphis_ | yes! | 07:23 |
| zyga | morphis_: but only those under CI today | 07:23 |
| zyga | we can split responsibilities | 07:23 |
| zyga | I can show suse (natively) and fedora (natively) | 07:23 |
| morphis_ | what means natively? | 07:24 |
| morphis_ | in a non-vm environment? | 07:24 |
| zyga | running on metal | 07:24 |
| zyga | yes | 07:24 |
| zyga | I shun VMs recently | 07:24 |
| zyga | because we're mot using them daily for real stuff | 07:24 |
| zyga | just for fire&forget | 07:24 |
| zyga | (e.g. the desktop issue) | 07:25 |
| zyga | mvo: hey | 07:27 |
| zyga | mvo: did you see PR 3410 | 07:28 |
| mup | PR snapcraft#1320 closed: store: send X-Ubuntu-Series, not X-Ubuntu-Release <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1320> | 07:33 |
| mup | PR snapcraft#1336 closed: HACKING: make running from virtualenv more obvious <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1336> | 07:36 |
| mvo | zyga: yeah, I noticed it, need to look in detail, was a bit distracted with the other things going on | 07:37 |
| mup | PR snapcraft#1300 closed: tools: add a script to install autopkgtest dependencies <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1300> | 07:39 |
| zyga | morphis_: hmm,not sure what happened | 07:48 |
| morphis_ | yeah, not sure too | 07:48 |
| zyga | oh man | 07:49 |
| zyga | morphis_: can you hear me? | 08:00 |
| zyga | morphis_: seems like google hangouts armageddon | 08:00 |
| * zyga does code reviews | 08:05 | |
| zyga | mvo: please pull me out of this if you need my help with release blockers | 08:05 |
| NicolinoCuralli | hi all: i need to delete a snap in brand store : who can help me? | 08:09 |
| kyrofa | Hey zyga, did you solve the snap-confine in lxc issue? | 08:34 |
| zyga | kyrofa: nope, I didn't have time to explore that yet | 08:34 |
| kyrofa | zyga, huh... you may not need to. I just updated a few different containers to 2.25 now (snap-confine also updated) and things seem to be working | 08:36 |
| zyga | oh, that's good news :) | 08:36 |
| morphis_ | zyga: https://build.opensuse.org/request/show/500035 | 08:37 |
| zyga | sorry for being passive about that, I think it will only be fixed once I actively try LXD and we have CI | 08:37 |
| zyga | morphis_: approved, thank you | 08:37 |
| kyrofa | zyga, yeah we really need lxd in CI | 08:39 |
| morphis_ | zyga: had to use /etc/profile.d in the end but it works now | 08:40 |
| zyga | morphis_: what happend when you tried xinitrd.d? | 08:41 |
| zyga | morphis_: just wasn't picked up? | 08:41 |
| zyga | or didn't export the environment back to other processes? | 08:41 |
| morphis_ | zyga: yes | 08:41 |
| morphis_ | it wasn't loaded for the DE nor for any shell | 08:42 |
| morphis_ | so not picked up at all | 08:42 |
| NicolinoCuralli | hi all: i have some difficulties with review process in the brand store : can someone help me ? I don't find on the store the place where paste the Snap declarations | 08:44 |
| === cydizen_ is now known as cydizen | ||
| abeato | ogra_, hey, I had to do a small correction in https://github.com/snapcore/core-build/pull/13 | 09:02 |
| mup | PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13> | 09:02 |
| abeato | (see last commit) | 09:02 |
| ogra_ | abeato, approved ... how could i miss that! | 09:03 |
| abeato | :) | 09:04 |
| abeato | ogra_, do we need some other approval or is it ready to be merged? | 09:04 |
| ogra_ | abeato, you need two people to approve | 09:04 |
| NicolinoCuralli | hi guys : someone can help me to find the person tha can help me to solve my problem? | 09:04 |
| abeato | ogra_, ok, who do I need to annoy? ;) | 09:04 |
| ogra_ | abeato, dunno ... someone from the snapd core team | 09:05 |
| abeato | ogra_, maybe mvo? https://github.com/snapcore/core-build/pull/13 ? :) | 09:05 |
| mup | PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13> | 09:05 |
| === cpaelzer_ is now known as cpaelzer | ||
| mvo | abeato: sure, I have a look | 09:07 |
| abeato | mvo, thanks! | 09:07 |
| mvo | zyga: re release> after a bit of thinking I will just revert the syntax change and the new symbols and go ahead with only that, then we are not under pressure for the profile-digest changes | 09:08 |
| zyga | OK | 09:09 |
| mvo | zyga: I also played a bit more with seccomp->bpf and ran into a strange apparmor/seccomp interation. when I load the bpf directly and run e.g. hello I get an EPERM when execve(snap-exec). however when I unload the apparmor profile of snpa-confine this is gone, syslog has something that looks like an oops from paparmor | 09:10 |
| zyga | log? | 09:10 |
| zyga | mvo: did you change the moment when you load the profile in snap-confine? | 09:11 |
| zyga | note that seccomp applies instantly | 09:11 |
| mvo | zyga: sure, here is the log http://paste.ubuntu.com/24724666/ | 09:11 |
| zyga | mvo: which kernel was this on? | 09:12 |
| mvo | zyga: and the full branch (slightly long and unfinished) https://github.com/snapcore/snapd/compare/master...mvo5:seccomp-bpf?expand=1 - the key is sc_apply_seccomp_bpf(security_tag); | 09:12 |
| mvo | zyga: 4.4.0-78 | 09:12 |
| zyga | hmm | 09:12 |
| mvo | zyga: do you think I should try a different one? | 09:12 |
| zyga | no, the kernel looks fine | 09:13 |
| mvo | zyga: the profile is loaded at the same point as the old sc_load_seccomp_context(seccomp_ctx); | 09:13 |
| mvo | zyga: whats puzzling is that its apparmor, the execve from seccomp would get killed (SIGSYS) but I get a EPERM | 09:13 |
| mvo | zyga: I guess I wait for jamie to see if he has some ideas | 09:15 |
| zyga | mvo: just curious, the sc_prepare_seccomp_context no longer does anything, right? | 09:16 |
| zyga | mvo: note that the code is structured in a specific way | 09:16 |
| mvo | zyga: I still made it prepare everything so that I can dump the content and compare the diff between the new and the old code | 09:16 |
| zyga | mvo: so when you load the profile you can still, afair, do more things, when we apply it it is too late to some things | 09:16 |
| mvo | zyga: oh, interessting | 09:16 |
| zyga | this is why those were split | 09:16 |
| zyga | not sure if this would explain the WARN you saw | 09:17 |
| zyga | jjohansen: ^^ you want to look at http://paste.ubuntu.com/24724666/ | 09:17 |
| mvo | zyga: interessting idea, I can play a bit and see if moving things around makes a difference | 09:18 |
| zyga | mvo: honestly, I'd love to hack on this | 09:18 |
| === dgadomski_ is now known as dgadomski | ||
| mvo | zyga: I will first try a newer kernel just to see if it makes a difference | 09:18 |
| zyga | mvo: but if you want to do it then feel free :) | 09:18 |
| mvo | zyga: go ahead | 09:18 |
| zyga | mvo: I need to review PRs and apply feedback first | 09:18 |
| mvo | zyga: the branch is https://github.com/snapcore/snapd/compare/master...mvo5:seccomp-bpf?expand=1 | 09:18 |
| zyga | mvo: but I can do some more hacking in the evening | 09:18 |
| zyga | did you see the hotfix PR by any chance? | 09:19 |
| mvo | zyga: yeah, its a fun and fascinating project. I need to also go and do the boring stuff now (cherry pick, release) | 09:19 |
| mvo | zyga: yeah, its a good idea - did you already describe in the forum how the poor souls on r1968 can get out of it? | 09:21 |
| zyga | mvo: no not yet, I wanted to get your feedback first | 09:24 |
| zyga | mvo: one thing I was thinking of is make periodic releases of the hotfix tool (only for developers using edge) | 09:25 |
| zyga | mvo: and to patch it a little more to be double-click-foolproof, just run it and it applies all hotfixes | 09:25 |
| Chipaca | pedronis`: snapd#3400 is ready for your perusal if you have a bit | 09:26 |
| mup | PR snapd#3400: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400> | 09:26 |
| mup | PR snapd#3414 opened: tests: show available entropy on error <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3414> | 09:29 |
| Chipaca | NicolinoCuralli: what is your problem? | 09:29 |
| NicolinoCuralli | chicapa: I need to upload the snap declaration for a snap under review on my brand store | 09:34 |
| zyga | morphis_: two more issues on suse | 09:36 |
| zyga | Failed to try-restart snapd.autoimport.service: Unit snapd.autoimport.service not found. | 09:36 |
| zyga | Failed to try-restart snapd.system-shutdown.service: Unit snapd.system-shutdown.service not found. | 09:36 |
| zyga | and earlier | 09:36 |
| zyga | Failed to preset unit: File snapd.autoimport.service: No such file or directory | 09:36 |
| zyga | Failed to preset unit: File snapd.system-shutdown.service: No such file or directory | 09:36 |
| morphis_ | zyga: we don't install these service units anymore | 09:37 |
| morphis_ | so what is starting it? | 09:37 |
| zyga | yes but something presets them | 09:37 |
| zyga | they are in systemd_services_list | 09:37 |
| morphis_ | ah I see | 09:37 |
| zyga | in the spec file | 09:37 |
| zyga | we should drop the two | 09:37 |
| zyga | I can do that if you want, I already have it open | 09:37 |
| zyga | building locally to test | 09:39 |
| morphis_ | zyga: please! | 09:42 |
| zyga | we need snap install pastebinit :) | 09:42 |
| zyga | there's no pastebinit on tumbleweed | 09:42 |
| zyga | oh, but there is susepaste and susepaste-screenshot | 09:43 |
| zyga | I'm especially intrerested in the screenshot paste :) | 09:43 |
| zyga | http://paste.opensuse.org/71458123 | 09:44 |
| zyga | morphis_: ^ looks ok? | 09:44 |
| morphis_ | yes | 09:44 |
| === pedronis` is now known as pedronis | ||
| pedronis | Chipaca: when I have processed the fact that all the spread runs I start fail for some random reason | 09:51 |
| Chipaca | pedronis: spread's just envious of your awesomeness | 09:53 |
| * zyga is drunk today, sorry for silly comment on 3400 | 09:55 | |
| === alan_g is now known as alan_g|errand | ||
| * Chipaca hugs zyga | 09:57 | |
| mvo | zyga: btw, do you know more about "cannot create lock directory /run/snapd/lock: Permission denied" yet? we see this a lot in the error tracker | 09:57 |
| Chipaca | zyga: i'm assuming you're not _actually_ drunk | 09:57 |
| zyga | no, not actually | 09:57 |
| zyga | mvo: no, still no idea what is going on there | 09:58 |
| zyga | mvo: how can I get error tracker data? | 09:58 |
| mvo | zyga: errors.ubuntu.com has a lot of it, .e.g https://errors.ubuntu.com/problem/19272ebc18709d4407dba0438a536d56bb143069 | 10:00 |
| mvo | zyga: there might be a form to fill in to get access (if you have not done so already) to the details | 10:00 |
| * zyga looks at http://susepaste.org/10525636 and sighs :/ | 10:01 | |
| zyga | looking | 10:01 |
| mvo | zyga: this one has 5k occurances last week | 10:01 |
| zyga | mvo: how did you find this, I mean, how to "get started"? | 10:01 |
| mvo | zyga: start from https://errors.ubuntu.com/ - it takes a bit to load the data, then in the top-5 you will see some "snap install" related ones | 10:02 |
| zyga | aha, let me try that | 10:02 |
| mvo | zyga: the top one is the one I just linked to | 10:02 |
| zyga | classic confinement, hmm | 10:03 |
| zyga | still, should not impact anything | 10:03 |
| mup | PR snapd#3397 closed: interfaces: disable "mknod |N" in the default seccomp template again <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3397> | 10:04 |
| zyga | mvo: question about this report, looking at https://errors.ubuntu.com/oops/2af7141c-45e8-11e7-9188-fa163e839e11 I see snapd version 2.25, is that the real version of the snapd being executed or the one installed via classic package? | 10:07 |
| mvo | zyga: that is the one running, the host and core versions are available via the build-id | 10:08 |
| joc | morphis_: would appreciate if you could look at getting that udisksctl auto alias setup soonish, we have test runs that would like it available | 10:08 |
| mup | PR snapd#3415 opened: interfaces: revert "interfaces: re-add reverted ioctl and quotactl <Created by mvo5> <https://github.com/snapcore/snapd/pull/3415> | 10:11 |
| pedronis | Chipaca: added some comments | 10:13 |
| * Chipaca reads | 10:14 | |
| zyga | morphis_: so, the overlordSuite.TestEnsureLoopPrune test never passes for me | 10:15 |
| zyga | morphis_: hmm, wonder if this related to multi-core build host vs single-core VM | 10:15 |
| zyga | morphis_: I'll commit and let OBS do the build | 10:16 |
| mvo | a review for #3415 would be great. it will unblock 2.26/2.27 | 10:17 |
| zyga | approved | 10:18 |
| mvo | ta | 10:19 |
| * mvo just needs tests now | 10:19 | |
| * mvo just needs to wait for tests now | 10:19 | |
| Chipaca | pedronis: "the store offered snap revision" sounds like it returns a revno. "the store offered snap revision snap info" sounds like chickenspeak. "the store offered snap"? | 10:20 |
| Chipaca | currently best phrasing i have is “// LookupRefresh returns a snap's store-offered revision information given its refresh candidate.” | 10:22 |
| pedronis | mvo: test are super flaky, I had zero happy runs since yesterday, maybe is just me though | 10:24 |
| mvo | pedronis: autsch, that does not sound encouraging | 10:25 |
| mvo | pedronis: thank you, I will know in some minutes | 10:25 |
| mup | PR snapd#3373 closed: snapstate: consider connect/disconnect tasks in CheckChangeConflict <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3373> | 10:26 |
| pedronis | I had one now after tentative N+ | 10:26 |
| pedronis | Chipaca: sounds ok | 10:27 |
| pedronis | (all things considered) | 10:27 |
| pedronis | mvo: could you push master into snapd#3385 again, that's other one I'm trying to see pass, maybe pushing master helps | 10:29 |
| mup | PR snapd#3385: cmd: add stub new snap-repair command and add timer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3385> | 10:29 |
| morphis_ | zyga: in OBS? | 10:33 |
| morphis_ | zyga: didn't checked that yet but I have just a single core on my vm too, works well here | 10:33 |
| pedronis | Chipaca: thx, did you see my question about the error? also I pmed you | 10:34 |
| Chipaca | i didn't see your question about the error | 10:35 |
| Chipaca | pedronis: where was that question? | 10:35 |
| morphis_ | Pharaoh_Atem: ping | 10:41 |
| pedronis | Chipaca: it was a comment attached to some other comments to some code that was changed | 10:44 |
| mvo | pedronis: sure, pushed 3385 | 10:44 |
| Chipaca | pedronis: about the snap name and real name not aligning? | 10:44 |
| Chipaca | local vs real i mean | 10:45 |
| pedronis | yes | 10:45 |
| Chipaca | pedronis: i replied to that, i think? | 10:45 |
| Chipaca | pedronis: basically, yes it's used and shown to the user | 10:46 |
| Chipaca | pedronis: (but that's not something this branch introduces?) | 10:46 |
| pedronis | don't we have the local name around when we show it though? | 10:46 |
| pedronis | Chipaca: yes, but moving around where it error is created changes which name we use | 10:46 |
| pedronis | that's why I'm bothering you :) | 10:47 |
| pedronis | you need to look at the diff I suppose | 10:47 |
| pedronis | I mean master vs your branch | 10:47 |
| pedronis | mvo: thanks, let's how it goes | 10:48 |
| * pedronis -> lunch | 10:48 | |
| Chipaca | so yes i move it from snapstate, using curInfo.Name() (which for from-the-store snaps is the RealName, ie the store name) to store using latest[0].Name, so the only case where they'd differ is if a snapid gets renamed | 10:52 |
| pstolowski | zyga, hey. it seems that we always use /usr/bin/snapctl from the core snap no matter what. am I right / is it expected? | 10:53 |
| === ogra_ is now known as ogra | ||
| === ogra is now known as ogra_ | ||
| === alan_g|errand is now known as alan_g | ||
| zyga | re | 11:12 |
| zyga | morphis_: yes, I think it just fails on multi-core systems | 11:12 |
| zyga | pstolowski: snapctl is always used (except classic) after we pivot_root so yes | 11:13 |
| morphis_ | zyga: ah you think it fails on multi-core thought somehow you mean the other way round | 11:13 |
| pstolowski | zyga, thanks.. ok, this explains my issues with renaming of SNAP_CONTEXT | 11:13 |
| zyga | morphis_: and it failed in OBS now | 11:14 |
| zyga | https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/x86_64 | 11:14 |
| zyga | pstolowski: ha, interesting | 11:14 |
| zyga | pstolowski: just bind-mount it into core snap | 11:14 |
| zyga | pstolowski: although we repack the core snap so not sure why you are seeing this | 11:15 |
| morphis_ | zyga: wait, you pushed to the system repository without testing? | 11:15 |
| zyga | morphis_: I tested it but it took many builds to pass | 11:15 |
| zyga | morphis_: since this is a trivial patch on top of existing working build I didn't expect it could be any worse | 11:16 |
| morphis_ | actually we should always go via an review request, that way we can verify it builds on all archs + systems | 11:16 |
| zyga | morphis_: well, it is randomly failing because that test is racy | 11:16 |
| Chipaca | pedronis: WRT the error, can I address it in a followup branch? doing it properly touches cmd/snap more than i'd like to in this one | 11:16 |
| zyga | morphis_: and the failure has nothing to do with the change at hand | 11:17 |
| zyga | morphis_: maybe we just get better build VMs now :/ | 11:17 |
| zyga | morphis_: I re-triggered the build | 11:18 |
| morphis_ | I see, was just looking at the log file | 11:18 |
| zyga | morphis_: it's the same failure I mentioned before and the one we fixed in master some time ago | 11:19 |
| zyga | morphis_: but apparently the fix was wrong as it also fails in travis very often | 11:19 |
| pstolowski | zyga, hmm indeed I see this is done in prepare.sh. ok let me verify if this is working | 11:20 |
| zyga | pstolowski: maybe we just don't copy snapctl | 11:20 |
| pstolowski | zyga, we do | 11:22 |
| zyga | so there must be something else at play | 11:22 |
| zyga | morphis_: it worked on retry | 11:24 |
| pstolowski | zyga, ok. confirmed. whatever we think we do in prepare.sh is not working for snapctl when I run spread test with qemu ;) | 11:27 |
| pstolowski | qemu:ubuntu-16.04-64 /root# md5sum /usr/bin/snapctl /snap/core/current/usr/bin/snapctl | 11:27 |
| pstolowski | 67d600f14953d72a8440e0d90a93abc4 /usr/bin/snapctl | 11:27 |
| pstolowski | 5ac1e109e0dd434d5141b9ad52b20f3f /snap/core/current/usr/bin/snapctl | 11:27 |
| zyga | pstolowski: let me look | 11:27 |
| morphis_ | zyga: good | 11:27 |
| zyga | pstolowski: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L46 | 11:28 |
| pedronis | Chipaca: it's ok | 11:28 |
| zyga | pstolowski: and also https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L74 | 11:29 |
| zyga | pstolowski: this gets called from https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L94 | 11:29 |
| zyga | pstolowski: hmm hmm hmm, no idea | 11:29 |
| zyga | pstolowski: how are you running your test exactly? | 11:29 |
| pstolowski | zyga, uh oh the tests I'm using do not call prepare.sh | 11:30 |
| zyga | pstolowski: oh? why? where are your tests? | 11:31 |
| zyga | pstolowski: this is typically done at suite level | 11:31 |
| pstolowski | zyga, well, existing one - e.g. main/snap-set | 11:31 |
| pstolowski | zyga, at least no explicit call to prepare.sh | 11:31 |
| zyga | pstolowski: https://github.com/snapcore/snapd/ | 11:32 |
| zyga | pstolowski: they do, or your spread is old/weird/broken | 11:32 |
| morphis_ | zyga: but what change we submit we should always go through a review request for suse | 11:32 |
| morphis_ | otherwise we may break existing installations | 11:32 |
| zyga | morphis_: sure, I didn't do it because I didn't have a branch and I showed you the diff to ack | 11:33 |
| morphis_ | yeah | 11:33 |
| pstolowski | zyga, ah, it's called from spread.yaml, that's ok then. i got confused by one of the other tests (extra-snap-assertions) which calls prepare.sh directly | 11:34 |
| zyga | brb | 11:40 |
| pstolowski | zyga, anyway... I run a single test like this: spread -debug qemu:ubuntu-16.04-64:tests/main/snap-set and clearly the snapctl in the core is different from the one from /usr/bin | 11:41 |
| zyga | morphis_: so.... | 11:42 |
| zyga | morphis_: on re-logout neither snapd.sh nor snapd-xdg.sh do stuff | 11:43 |
| zyga | morphis_: /snap/bin is not in path | 11:43 |
| morphis_ | you have reboot | 11:43 |
| zyga | ah, the X session holds this too? | 11:43 |
| zyga | ok | 11:43 |
| * zyga reboots then :) | 11:43 | |
| pstolowski | zyga, anyway... I run a single test like this: spread -debug qemu:ubuntu-16.04-64:tests/main/snap-set and clearly the snapctl in the core is different from the one from /usr/bin | 11:44 |
| zyga | morphis_: indeed, now it works perfectly! | 11:45 |
| morphis_ | not sure how suse configures this but XDG_DATA_DIRS was filled with /var/lib/snapd/desktop and PATH with /snap/bin | 11:46 |
| zyga | morphis_: the snapd-xdg.sh file is +x while all the other files there are not | 11:46 |
| morphis_ | hm | 11:46 |
| morphis_ | should be 644, I agree | 11:46 |
| zyga | morphis_: but it doesn't hurt | 11:46 |
| zyga | morphis_: I think snapd on suse is really good now | 11:46 |
| morphis_ | yeah, will fix that later when I can power up my suse vm again | 11:46 |
| morphis_ | zyga: one thing is missing | 11:46 |
| zyga | yeah? | 11:46 |
| zyga | xdg-open | 11:46 |
| morphis_ | cleanup of /var/lib/snapd on removal | 11:46 |
| zyga | ah, interesting | 11:47 |
| zyga | yep, we should use the management script and just make it better | 11:47 |
| morphis_ | naah, xdg-open is missing everywhere but Ubuntu :-) | 11:47 |
| zyga | and use it on all the distributions | 11:47 |
| morphis_ | zyga: yes | 11:47 |
| * zyga installs docker | 11:47 | |
| morphis_ | was ping'ing Pharaoh_Atem this morning as he wanted to generalize it but if he doesn't has time I can do that | 11:47 |
| zyga | morphis_: sounds good | 11:48 |
| Son_Goku | morphis_: moo? | 11:53 |
| morphis_ | Son_Goku: hey! | 11:54 |
| morphis_ | Son_Goku: just talked with zyga about snap-mgmt.sh, do you want to generalize it or should I? | 11:54 |
| Son_Goku | I want it perfectly working first :) | 11:54 |
| morphis_ | Son_Goku: one thing missing before we reach that goal :-) | 11:55 |
| Son_Goku | I'm still fine-tuning the script | 11:55 |
| Son_Goku | I'm nearly there, and then we can work generalizing | 11:55 |
| Son_Goku | err, work on generalizing it | 11:55 |
| morphis_ | Son_Goku: good | 11:55 |
| Son_Goku | I expect that we can start generalizing next week | 11:56 |
| Son_Goku | as I'll take care of the last wibbles in the script and packaging this weekend | 11:56 |
| Son_Goku | at the latest :D | 11:56 |
| morphis_ | nice! | 11:57 |
| zyga | morphis_: docker works but adduser/addgroup vs useradd groupadd is an issue, we should fix this eventually | 12:06 |
| morphis_ | zyga: who calls these? | 12:06 |
| zyga | morphis_: the user is instructed to | 12:06 |
| morphis_ | for the docker snap? | 12:07 |
| morphis_ | you can but you also can simply run the docker command via sudo | 12:07 |
| Son_Goku | the modern debian addfoo commands have never been ported outside of the distribution | 12:08 |
| Son_Goku | interestingly, I think debian is the upstream for shadow-utils | 12:09 |
| zyga | anyway, it will go away once snapd does user management | 12:13 |
| Son_Goku | you scare me with phrases like that | 12:13 |
| Son_Goku | "user management"? | 12:13 |
| Son_Goku | snapd will replace shadow-utils too? | 12:13 |
| zyga | no, it will just create service accounts like the one for docker | 12:13 |
| zyga | better than asking users to follow instructions :) | 12:13 |
| Son_Goku | oh, so there'll be a snappy user for this | 12:13 |
| zyga | Son_Goku: yes, most likely a specific one | 12:14 |
| zyga | there's a writeup about this ... | 12:14 |
| Son_Goku | we'll probably want the uid + gid reserved in Fedora | 12:14 |
| zyga | https://forum.snapcraft.io/t/snappy-and-users-and-groups/331 | 12:14 |
| Son_Goku | that way it's sane across the board | 12:14 |
| zyga | but brace yourself | 12:14 |
| zyga | that's a long read | 12:14 |
| Son_Goku | holy crap | 12:15 |
| Son_Goku | I'll need to bookmark this | 12:15 |
| Son_Goku | jdstrand, damn, you wrote a lot... | 12:15 |
| Saviq | kalikiana, https://code.launchpad.net/~saviq/snapcraft/+git/snapcraft/+merge/324856 | 12:18 |
| zyga | mvo: is did you see the lock directory issue on any of your machines? | 12:19 |
| morphis_ | zyga: btw. if you didn't saw it yet: https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory#How_to_add_a_new_package_to_Factory | 12:25 |
| zyga | morphis_: if system:snappy counts as a devel project then we're very close | 12:27 |
| morphis_ | zyga: right | 12:27 |
| morphis_ | zyga: I think for factory inclusion we should better have the snap-mgmt.sh script included | 12:39 |
| morphis_ | otherwise package removal is pretty dirty | 12:39 |
| morphis_ | so let me add that this evening | 12:39 |
| zyga | morphis_: yes, I agree | 12:42 |
| zyga | morphis_: sounds good | 12:42 |
| zyga | hmm | 12:42 |
| zyga | github died | 12:43 |
| zyga | "major service outage" | 12:43 |
| zyga | well | 12:43 |
| morphis_ | yeah | 12:43 |
| Son_Goku | zyga: you need to request it to be added as a devel project | 12:46 |
| Son_Goku | it must be specially marked for Factory | 12:46 |
| Son_Goku | otherwise the bot will reject the SRs | 12:47 |
| Son_Goku | talk to DimStar in #opensuse-factory about figuring out the process to that | 12:47 |
| Son_Goku | though really, now that snapd is only one package, you can move it into system:packagemanager and avoid the mess entirely | 12:48 |
| Son_Goku | err, one source package | 12:48 |
| zyga | Son_Goku: what is system:packagemanager? some blessed devel repo? | 12:50 |
| Son_Goku | yes | 12:50 |
| zyga | Son_Goku: I think we could just get system:snapd tagged this way | 12:50 |
| zyga | how can we check if it is tagged or not? | 12:50 |
| Son_Goku | well, system:snappy | 12:50 |
| zyga | (right) | 12:50 |
| Son_Goku | there's a whitelist somewhere, lemme check | 12:50 |
| zyga | Son_Goku: thanks, how do you know those things? :) | 12:53 |
| Chipaca | spread from travis is really having a bad day today :-( | 12:53 |
| zyga | Chipaca: github is down | 12:53 |
| Chipaca | this might explain things | 12:54 |
| Son_Goku | zyga, with the extremely notable exception of Debian and Ubuntu, I'm involved in all major Linux distributions | 12:54 |
| Chipaca | quick, move everything back to launchpad while nobody is looking | 12:54 |
| * Son_Goku stabs Chipaca with a fork | 12:54 | |
| kyrofa | Gaaaaah giiiithuuuub | 12:54 |
| * Son_Goku runs and whistles | 12:54 | |
| Son_Goku | kyrofa: this is why you have a replica project on GitLab :) | 12:54 |
| zyga | aaaand its back | 12:54 |
| Son_Goku | fwiw, it was never down for me | 12:55 |
| Son_Goku | apparently, only down in the European side | 12:55 |
| zyga | Son_Goku: look at status.github.com | 12:55 |
| kyrofa | Liar. It works every other refresh. Some presentation nodes | 12:55 |
| zyga | well they sure lost their 5-9s | 12:56 |
| kyrofa | Five? Hahaha | 12:56 |
| zyga | soon they will have 9-5s | 12:57 |
| kyrofa | Their API is 95% | 12:57 |
| Chipaca | they totally have 9 9s | 12:57 |
| zyga | yeah, I'm watching the same page | 12:57 |
| Chipaca | 0.999999999 | 12:57 |
| zyga | LOL | 12:57 |
| cjwatson | I once briefly worked on software that required six nines | 12:57 |
| cjwatson | That was interesting | 12:57 |
| zyga | cjwatson: was it changed (the software)? | 12:58 |
| cjwatson | Very carefully :-) | 12:58 |
| cjwatson | telco stuff | 12:58 |
| Chipaca | I love that we can build stuff to that spec | 12:58 |
| zyga | I wonder how that must work and be like | 12:58 |
| cjwatson | hot failover EVERYWHERE | 12:58 |
| Chipaca | I hate what we apparently have to do to get there | 12:58 |
| zyga | how doyou learn by making mistakes? | 12:58 |
| zyga | aha | 12:59 |
| zyga | so you can still | 12:59 |
| zyga | interesting | 12:59 |
| Chipaca | zyga: you do that part on somebody *else's* telco | 12:59 |
| cjwatson | you get 30 seconds a year of downtime so you don't have time to boot anything | 12:59 |
| cjwatson | at least not much | 12:59 |
| mvo | zyga: no, the lock directory issue I have not seen myself, just from errrors.u.c | 12:59 |
| zyga | thanks | 13:00 |
| zyga | I'm still exploring it | 13:00 |
| elopio | mpt: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1555569 | 13:01 |
| mup | Bug #1555569: [snaps] Show human-readable names for store apps <gnome-software> <sdoc> <Snappy:New> <Software Center Agent:Fix Released> <gnome-software (Ubuntu):Triaged> <https://launchpad.net/bugs/1555569> | 13:01 |
| mup | PR snapcraft#1337 opened: autotools: don't force uniqueness on configflags <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/1337> | 13:03 |
| Saviq | kalikiana, or rather ↑ | 13:03 |
| mvo | pedronis: 3385 should be ready now btw | 13:36 |
| pedronis | mvo: I saw that, will merge it in a bit | 13:49 |
| mvo | pedronis: thanks | 13:50 |
| zyga | I have an idea why the lock thing is exploding | 13:53 |
| zyga | \o/ | 13:53 |
| zyga | mvo: I think this is another race | 13:57 |
| zyga | mvo: running a scenario to confirm now | 13:57 |
| Son_Goku | zyga, there's a few fixes I need to submit to the snapd package on openSUSE | 13:58 |
| Son_Goku | so I'll prepare those tomorrow | 13:58 |
| Son_Goku | I won't have any time today | 13:58 |
| zyga | Son_Goku: sure, what kind of fixes? | 13:58 |
| Son_Goku | conditional checks for BRs and stuff | 13:58 |
| zyga | Son_Goku: no worries, we wanted to prepare to submit to factory | 13:58 |
| zyga | BRs? | 13:59 |
| Son_Goku | BuildRequires | 13:59 |
| zyga | sure, thank you | 13:59 |
| zyga | Son_Goku: but we can do that after your patches are merged | 13:59 |
| Son_Goku | yes | 13:59 |
| Son_Goku | wait what? | 14:00 |
| Son_Goku | what patches? | 14:00 |
| Son_Goku | to snap-mgmt.sh, you mean? | 14:00 |
| zyga | Son_Goku: well the fixes you just mentioned | 14:00 |
| Son_Goku | well, I think I already branched snapd from system:snappy | 14:00 |
| mup | PR snapcraft#1328 closed: qmake plugin: set default qt version <Created by tim-sueberkrueb> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1328> | 14:38 |
| === chihchun is now known as chihchun_afk | ||
| pstolowski | zyga, ok, the problem with prepare.sh is that we first install new core from edge, and that already fails on configure hook (because of changes to snapd and changes to snapctl which are not in effect yet) and makes prepare.sh fail before we have a chance to re-pack core with new binaries. so it's not actually the test failing, but prepare.sh very early on. | 14:52 |
| cachio | niemeyer, mvo, ziga, As I cant reproduce the openvswitch error from my machine, is it ok if I create a test PR to run it from travis to get more information about the error? | 14:52 |
| cachio | niemeyer, mvo, ziga, afaik it is getting stuck trying to create the db | 14:53 |
| Chipaca | kyrofa: are you at the sprint? | 14:54 |
| zyga | pstolowski: interesting | 14:54 |
| zyga | pstolowski: we should download core then, not install it | 14:54 |
| zyga | cachio: fine with me | 14:54 |
| pstolowski | zyga, indeed | 14:55 |
| mup | PR snapd#3416 opened: DONT REVIEW - Adding debug information to test interfaces-openvswitch <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3416> | 15:03 |
| kyrofa | Chipaca, yessir, what's up? | 15:04 |
| === nacc_ is now known as nacc | ||
| Chipaca | kyrofa: I hadn't realised you guys would be in london :-) was wondering if you were doing anything this eve | 15:08 |
| kyrofa | Chipaca, nope | 15:09 |
| kyrofa | Chipaca, want to? | 15:09 |
| Chipaca | kyrofa: it doesn't sound like a bad idea | 15:09 |
| kyrofa | Chipaca, it indeed sounds relatively acceptable | 15:09 |
| Chipaca | all things considered etc | 15:10 |
| kyrofa | Chipaca, how close do you live? | 15:10 |
| Chipaca | kyrofa: an hour away, approx | 15:12 |
| Saviq | kyrofa, https://travis-ci.org/snapcore/snapcraft/builds/237914554?utm_source=github_status&utm_medium=notification | 15:13 |
| kyrofa | Chipaca, want do you want to do? Come in here, stay out there? | 15:13 |
| Chipaca | kyrofa: i think i'll be going in, in a bit | 15:14 |
| Chipaca | i'll have to find my bluefin pass! :-) | 15:14 |
| kyrofa | Chipaca, awesome. That's a bit of a trip though, you're welcome to crash if you like | 15:14 |
| ogra_ | slangasek, why is the ubuntu-image deb trying to loop mount img files ? i thought it would not require any privieged actions anymore | 15:16 |
| slangasek | ogra_: because you have a version of e2fsprogs that's too old to let it populate a filesystem at creation time | 15:20 |
| ogra_ | oh, thats still broken in 16.04 because e2fslibs wasnt fixed :/ | 15:20 |
| ogra_ | slangasek, yeah :( | 15:20 |
| ogra_ | i thought that was supposed to have been SRUed long ago | 15:21 |
| slangasek | ogra_: absolutely not, that's a new major upstream version of e2fsprogs with behavior changes | 15:30 |
| ogra_ | hmpf, k | 15:30 |
| pstolowski | zyga, if I don't install core in prepare and only download & modify+repack, it needs to be installed with --dangerous; is this a problem for our testing? | 15:31 |
| zyga | pstolowski: not sure, perhaps yes | 15:32 |
| zyga | pstolowski: I assume that we check the signature right? | 15:32 |
| ogra_ | boo | 15:32 |
| zyga | pstolowski: and you cannot just ack the assertion | 15:32 |
| zyga | pstolowski: and install it? | 15:32 |
| ogra_ | root@11f68f46633c:/# /snap/bin/htop | 15:32 |
| ogra_ | cannot perform operation: pivot_root /tmp/snap.rootfs_CYPssc /tmp/snap.rootfs_CYPssc//var/lib/snapd/hostfs: Operation not permitted | 15:32 |
| ogra_ | (having snap and snapd running inside docker lets you install and remove snaps ... but you cant run them) | 15:33 |
| zyga | ogra_: missing patches I think | 15:33 |
| zyga | ogra_: can you show me the denial? | 15:33 |
| ogra_ | zyga, i dont think i can ... apparmor is off in that container | 15:34 |
| pstolowski | zyga, what do you mean by acking the assertion? I think I need to ignore it and force dangerous, as checksum will not match anymore? we got away with it because prepare unmount and remounts it after installed | 15:34 |
| kyrofa | Chipaca, think you'll be here around dinner time-ish? | 15:34 |
| Chipaca | kyrofa: are you guys at bluefin? | 15:34 |
| ogra_ | zyga, i doubt it is apparmor related, ratther docker itself | 15:34 |
| kyrofa | Chipaca, yes | 15:34 |
| zyga | ogra_: and in the outside? apparmor is really a kernel-wide thing | 15:34 |
| zyga | ogra_: I disagree, this looks like apparmor | 15:35 |
| Chipaca | kyrofa: i could aim to be there at 6pm, or I could aim for later if you want to go back to the hotel and such | 15:35 |
| zyga | pstolowski: snap akc | 15:35 |
| zyga | darn :) | 15:35 |
| zyga | snap *ack* | 15:35 |
| fgimenez_ | morphis_: it seems that during this test reexec was disabled on debian https://travis-ci.org/snapcore/snapd/builds/235819260#L2936 i've seen this in several executions, have you found this kind of error before? | 15:35 |
| zyga | pstolowski: but without the assertion the samantics is not the same in some places | 15:35 |
| mup | PR snapd#3415 closed: interfaces: revert "interfaces: re-add reverted ioctl and quotactl <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3415> | 15:35 |
| ogra_ | zyga, and indeed you are right ... http://paste.ubuntu.com/24727427/ | 15:36 |
| kyrofa | Chipaca, or we can do BOTH | 15:36 |
| zyga | ogra_: oh very interesting | 15:37 |
| kyrofa | Chipaca, no need to go back to the hotel, come whenever you think you'll be hungry | 15:37 |
| mvo | fgimenez_: is it reasonable straightfroward for you to test if current master is fixed with regards for the snap revert test that caused the network-manager regression? if so, could you please trigger a test? | 15:37 |
| pstolowski | zyga, I know... thus the question about affecting the tests.. anyway. i think I have a simple workaround (setting both new and old var in hookmgr) which is needed anyway for transition. no need to modify prepare then | 15:37 |
| zyga | ogra_: can you just add "signal," to snap-confine's apparmor profile and reload it | 15:37 |
| mvo | fgimenez_: I think master is fine and I prepared cherry-picks for 2.26, if your test is positive I will upload 2.26.4 to the PPA and make new beta images | 15:38 |
| ogra_ | zyga, in the container ? | 15:38 |
| ogra_ | not sure that will work | 15:38 |
| fgimenez_ | mvo: of couse on it, will let you know how it goes | 15:38 |
| ogra_ | (simply beacause i wont be able to relaod) | 15:38 |
| ogra_ | **reload | 15:38 |
| zyga | ogra_: yes, | 15:38 |
| zyga | ogra_: why not? | 15:38 |
| mvo | fgimenez_: thank you! | 15:39 |
| zyga | ogra_: that doesn't sound right, snapd does it all the time, apparmor is stacked | 15:39 |
| ogra_ | zyga, apparmor is completely disabled | 15:39 |
| Chipaca | kyrofa: that's my secret: i'm always hungry | 15:39 |
| mvo | fgimenez_: I have dinner now I think, I will read scollback, super happy that we can move foward with 2.26 now :) | 15:39 |
| zyga | ogra_: it's not disabled, what makes you say so? | 15:39 |
| zyga | ogra_: that denial is from apparmor | 15:39 |
| ogra_ | root@11f68f46633c:/# apparmor_parser | 15:39 |
| ogra_ | Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.) | 15:39 |
| ogra_ | Warning: unable to find a suitable fs in /proc/mounts, is it mounted? | 15:39 |
| ogra_ | Use --subdomainfs to override. | 15:39 |
| fgimenez_ | mvo: np :) it would be great to have snapd#3348 so that we can trigger this test automatically as soon as new core snaps are published | 15:39 |
| mup | PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348> | 15:39 |
| kyrofa | Chipaca, haha, well then, just come now! | 15:39 |
| zyga | ogra_: apparmor is not a container thing, it is loaded into your kernel | 15:39 |
| kyrofa | You're tired of working today anyway | 15:39 |
| zyga | ogra_: and it actually stopped snap-conifne in the container from doing something | 15:39 |
| ogra_ | zyga, but the container cant talk to it | 15:39 |
| zyga | ogra_: so how can it be disabled? | 15:39 |
| ogra_ | zyga, on docker level | 15:40 |
| zyga | ogra_: it can, because the container loaded the apparmor profile for snap-confine | 15:40 |
| Chipaca | grah grah grah with spread and { Error preparing project on linode:ubuntu-14.04-64 } | 15:40 |
| ogra_ | zyga, --security-opt apparmor:unconfined | 15:40 |
| zyga | ogra_: that's not the same as disabled | 15:40 |
| mvo | fgimenez_: indeed! it has a +1 from me already | 15:40 |
| ogra_ | for docker run | 15:40 |
| zyga | ogra_: can you do what I suggested | 15:40 |
| zyga | ogra_: it will let you see what is really wrong | 15:40 |
| ogra_ | zyga, i can not run apparmor_parser | 15:40 |
| zyga | ogra_: what happens when you do? | 15:41 |
| ogra_ | so i cant change the profile | 15:41 |
| ogra_ | see above | 15:41 |
| zyga | you get a denial from snap-confine when you run apparmor_parser? | 15:41 |
| * zyga must be missing a link to another error | 15:41 | |
| zyga | ah, I see now | 15:41 |
| ogra_ | zyga, i cant run appramor_parser to reload any profile since apparmor_parser can not run inside the container | 15:41 |
| ogra_ | due to the /proc fs there not having the needed bits | 15:42 |
| mvo | jdstrand: some good news, we have a working seccomp->bpf thing in go and the seecomp code in snap-confine can shrink by ~800 lines or so now (to be fair a lot of sc_add_map() calls in there). zyga will also work on this so I'm sure it will be nice | 15:42 |
| zyga | ogra_: is proc and sys normal but the kernel on the outside is not? | 15:42 |
| zyga | ogra_: is the kernel fully patched? | 15:42 |
| jdstrand | interesting | 15:42 |
| fgimenez_ | mvo: aha thx, sorry didn't notice, zyga, morphis_ could you please take a look at snapd#3348? | 15:42 |
| mup | PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348> | 15:42 |
| ogra_ | zyga, i have not really any idea how docker creates its virtual /roc in the containers ... it should not be shared with the host afaik | 15:43 |
| ogra_ | **proc | 15:43 |
| zyga | ogra_: I think it must be, just different namespaces | 15:43 |
| zyga | there's just one proc | 15:43 |
| ogra_ | with docker ? | 15:43 |
| zyga | yes | 15:43 |
| zyga | ogra_: anyway, my real questions this: is the kernel you are running on fully patched to support apparmor features from ubuntu? | 15:43 |
| ogra_ | afaik you get a dedicated /proc when starting a container | 15:43 |
| zyga | ogra_: if not then don't touch docker | 15:44 |
| zyga | ogra_: dedicated how? it's just a procfs mount | 15:44 |
| zyga | ogra_: it's all the namespaces that make it different | 15:44 |
| ogra_ | root@11f68f46633c:/# ls /proc/|wc -l | 15:44 |
| ogra_ | 72 | 15:44 |
| zyga | ogra_: see above | 15:44 |
| ogra_ | ogra@anubis:~$ ls /proc/|wc -l | 15:44 |
| ogra_ | 429 | 15:44 |
| zyga | ogra_: it's the normal procs | 15:44 |
| zyga | ogra_: with a PID namespace | 15:44 |
| ogra_ | inside vs outside the container | 15:44 |
| jdstrand | ogra_: I'm late to the party. are you trying to run snaps in a docker container? | 15:44 |
| zyga | ogra_: (it's different because you are looking from a namespace) | 15:45 |
| zyga | but you are looking at the same thing as outside | 15:45 |
| ogra_ | jdstrand, well, first i only tried to get snapd to run and the core snap installed ... got that working ... now i got greedy and tried to run a snap :P | 15:45 |
| jdstrand | ogra_: that isn't going to work unless you disable apparmor in snapd | 15:45 |
| jdstrand | ogra_: it works in lxd because lxd was modified to understand apparmor stacking | 15:46 |
| zyga | jdstrand: note that I think ogra also uses an "interesting" kernel where some things are missing | 15:46 |
| ogra_ | jdstrand, well, i disabled apparmor in docker ... probably i should cheat and hack lsb-release/os-release so snapd doesnt think it is on ubuntu | 15:46 |
| zyga | jdstrand: what it looks like to me is that that version has no idea about stacking | 15:46 |
| zyga | jdstrand: and what happens is that it uses the outside profile | 15:46 |
| zyga | ogra_: we no longer care about os-release | 15:47 |
| zyga | ogra_: we look at apparmor features in sysfs | 15:47 |
| jdstrand | zyga: well, I think it is likely that in the container apaprmor is disabled because things aren't mounted, etc, but apparmor init notices that it isn't lxd and says apparmor isn't available | 15:47 |
| ogra_ | well, then only llsb_release | 15:47 |
| === koza is now known as koza|away | ||
| ogra_ | zyga, ouch | 15:47 |
| ogra_ | then i have no chance of hacking around this i guess | 15:47 |
| zyga | jdstrand: yes but also note that snap-confine itself (in docker) gets killed by apparmor | 15:47 |
| jdstrand | ogra_: you need to disable apparmor in the snapd in docker | 15:47 |
| zyga | jdstrand: and uses a non-stacked profile path | 15:48 |
| jdstrand | (and snap-confine) | 15:48 |
| zyga | ogra_: I think this is a moot exercise, what are you trying to achieve? | 15:48 |
| jdstrand | ogra_: is this a docker snap or a docker deb? | 15:48 |
| ogra_ | jdstrand, right ... and in the past i could have done that by hacking the distro info to pretend i'm not ubuntu | 15:48 |
| ogra_ | (disabling apparmor of snapd) | 15:49 |
| ogra_ | jdstrand, dockeer deb on 16.04 | 15:49 |
| ogra_ | zyga, nothing really ... | 15:50 |
| jdstrand | ok, so, in a docker deb, the docker daemon is not confined. if you used --security-opt apparmor:unconfined (or whatever the incantaion is), then that means the container is not confined either. if you can convince snapd in the container that it shouldn't use apparmor, then apparmor should not be in your way | 15:51 |
| zyga | ogra_: to do that, I think, you must boot with apparmor disabled on command line | 15:51 |
| zyga | ogra_: I think that may be sufficient | 15:51 |
| jdstrand | but, docker has a seccomp list it puts on containers which could block pivot_root | 15:51 |
| jdstrand | (or other things) | 15:52 |
| ogra_ | zyga, linaro uses docker for all image building ... essentially all i initially tried was to get "snap known --remote model series=16 model=pc-amd64 brand-id=canonical" to work ... to not have them use hacked up model assertions for the images they offer (since they end up non-upgradeable) | 15:52 |
| ogra_ | zyga, so i only tried to get snapd and the snap command to work (which i achieved) ... the "running a snap" was just something i tried then ... since i was in that env anyway | 15:52 |
| fgimenez_ | mm the store is returning 50x on some requests http://paste.ubuntu.com/24727574/ | 15:53 |
| zyga | I see | 15:53 |
| ogra_ | zyga, though i guess it would be nice to find a docker setup where you can actually use snaps :) | 15:53 |
| zyga | all the goodies today make me want to go downstairs, take a shower and read a book outside | 15:53 |
| ogra_ | heh | 15:54 |
| zyga | ogra_: I think that needs love | 15:54 |
| zyga | jdstrand: is there any docker setup that would work today? | 15:54 |
| zyga | ogra_: I think lxd is possible but docker is not | 15:54 |
| ogra_ | zyga, right ... well, at least snapd runs now, i have a setup here (will blog about it later in the week) | 15:54 |
| ogra_ | zyga, right ... but what do you do with third parties that dont use lxd | 15:54 |
| ogra_ | (lxd is fine btw, i tried that today) | 15:55 |
| ogra_ | (well ... lxc actually) | 15:55 |
| zyga | ogra_: say it is not supported, it's not going to magically fix itself | 15:55 |
| zyga | unless we make snapd and docker owrk | 15:55 |
| zyga | *work | 15:55 |
| ogra_ | zyga, well, all i needed was the model assertion ... | 15:56 |
| ogra_ | so make the snap conmmand work enough to download it ... that works now | 15:56 |
| ogra_ | running a snap would just have been the cherry on top ... not a requirement | 15:56 |
| ogra_ | (it wouldnt have helped anyway since ubuntu-image is now --classic which makes unusable for 90% of my use cases as a snap ... i'll have to resort to the deb anyway) | 15:58 |
| zyga | I see | 15:59 |
| ogra_ | (though i just found that the deb is unusable as well in 16.04 containers if you dont add PPAs ... (see my conversation with slangasek above)) ... | 15:59 |
| jdstrand | zyga: that question is open ended. I have not tried to run snaps within a docker container. All I can say is that if you are using the docker deb and you run containers unconfined and you make sure snapd doesn't think it should use apparmor, it could maybe be made to work (if tweaking the docker syscall list and likely running a system container) | 16:15 |
| mup | PR snapd#3417 opened: httputil,store: extract retry code to httputil, reorg usages <Created by pedronis> <https://github.com/snapcore/snapd/pull/3417> | 16:16 |
| jdstrand | zyga: if you use the docker snap, it will not work because docker doesn't know about apparmor stacking. if you use the deb but don't launch containers unconfined, you could *maybe* craft a profile for the container that would allow snaps to run *if* snapd in the container didn't think it should use apparmor | 16:17 |
| pedronis | mvo: will snapd#3385 create an always failing timer on classic? is that a problem? | 16:18 |
| mup | PR snapd#3385: cmd: add stub new snap-repair command and add timer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3385> | 16:18 |
| bdx | hows it going everyone? I'm wondering if there is a best practice for snapping projects where the codebase comes from github? i.e. should we be tagging builds and associating those with the snap, or a direct code clone when building the snap? | 16:20 |
| ogra_ | bdx, you should just use build.snapcraft.io ;) | 16:27 |
| ogra_ | (at least if you own the GH branches) | 16:28 |
| === chihchun_afk is now known as chihchun | ||
| bdx | ogra_: sick! is this newnew? | 16:32 |
| ogra_ | yeah, relatively new | 16:32 |
| fgimenez_ | mvo: i think we currently can't make sure that the core-revert passes with the code in master, we would need to use a core snap built from that code, if we could have a new edge core that would be enough, we can also wait until next edge core tomorrow | 16:33 |
| bdx | this looks awesome! digging in now. thanks! | 16:33 |
| ogra_ | enjoy :) | 16:33 |
| fgimenez_ | mvo: assuming that the deb ppa has those changes, with the current flakyness maybe it wasn't updated (it syncs after merge + green build) | 16:34 |
| aquarius_ | yo, snappy types! I'm getting a weird error when I run the snap I've just built: | 16:38 |
| aquarius_ | Failed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.3234" is not allowed to own the service "org.kryogenix.pick-colour-picker" due to AppArmor policy | 16:38 |
| aquarius_ | so, what should my service be named? | 16:38 |
| zyga | aquarius_: you want to look at the dbus interface but if this is a user session service I think that is currently unsupported | 16:42 |
| zyga | (though in progress) | 16:42 |
| aquarius_ | zyga: er | 16:44 |
| aquarius_ | I don't know what that means :) | 16:44 |
| zyga | aquarius_: is your snap using the dbus session bus? | 16:45 |
| aquarius_ | the issue I was having is this: my snapped python2/gtk app worked fine, but it did not use my desktop theme. It was suggested that I should use add the home, gsettings, and unity7 plugs, which I have done, and now the snap installs but the app will not launch, with the above error. | 16:45 |
| zyga | aquarius_: none of those would make it match your desktop theme | 16:46 |
| aquarius_ | I have a section in the snapcraft.yaml which looks like this: | 16:46 |
| zyga | aquarius_: did your snap previously work in devmode or in strict confinement? | 16:46 |
| aquarius_ | https://paste.gnome.org/paztxcuml | 16:46 |
| aquarius_ | but that section was there before and it worked. | 16:46 |
| aquarius_ | I installed with --dangerous, but not with --devmode. | 16:47 |
| aquarius_ | I don't really understand what that entails. :) | 16:47 |
| aquarius_ | (that is: does --dangerous imply --devmode?) | 16:47 |
| zyga | no, it doesn't | 16:47 |
| zyga | aquarius_: I'm sorry but I cannot help you now, I ned to leave now; either catch me tomorrow or perhaps ask jdstrand | 16:48 |
| aquarius_ | will do! cheers, pal | 16:48 |
| aquarius_ | jdstrand: ping (you're who didrocks suggested I should talk to, actually :)) | 16:48 |
| kyrofa | aquarius_, --devmode means "install without confinement (and warn when my app does something that WOULD be denied)" | 16:51 |
| kyrofa | aquarius_, --dangerous, on the other hand, means "install without verifying that this snap comes from a trusted source" | 16:51 |
| kyrofa | aquarius_, --devmode implies --dangerous, but not the other way around | 16:51 |
| === chihchun is now known as chihchun_afk | ||
| aquarius_ | excellent | 16:55 |
| bdx | ogra_: build.snapcraft.io is like CI/CD for snaps? | 16:55 |
| aquarius_ | thank you for that, kyrofa! So, I was not installing with --devmode, and I was installing with --dangerous: I need --dangerous because I'm installing the snap I've just built :) And I didn't need --devmode which means that my app was working under confinement. | 16:56 |
| kyrofa | aquarius_, indeed | 16:56 |
| kyrofa | bdx not quite. CI typically runs tests, etc., acting as a gateway for, say, accepting pull requests | 16:57 |
| nacc | https://build.snapcraft.io/ has a nice picture | 16:58 |
| nacc | about halfway down the page as to where it fits (it's after CI) | 16:59 |
| bdx | ahh, the second graphic is what I was looking for | 16:59 |
| bdx | lets take any web app for example | 17:00 |
| bdx | rails, django, php .... something that is not a snap | 17:00 |
| bdx | so, you have a repo for your django site, would that now contain a snapcraft.yaml? | 17:01 |
| bdx | or would the application code be separate from the snap? | 17:01 |
| nacc | bdx: aiui, yes, you need a snapcraft.yaml still (i'm not sure if it can live in a separte 'packaging' repository/branch) | 17:02 |
| ogra_ | you would likely have a django setup defined and configured inside your snapcraft.yaml, so your snap would ship it along to serve your site | 17:02 |
| bdx | ogra_: a 'django' snap could be a generic snap that lets you set a key and a repo basically? | 17:03 |
| ogra_ | (or you have a webserver snap that shares content with your snap via the content interface ... that way you could update the site only ... but that would be a very personal/specific setup) | 17:04 |
| nacc | bdx: a snap is an entire application, you wouldn't snap django itself (imo), but your use of django | 17:04 |
| ogra_ | bdx, no, i mean you would ship a full webserver environment including django inside your snap | 17:04 |
| nacc | bdx: in snap parlance, django would be a 'part' | 17:05 |
| ogra_ | or alternatively make two snaps and have one share datas from the other | 17:05 |
| ogra_ | *data | 17:05 |
| bdx | I see this, but how does the snap interface to the application code | 17:05 |
| bdx | currently I use a git-layer in my charms to pull in application code | 17:05 |
| ogra_ | have a look at the content interface | 17:05 |
| bdx | ok | 17:05 |
| bdx | I'm trying to understand what about my charms should become snaps | 17:06 |
| ogra_ | your webserver would use shared code from $SNAP/wrbserver/shared and be configured for that ... and your app code would then provide stuff in that dir through the content-sharing interface | 17:06 |
| bdx | ogra_: I see, so I could use the charm to handle the application code in that case | 17:07 |
| ogra_ | when you upgrade your app snap it will automatically ship the updated code in that dir | 17:07 |
| bdx | I see ... so my application code is packaged with the snap then | 17:07 |
| ogra_ | well, it really depends what you want ... either bundle the server with the app or use an interface to hold both of them separated | 17:08 |
| ogra_ | everything is possible ;) | 17:08 |
| bdx | totally ... thats what make it so difficult | 17:08 |
| bdx | I feel like I need to be more educated on snaps to be making these decisions | 17:09 |
| ogra_ | (you could also have a deb based server that has a fixed config to look in /snap/$your-app/current/data/ for all its stuff | 17:09 |
| ogra_ | ) | 17:09 |
| bdx | I'll work on that | 17:09 |
| bdx | yeah ... then have the charm deliver the application code | 17:09 |
| ogra_ | there are no limits to creativity with snaps ;) | 17:09 |
| bdx | I think my problems moving forward will be knowing and understanding the framework here and what is available and how to use it | 17:10 |
| ogra_ | right ... i guess thats a matter of playing around with it and learning its capabilities ;) | 17:11 |
| jdstrand | aquarius_: you need to slots the dbus interface so it may bind to that well-known name. do 'snap download corebird', unsquashfs it, then look at squashfs-root/meta/snap.yaml for an example | 17:11 |
| jdstrand | basically: | 17:12 |
| jdstrand | slots: | 17:12 |
| jdstrand | foo: | 17:12 |
| jdstrand | bus: session | 17:12 |
| jdstrand | interface: dbus | 17:12 |
| jdstrand | name: org.kryogenix.pick-colour-picker | 17:12 |
| bdx | possibly I need to forget about what components the charm will handle, and just try to get something fully snapped then turn around and use the charm to fill in the lifecycle ops that are still needed following the app being fully snapped | 17:12 |
| Saviq | kyrofa, https://github.com/snapcore/snapcraft/commit/d22880fdcee434a5e85c376e8f26c61a661231ce | 17:12 |
| jdstrand | aquarius_: see https://github.com/snapcore/snapd/wiki/Interfaces#dbus | 17:14 |
| mvo | pedronis: always failing timer> yeah, I can make it just exit(0) instead, that will probably be fine | 17:17 |
| pedronis | mvo: ah, ok | 17:17 |
| Saviq | kyrofa, bug #1694765 | 17:19 |
| mup | Bug #1694765: source-type: git uses --remote for submodules <Snapcraft:New> <https://launchpad.net/bugs/1694765> | 17:19 |
| aquarius_ | jdstrand: I've got that section you described above under plugs; is that wrong, or do I need to declare it under plugs *and* slots? | 17:20 |
| aquarius_ | jdstrand: that is: it's currently https://github.com/stuartlangridge/ColourPicker/blob/app/snap/snapcraft.yaml#L23 | 17:21 |
| aquarius_ | do i need to duplicate that "plugs" section as "slots"? | 17:21 |
| mvo | pedronis: unless I'm missing something this is already the case: http://paste.ubuntu.com/24728381/ | 17:22 |
| pedronis | mvo: yes, sorry, I forgot: if err != errOnClassic { | 17:23 |
| kyrofa | pedronis, this looks like kyle but it's actually Chipaca. Github on mobile won't let me merge snapd#3400, could you give it a poke? | 17:23 |
| mup | PR snapd#3400: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400> | 17:23 |
| pedronis | kyrofa: Chipaca, looking | 17:24 |
| kyrofa | :) thanks | 17:24 |
| mvo | pedronis: great, thanks for double checking | 17:24 |
| pedronis | kyrofa: Chipaca, done | 17:25 |
| aquarius_ | heh, so, it can't be plugs, since I get "cannot have plug and slot with the same name", so I'll try just as a slot. Cargo cult programming ftw. :) | 17:26 |
| mup | PR snapd#3400 closed: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3400> | 17:26 |
| aquarius_ | ok, I've now got it to install, at least, but it hasn't actually fixed the original issue of not having a theme. I'll talk to didrocks again :) | 17:32 |
| aquarius_ | jdstrand: my snapcraft.yaml looks like this: http://paste.ubuntu.com/24728481/ -- is that what you were suggesting? | 17:33 |
| jdstrand | aquarius_: yes. and also yes, I don't have answers for the theme | 17:34 |
| aquarius_ | jdstrand: no problem (the theme is not your thnig :)) | 17:35 |
| aquarius_ | jdstrand: just checking I was doing what you suggested | 17:35 |
| === cachio is now known as cachio_afk | ||
| seb128 | aquarius_, hey, just in case it's interesting to you, colourpicker fails to start from snap here with that error | 17:56 |
| seb128 | File "/snap/pick-colour-picker/x1/lib/python2.7/site-packages/pick/__main__.py", line 874, in start_everything_first_time | 17:56 |
| seb128 | self.w.set_default_icon(image.get_pixbuf()) | 17:56 |
| seb128 | TypeError: Argument 0 does not allow None as a value | 17:56 |
| aquarius_ | huh. really? it starts for me, it just doesn't have the right theme... | 17:56 |
| aquarius_ | I suspect this is about paths. Fabulous, etc :) | 17:58 |
| seb128 | aquarius_, could be, in any case it looks like the pixbuf might be None and your code doesn't handle that case | 18:06 |
| aquarius_ | indeed! | 18:06 |
| aquarius_ | although it shouldn't be :) | 18:06 |
| aquarius_ | I'll look into it (and try ti work out why it's none!) | 18:06 |
| seb128 | let me know if you need debug infos | 18:06 |
| === JanC_ is now known as JanC | ||
| niemeyer | Forum going down/up for a quick configuration update.. | 18:26 |
| niemeyer | Almost there.. aaaaaaan | 18:27 |
| niemeyer | d.. it's up! | 18:28 |
| mup | PR snapd#3418 opened: tests: prefer ipv4 over ipv6 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3418> | 18:33 |
| seb128 | aquarius_, theme works here in devmode on xenial/unity | 18:43 |
| niemeyer | SMTP is failing to relay properly.. reverting setup.. :( | 18:46 |
| ogra_ | jdstrand, FYI ... --security-opt seccomp:unconfined in the "docker run" command works around the blocker ... not that this gets me much further though ... | 18:55 |
| ogra_ | root@7c9bcf90f68b:/# /snap/bin/htop | 18:55 |
| ogra_ | cannot bind-mount the mount namespace file /proc/202/ns/mnt -> htop.mnt: Permission denied | 18:55 |
| ogra_ | support process for mount namespace capture exited abnormally | 18:55 |
| ogra_ | :P | 18:55 |
| jdstrand | ogra_: I had a sneaking suspicion that mount, pivot_root and the like would be blocked by docker | 19:44 |
| mup | PR snapd#3419 opened: interfaces: partly revert aace15ab53 to unbreak core reverts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3419> | 19:50 |
| mvo | jdstrand: I have another partial revert for you -^ | 19:51 |
| mvo | jdstrand: for you to review, we have a reliable test now and it breaks on this symbol now | 19:51 |
| jdstrand | oh sigh | 19:52 |
| jdstrand | all my arg filtering work keeps getting reverted | 19:52 |
| === cachio_afk is now known as cachio | ||
| jdstrand | mvo: responded | 19:54 |
| mvo | jdstrand: thank you! | 19:56 |
| mvo | jdstrand: well, not for long hopefully, https://github.com/mvo5/snappy/commits/seccomp-bpf will fix it (when its polished enough to get merged) | 19:58 |
| cachio | niemeyer, could you please update the https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz with the last version which has the repeat? | 20:07 |
| niemeyer | cachio: Yeah, just not right now.. | 20:13 |
| niemeyer | cachio: Also, not sure how that helps? I mean, -repeat is only useful locally I suppose? | 20:14 |
| cachio | niemeyer, I need to check the test is working in ci | 20:18 |
| cachio | niemeyer, because from my machine it always pass | 20:18 |
| cachio | niemeyer, not sure if it is because my connection is slower or why | 20:19 |
| cachio | niemeyer, so ,my idea is to repeat the execution 100 times in ci to check the fix works | 20:19 |
| cachio | niemeyer, does it make sense? | 20:20 |
| niemeyer | cachio: Ah, yep | 20:23 |
| niemeyer | cachio: Can't do that now, but will do | 20:23 |
| niemeyer | Need to step out for a while | 20:24 |
| mup | PR snapd#3420 opened: many: slight improvement of some snap error messaging <Created by chipaca> <https://github.com/snapcore/snapd/pull/3420> | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!