=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:07] o/ [06:08] good morning [06:08] hey zyga [06:08] hey :) [06:09] zyga: mvo: morning guys [06:09] good morning [06:09] hey mborzecki [06:10] mborzecki: please wait on the opens use review, I found some things to change last night that I didn't address yet [06:10] zyga: ok [06:16] zyga: your opensuse build update shows "+ echo 'Package build incorrect, '\''snap --version'\'' mentions '\''unknown'\'''" [06:16] zyga: in the spread tests [06:16] yeah, I saw that [06:17] that's what I meant :) [06:17] ok [06:17] zyga: oh, sorry, missed that I guess [06:17] it works fine in casual testing but I wanted to see spread run before releasing this [06:17] no worries, thank you for looking === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:35] https://github.com/snapcore/snapd/pull/6094 could use another review [07:36] PR #6094: wrappers: fix generating of service units with multiple `before` dependencies [07:36] then we can land it and pick it for 2.36 [07:49] yep [07:51] mborzecki: interesting, in my local build I see the correct version on "snap version" [08:07] good morning! === chihchun is now known as chihchun_afk [08:09] --debug session shows unknown [08:09] so odd, let's see why [08:10] ah [08:10] because of how we build in spread [08:11] normal builds are fine [08:14] hm i'm debugging why #5896 spread test for device keys seeminglly doesn't work [08:14] PR #5896: snapcraft.yaml: set grade to stable [08:15] the test snap finds a device /dev/input/by-path/platform-i8042-serio-0-event-kbd which as it turns out has all the attributes that make it match with device-buttons interface :/ [08:23] hm no it doesn't match, but the snap can still access it [08:24] zyga: any clues, there's a device /dev/input/event2 maj:min is 13:66, it's not listed in devices.list for that snap, but when running under --shell i can still open it [08:36] mborzecki: _hmm_ [08:36] mborzecki: when you open shell can you see the process listed in the control group? [08:38] zyga: heh, no cgroup.procs is empty [08:39] what system is that? [08:39] is that devmode system? [08:39] zyga: 18.04 [08:40] that's interesting [08:40] ah [08:40] well [08:40] there's this one old odd behavior [08:40] if you have no device tags for a given security tag [08:40] then we don't use cgroups [08:40] no tagging == no device cgroup [08:42] zyga: sounds like a problem, with this interface you could get access to all /dev/input/* [08:43] yes, it feels like we should make it unconditional [08:43] can you check if that's still the case [08:43] the code is in snap-confine/ in udev-support AFAIR [08:45] zyga: feels like this is going to be fun, i need some coffee first [08:47] uh, I forgot about dentist appointment [08:47] need to go [08:50] pstolowski: quick question: we only run the post-refresh hook on refreshes, right? not on a fresh install? so if I want something that run on a fresh install and a refresh I need to install two hook hanlders? [08:53] mvo: correct, pre- and post-refresh hooks run only on refreshes. and install hook is run only on fresh install [08:54] mvo, zyga: the snapd autopkg tests are not happy with python 3.7 in disco. please fix [08:54] pstolowski: ta [08:55] doko: sure, looking [09:10] Thank you doko [09:10] * zyga is at the dentist [09:13] is snapd such a pain? [09:15] zyga: thanks for https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1801687 [09:15] Bug #1801687: Please remove the plainbox package [09:19] morning from the summit [09:28] Chipaca: hey, what's the turnout? [09:29] mborzecki: ~100,000 people [09:29] Chipaca: over 9000 ;) [09:29] mborzecki: :-) [09:33] Chipaca: good morning! how are things there? anything exciting happening already? [09:46] mvo: popey is playing with his nipple already [09:47] ! [09:47] in public ?!?! [09:47] INORITE [09:48] diddledan: *cough* === iliv_ is now known as ivan_CMD [09:59] PR snapd#6096 opened: spread.yaml: add more systems to the autopkgtest and qemu backends [10:00] PR snapd#6097 opened: interfaces/tests: MockHotplugSlot test helper [10:06] doko: I uploaded a new snapd into disco that should now run the adt tests, will be interessting to see if they fail or pass so maybe there is more work needed but this should at least unblock things [10:06] Dentist over, heading home [10:06] zyga: welcome back [10:06] What was the issue with python 3.7? [10:07] zyga: pr is 6096 [10:07] zyga: its an internal issue might be worth reworking how we drive adt [10:08] I love it when you have to do things like that for every release ... maybe just do the reverse, where it's *not* supported? [10:08] doko: sure, let me look what we can do to make this simpler [10:09] doko: thanks for approving it though [10:09] * mvo looks into reworking that code [10:15] degville: https://snapcraft.io/docs/reference/env is referenced in a few places and redirects to a 410 page https://docs.snapcraft.io/reference/env [10:21] ooh, thanks popey. [10:23] mvo: what's the status of 2.36? is there anything immediately blocked on me? [10:24] pedronis: we need confirmation about the 2.36 API of "system" vs "core" [10:25] pedronis: I sent a mail about this but no reply yet [10:25] PR snapd#6098 opened: interfaces/builtin: support hotplug for camera interface [10:27] zyga: about that cgroup & apparmor, i think now with the process ending up in devices cgroup always, accessing /dev/input/event2 is blocked before lsm gets to have a say on this [10:28] and back home now [10:28] mborzecki: that's correct [10:29] zyga: ok, i'll push the change for s-c as separate PR, some tests may need to be updated, especially the ones where we check between EPERM and EACCESS [10:30] aha, that makes sense [10:30] thank you [10:30] mvo, i'm recently working a lot with x86 images ... was there any actual reason that we show the grub menu there ? [10:31] i mean ... you normally dont select anything there anyway ... [10:33] ogra: no real reason, it may become more interessting once we provide recovery via this mechanism but even then its not a huge reason [10:33] ogra: also kind of nice to show people what system they use but *shrug* really no strong reason :) [10:34] it feel like wasted boot time [10:34] *feels [10:51] I built the package locally out of a release tarball and the version is correct [10:51] the issue must be related to how we build the tarball inside spread [11:02] PR snapd#6099 opened: cmd/snap-confine: always put the snap process under a device cgroup [11:06] mborzecki: interesting, let's see what we get [11:06] (from tests) [11:07] zyga: yeah, much fun [11:08] hmm [11:08] mborzecki: https://forum.snapcraft.io/t/parallel-installs/7679 [11:09] mborzecki: says 1. parallel installs are experimental and you need to 'snap set hose-my-system=very-yes' [11:09] mborzecki: but also, 2. you need 2.36 [11:09] Chipaca: yes [11:09] Chipaca: 2*yes [11:09] mborzecki: I thought 2.36 marked them non-experimental? [11:09] Chipaca: no, we delayed that to 2.37 [11:09] ah, missed that [11:09] ok [11:10] mborzecki: are the store-side limitations still true? [11:10] Chipaca: no, there's a note from wgrant, i should probably update the first message [11:11] mborzecki: yes please :-) [11:12] Chipaca: aand done [11:12] Chipaca: are you guys actively trying to break it? :) [11:12] mborzecki: 👍 [11:12] mborzecki: people are being told it works /o\ [11:13] Chipaca: good, good, ping me if there are any questions [11:13] will do :-) [11:15] zyga: that device cgroup change, i think it's more of a 2.37 material, wdyt? [11:16] mborzecki: not for 2.36 for sure [11:16] we need to discuss with jdstrand and pedronis [11:18] PR snapd#5946 closed: cmd/snap: unhide --name parameter to snap install, tweak help message [11:24] zyga: I'm going a bit through my email etc backlog and some travel admin stuff, but I should be available later in the week to discuss things [11:24] mvo: https://pastebin.ubuntu.com/p/4hpHK8MRHq/ [11:26] niemeyer: ^ i really wish we could do smarter formatting of tables on the terminal :-( [11:26] Chipaca: woah [11:26] (granted that message is longer than it needs to be :) ) [11:29] pedronis: thank you [11:29] Chipaca: use case for those ultra crazy wide monitors ;) [11:39] 80 chars are enough for everyone ! [11:49] PR snapd#5916 closed: data: run snapd.autoimport.service only after seeding [11:49] zyga: a bunch of tests failed in 6099 [11:50] zyga: I see your wide monitor use case, and I raise you a use case for in-snap sub-mount namespaces [11:50] Chipaca: whaaat? [11:50] zyga: also in-snap network namespaces [11:50] zyga: you started! this is all your fault [11:50] that I actually want [11:50] app firewall [11:51] looking at logs there maciej [11:51] eh [11:51] log too long [11:51] mborzecki: Ensure we can run a statically linked binary from an empty base <- this failed, interesting [11:51] zyga: yeah, the log hit travis limits [11:52] mborzecki: I think at this point you need to see what happens until you can run the statically linked echo test [11:52] zyga: anyways, Operation not permitted popping up quite frequently, must have been blocked by device cgroups then [11:53] yeah [11:57] pedronis: o/ [12:07] Chipaca: error: invalid argument for flag `--id' (expected main.snapshotID): strconv.ParseUint: parsing "": invalid syntax, is this something you were looking for? [12:09] mborzecki: you should have logs [12:10] mborzecki: if it's amazon telling you about id -2, take its vodka away [12:10] mborzecki: uid -2 that is [12:10] Chipaca: yes, it is https://paste.ubuntu.com/p/Ms9jXqvH6V/ [12:10] bah [12:10] bah² [12:10] bah³ [12:10] bah⁹⁹ [12:11] mborzecki: i'm not sure i can handle it better than just failing [12:11] mborzecki: but also i don't know why i'm getting that -2 [12:11] mborzecki: I do know why it's a -2 :-) [12:11] mborzecki: amazon linux 2, yes? [12:11] Chipaca: yes [12:12] hm we could dump /etc/passwd in debug [12:13] mborzecki: AIUI it's a manifestation of https://github.com/golang/go/issues/22739 [12:13] mborzecki: the -2, i mean [12:14] Chipaca: it is an off-by-one issue :) [12:14] nope, it's golang's syscall return value munging [12:14] so [12:14] that -2 comes from os.Getuid() returning something too big [12:14] for go [12:15] Chipaca: hi [12:15] which doesn't make sense on itself [12:15] but ¯\_(ツ)_/¯ [12:15] Chipaca: although it's globbed, the path i mean [12:15] pedronis: hi! welcome back. Random question about aliases (from a user at the summit): are multiple snaps having the same alias supported ok store-side? [12:15] Chipaca: some stat maybe? uid/gid handled incorrectly [12:15] pedronis: i assume yes but dunno how tested it is :-) [12:16] mborzecki: i literally just remembered where the -2 comes from today, so i need to comb it [12:16] Chipaca: yes, you'll need to use snap prefer and --unaliased in case you want them both on the same system [12:18] pedronis: yep [12:19] Chipaca: Yeah, that looks pretty bad [12:19] Chipaca: We need something significantly more polished [12:19] niemeyer: I can make it shorter, but I can't make it short enough without giving the user context about why they're being warned [12:20] i mean, short, or with context [12:20] just saying "this app is devmode" isn't enough imo [12:20] Chipaca: The date formating is also breaking our old rule about having no spaces before the last item [12:20] niemeyer, hey, when you have some time, could you please take a look to this PR? https://github.com/snapcore/spread/pull/70 [12:20] PR spread#70: Reboot on backgraound to avoid spread wait for long time [12:20] Making it even harder to read [12:20] cachio: Sure [12:21] I have some time now, but it'll be hard to review it while in line at the border :) [12:22] Chipaca: We might have a short description and a link [12:22] niemeyer: i was thinking of "snap help devmode" [12:22] ie having topics [12:23] as well as commands [12:23] That sounds nice! [12:23] Chipaca: Perhaps just some twist on it so it doesn't look like a command? [12:24] Do we support that today? [12:24] snap help ? [12:24] niemeyer: yes [12:24] Yeah, so we need to disambiguate [12:24] niemeyer: and snap help --all is how you get the long list of everything [12:24] so 'snap' on its own tells you to 'snap help --all' for ex [12:25] niemeyer, great, thanks [12:25] snap about devmode [12:25] niemeyer: wrt the timestamp, i'll change it to use the shorter format we discussed for 'snap saved' [12:25] Chipaca: Sounds good [12:26] that one doesn't have spaces [12:26] Chipaca: Or we could really use the link for the detailing of an issue [12:27] Chipaca: Or alternatively, transform the output of warnings into yaml [12:27] So we can actually read it [12:33] PR snapd#6100 opened: overlord/ifacestate: hotplug-remove-slot task handler [12:34] PR snapd#6101 opened: switch travis unit tests to xenial [12:35] sigh [12:35] * zyga tries again [12:35] Chipaca: I remember we do line wrapping for some errors, either way the super informative warning is good if it's are, but will get annoying if the warning is very common [12:35] PR snapd#5963 closed: tests/hotplug: spread test for hotplug based on dummy interface <⛔ Blocked> [12:35] s/it's are/it's rare/ [12:41] pedronis: agreed about that [12:42] https://www.irccloud.com/pastebin/mEgjLBWg/ [12:42] mborzecki: ^ weird, right? [12:43] info file is correct too [12:43] zyga: 1337 version is better than none :) [12:43] 31337 [12:44] zyga: the one i have here locally is ok [12:44] yeah [12:45] zyga: from what i see we change it in prepare when bulding rpms [12:45] I think I know what's wrong now [12:46] copy [12:46] zyga: are you calling go generate as part of the build? [12:46] I call mkversion.sh in prepare [12:46] google:opensuse-42.3-64 /# find -name version_generated.go [12:46] ./usr/src/packages/BUILD/snapd-1337.2.36/gopath/src/github.com/snapcore/snapd/cmd/version_generated.go [12:46] so this file is good [12:47] niemeyer: some cool people from travis-ci are here [12:47] niemeyer: it turns out we can throw money at them and get more concurrent runs [12:47] zyga: then why it's unknown in snap version output? [12:47] niemeyer: it's just a bit messy and requires a human, because we're using .org [12:47] ./usr/src/packages/BUILD/snapd-1337.2.36/gopath/src/github.com/snapcore/snapd/cmd/VERSION [12:47] niemeyer: let's chat [12:47] there's also this which is equally correct [12:48] mborzecki: now I'm confused :/ [12:48] * zyga looks [12:49] grr, unit tests are 8 minutes again :-( [12:49] zyga: in arch i'm calling ./mkversion.sh $pkgver-$pkgrel [12:49] zyga: so it's not guessing the version [12:49] mborzecki: hi, was https://forum.snapcraft.io/t/cross-snap-service-ordering/8319 discussed with niemeyer, it doesn't seem to match the brief discussion we had in SLC [12:50] the version is fine in VERSION and in go so it's not that [12:50] pedronis: hi, no hence the forum topic, could you leave a comment with what you discussed in slc there? [12:50] must be something I'm missing :/ [12:50] I was thinking it must be a copy [12:50] C and Go are built differently [12:50] C picks up the version okay [12:50] go uses import paths to build stuff [12:51] so I was thinking there must be a bit of copy that was not changed with mkversion somewhere [12:51] mborzecki: I'll try to put something there today or tomorrow, we just sketched some ideas [12:51] it will need further discussion [12:51] google:opensuse-42.3-64 /root# GOPATH=/usr/src/packages/BUILD/snapd-1337.2.36/gopath go build -buildmode=pie github.com/snapcore/snapd/cmd/snap [12:51] https://www.irccloud.com/pastebin/szuxkg0r/ [12:51] so this worked okay [12:51] pedronis: fair enough, i'm out to conference on wed and thu so no rush [12:51] Chipaca: Ack [12:51] I'll add a sanity check in %build to see what version we se [12:53] mborzecki: ah, there _is_ a copy [12:53] wtf? [12:53] we have /home/gopath [12:53] and /usr/src/ [12:53] * zyga looks [12:53] but this is why this happened [12:53] src.rpm got installed? [12:54] no, I think that's our spread hacking magic [12:54] aka mess [12:55] hmm [12:55] mborzecki: what is GOHOME? [12:56] GOHOME? [12:56] it's set in spread.yaml [12:56] git grep GOHOME [12:56] looks like our invention [12:56] zyga: right, but we set GOPATH using that [12:56] that's fine though [12:56] I wonder where /usr/src came from [12:57] specifically usr/src/packages/BUILD [12:57] doesn't feel like something out of srcrpm [12:58] * zyga looks [12:58] quick coffee while spread starts up [12:59] zyga: /usr/src is GOROOT [12:59] I'm guessing [13:02] Chipaca: nope, suse sets GOROOT in the environment to something like /usr/lib64/go/1.11 [13:02] there is no match for /usr/src in our tree so I'm puzzled [13:03] mvo: I pinged you from a couple of unanswered forum topics [13:05] off to pick up the kids [13:13] I see what's going on now [13:14] just not sure how /usr/share/packages is defined [13:14] but that's fine [13:14] got it! [13:14] # rpm -E '%{_topdir}' [13:14] /usr/src/packages [13:14] so [13:14] we have a copy there in BUILD [13:15] and we have a copy in /home/gopath [13:15] now just to untangle that [13:18] zyga, it's /usr/lib/rpm/macros [13:18] SUSE patches rpm to force that [13:18] yeah, I know now :) [13:19] what it does is that if ~/rpmbuild doesn't exist, it will use that directory instead [13:19] (IMO, that's broken, but whatever...) [13:19] also... zyga: https://twitter.com/fedora/status/1059728342666989568 [13:19] looky, you're in the picture :D [13:20] Niiiice :) [13:20] as am I! weee! :D [13:20] seems he surrenders [13:20] :) [13:21] yep, he's now a Fedora man [13:21] no more Ubuntu for him :D [13:21] go IBM ! [13:21] :P [13:22] :S [13:32] mborzecki: fyi, the fuse-support test in your cgroup PR is failing cause you're checking for Permission Denied (as you said above) [13:34] zyga, mborzecki, you guys will want to look into this: https://bugzilla.redhat.com/show_bug.cgi?id=1438079#c4 [13:35] I have a feeling we're switching the unified hierarchy for cgroups (aka cgroups v2) very soon [13:35] pedronis: thanks for the pings, I'm replying now [13:35] Son_Goku: I know about it, I talked to zbyszek [13:35] I think that v2 is not ready yet [13:35] it doesn't have the controllers we need [13:36] ok [13:38] jdstrand: a couple of tests fail the same way, and i have some issues with devmode, we do not generate udev rules in that case but with the PR s-c will still put the snap under a cgroup [13:38] Son_Goku: thanks for the heads up [13:39] zyga: iirc we're only missing freezer at this point, aren't we? [13:39] mborzecki: haha, not sure if only but the freezer is the first one I noticed [13:40] zyga, need karma for this: https://bodhi.fedoraproject.org/updates/FEDORA-2018-48cc10ba1d [13:40] ack, I'll test it today [13:40] zyga: maybe it'd be a good idea to check what's in there already and what we're missing [13:41] zyga: switching will be proobably held for as long as docker dones not support v2 [13:41] mborzecki: based on my discussion with zbyszek there is really no rush for this, it will likely take years [13:42] ppisati, did you take a look at the pi3 b+ NIC-LED isues described in https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509 ? [13:42] (i think the patchset i pointed to initially had fixes for that too) [13:44] mborzecki: I understand the PR and the motivation. Please see my comments in both PR 5897 and PR 6099. 5897 can land if we force the use of the cgroup, like we did with joystick (see comment) [13:44] PR #5897: interfaces/builtin: add device-buttons interface for accessing events <⛔ Blocked> [13:44] PR #6099: cmd/snap-confine: always put the snap process under a device cgroup [13:51] jdstrand: thanks! will do [13:51] mborzecki: fixed, I think [13:52] just quick local spread run before pushing [13:52] zyga: what was it? [13:52] mborzecki: GOPATH takes priority over what we want to build [13:52] PR snapd#6094 closed: wrappers: fix generating of service units with multiple `before` dependencies [13:52] I swapped GOPATH with indigo_gopath [13:52] https://www.irccloud.com/pastebin/wYHe3zeU/ [13:52] mborzecki: ^ my notes from this session [13:55] ogra: i'm looking into it - the led patches are already there, but one of the function (lan78xx_otp_read()) is buggy, or to better - if i apply the correct fix, then leds are working but the entire chip stops working (we don't get any phy interrupt when packate arrives at the interface) [13:55] *packets [13:56] ok ... [13:56] * ogra comments in the forum thread [13:56] ogra: IOW, the lan78xx driver in 4.4 relies on the buggy behaviour of that function [13:57]