[03:00] kyrofa, I think you've made the steps in snapcraft.yaml too magic [03:00] to me, prep, build, etc should be stages where you explicitly describe what it should do [03:01] rather than having to do the backwards thing of overriding default behaviors === chihchun_afk is now known as chihchun [05:05] Caelum: do you have more info? [05:07] morning [05:11] Hey [05:11] Maciej, can you please boot tumbleweed [05:11] If you have one [05:12] don't have one installed atm [05:12] Ah, ok [05:12] Ill check [05:12] what's with tw? [05:13] Something broke apparently [05:13] Just woke up, will check soon [05:14] PR snapd#5003 closed: cmd/snap-seccomp: graceful handling of non-multilib host [05:14] zyga: ok, let me know if you need help, i have a spare t60 i could try it on, though i don't remember if there's an hdd inside [05:15] I thought you have VMs on your beefy box :-) [05:15] zyga: cloud vms yes, graphical ones, not so much [05:36] re [05:41] PR snapd#5028 opened: cmd/snap-seccomp: graceful handling of non-multilib host (2.32) [05:44] trivial review ^^ [05:51] * zyga updates his opensuse tunmbleweed snapd to what is in system:snappy repo [05:55] Caelum: I cannot see any issue [05:55] please tell me what you experienced [05:59] mborzecki: can you look at https://github.com/snapcore/snapd/pull/4957 [05:59] PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation [06:00] 3rd review just to be sure [06:00] ok [06:05] * zyga -> breakfast [06:26] chihchun: tee-hee-hee [06:27] zyga: tee-hee-hee [06:27] I hope this boosts code reviews [06:28] zyga: I guess you pinged the wrong person [06:28] oh [06:29] sorry, yes [06:29] chipaca sometimes has a nickname similar to the one you use [06:29] I missed that :) [06:29] :) [06:31] morning mvo [06:31] zyga: good morning! how are you? [06:32] good morning, I'm not taking a longish walk today :) [06:32] so hopefully I'll make some code [06:40] zyga: :) [06:49] zyga: no reports yet about any issues with 2.32.3 afaict? [06:50] zyga: did you see anything? [06:50] no, nothing about 2.32.3 yet [06:54] mvo: hey, can we land #5028? [06:54] PR #5028: cmd/snap-seccomp: graceful handling of non-multilib host (2.32) [07:07] PR snapd#5028 closed: cmd/snap-seccomp: graceful handling of non-multilib host (2.32) [07:07] mvo: thanks! [07:08] np! 5026 needs a second review, very trivial [07:11] PR snapd#5026 closed: tests: add check for OOM error after each test [07:12] PR snapd#4987 closed: tests: add test to ensure `snap refresh --amend` works with different channels [07:12] mborzecki: 5024 looks very good, just some testing tweaks and it is golden === pstolowski|afk is now known as pstolowski [07:12] mornings [07:13] morning [07:13] hey [07:13] mvo: yes, thanks for you suggestions, i'll be pushing a patch soon [07:13] pstolowski: hello [07:13] and a second look at 5020 would be great, sorry for being pushy, want to get the SRU out this morning :) [07:13] hey pstolowski [07:17] good morning [07:17] hey ho [07:17] o/ zyga [07:19] PR snapd#4845 closed: snap, store: store version numbers in the commands database [07:20] mborzecki: curious why is 4942 marked as blocked? it looks like its ready to go in, no? modulo the small ugliness in the journal but thats ok IMO for now [07:21] mvo: heh, forgot about the label :) let me fix that [07:21] mvo: squash merge right? [07:24] mborzecki: yes please [07:27] PR snapd#4942 closed: cmd/snap: user session application autostart v3 [07:34] PR snapd#5029 opened: cmd/snap: user session application autostart v3 (2.32) [07:34] PR snapd#5030 opened: packaging/amzn2: initial packaging of 2.32.3 for Amazon Linux 2 [07:35] need more coffee [07:35] PR snapd#5020 closed: errtracker: check for whoopsie.service instead of reading /etc/whoopsie [07:37] mborzecki: question about 5030, why are we using /var/lib/snapd/snap there? [07:38] zyga: it's very rhel like and also lists `ID_LIKE="centos rhel fedora"` in /etc/os-release [07:39] so just because? [07:39] zyga: yeah, we already have the right switches to cover rhel/fedora [07:40] sure but we can add a new distro to the list [07:40] and just use /snap [07:41] PR snapd#5031 opened: errtracker: check for whoopsie.service instead of reading /etc/whoopsie (2.32) [07:43] zyga: no strong opinions here, this just saves vetting DistroLike switches and there's one rpmlint warning less [07:43] I'd go for /snap [07:49] mborzecki: added three comments [07:49] zyga: thanks [08:01] willcooke: hey, there's an issue that skype crashes wayland on startup [08:01] is that something on anyone's radar on your team? [08:02] zyga, oh, no, not something I was aware of [08:03] zyga: why do you torture yourself with wayland :-) [08:03] willcooke: just login into wayland ssh in and look at the journal [08:03] run Skype and boom [08:03] Chipaca: x11 corrupts screen on my thinkpad [08:03] Chipaca: not sure why, wayland works better for that [08:03] (apart from taking down gnome-session when things go) [08:03] zyga: intel board? [08:03] popey: ping [08:03] Chipaca: my thinkpad [08:04] om26er: good morning [08:04] good day popey :) [08:04] om26er: I spoke to the store team, turns out we cannot rename snaps, so we should publish s-t and remove s-t-3 [08:04] zyga: btw is the fix for #1760841 in a core already? [08:04] Bug #1760841: snapd does not parse /etc/fstab properly when using mhddfs [08:04] Chipaca: yes, it's in .3 [08:05] aha [08:05] popey: so lets merge that one then ? [08:05] well actually my current "ping" was for https://github.com/snapcrafters/android-studio/pull/19 :) [08:05] PR snapcrafters/android-studio#19: Fix app startup based on latest snapcraft changes [08:08] popey: android studio release that we pushed yesterday won't start so this fixes it [08:09] speaking of which, I think if we(I) enable the CI for that snap, we won't have that kind of issue again. [08:10] "build and try to run" [08:17] Chipaca: some comments on 5027 [08:17] and sorry for the branch summary change ;) [08:18] lol :D [08:18] 10 best patches you read this week [08:22] zyga, confirmed. LP: #1762954 [08:22] Bug #1762954: Running the skype snap under the Wayland session crashes the whole session

