[00:11] kyrofa: ... ok [00:11] sergiusens: if you can confirm, i can do it [00:24] kyrofa: thannks, i see it in the snapcraft yaml and also saw it earlier with conjure-up. Will try that! [00:57] kyrofa: ok, now i'm confused, if i build my own python != ubuntu python (e.g., 3.6 instead of 3.5 in xenial), how do i ensure the parts that depend on it use that python? it seems like it's usinng the packaged python3 to build the modules === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [05:35] kyrofa: shoot! [05:36] kyrofa: I'm on the west coast for the week, not watching IRC much though === lool- is now known as lool [05:47] PR snapd#3967 closed: release: release snapd 2.28 [05:47] PR snapd#3969 closed: hooks: rename refresh hook to post-refresh === Mirv_ is now known as Mirv [05:50] PR snapd#3968 closed: daemon: use client.Snap instead of map[string]interface{} for snaps [05:51] PR snapd#3962 closed: tests: Increase SNAPD_CONFIGURE_HOOK_TIMEOUT to 3 minutes to install real snaps [05:52] PR snapd#3960 closed: travis: switch to container based test runs === JoshStrobl|zzz is now known as JoshStrobl [06:32] * zyga-ubuntu -> breakfast [07:24] * zyga-ubuntu bisects snap-seccomp regression [08:20] doko: hey [08:21] doko: not sure if you are at the rally or at home [08:21] doko: I ran into something that I don't understand and I think you could shed some light on it [08:21] doko: I summarized the problem here: https://forum.snapcraft.io/t/snap-seccomp-fails-tests-on-artful-is-it/2263/4?u=zyga [08:21] doko: a small test program doesn't compile [08:21] doko: and fails with the following error [08:21] /usr/include/stdlib.h:25:10: fatal error: bits/libc-header-start.h: Nie ma takiego pliku ani katalogu [08:21] (no such file or directory, sorry about that last fragment) [08:31] * zyga-ubuntu moves to another task, not sure how to do this === JoshStrobl is now known as JoshStrobl|Work === dasjoe_ is now known as dasjoe === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:21] PR snapd#3970 opened: interfaces/mount,cmd/snap-update-ns: move change code [09:31] man, this is a lonely week here [09:39] "Issues while validating snapcraft.yaml: Additional properties are not allowed ('grade', 'confinement' were unexpected)" in snap classic [09:39] can anybody help [09:41] Neeraj: hey [09:41] Neeraj: drop grade, I think it's not used anymore [09:41] Neeraj: what was the value of "confinement"? [09:42] confinement is "strict" [09:42] Neeraj: not sure what the latter part of the message is about [09:43] try again and tell me what you get [09:43] Issues while validating snapcraft.yaml: Additional properties are not allowed ('confinement' was unexpected) [09:44] is it ok to drop confinement [09:44] (classic)admin@GTXQB02:~/TSE$ snapcraft Issues while validating snapcraft.yaml: Additional properties are not allowed ('confinement' was unexpected) [09:44] I am in classic mode [09:45] Neeraj: what do you mean you are in classic mode? [09:46] --beta --devmode classic [09:47] Neeraj: do you mean that the snap you've installed is in that mode and that somehow affects how it validates in snapcraft? [09:47] yes [09:48] zyga-ubuntu : is you are correct [09:49] zyga-ubuntu: snapcraft executes only in classic mode [09:50] Neeraj: hmm, I doubt that how snapcraft is installed affects how it validates other snaps [09:51] Neeraj: in any case, I'm not a snapcraft developer, please ask when US wakes up :/ I don't know what the problem might be [09:51] Neeraj: if you pastebin the snapcraft.yaml and open a forum thread it will be easier to get an answer in other timezones [11:29] PR snapd#3971 opened: interfaces/mount: make Change.Perform testable and test it [12:30] o/ [12:43] * zyga-ubuntu -> break [12:45] >_> [13:51] <__chip__> zyga-ubuntu: good morning sah [14:19] sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5 [14:19] Bug #1598309: The aplay command doesn't work [14:21] sergiusens: fyi, two people in this room hit this issue and were annoyed by it, in fact, considering classic confinement [14:46] zyga-ubuntu: o/? [14:50] sergiusens: https://forum.snapcraft.io/t/snap-and-executable-stacks/1812 [14:51] Chipaca: hey [14:51] Chipaca: how are things? [14:52] jdstrand: hello [14:52] sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1719928 [14:52] Bug #1719928: snapcraft update won't fetch from SNAPCRAFT_PARTS_URI [15:05] PR snapd#3972 opened: repo: sanitize plugs and slots early in ReadInfo [15:08] zyga-ubuntu: hi. Thanks for the review of my user-mounts PR. There were a few change suggestions (moving code to snap-update-ns, persisting mount namespaces, etc). Want to discuss? [15:08] jamesh: hi [15:08] jamesh: yes! [15:08] jamesh: I think mvo was trying to set up a hangout [15:09] jamesh: can you guys get together and join, say, the daily standup HO? === chihchun is now known as chihchun_afk [15:09] zyga-ubuntu: mvo said he didn't necessarily need to be in the hangout. Let me find some place quiet [15:09] aha, that's fine [15:10] I'm ready as you are, just give me the word [15:26] https://github.com/snapcore/snapd/pull/3973 [15:26] PR #3973: cmd/snap-confine: put processes into freezer hierarchy [15:26] PR snapd#3973 opened: cmd/snap-confine: put processes into freezer hierarchy [15:29] kalikiana_: http://www.proli.net/2017/05/23/kdevelop-runtimes-docker-and-flatpak-integration/ [15:36] PR snapd#3974 opened: Recognise Solus as a classic Linux distribution [15:38] ikey: thank you! [15:38] np bud [15:39] more to come probably [15:39] we need snapd/polkit for the solus SC to work [15:39] so im taking us to git which means making git support solus :P [15:40] i considered changing the conditional to if distro == ubuntu but then i remembered everyone mangles their os-release/lsb_release for branding .. [15:40] "taking us to git" ? [15:40] taking solus snapd package to git in unstable [15:40] vs released pkg [15:40] so that i can get SC working [15:40] zyga-ubuntu: this check really needs to be reworked [15:40] Son_Goku, it would break ubuntu derivatives that rebrand [15:40] and others [15:40] i had the same thought [15:40] but i dont see it as viable [15:41] which is why its "explicitly not ubuntu" vs "is ubuntu" [15:41] ikey: well, if we check for ID and ID_LIKE for particular values to enable ubuntu-ish behavior [15:41] assuming derivs arent derping that already [15:41] then default to not enabling ubuntu-ish behavior, it's more likely to work properly [15:41] and im not aware of many using ID_LIKE [15:41] tbh [15:42] most derivatives of the major distributions use ID_LIKE [15:42] yknow what'd simplify it all together? [15:42] for example, even RHEL identifies as "like Fedora" [15:42] if the snapd package in the repos contains a file saying a reexec is OK [15:42] ikey: runtime detection? :) [15:42] so its determined at packaging level [15:42] and all derivs implicitly use it [15:42] unless they repackage [15:42] ikey: in Fedora, I do that for re-exec [15:43] that's the /etc/sysconfig/snapd [15:43] because otherwise derivatives are busted [15:43] stateless it! :P [15:43] lol [15:44] well, I was talking to mvo earlier about making it so snapd didn't depend on environment variables to do this [15:44] and instead read a config file in /etc/ and in /usr/share [15:44] * ikey likey [15:44] (with /etc/ overriding /usr/share values, obviously) [15:44] :D [15:44] well, this scheme is something we've been moving to as a whole in Fedora [15:44] ah good [15:44] it's why we don't recommend doing dumb things like using environmentfiles [15:45] heh [15:45] but the Go community explicitly recommends controlling by environment files [15:45] and then systemd was like hey - lets reinvent pam_env xD [15:45] well, at least the pam_env works with packager -> override by admin model [15:45] mm [15:45] err, the systemd version [15:45] the pam_env doesn't [15:45] ya no that ones bork [15:45] everything lives in bloody /etc [15:46] my ideal is that /etc/ would be drained of things shipped by packages [15:46] yeo [15:46] *yep [15:46] i think we need to align all distros on the new wheres though [15:46] in clr and solus we went for /usr/share/defaults for renamespaced config fallbacks [15:46] and if sensible, /usr/share/$pkg [15:47] like pulseaudio [15:47] ikey: I was starting to use /usr/share/$pkg/sysconfig [15:47] ew [15:47] its not config :p [15:47] well, it is [15:47] its default stuff lol [15:47] (oh we also use /usr/share/xdg/* ) [15:47] well, the idea is that /etc/sysconfig would override /usr/share/*/sysconfig [15:47] plus having a single namespace is nicer for tooling [15:47] /usr/share/defaults/* [15:48] though if I could have my way, I'd flip it to /usr/share/sysconfig and /etc/sysconfig as the override [15:48] yeah [15:48] easier for autotools too tbh [15:48] yeah [15:48] the reason I didn't call it defaults is because in many cases, applications don't support partial overrides [15:49] shpose [15:49] and that the whole config files have to be overridden [15:49] a lot of our stateless patches end up being something like: [15:49] const char *cfg = NULL; [15:49] if (access(SYSTEM_CONFIG, F_OK) == 0) { [15:49] cfg = SYSTEM_CONFIG; [15:49] } else { [15:50] cfg = VENDOR_CONFIG; [15:50] } [15:50] In a nut shell ^ [15:50] right [15:50] and that does make sense [15:50] older applications are harder to do merges on [15:50] and that's pretty much why I went with sysconfig as the directory name [15:50] yeah [15:50] IMO, it's more obvious to people what it means [15:50] reason i disagree with the name is because the relation to SYSCONFDIR [15:51] ah [15:51] When there is the mental separation of sys vs vendor [15:51] I didn't think of that [15:51] or rather, os / data [15:51] right [15:51] + config [15:52] its a tough one for sure but id love for us all to go the same path [15:52] whatever that path is [15:52] and then start prodding all the relevant projects to follow [15:52] so another thought I had was /usr/share/vendorcfg [15:52] and /etc/sysconfig for the admin version [15:53] but I didn't like that so much because it's not as obvious for the mental map [15:53] as long as the package upstreams are onboard with the possibility of their vendorcfg being replaced by us [15:53] which is the issue i guess [15:53] we're the vendors they're the upstreams [15:53] yeah [15:53] well, the idea is that /etc/sysconfig is where users make their own configs [15:53] right [15:53] local sysadmin [15:53] and /usr/share/vendorcfg is where the packages ship them [15:54] (you can see why we ended up with 'defaults' eh? :P) [15:54] yeah [15:54] tbh its almost like "fallback" is the more appropriate term [15:54] I threw away that name almost immediately because the implications that the name has [15:54] just sounds lame [15:54] yer [15:54] naming things is hard :) [15:54] oh dont i know it [15:55] * ikey is the author of such wonders as 'Dave2' and 'libthingamabob' [15:55] https://bugs.launchpad.net/snapcraft/+bug/1590599 [15:55] Bug #1590599: snapcraft prerequites are slow to resolve [15:56] * ikey looks at related snapcraft pull and hugs ypkg [15:57] ikey: thinking of adding a snapcraft backend for ypkg? :-D [15:58] kyrofa: sorry to bother, but did you see my last messages from yesterday? how do I ensure that if I have a python3 part (e.g., for 3.6.2, while xenial has 3.5.x), that the subsequent parts use that python? (otherwise, there doesn't seem to be any modules installed by the subsequent part for 3.6) [16:04] davidcalle, hrm .. all the links at the bottom of https://docs.ubuntu.com/core/en/reference/gadget#examples-of-production-ready-gagdet-snaps are wrong ... [16:05] ogra_: ok, what are the more recent ones? [16:06] davidcalle, they are on GH ... i'd open a PR but that page doesnt seem to be in https://github.com/CanonicalLtd/ubuntu-core-docs/tree/master/en/guides/build-device [16:06] boo [16:07] because i'm in the wrong dir :P [16:07] ogra_: https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/reference/gadget.md [16:07] :D [16:07] yeah, got it [16:07] kalikiana_, probably could [16:07] emit .snap's easily enough [16:07] id leave it until i have a solus base snap though [16:08] stokachu: --^ you might have a comment on my earlier point. As I thinkn you also have 3.6.2 in your snap as a part [16:09] also, why does `snapcraft pull` build stuff. [16:10] SNAPCRAFT_PARTS_URI=http://metadata.neon.kde.org/snap/parts.yaml [16:10] git://anongit.neon.kde.org/applications/kate.git [16:12] kyrofa: fwiw, if the 'fix' is to build python in a classic snap, that should be a hard requirement (it seems like this is 'known')? [16:12] sergiusens: --^ [16:13] augh, no zyga now :-( [16:13] niemeyer: https://github.com/snapcore/snapd/pull/3964/files#diff-784fe30c70e6724012b7d456d65d97acL152 [16:13] PR #3964: many: implement our own ANSI-escape-using progress indicator [16:14] niemeyer: :-D but also :-D [16:15] davidcalle, https://github.com/CanonicalLtd/ubuntu-core-docs/pull/37 [16:15] PR CanonicalLtd/ubuntu-core-docs#37: point to proper repos for gadget examples [16:16] ogra_: merged, thanks [16:16] <3 [16:20] PR snapd#3975 opened: snap-confine: Only attempt to copy/mount NVIDIA libs when NVIDIA is used [16:28] kalikiana_: https://gitlab.com/Conan_Kudo/snapcore-mkrpmtree & https://gitlab.com/Conan_Kudo/snapcore-mkrpmtree/pipelines/12211338 [16:28] :D [16:30] kyrofa: nm on the how to use the staged python, PEBKAC [16:33] kalikiana_: https://bugs.launchpad.net/snapcraft/+bug/1719951 [16:33] Bug #1719951: SNAPCRAFT_PARTS_URI doesn't work with cleanbuild [16:58] ogra_ ping [17:00] PR snapd#3976 opened: snap-confine: Support biarch Linux distribution confinement [17:24] PR snapd#3977 opened: interfaces: Enhance full-confinement support for biarch distributions [17:34] alright folks, how do i request a 2 track snap repo? [17:37] PR snapd#3978 opened: cmd: Correctly name the "Ubuntu" and "Arch" NVIDIA methods [17:42] ondra, moop [17:48] jdstrand: if you could have a quick look at https://github.com/snapcore/snapd/pull/3979 that would be great [17:48] PR #3979: snap-confine: update apparmor rules for fedora based base snaps [17:48] PR snapd#3979 opened: snap-confine: update apparmor rules for fedora based base snaps === JanC_ is now known as JanC [18:02] looks like 3979 is covered by my PR [18:02] more completely [18:03] conflicts at least. :p [18:03] (3976) === Son_Goku is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku [19:08] Chipaca: hey [19:08] how's stuff in NYC? [19:08] zyga-ubuntu: hi! [19:08] zyga-ubuntu: not bad [19:09] I saw your PR, neat stuff [19:09] zyga-ubuntu: i pinged you yesterday and then was busy when you got back to me [19:09] oh, what about? [19:09] yes, i'm addressing your review now, thank you [19:09] :-) [19:09] travis is a bit slow today [19:10] zyga-ubuntu: I'm geting a "cannot perform operation: mount --bind yadda/yadda/etc/alternatives: permission denied" [19:10] zyga-ubuntu: so I thought maybe you'd know what i broke :) [19:11] zyga-ubuntu: (my base does have etc/alternatives) [19:12] Chipaca: yes, it's a non-generalized rules [19:12] *rule [19:12] Chipaca: can you show me the real denial (dmesg | grep DENIED) [19:12] Chipaca: I thought we fixed that, if not I can correct quickly if you confirm [19:12] zyga-ubuntu: PM [19:13] Chipaca: I had a productive day today so there's a few things up there but I'd like one thing merged [19:13] ack [19:14] https://github.com/snapcore/snapd/pull/3966 [19:14] PR #3966: cmd/snap-seccomp,osutil: make user/group lookup functions public [19:14] I'd love to land this so that I can iterate [19:14] Chipaca: I'll get some tea and propose a PR for that [19:20] a PR for tea ... mmmm === genii_ is now known as genii [19:36] jdstrand: hey, tools r934 are in production now. [20:29] is there a 'best practices' for testing snaps as-installed? [20:48] PR snapd#3980 opened: snap-confine: Ensure lib64 biarch directory is respected [20:49] nacc, not really, since it depends on what the snap is [20:49] nacc, for a webapp, I like running a capybara suite against it [20:50] kyrofa: e.g., we have dep8 that understands (from the src) how to run tests. It feels like we should have something, perhaps onnly for classic snaps, that allows a pivot to the classic and run a test suite [20:50] *to the classic snap [20:52] nacc, that might make sense to do as the part is being built, but perhaps less sense once the snap is assembled, as things might be completely reorganized and contain _several_ parts [20:52] kyrofa: yeah that's possibly true [20:53] i guess i also think there are some apps taht are being built, and the expectation is some behavior on them, e.g., asserted with unit tests. It would make sense to make it 'easy' to test in the snap as-installed, that the behavior is what you want [20:53] nacc, and I'm not sure how much sense it makes on a whole. For example, consider the Nextcloud snap. I'm not really interested in running MySQL's test suite, or Apache's [20:53] sure [20:53] But I sure want to test that the whole thing works in concert [20:53] Which is a different set of tests [20:53] but let's say you want to know that mysql accepts your statements, via a unit test. [20:53] yeah, I think we're actaully saying the same thing :) [20:54] But I can't even communicate with mysql from outside the snap. If mysql's unit tests don't pass I have other problems [20:54] You need some sort of higher-level acceptance tests [20:54] in classic you could, right? [20:54] i'm referring to classic in my case [20:54] i agree with confined snaps it's not easy to solve [20:54] or it's too snap-specific [20:55] nacc, so you're thinking you would bundle some sort of tests in the final snap? [20:55] yeah [20:55] that is intended to run in the same env as the sanp [20:55] and runs the tests in that env [20:56] nacc, that doesn't bloat the snap? [20:56] classic snaps are *really* easy to break [20:56] :) [20:56] Hahaha [20:56] with mixed hosts [20:56] (mixed = not all the same host OS) [20:56] nacc, so sort of a "am I sane" app [20:56] yeah, exactly [20:56] it's like a self-check [20:56] i guess that's what i can do [20:56] .selftest [20:56] i have the tests in my source [20:56] yep [20:57] kyrofa: thanks! that's a godo idea [20:57] nacc, seems reasonable! [20:57] rbasak: --^ [20:57] nacc, I'm not sure I'd call it general guidance, but if that seems doable for your snap I think it seems nice a nice idea [20:57] Uh. seems like a nice... you get the idea [20:57] So braindead :P [20:58] kyrofa: yeah, it might not be generally useful. I think classic snaps need it more than confined. classic's runtime is far less well-defined [20:58] nacc, are you at the rally, by the way? [20:58] kyrofa: unfortunately not [20:58] nacc, agreed [20:58] nacc, darn, would have liked to meet [20:58] i'd be in the snappy room yelling otherwise :) [20:58] Ha! [21:01] im having issues with snap-update-ns from snapd git [21:02] snap-update-ns failed with code 1: No such file or directory [21:02] leaving note more as a reminder to myself tomorrow to bring it up [21:06] zyga-ubuntu: https://bugs.launchpad.net/snappy/+bug/1719747 [21:06] Bug #1719747: Fedora 26 LXD container: cannot load apparmor profile [21:08] PR snapd#3960 opened: travis: switch to container based test runs [21:08] roadmr: oh! yay :) [21:09] oSoMoN: ^ (14:36 < roadmr> jdstrand: hey, tools r934 are in production now.) [21:09] roadmr: thank you :) [21:09] oSoMoN: that has the chromium fix [21:09] jdstrand: np! we did an unrelated rollout but the tools update piggybacked on it :) [21:09] music to my ears :) [21:09] I <3 piggybacking [21:10] jdstrand, yeah I noticed, my latest build went through without the need for a manual review, thanks! [21:12] whee :) [21:33] ogra_: fyi, the issue with avahi is that ond ra uploaded the snap ahead of the feature that allows it to work. aka, update to 2.28 and it works fine [21:33] ogra_: I'm letting Til know now === JoshStrobl|Work is now known as JoshStrobl|zzz [21:56] PR snapd#3979 closed: snap-confine: update apparmor rules for fedora based base snaps [22:05] ow. my PR up in flames. :P [22:16] PR snapd#3981 opened: release: 2.28.1 [23:28] ikey: +1 for including "whereby" in a pr