mwhudsonyay spammers found the forum01:20
mupPR 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
luk3yxI'm having an issue with building a snap.05:46
luk3yxsnapcraft doesn't copy the '.desktop' files across with the 'dump' plugin like it used to.05:46
=== chihchun_afk is now known as chihchun
zygamorphis_: hey06:43
zygamorphis_: just running tumbleweed here, I noticed that none of the desktop launchers work06:43
morphis_zyga: which desktop launchers do you mean?06:43
morphis_the ones you get in the gnome shell dash?06:43
zygamorphis_: any made by snaps06:43
zygamorphis_: yes06:43
morphis_hm, I tried this with krita and I could start06:44
zygamorphis_: we just set PATH06:44
zygamorphis_: in which DE and suse release?06:44
zygaanyway, running gnome tumbleweed, it doesn't work06:44
zygalooking at why now06:44
morphis_I hope this didn't broke recently, let me check06:45
zygaI don't see the extra variable that points to /var/lib/snapd/desktop06:45
morphis_could have been that I fixed that locally but never pushed the fix06:46
morphis_actually this works pretty well on Fedora06:46
morphis_zyga: I wonder if the profile.d handling is different or has changed06:47
zygamorphis_: what do you have in /etc/profile.d?06:47
zygaI have snapd.sh that has one line (except comments): PATH=$PATH:/snap/bin06:48
morphis_powering up my suse VM, on Fedora I have what should be there06:48
zygathe 65snappy Xsession thing is not around06:48
luk3yxWhy doesn't snapcraft put .desktop files in correctly?06:48
zygaluk3yx: no idea, sorry06:49
morphis_zyga: the interesting thing is that the same file on Fedora has the proper XDG_DATA_DIRS vars set06:51
zygamorphis_: separate file06:51
zygamorphis_: I think we don't have one thing across the trees06:51
morphis_/etc/profile.d/snapd.sh sets XDG_DATA_DIRS on Fedora06:51
zygamorphis_: look at etc/X11 in the source tree06:51
zygabecause that's not the same file06:52
morphis_on Suse it doesn't06:52
zygain the source tree we have two files06:52
zygaand in Fedora we use entirely different one (because /snap I suspect)06:52
zygamorphis_: exactly06:52
zygamorphis_: and on ubuntu/debian/suse we take etc from the source package06:52
morphis_that is nasty, we should't differentiate what is in these files across distros06:53
zygaI think it is also somewhat incorrect, that's why we did it this way06:53
zygasomeone reported a bug on XDG_DATA_DIRS, let me try to find it06:53
morphis_ /etc/x11/XSession.d isn't support on Suse as it seems06:54
zygaI can only find https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/155456306:54
mupBug #1554563: Please support /var/lib/snappy/desktop as an additional desktop directory <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1554563>06:54
zygayeah, I see06:54
morphis_ah it's /etc/X11/xinit/xinitrc.d/ instead06:55
zygashall I prepare a patch?06:55
morphis_I am on it already06:56
zygathis is what I made06:57
abeatozyga, hey, mind taking a look when possible at https://github.com/snapcore/snapd/pull/3353 ?06:59
mupPR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>06:59
zygaabeato: yes, certainly06:59
zyganot mind :)06:59
morphis_zyga: yeah, same here06:59
zygaabeato: can you please ensure that every if / else uses braces fully07:00
abeatozyga, also one-liners?07:01
zygathank you, sorry for the nitpick but this is the coding style we're using everywhere else07:04
abeatozyga, done07:07
morphis_zyga: btw. there will be a blog post later this week telling about working lxd/docker on Suse/Fedora07:07
abeatozyga, sure, I had not noticed07:07
zygaabeato: thank you, looking07:07
zygamorphis_: nice, thank you :)07:08
zygaabeato: looks nice, I'll comment in a sec07:09
abeatozyga, great07:09
morphis_zyga: btw. what do you think about doing an Ubuntu Testing day for snaps on Fedora/Suse?07:19
zygamorphis_: I think this is a good idea07:23
zygamorphis_: we could do a converged one for a few distributions07:23
morphis_then let me organize that07:23
zygamorphis_: but only those under CI today07:23
zygawe can split responsibilities07:23
zygaI can show suse (natively) and fedora (natively)07:23
morphis_what means natively?07:24
morphis_in a non-vm environment?07:24
zygarunning on metal07:24
zygaI shun VMs recently07:24
zygabecause we're mot using them daily for real stuff07:24
zygajust for fire&forget07:24
zyga(e.g. the desktop issue)07:25
zygamvo: hey07:27
zygamvo: did you see  PR 341007:28
mupPR 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
mupPR 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
mvozyga: yeah, I noticed it, need to look in detail, was a bit distracted with the other things going on07:37
mupPR 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
zygamorphis_: hmm,not sure what happened07:48
morphis_yeah, not sure too07:48
zygaoh man07:49
zygamorphis_: can you hear me?08:00
zygamorphis_: seems like google hangouts armageddon08:00
* zyga does code reviews 08:05
zygamvo: please pull me out of this if you need my help with release blockers08:05
NicolinoCurallihi all: i need to delete a snap  in  brand store : who can help me?08:09
kyrofaHey zyga, did you solve the snap-confine in lxc issue?08:34
zygakyrofa: nope, I didn't have time to explore that yet08:34
kyrofazyga, 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 working08:36
zygaoh, that's good news :)08:36
morphis_zyga: https://build.opensuse.org/request/show/50003508:37
zygasorry for being passive about that, I think it will only be fixed once I actively try LXD and we have CI08:37
zygamorphis_: approved, thank you08:37
kyrofazyga, yeah we really need lxd in CI08:39
morphis_zyga: had to use /etc/profile.d in the end but it works now08:40
zygamorphis_: what happend when you tried xinitrd.d?08:41
zygamorphis_: just wasn't picked up?08:41
zygaor didn't export the environment back to other processes?08:41
morphis_zyga: yes08:41
morphis_it wasn't loaded for the DE nor for any shell08:42
morphis_so not picked up at all08:42
NicolinoCurallihi 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 declarations08:44
=== cydizen_ is now known as cydizen
abeatoogra_, hey, I had to do a small correction in https://github.com/snapcore/core-build/pull/1309:02
mupPR 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
abeatoogra_, do we need some other approval or is it ready to be merged?09:04
ogra_abeato, you need two people to approve09:04
NicolinoCurallihi guys : someone can help me to find the person tha can help me to solve my problem?09:04
abeatoogra_, ok, who do I need to annoy? ;)09:04
ogra_abeato, dunno ... someone from the snapd core team09:05
abeatoogra_, maybe mvo? https://github.com/snapcore/core-build/pull/13 ? :)09:05
mupPR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>09:05
=== cpaelzer_ is now known as cpaelzer
mvoabeato: sure, I have a look09:07
abeatomvo, thanks!09:07
mvozyga: 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 changes09:08
mvozyga: 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 paparmor09:10
zygamvo: did you change the moment when you load the profile in snap-confine?09:11
zyganote that seccomp applies instantly09:11
mvozyga: sure, here is the log http://paste.ubuntu.com/24724666/09:11
zygamvo: which kernel was this on?09:12
mvozyga: 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
mvozyga: 4.4.0-7809:12
mvozyga: do you think I should try a different one?09:12
zygano, the kernel looks fine09:13
mvozyga: the profile is loaded at the same point as the old sc_load_seccomp_context(seccomp_ctx);09:13
mvozyga: whats puzzling is that its apparmor, the execve from seccomp would get killed (SIGSYS) but I get a EPERM09:13
mvozyga: I guess I wait for jamie to see if he has some ideas09:15
zygamvo: just curious, the sc_prepare_seccomp_context no longer does anything, right?09:16
zygamvo: note that the code is structured in a specific way09:16
mvozyga: I still made it prepare everything so that I can dump the content and compare the diff between the new and the old code09:16
zygamvo: so when you load the profile you can still, afair, do more things, when we apply it it is too late to some things09:16
mvozyga: oh, interessting09:16
zygathis is why those were split09:16
zyganot sure if this would explain the WARN you saw09:17
zygajjohansen: ^^ you want to look at http://paste.ubuntu.com/24724666/09:17
mvozyga: interessting idea, I can play a bit and see if moving things around makes a difference09:18
zygamvo: honestly, I'd love to hack on this09:18
=== dgadomski_ is now known as dgadomski
mvozyga: I will first try a newer kernel just to see if it makes a difference09:18
zygamvo: but if you want to do it then feel free :)09:18
mvozyga: go ahead09:18
zygamvo: I need to review PRs and apply feedback first09:18
mvozyga: the branch is https://github.com/snapcore/snapd/compare/master...mvo5:seccomp-bpf?expand=109:18
zygamvo: but I can do some more hacking in the evening09:18
zygadid you see the hotfix PR by any chance?09:19
mvozyga: yeah, its a fun and fascinating project. I need to also go and do the boring stuff now (cherry pick, release)09:19
mvozyga: 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
zygamvo: no not yet, I wanted to get your feedback first09:24
zygamvo: one thing I was thinking of is make periodic releases of the hotfix tool (only for developers using edge)09:25
zygamvo: and to patch it a little more to be double-click-foolproof, just run it and it applies all hotfixes09:25
Chipacapedronis`: snapd#3400 is ready for your perusal if you have a bit09:26
mupPR snapd#3400: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400>09:26
mupPR snapd#3414 opened: tests: show available entropy on error <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3414>09:29
ChipacaNicolinoCuralli: what is your problem?09:29
NicolinoCurallichicapa: I need to upload the snap declaration for a snap under review on my brand store09:34
zygamorphis_: two more issues on suse09:36
zygaFailed to try-restart snapd.autoimport.service: Unit snapd.autoimport.service not found.09:36
zygaFailed to try-restart snapd.system-shutdown.service: Unit snapd.system-shutdown.service not found.09:36
zygaand earlier09:36
zygaFailed to preset unit: File snapd.autoimport.service: No such file or directory09:36
zygaFailed to preset unit: File snapd.system-shutdown.service: No such file or directory09:36
morphis_zyga: we don't install these service units anymore09:37
morphis_so what is starting it?09:37
zygayes but something presets them09:37
zygathey are in systemd_services_list09:37
morphis_ah I see09:37
zygain the spec file09:37
zygawe should drop the two09:37
zygaI can do that if you want, I already have it open09:37
zygabuilding locally to test09:39
morphis_zyga: please!09:42
zygawe need snap install pastebinit :)09:42
zygathere's no pastebinit on tumbleweed09:42
zygaoh, but there is susepaste and susepaste-screenshot09:43
zygaI'm especially intrerested in the screenshot paste :)09:43
zyga   http://paste.opensuse.org/7145812309:44
zygamorphis_: ^ looks ok?09:44
=== pedronis` is now known as pedronis
pedronisChipaca: when I have processed the fact that all the spread runs I start fail for some random reason09:51
Chipacapedronis: spread's just envious of your awesomeness09:53
* zyga is drunk today, sorry for silly comment on 340009:55
=== alan_g is now known as alan_g|errand
* Chipaca hugs zyga 09:57
mvozyga: btw, do you know more about "cannot create lock directory /run/snapd/lock: Permission denied" yet? we see this a lot in the error tracker09:57
Chipacazyga: i'm assuming you're not _actually_ drunk09:57
zygano, not actually09:57
zygamvo: no, still no idea what is going on there09:58
zygamvo: how can I get error tracker data?09:58
mvozyga: errors.ubuntu.com has a lot of it, .e.g https://errors.ubuntu.com/problem/19272ebc18709d4407dba0438a536d56bb14306910:00
mvozyga: there might be a form to fill in to get access (if you have not done so already) to the details10:00
* zyga looks at http://susepaste.org/10525636 and sighs :/10:01
mvozyga: this one has 5k occurances last week10:01
zygamvo: how did you find this, I mean, how to "get started"?10:01
mvozyga: 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 ones10:02
zygaaha, let me try that10:02
mvozyga: the top one is the one I just linked to10:02
zygaclassic confinement, hmm10:03
zygastill, should not impact anything10:03
mupPR 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
zygamvo: 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
mvozyga: that is the one running, the host and core versions are available via the build-id10:08
jocmorphis_: would appreciate if you could look at getting that udisksctl auto alias setup soonish, we have test runs that would like it available10:08
mupPR snapd#3415 opened: interfaces: revert "interfaces: re-add reverted ioctl and quotactl <Created by mvo5> <https://github.com/snapcore/snapd/pull/3415>10:11
pedronisChipaca: added some comments10:13
* Chipaca reads10:14
zygamorphis_: so, the overlordSuite.TestEnsureLoopPrune test never passes for me10:15
zygamorphis_: hmm, wonder if this related to multi-core build host vs single-core VM10:15
zygamorphis_: I'll commit and let OBS do the build10:16
mvoa review for #3415 would be great. it will unblock 2.26/2.2710:17
* mvo just needs tests now10:19
* mvo just needs to wait for tests now10:19
Chipacapedronis: "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
Chipacacurrently best phrasing i have is “// LookupRefresh returns a snap's store-offered revision information given its refresh candidate.”10:22
pedronismvo: test are super flaky, I had zero happy runs since yesterday, maybe is just me though10:24
mvopedronis: autsch, that does not sound encouraging10:25
mvopedronis: thank you, I will know in some minutes10:25
mupPR 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
pedronisI had one now after tentative N+10:26
pedronisChipaca: sounds ok10:27
pedronis(all things considered)10:27
pedronismvo: could you push master into snapd#3385 again,  that's other one I'm trying to see pass, maybe pushing master helps10:29
mupPR 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 here10:33
pedronisChipaca: thx, did you see my question about the error?  also I pmed you10:34
Chipacai didn't see your question about the error10:35
Chipacapedronis: where was that question?10:35
morphis_Pharaoh_Atem: ping10:41
pedronisChipaca: it was a comment attached to some other comments to some code that was changed10:44
mvopedronis: sure, pushed 338510:44
Chipacapedronis: about the snap name and real name not aligning?10:44
Chipacalocal vs real i mean10:45
Chipacapedronis: i replied to that, i think?10:45
Chipacapedronis: basically, yes it's used and shown to the user10:46
Chipacapedronis: (but that's not something this branch introduces?)10:46
pedronisdon't we have the local name around when we show it though?10:46
pedronisChipaca: yes, but moving around where it error is created changes which name we use10:46
pedronisthat's why I'm bothering you :)10:47
pedronisyou need to look at the diff I suppose10:47
pedronisI mean master vs your branch10:47
pedronismvo: thanks, let's how it goes10:48
* pedronis -> lunch10:48
Chipacaso 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 renamed10:52
pstolowskizyga, 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
zygamorphis_: yes, I think it just fails on multi-core systems11:12
zygapstolowski: snapctl is always used (except classic) after we pivot_root so yes11:13
morphis_zyga: ah you think it fails on multi-core thought somehow you mean the other way round11:13
pstolowskizyga, thanks.. ok, this explains my issues with renaming of SNAP_CONTEXT11:13
zygamorphis_: and it failed in OBS now11:14
zygapstolowski: ha, interesting11:14
zygapstolowski: just bind-mount it into core snap11:14
zygapstolowski: although we repack the core snap so not sure why you are seeing this11:15
morphis_zyga: wait, you pushed to the system repository without testing?11:15
zygamorphis_: I tested it but it took many builds to pass11:15
zygamorphis_: since this is a trivial patch on top of existing working build I didn't expect it could be any worse11:16
morphis_actually we should always go via an review request, that way we can verify it builds on all archs + systems11:16
zygamorphis_: well, it is randomly failing because that test is racy11:16
Chipacapedronis: 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 one11:16
zygamorphis_: and the failure has nothing to do with the change at hand11:17
zygamorphis_: maybe we just get better build VMs now :/11:17
zygamorphis_: I re-triggered the build11:18
morphis_I see, was just looking at the log file11:18
zygamorphis_: it's the same failure I mentioned before and the one we fixed in master some time ago11:19
zygamorphis_: but apparently the fix was wrong as it also fails in travis very often11:19
pstolowskizyga, hmm indeed I see this is done in prepare.sh. ok  let me verify if this is working11:20
zygapstolowski: maybe we just don't copy snapctl11:20
pstolowskizyga, we do11:22
zygaso there must be something else at play11:22
zygamorphis_: it worked on retry11:24
pstolowskizyga, ok. confirmed. whatever we think we do in prepare.sh is not working for snapctl when I run spread test with qemu ;)11:27
pstolowskiqemu:ubuntu-16.04-64 /root# md5sum /usr/bin/snapctl /snap/core/current/usr/bin/snapctl11:27
pstolowski67d600f14953d72a8440e0d90a93abc4  /usr/bin/snapctl11:27
pstolowski5ac1e109e0dd434d5141b9ad52b20f3f  /snap/core/current/usr/bin/snapctl11:27
zygapstolowski: let me look11:27
morphis_zyga: good11:27
zygapstolowski: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L4611:28
pedronisChipaca: it's ok11:28
zygapstolowski: and also https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L7411:29
zygapstolowski: this gets called from https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L9411:29
zygapstolowski: hmm hmm hmm, no idea11:29
zygapstolowski: how are you running your test exactly?11:29
pstolowskizyga, uh oh the tests I'm using do not call prepare.sh11:30
zygapstolowski: oh? why? where are your tests?11:31
zygapstolowski: this is typically done at suite level11:31
pstolowskizyga, well, existing one - e.g. main/snap-set11:31
pstolowskizyga, at least no explicit call to prepare.sh11:31
zygapstolowski:  https://github.com/snapcore/snapd/11:32
zygapstolowski: they do, or your spread is old/weird/broken11:32
morphis_zyga: but what change we submit we should always go through a review request for suse11:32
morphis_otherwise we may break existing installations11:32
zygamorphis_: sure, I didn't do it because I didn't have a branch and I showed you the diff to ack11:33
pstolowskizyga, 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 directly11:34
pstolowskizyga, 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/bin11:41
zygamorphis_: so....11:42
zygamorphis_: on re-logout neither snapd.sh nor snapd-xdg.sh do stuff11:43
zygamorphis_: /snap/bin is not in path11:43
morphis_you have reboot11:43
zygaah, the X session holds this too?11:43
* zyga reboots then :)11:43
pstolowskizyga, 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/bin11:44
zygamorphis_: 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/bin11:46
zygamorphis_: the snapd-xdg.sh file is +x while all the other files there are not11:46
morphis_should be 644, I agree11:46
zygamorphis_: but it doesn't hurt11:46
zygamorphis_: I think snapd on suse is really good now11:46
morphis_yeah, will fix that later when I can power up my suse vm again11:46
morphis_zyga: one thing is missing11:46
morphis_cleanup of /var/lib/snapd on removal11:46
zygaah, interesting11:47
zygayep, we should use the management script and just make it better11:47
morphis_naah, xdg-open is missing everywhere but Ubuntu :-)11:47
zygaand use it on all the distributions11:47
morphis_zyga: yes11: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 that11:47
zygamorphis_: sounds good11:48
Son_Gokumorphis_: 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_GokuI want it perfectly working first :)11:54
morphis_Son_Goku: one thing missing before we reach that goal :-)11:55
Son_GokuI'm still fine-tuning the script11:55
Son_GokuI'm nearly there, and then we can work generalizing11:55
Son_Gokuerr, work on generalizing it11:55
morphis_Son_Goku: good11:55
Son_GokuI expect that we can start generalizing next week11:56
Son_Gokuas I'll take care of the last wibbles in the script and packaging this weekend11:56
Son_Gokuat the latest :D11:56
zygamorphis_: docker works but adduser/addgroup vs useradd groupadd is an issue, we should fix this eventually12:06
morphis_zyga: who calls these?12:06
zygamorphis_: the user is instructed to12:06
morphis_for the docker snap?12:07
morphis_you can but you also can simply run the docker command via sudo12:07
Son_Gokuthe modern debian addfoo commands have never been ported outside of the distribution12:08
Son_Gokuinterestingly, I think debian is the upstream for shadow-utils12:09
zygaanyway, it will go away once snapd does user management12:13
Son_Gokuyou scare me with phrases like that12:13
Son_Goku"user management"?12:13
Son_Gokusnapd will replace shadow-utils too?12:13
zygano, it will just create service accounts like the one for docker12:13
zygabetter than asking users to follow instructions :)12:13
Son_Gokuoh, so there'll be a snappy user for this12:13
zygaSon_Goku: yes, most likely a specific one12:14
zygathere's a writeup about this ...12:14
Son_Gokuwe'll probably want the uid + gid reserved in Fedora12:14
Son_Gokuthat way it's sane across the board12:14
zygabut brace yourself12:14
zygathat's a long read12:14
Son_Gokuholy crap12:15
Son_GokuI'll need to bookmark this12:15
Son_Gokujdstrand, damn, you wrote a lot...12:15
Saviqkalikiana, https://code.launchpad.net/~saviq/snapcraft/+git/snapcraft/+merge/32485612:18
zygamvo: 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_Factory12:25
zygamorphis_: if system:snappy counts as a devel project then we're very close12:27
morphis_zyga: right12:27
morphis_zyga: I think for factory inclusion we should better have the snap-mgmt.sh script included12:39
morphis_otherwise package removal is pretty dirty12:39
morphis_so let me add that this evening12:39
zygamorphis_: yes, I agree12:42
zygamorphis_: sounds good12:42
zygagithub died12:43
zyga"major service outage"12:43
Son_Gokuzyga: you need to request it to be added as a devel project12:46
Son_Gokuit must be specially marked for Factory12:46
Son_Gokuotherwise the bot will reject the SRs12:47
Son_Gokutalk to DimStar in #opensuse-factory about figuring out the process to that12:47
Son_Gokuthough really, now that snapd is only one package, you can move it into system:packagemanager and avoid the mess entirely12:48
Son_Gokuerr, one source package12:48
zygaSon_Goku: what is system:packagemanager? some blessed devel repo?12:50
zygaSon_Goku: I think we could just get system:snapd tagged this way12:50
zygahow can we check if it is tagged or not?12:50
Son_Gokuwell, system:snappy12:50
Son_Gokuthere's a whitelist somewhere, lemme check12:50
zygaSon_Goku: thanks, how do you know those things? :)12:53
Chipacaspread from travis is really having a bad day today :-(12:53
zygaChipaca: github is down12:53
Chipacathis might explain things12:54
Son_Gokuzyga, with the extremely notable exception of Debian and Ubuntu, I'm involved in all major Linux distributions12:54
Chipacaquick, move everything back to launchpad while nobody is looking12:54
* Son_Goku stabs Chipaca with a fork12:54
kyrofaGaaaaah giiiithuuuub12:54
* Son_Goku runs and whistles12:54
Son_Gokukyrofa: this is why you have a replica project on GitLab :)12:54
zygaaaaand its back12:54
Son_Gokufwiw, it was never down for me12:55
Son_Gokuapparently, only down in the European side12:55
zygaSon_Goku: look at status.github.com12:55
kyrofaLiar. It works every other refresh. Some presentation nodes12:55
zygawell they sure lost their 5-9s12:56
kyrofaFive? Hahaha12:56
zygasoon they will have 9-5s12:57
kyrofaTheir API is 95%12:57
Chipacathey totally have 9 9s12:57
zygayeah, I'm watching the same page12:57
cjwatsonI once briefly worked on software that required six nines12:57
cjwatsonThat was interesting12:57
zygacjwatson: was it changed (the software)?12:58
cjwatsonVery carefully :-)12:58
cjwatsontelco stuff12:58
ChipacaI love that we can build stuff to that spec12:58
zygaI wonder how that must work and be like12:58
cjwatsonhot failover EVERYWHERE12:58
ChipacaI hate what we apparently have to do to get there12:58
zygahow doyou learn by making mistakes?12:58
zygaso you can still12:59
Chipacazyga: you do that part on somebody *else's* telco12:59
cjwatsonyou get 30 seconds a year of downtime so you don't have time to boot anything12:59
cjwatsonat least not much12:59
mvozyga: no, the lock directory issue I have not seen myself, just from errrors.u.c12:59
zygaI'm still exploring it13:00
elopiompt: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/155556913:01
mupBug #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
mupPR snapcraft#1337 opened: autotools: don't force uniqueness on configflags <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/1337>13:03
Saviqkalikiana, or rather ↑13:03
mvopedronis: 3385 should be ready now btw13:36
pedronismvo: I saw that, will merge it in a bit13:49
mvopedronis: thanks13:50
zygaI have an idea why the lock thing is exploding13:53
zygamvo: I think this is another race13:57
zygamvo: running a scenario to confirm now13:57
Son_Gokuzyga, there's a few fixes I need to submit to the snapd package on openSUSE13:58
Son_Gokuso I'll prepare those tomorrow13:58
Son_GokuI won't have any time today13:58
zygaSon_Goku: sure, what kind of fixes?13:58
Son_Gokuconditional checks for BRs and stuff13:58
zygaSon_Goku: no worries, we wanted to prepare to submit to factory13:58
zygasure, thank you13:59
zygaSon_Goku: but we can do that after your patches are merged13:59
Son_Gokuwait what?14:00
Son_Gokuwhat patches?14:00
Son_Gokuto snap-mgmt.sh, you mean?14:00
zygaSon_Goku: well the fixes you just mentioned14:00
Son_Gokuwell, I think I already branched snapd from system:snappy14:00
mupPR 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
pstolowskizyga, 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
cachioniemeyer, 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
cachioniemeyer, mvo, ziga, afaik it is getting stuck trying to create the db14:53
Chipacakyrofa: are you at the sprint?14:54
zygapstolowski: interesting14:54
zygapstolowski: we should download core then, not install it14:54
zygacachio: fine with me14:54
pstolowskizyga, indeed14:55
mupPR snapd#3416 opened: DONT REVIEW - Adding debug information to test interfaces-openvswitch <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3416>15:03
kyrofaChipaca, yessir, what's up?15:04
=== nacc_ is now known as nacc
Chipacakyrofa: I hadn't realised you guys would be in london :-) was wondering if you were doing anything this eve15:08
kyrofaChipaca, nope15:09
kyrofaChipaca, want to?15:09
Chipacakyrofa: it doesn't sound like a bad idea15:09
kyrofaChipaca, it indeed sounds relatively acceptable15:09
Chipacaall things considered etc15:10
kyrofaChipaca, how close do you live?15:10
Chipacakyrofa: an hour away, approx15:12
Saviqkyrofa, https://travis-ci.org/snapcore/snapcraft/builds/237914554?utm_source=github_status&utm_medium=notification15:13
kyrofaChipaca, want do you want to do? Come in here, stay out there?15:13
Chipacakyrofa: i think i'll be going in, in a bit15:14
Chipacai'll have to find my bluefin pass! :-)15:14
kyrofaChipaca, awesome. That's a bit of a trip though, you're welcome to crash if you like15:14
ogra_slangasek, why is the ubuntu-image deb trying to loop mount img files ? i thought it would not require any privieged actions anymore15:16
slangasekogra_: because you have a version of e2fsprogs that's too old to let it populate a filesystem at creation time15: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 ago15:21
slangasekogra_: absolutely not, that's a new major upstream version of e2fsprogs with behavior changes15:30
ogra_hmpf, k15:30
pstolowskizyga, 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
zygapstolowski: not sure, perhaps yes15:32
zygapstolowski: I assume that we check the signature right?15:32
zygapstolowski: and you cannot just ack the assertion15:32
zygapstolowski: and install it?15:32
ogra_root@11f68f46633c:/# /snap/bin/htop15:32
ogra_cannot perform operation: pivot_root /tmp/snap.rootfs_CYPssc /tmp/snap.rootfs_CYPssc//var/lib/snapd/hostfs: Operation not permitted15:32
ogra_(having snap and snapd running inside docker lets you install and remove snaps ... but you cant run them)15:33
zygaogra_: missing patches I think15:33
zygaogra_: can you show me the denial?15:33
ogra_zyga, i dont think i can ... apparmor is off in that container15:34
pstolowskizyga, 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 installed15:34
kyrofaChipaca, think you'll be here around dinner time-ish?15:34
Chipacakyrofa: are you guys at bluefin?15:34
ogra_zyga, i doubt it is apparmor related, ratther docker itself15:34
kyrofaChipaca, yes15:34
zygaogra_: and in the outside? apparmor is really a kernel-wide thing15:34
zygaogra_: I disagree, this looks like apparmor15:35
Chipacakyrofa: i could aim to be there at 6pm, or I could aim for later if you want to go back to the hotel and such15:35
zygapstolowski: snap akc15:35
zygadarn :)15:35
zygasnap *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
zygapstolowski: but without the assertion the samantics is not the same in some places15:35
mupPR 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
kyrofaChipaca, or we can do BOTH15:36
zygaogra_: oh very interesting15:37
kyrofaChipaca, no need to go back to the hotel, come whenever you think you'll be hungry15:37
mvofgimenez_: 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
pstolowskizyga, 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 then15:37
zygaogra_: can you just add "signal," to snap-confine's apparmor profile and reload it15:37
mvofgimenez_: 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 images15:38
ogra_zyga, in the container ?15:38
ogra_not sure that will work15:38
fgimenez_mvo: of couse on it, will let you know how it goes15:38
ogra_(simply beacause i wont be able to relaod)15:38
zygaogra_: yes,15:38
zygaogra_: why not?15:38
mvofgimenez_: thank you!15:39
zygaogra_: that doesn't sound right, snapd does it all the time, apparmor is stacked15:39
ogra_zyga, apparmor is completely disabled15:39
Chipacakyrofa: that's my secret: i'm always hungry15:39
mvofgimenez_: I have dinner now I think, I will read scollback, super happy that we can move foward with 2.26 now :)15:39
zygaogra_: it's not disabled, what makes you say so?15:39
zygaogra_: that denial is from apparmor15:39
ogra_root@11f68f46633c:/# apparmor_parser15: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 published15:39
mupPR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>15:39
kyrofaChipaca, haha, well then, just come now!15:39
zygaogra_: apparmor is not a container thing, it is loaded into your kernel15:39
kyrofaYou're tired of working today anyway15:39
zygaogra_: and it actually stopped snap-conifne in the container from doing something15:39
ogra_zyga, but the container cant talk to it15:39
zygaogra_: so how can it be disabled?15:39
ogra_zyga, on docker level15:40
zygaogra_: it can, because the container loaded the apparmor profile for snap-confine15:40
Chipacagrah grah grah with spread and { Error preparing project on linode:ubuntu-14.04-64 }15:40
ogra_zyga, --security-opt apparmor:unconfined15:40
zygaogra_: that's not the same as disabled15:40
mvofgimenez_: indeed! it has a +1 from me already15:40
ogra_for docker run15:40
zygaogra_: can you do what I suggested15:40
zygaogra_: it will let you see what is really wrong15:40
ogra_zyga, i can not run apparmor_parser15:40
zygaogra_: what happens when you do?15:41
ogra_so i cant change the profile15:41
ogra_see above15:41
zygayou get a denial from snap-confine when you run apparmor_parser?15:41
* zyga must be missing a link to another error15:41
zygaah, I see now15:41
ogra_zyga, i cant run appramor_parser to reload any profile since apparmor_parser can not run inside the container15:41
ogra_due to the /proc fs there not having the needed bits15:42
mvojdstrand: 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 nice15:42
zygaogra_: is proc and sys normal but the kernel on the outside is not?15:42
zygaogra_: is the kernel fully patched?15:42
fgimenez_mvo: aha thx, sorry didn't notice, zyga, morphis_ could you please take a look at snapd#3348?15:42
mupPR 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 afaik15:43
zygaogra_: I think it must be, just different namespaces15:43
zygathere's just one proc15:43
ogra_with docker ?15:43
zygaogra_: 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 container15:43
zygaogra_: if not then don't touch docker15:44
zygaogra_: dedicated how? it's just a procfs mount15:44
zygaogra_: it's all the namespaces that make it different15:44
ogra_root@11f68f46633c:/# ls /proc/|wc -l15:44
zygaogra_: see above15:44
ogra_ogra@anubis:~$ ls /proc/|wc -l15:44
zygaogra_: it's the normal procs15:44
zygaogra_: with a PID namespace15:44
ogra_inside vs outside the container15:44
jdstrandogra_: I'm late to the party. are you trying to run snaps in a docker container?15:44
zygaogra_: (it's different because you are looking from a namespace)15:45
zygabut you are looking at the same thing as outside15: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 :P15:45
jdstrandogra_: that isn't going to work unless you disable apparmor in snapd15:45
jdstrandogra_: it works in lxd because lxd was modified to understand apparmor stacking15:46
zygajdstrand: note that I think ogra also uses an "interesting" kernel where some things are missing15: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 ubuntu15:46
zygajdstrand: what it looks like to me is that that version has no idea about stacking15:46
zygajdstrand: and what happens is that it uses the outside profile15:46
zygaogra_: we no longer care about os-release15:47
zygaogra_: we look at apparmor features in sysfs15:47
jdstrandzyga: 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 available15:47
ogra_well, then only llsb_release15:47
=== koza is now known as koza|away
ogra_zyga, ouch15:47
ogra_then i have no chance of hacking around this i guess15:47
zygajdstrand: yes but also note that snap-confine itself (in docker) gets killed by apparmor15:47
jdstrandogra_: you need to disable apparmor in the snapd in docker15:47
zygajdstrand: and uses a non-stacked profile path15:48
jdstrand(and snap-confine)15:48
zygaogra_: I think this is a moot exercise, what are you trying to achieve?15:48
jdstrandogra_: 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 ubuntu15:48
ogra_(disabling apparmor of snapd)15:49
ogra_jdstrand, dockeer deb on 16.0415:49
ogra_zyga, nothing really ...15:50
jdstrandok, 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 way15:51
zygaogra_: to do that, I think, you must boot with apparmor disabled on command line15:51
zygaogra_: I think that may be sufficient15:51
jdstrandbut, docker has a seccomp list it puts on containers which could block pivot_root15: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 anyway15:52
fgimenez_mm the store is returning 50x on some requests http://paste.ubuntu.com/24727574/15:53
zygaI see15:53
ogra_zyga, though i guess it would be nice to find a docker setup where you can actually use snaps :)15:53
zygaall the goodies today make me want to go downstairs, take a shower and read a book outside15:53
zygaogra_: I think that needs love15:54
zygajdstrand: is there any docker setup that would work today?15:54
zygaogra_: I think lxd is possible but docker is not15: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 lxd15:54
ogra_(lxd is fine btw, i tried that today)15:55
ogra_(well ... lxc actually)15:55
zygaogra_: say it is not supported, it's not going to magically fix itself15:55
zygaunless we make snapd and docker owrk15: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 now15:56
ogra_running a snap would just have been the cherry on top ... not a requirement15: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
zygaI see15: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
jdstrandzyga: 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
mupPR snapd#3417 opened: httputil,store: extract retry code to httputil, reorg usages <Created by pedronis> <https://github.com/snapcore/snapd/pull/3417>16:16
jdstrandzyga: 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 apparmor16:17
pedronismvo: will snapd#3385 create an always failing timer on classic? is that a problem?16:18
mupPR snapd#3385: cmd: add stub new snap-repair command and add timer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3385>16:18
bdxhows 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
bdxogra_: sick! is this newnew?16:32
ogra_yeah, relatively new16: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 tomorrow16:33
bdxthis 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 policy16:38
aquarius_so, what should my service be named?16:38
zygaaquarius_: you want to look at the dbus interface but if this is a user session service I think that is currently unsupported16:42
zyga(though in progress)16:42
aquarius_zyga: er16:44
aquarius_I don't know what that means :)16:44
zygaaquarius_: 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
zygaaquarius_: none of those would make it match your desktop theme16:46
aquarius_I have a section in the snapcraft.yaml which looks like this:16:46
zygaaquarius_: did your snap previously work in devmode or in strict confinement?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
zygano, it doesn't16:47
zygaaquarius_: I'm sorry but I cannot help you now, I ned to leave now; either catch me tomorrow or perhaps ask jdstrand16:48
aquarius_will do! cheers, pal16:48
aquarius_jdstrand: ping (you're who didrocks suggested I should talk to, actually :))16:48
kyrofaaquarius_, --devmode means "install without confinement (and warn when my app does something that WOULD be denied)"16:51
kyrofaaquarius_, --dangerous, on the other hand, means "install without verifying that this snap comes from a trusted source"16:51
kyrofaaquarius_, --devmode implies --dangerous, but not the other way around16:51
=== chihchun is now known as chihchun_afk
bdxogra_: 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
kyrofaaquarius_, indeed16:56
kyrofabdx not quite. CI typically runs tests, etc., acting as a gateway for, say, accepting pull requests16:57
nacchttps://build.snapcraft.io/ has a nice picture16:58
naccabout halfway down the page as to where it fits (it's after CI)16:59
bdxahh, the second graphic is what I was looking for16:59
bdxlets take any web app for example17:00
bdxrails, django, php .... something that is not a snap17:00
bdxso, you have a repo for your django site, would that now contain a snapcraft.yaml?17:01
bdxor would the application code be separate from the snap?17:01
naccbdx: 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 site17:02
bdxogra_: 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
naccbdx: a snap is an entire application, you wouldn't snap django itself (imo), but your use of django17:04
ogra_bdx, no, i mean you would ship a full webserver environment including django inside your snap17:04
naccbdx: in snap parlance, django would be a 'part'17:05
ogra_or alternatively make two snaps and have one share datas from the other17:05
bdxI see this, but how does the snap interface to the application code17:05
bdxcurrently I use a git-layer in my charms to pull in application code17:05
ogra_have a look at the content interface17:05
bdxI'm trying to understand what about my charms should become snaps17: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 interface17:06
bdxogra_: I see, so I could use the charm to handle the application code in that case17:07
ogra_when you upgrade your app snap it will automatically ship the updated code in that dir17:07
bdxI see ... so my application code is packaged with the snap then17: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 separated17:08
ogra_everything is possible ;)17:08
bdxtotally ... thats what make it so difficult17:08
bdxI feel like I need to be more educated on snaps to be making these decisions17: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 stuff17:09
bdxI'll work on that17:09
bdxyeah ... then have the charm deliver the application code17:09
ogra_there are no limits to creativity with snaps ;)17:09
bdxI think my problems moving forward will be knowing and understanding the framework here and what is available and how to use it17:10
ogra_right ... i guess thats a matter of playing around with it and learning its capabilities ;)17:11
jdstrandaquarius_: 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 example17:11
jdstrand foo:17:12
jdstrand  bus: session17:12
jdstrand  interface: dbus17:12
jdstrand  name: org.kryogenix.pick-colour-picker17:12
bdxpossibly 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 snapped17:12
Saviqkyrofa, https://github.com/snapcore/snapcraft/commit/d22880fdcee434a5e85c376e8f26c61a661231ce17:12
jdstrandaquarius_: see https://github.com/snapcore/snapd/wiki/Interfaces#dbus17:14
mvopedronis: always failing timer> yeah, I can make it just exit(0) instead, that will probably be fine17:17
pedronismvo: ah, ok17:17
Saviqkyrofa, bug #169476517:19
mupBug #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#L2317:21
aquarius_do i need to duplicate that "plugs" section as "slots"?17:21
mvopedronis: unless I'm missing something this is already the case: http://paste.ubuntu.com/24728381/17:22
pedronismvo: yes, sorry, I forgot:  if err != errOnClassic {17:23
kyrofapedronis, 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
mupPR snapd#3400: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400>17:23
pedroniskyrofa: Chipaca, looking17:24
kyrofa:) thanks17:24
mvopedronis: great, thanks for double checking17:24
pedroniskyrofa: Chipaca, done17: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
mupPR 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
jdstrandaquarius_: yes. and also yes, I don't have answers for the theme17:34
aquarius_jdstrand: no problem (the theme is not your thnig :))17:35
aquarius_jdstrand: just checking I was doing what you suggested17:35
=== cachio is now known as cachio_afk
seb128aquarius_, hey, just in case it's interesting to you, colourpicker fails to start from snap here with that error17:56
seb128  File "/snap/pick-colour-picker/x1/lib/python2.7/site-packages/pick/__main__.py", line 874, in start_everything_first_time17:56
seb128    self.w.set_default_icon(image.get_pixbuf())17:56
seb128TypeError: Argument 0 does not allow None as a value17: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
seb128aquarius_, could be, in any case it looks like the pixbuf might be None and your code doesn't handle that case18: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
seb128let me know if you need debug infos18:06
=== JanC_ is now known as JanC
niemeyerForum going down/up for a quick configuration update..18:26
niemeyerAlmost there.. aaaaaaan18:27
niemeyerd.. it's up!18:28
mupPR snapd#3418 opened: tests: prefer ipv4 over ipv6 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3418>18:33
seb128aquarius_, theme works here in devmode on xenial/unity18:43
niemeyerSMTP 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/htop18:55
ogra_cannot bind-mount the mount namespace file /proc/202/ns/mnt -> htop.mnt: Permission denied18:55
ogra_support process for mount namespace capture exited abnormally18:55
jdstrandogra_: I had a sneaking suspicion that mount, pivot_root and the like would be blocked by docker19:44
mupPR snapd#3419 opened: interfaces: partly revert aace15ab53 to unbreak core reverts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3419>19:50
mvojdstrand: I have another partial revert for you -^19:51
mvojdstrand: for you to review, we have a reliable test now and it breaks on this symbol now19:51
jdstrandoh sigh19:52
jdstrandall my arg filtering work keeps getting reverted19:52
=== cachio_afk is now known as cachio
jdstrandmvo: responded19:54
mvojdstrand: thank you!19:56
mvojdstrand: 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
cachioniemeyer, could you please update the https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz with the last version which has the repeat?20:07
niemeyercachio: Yeah, just not right now..20:13
niemeyercachio: Also, not sure how that helps?  I mean, -repeat is only useful locally I suppose?20:14
cachioniemeyer, I need to check the test is working in ci20:18
cachioniemeyer, because from my machine it always pass20:18
cachioniemeyer, not sure if it is because my connection is slower or why20:19
cachioniemeyer, so ,my idea is to repeat the execution 100 times in ci to check the fix works20:19
cachioniemeyer, does it make sense?20:20
niemeyercachio: Ah, yep20:23
niemeyercachio: Can't do that now, but will do20:23
niemeyerNeed to step out for a while20:24
mupPR 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!