[08:22] thank you! [08:22] np, thanks for the ping [08:23] probably a good chunk of our users will just use wayland for some reason and will bump into this [08:24] thanks for the review on 4957 [08:24] I'll get right to it [08:31] willcooke: zyga: FWIW I think there's already a bug for that issue [08:31] or is it an issue for that bug [08:32] ah, maybe i'm thinking of https://forum.snapcraft.io/t/skype-crashes-gnome-on-ubuntu-18-04/4927 [08:33] PR snapd#5031 closed: errtracker: check for whoopsie.service instead of reading /etc/whoopsie (2.32) [08:35] or https://forum.snapcraft.io/t/vs-code-makes-shell-crash/4362 [08:36] willcooke: zyga: from that last one, https://bugs.launchpad.net/snappy/+bug/1760252 [08:36] Bug #1760252: starting slack crashes xwayland on 18.04 [08:36] so generally classic snaps then [08:36] on wayland [08:36] i mean, it's wayland (or xwayland?) that crashes [08:36] maybe bundled lib input? [08:37] yeah, was just looking at that, seems like it could be xwayland [08:37] * willcooke uploading stack traces [08:37] it was xwayland from what I've seen [08:38] call me ornery but imo if a client can crash wayland, there might be a bug in the client but there is a bug in wayland [08:38] one or two [08:38] :-) [08:38] zyga: sorry, looks like the problem disappeared [08:39] no worries, what was the problem? [08:39] snaps weren't starting from gnome app menu [08:42] k, hopefully LP will do some retracing and I will tidy up all the various bugs once that's happened. [08:42] Off to the office now, will be back later on [08:42] sure, thank you willcooke [08:42] willcooke, you are on a wayland session? [08:43] seb128, I was to test that [08:43] oh, k [08:43] thx [08:52] * Chipaca is off to the dentist's. ttfn! [09:09] om26er: ok. === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:46] PR snapd#4957 closed: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation [09:46] PR snapd#5032 opened: repo: pass and return ConnRef via pointers [09:47] pstolowski: why by pointer? [09:48] zyga: to save on passing, that was pointed out by pedronis in interface hooks review [09:54] mvo: is .4 ready? [09:55] zyga: .3.1 [09:56] zyga: yes it just got pushed to xenial-proposed and once my test builds finished also to the other releases [09:56] 3.1? is that a deb only or a real upstream release? [09:56] zyga: its pretty small and *finally* use git-buildpackage which makes me incredible happy [09:56] nice, thank you! [09:56] zyga: its deb only but we could still put it into the beta channel for consistency [09:57] is that only the OOM thing? [09:57] zyga: either way .4 needs to wait a little bit until we are sure we don't need to do anything for 2.32.3, i.e. no regressions [09:57] zyga: a little bit more, one sec [09:57] should it be on releases page on GitHub? [09:58] zyga: https://github.com/snapcore/snapd/blob/2.32.3.1/packaging/ubuntu-16.04/changelog [09:58] mvo: let me know when you push the tag [09:58] zyga: probably, I'm a bit hesitant because .4 will happen soon and I don't want to put too much burden on the downstream packagers but otoh I think its more correct to have a release on GH [09:58] zyga: it is pushed [09:58] I can drop it on the release page [09:59] thanks! [09:59] zyga: also the release script can now be simplified because the orig.tar.xz is sane now (snapd-2.32.3.1) [09:59] whee, good [10:00] so orig.tar.gz doesn't need renaming internally [10:02] zyga: yeah, I upload the file to the ppa in a sec [10:06] mvo: we should discuss at the standup when to cut .4 [10:07] pedronis: +1 [10:07] pedronis: my strawman would be tomorrow morning [10:07] pedronis: but happy to discuss [10:16] 14.04 journalctl, no --show-cursor, no --after-cursor, no --identifier, damn [10:19] yeah [10:19] lack of cursor sucks [10:19] does anyone mind not running user session app autostart spread test on 14.04? [10:22] it's fine, 14.04 was supposed to be server-only [10:28] mvo: want me to look into #5029? [10:28] PR #5029: cmd/snap: user session application autostart v3 (2.32) [10:39] mborzecki: want to look at https://github.com/snapcore/snapd/pull/5033 [10:39] PR #5033: cmd: generalize locking to global, snap and per-user locks [10:39] it's very straightforward [10:39] PR snapd#5033 opened: cmd: generalize locking to global, snap and per-user locks [11:07] PR snapd#5034 opened: userd: set up journal logging streams for autostarted apps [11:14] mborzecki: hey, how do we go vendor stuff in fedora? it's seems to be the only one unhappy about my new dependencies (go-udev..)? [11:15] pstolowski: which pr? [11:15] pstolowski: we package [11:15] mborzecki: https://github.com/snapcore/snapd/pull/4940 [11:15] PR #4940: RFC: added UDevMonitor for future hotplug support [11:16] zyga: package as separate rpm for every go package we need? [11:16] pstolowski: package according to the way we need to in fedora, yes [11:16] pstolowski: btw. do have a solution for go-dev already? other deps from from rps [11:17] and iirc go-udev was not packaged for fedora yet [11:17] mborzecki yes, that's very probable, it's a small and not very popular project i think [11:17] gofed is pretty nice [11:18] zyga. mborzecki ok, if that's the case then I think I need a general +1 on the PR first before investing time into packaging (it's ~3 go packages as go-udev pulls others) [11:18] anyways i think the tests were using vendored deps on fedora [11:19] pstolowski: do you know what the transitive deps are? govendor list -v should show it [11:28] mborzecki, they'd better not be [11:28] I delete the vendor directory in prep [11:29] I've already had that happen once and found out that we were testing Fedora wrong [11:29] Son_Goku: yeah, saw that, i'm thinking of something to just unblock spread in that pr [11:29] or maybe we should just package go-udev for fedora and submit it for review [11:29] if you package the godeps, I'll review and merge them into the archive [11:30] as zyga knows, I can be very fast with go package reviews [11:30] yes [11:30] and go deps are easy to package because the gofed tool does nearly all the work [11:31] i can probably take a look, unless pstolowski you want to give it a 'go' :) [11:32] mborzecki: happy to do it, although as I said perhaps it makes sense to get general +1 on using go-udev first, because it hasn't been decided yet [11:33] dependencies aren't free :) [11:33] pstolowski: hm thought we were already good with using it [11:35] PR snapcraft#2058 closed: python plugin: install python-distutils when run on bionic [11:35] mborzecki: I'm not sure, Gustavo hasn't yet commented on the branch (and on the HLD) [11:36] Son_Goku: thanks for the hints! [11:37] gofed is in .... python? [11:37] yes [11:37] most of Fedora tooling is in Python [11:37] most of openSUSE tooling is in ruby :P [11:38] and most of Debian tooling is in Perl [11:47] PR snapcraft#2062 closed: packaging: simplify snapcraft.yaml [11:57] Son_Goku: gofed generates a busted spec, https://paste.debian.net/1019710/ there's no newline after %changelog [11:58] I know :/ [11:58] the changelog entry is also wrong [11:59] other than that the rpm gets built :) [12:01] off to pick up the kids, coming back for standup [12:02] cachio: mvo: I'm looking again at tests again staging, seems we need to copy canonical-livepatch to staging, and test-snapd-only-in-edge [12:03] we probably want to copy core from edge to edge as well [12:07] pedronis, sure,I'll do it [12:08] cachio: once we have solved the cred problems with spread-cron, we should revisit the various store tests branches there and add back staging I think [12:08] pedronis, ok, we could have a nightly exec [12:08] I think we could trigger on store deploys [12:09] but we'll see [12:09] probably next week at this point [12:09] ok [12:25] whoo, dentist anesthetic waring off [12:25] * Chipaca is not having fun [12:25] wearing off* [12:41] pedronis, my internet is so slow today [12:41] it is taking long time to upload the core === sergiusens_ is now known as sergiusens [12:59] pedronis, snaps ready [13:03] pedronis: standup? [13:13] something new: 2018-04-11 11:08:43 Cannot allocate linode:fedora-27-64: cannot allocate new Linode server for fedora-27-64: no open slots for this plan!t [13:25] pstolowski: sorry, i've just restarted the travis build in 4940 [13:32] mborzecki: np, it's going to fail unless you pushed something to the branch? [13:33] pstolowski: no, i did not, it's going to fail ;) [13:33] ok ;) [14:11] mvo: should I squash-merge #5002 given that it has many commits? otoh it means that the next two might need to be changed because of conflicts with the squash [14:11] PR #5002: many: use the new install/refresh /v2/snaps/refresh store API (2.32) [14:11] pedronis: no squash please [14:11] ok [14:11] pedronis: this will be a super messy merge back otherwise [14:12] pedronis: thanks [14:13] PR snapd#5002 closed: many: use the new install/refresh /v2/snaps/refresh store API (2.32) [14:13] mvo: merging [14:14] PR snapd#5022 closed: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps (2.32) [14:16] mvo: my 2.32 stuff is merged [14:16] PR snapd#5021 closed: overlord/snapstate: introduce envvars to control the channels for bases and prereqs (2.32) [14:18] pedronis: thank you [14:19] mborzecki: 5029 needs a review - just double checking that its the right commit etc [14:20] PR snapd#4840 closed: many: add `core.problem-reports.disabled` option [14:26] * cachio afk [14:29] PR snapd#5029 closed: cmd/snap: user session application autostart v3 (2.32) [14:39] Wimpress and kenvandine does this (https://forum.snapcraft.io/t/snap-application-and-snap-themes/4946) not somewhat align with what was discussed around a month ago? That theme does a bit more, I'll let you comment on that though :-) [14:46] sergiusens, yes, i replied with a link to jamesh's post [14:49] PR snapd#5035 opened: release: snapd 2.32.4 [15:01] Chipaca: hey, could you look at https://github.com/snapcore/snapd/pull/5033 [15:01] PR #5033: cmd: generalize locking to global, snap and per-user locks [15:01] nothing major [15:03] kenvandine: your the man! [15:03] 're [15:12] who fancies digging into snapcraft? https://forum.snapcraft.io/t/error-while-building-argument-list-too-long/4948 [15:14] diddledan, yuck [15:14] I aim to please :-p [15:14] diddledan, can you try on edge? [15:14] I did [15:14] the second paste [15:14] diddledan, scriptlets give better errors there [15:14] Oh [15:14] * kyrofa scrolls down further [15:15] Dang, still not helpful [15:16] diddledan, but yeah, I'll own this one [15:16] yey [15:16] did you look at the yaml yet? ;-) [15:16] a mere snip at 1350 lines [15:16] diddledan, no, you're scaring me [15:16] * kyrofa cries [15:17] haha [15:17] * diddledan cuddles kyrofa [15:17] diddledan: hey, at least three of those lines are comments now [15:18] :-p [15:25] diddledan, ignoring the actual cause, the fact that this is so opaque is problematic. In an ideal world, how would this be presented to you? [15:25] well to begin with I think actually telling me what command was being executed would help me to understand what it's doing when it fails === chihchun is now known as chihchun_afk [15:26] at least then I'd be able to determine whether there is a workaround while the problem gets fixed [15:28] I guess it would also help me discern whether it's my fault with wonky build configuration or an endemic problem with snapcraft itself [15:29] zyga: is #5033 part of not landing new stuff? [15:29] PR #5033: cmd: generalize locking to global, snap and per-user locks [15:29] Chipaca: it was proposed in the morning [15:33] pstolowski: Do you want to have a call in a few mins to discuss it? [15:33] haha, but that was posted in the morning [15:33] :) [15:33] no more newies [15:34]