=== phoenix_firebrd is now known as phoenix_firebrd_ === phoenix_firebrd_ is now known as phoenix_firebrd [08:33] stgraber: are you around? [08:45] PR snapd#5239 opened: client,cmd/snap,daemon,tests: expose base of a snap over API, show it in snap info --verbose [08:47] stgraber: our "make sure we don't break lxd" integration test started failing yesterday, but it doesn't seem to be anything we changed; instead of eth0, the container now has eth1 === doko is now known as doko_ === doko_ is now known as doko [09:29] stgraber: OTOH it also happens with --channel=3.0 so I _imagine_ it's not something lxd changed :-) [09:29] but i still don't know how to fix it [10:15] Chipaca: have you seen https://github.com/snapcore/snapd/pull/5237 [10:15] PR #5237: tests: fix lxd test - in current lxd we get eth1 instead of eth0 [10:17] I don't know if it's correct, but it passes [10:29] pedronis: what's testbr0 attached to there [10:51] Chipaca: the network/ vbridge I suppose created some lines above [10:51] lxd.lxc network create testbr0 [10:51] pedronis: right, but it then connects that to eth0 [10:53] Chipaca: I don't know [11:00] Chipaca: if I search for network attach , I see a "default" between testbr0 and eth0 that here is not there [11:02] Chipaca: this seems relevant btw: https://github.com/lxc/lxd/issues/2873 [11:07] Chipaca: trying something [11:10] pedronis: i saw that, but it's fixed, with eth0 being set by default [11:10] pedronis: something seems to be overriding it [11:10] pedronis: (and i tried with --channel=3.0 with the same result) [11:10] anyway, i should go see about food [11:12] Chipaca: mmh [11:19] PR snapcraft#2147 closed: recording: expose the version of snapcraft [11:22] PR snapcraft#2150 opened: Os release in manifest [11:42] zyga: hey, so I need to upload a test snap for the evdev tests. I think I need reminding on how to do that with the Canonical account. can you help me? [11:43] zyga: I used to use the shared password, but that doesn't work any more. iiuc, there is the collaboration feature, but I don't see how to use it... maybe I am not a collaborator? [11:44] zyga: maybe I shouldn't care? [11:44] (about the collaboration feature) [11:45] jdstrand: thanks for the input on the xorg crasher bug. It's not easy to reproduce. [11:46] Umm [11:46] I think you have to just upload it [11:46] Then you can share it with another person [11:47] popey: my pauses are probably just because the keyboard and mouse are removed/added but the crashing seems like an nvidia issue, but I don't know [11:47] Like mvo, cachio or me [11:47] jdstrand: I ran your for loop and it locked up my laptop for the period of the test. [11:47] but recovered after [11:47] zyga: hmm. ok. well, there is that 'shared account' for 'Canonical-maintained snaps' [11:47] (my laptop always pauses when doing snap refreshes :( ) [11:48] (which is surprising given it's an i7 with 2xSSD and 64GB RAM) [11:48] I don’t know anything about the shared account [11:48] popey: yeah, that is probably the remove/add of input devices. I bet the second for loop wouldn't do that [11:48] zyga: ok, I guess I'll ask mvo when he is back (is he off?) [11:49] I don’t know [11:49] I’m off :-) [11:49] jdstrand: will try later once I am not working :) [11:49] jdstrand: if you upload it then it will need to be transfered [11:49] zyga: oh, sorry. you don't really act like you're off :) [11:50] I think now it should be possible for m-vo to register it and share it already before you upload [11:50] hehe, the bliss/bane of phone irc [11:50] but m-vo is off today [11:51] I was about to go on a bike somewhere but it's 31C in the shade and I'm somewhat not feeling like getting scorched by the sun today [11:51] pedronis: it isn't a big deal. if I can do it after the fact, that's fine [11:51] so I'm tuning my 3D printer instead [11:52] popey: just do `seq 1 10`. it shouldn't crash but also shouldn't pause [11:52] popey: while it won't fix your nvidia issue, it should make refreshes more pleasant [11:52] popey: (if you give me confirmation of no pauses, I could submit something then) [12:02] Chipaca: my point was more that there are two settable values, so fwiw this also seems to make it pass again: https://pastebin.ubuntu.com/p/yw7d6JjMkk/ [12:02] sigh [12:02] pedronis: but _why did it stop working_? [12:02] for that you need stgraber [12:03] pedronis: yes :-) [12:03] for all I know it worked by chance before [12:03] bah, maybe, but probably yes [12:03] yeah, likely that [12:03] because from what I can read the 2nd value is the relevant one here [12:03] but i'd rather not +1 random changes that make it work by chance now :-D [12:04] Chipaca: anyway atm from my understand I prefere this one over the one in the PR [12:04] as random changes go :) [12:04] :-) === chihchun_afk is now known as chihchun [12:08] popey: ok, I looked at the error reports. This is clearly a problem with Xorg, so I've added a little detail, added xorg-server and marked snapd as invalid. It is possible if I do the 'not input subsystem unless needed' patch for snapd it will reduce the frequency, but that is just a hunch [12:10] popey: in other words, it is now in the desktop team's court === chihchun is now known as chihchun_afk [12:10] desktop, or foundations? [12:11] Morning all [12:11] popey: well, whoever handles xorg. I thought that was desktop, but maybe you know more than I [12:14] :) [12:21] hi, I'm trying to debug a failure uploading the maas snap that's built from LP to the store. it fails with: https://pastebin.ubuntu.com/p/7MWwDTHDPP/ [12:21] when I build the snap locally those symlinks are not absolute [12:23] ackk: what does 'unsquashfs -lls /path/to/your/snap | grep iab.txt' show? [12:24] good morning niemeyer :) [12:25] jdstrand, https://paste.ubuntu.com/p/GmGg3DZ78m/ [12:25] ackk: right it is pointing at /var/lib/ieee-data/iab.txt [12:25] jdstrand, when the snap is built locally (either with latest snapcraft snap or the same deb as LP) they're relatiev [12:26] jdstrand, https://paste.ubuntu.com/p/7n8bssHrKx/ [12:26] jdstrand, LP guys were suggesting a workaround might be adding python3-netaddr to build-packages (it currently is in stage-packages as we depend on it) [12:27] jdstrand: Hey, morning! [12:27] jdstrand, could it be related to that? [12:28] ackk: you are using 'll', but you didn't show me the unsquashfs -lls output of both (your local and the one failing review) [12:29] ackk: so, snapcraft tries to be smart about symlinks. if you are doing 'snapcraft' rather than 'snapcraft cleanbuild' and happen to have something in your local env that changes the result, yes, that could be the case (you'd need a snapcraft person to comment on that) [12:29] jdstrand, the first one is from a mounted snap (with mount -t squashfs) [12:29] jdstrand, the latter is from a prime/ dir of a locally built snap [12:30] jdstrand, ah, I see, so this happens because LP doesn't install the package system-wide [12:30] jdstrand, does LP use cleanbuild? [12:30] ackk: it will use something equivalent iirc [12:30] ie, a small chroot [12:31] jdstrand, so how would a snap using a package like python3-netaddr that has external symlink would fix the issue? [12:31] $ ll /usr/lib/python3/dist-packages/netaddr/eui/iab.txt [12:31] lrwxrwxrwx 1 root root 26 Oct 23 2017 /usr/lib/python3/dist-packages/netaddr/eui/iab.txt -> /var/lib/ieee-data/iab.txt [12:31] jdstrand, ^^ FTR [12:32] I'm also not sure at what stage snapcraft tries to be smart. looking at the mounted snap is equivalent to -lls. I'm not 100% sure looking in prime is (but I think it might be) [12:32] jdstrand, it's the same in the locally built .snap [12:33] ackk: iirc (again, I am not a snapcraft dev), if the file is not staged, it can't be smart so just keeps it. if it finds the file in your staged area, it fixes up the symlink [12:33] jdstrand, maybe adding ieee-data (the package that contains the /var/lib/ieee-data files would fix the issue? [12:33] possibly [12:34] ackk: do you actually need those files? the other route if you don't is to use 'organize' and remove the symlinks [12:34] jdstrand, although python3-netaddr has it as dependency [12:34] jdstrand, I suspect we might (the lib probably does) [12:34] jdstrand, this seems a more general problem though? what about packages that symlink to extenral files? [12:36] ackk: packages aren't allowed to symlink outside the snap. there is no guarantee the file will be present. take your snap. if it actually needed that file, it would be broken on any system that didn't have ieee-data installed [12:37] ackk: the answer is that your snap needs to supply the file and be adjusted to point to the right place. perhaps there is a bug in snapcraft (you might file it). I suspect you have ieee-data installed but LP does not [12:38] jdstrand, I certainly have locally, as I build with "snacraft build" [12:39] ackk: I strongly suggest using 'snapcraft cleanbuild' as a final step to most closely replicate LP [12:39] jdstrand, sure, but that means the snap I build will be rejected as well :) [12:39] ackk: that gives you the opportunity to debug locally though [12:41] jdstrand, sure. yeah I'll try the route of removing those symlinks and linking to the right place in the snap [12:41] ackk: perhaps try to stage ieee-data and see if that helps. if it doesn't, file a bug [12:42] maybe it isn't pulling it in for some reason. maybe it isn't finding it. if there is a bug, yeah, remove and re-add them in the meantime [12:42] jdstrand, ieee-data is a dependency of python3-netaddr so it must be pulled in as we have the latter in stage-packages [12:44] ackk: unless there is a bug in dependencyy resolution in snapcraft. you can probably look in the LP build log and see if it was downloaded [12:51] jdstrand, yes, is does get installed [13:01] cachio_: hey, I'm developing aspread test that uses snapcraft.yaml. I see things in tests/lib/snaps that do the same (fine), but then I see bzr branches in LP that replicate what is in snapd's git to get LP builds of the snaps for all archs. is that the correct way to do things these days? [13:01] jdstrand, hey [13:02] test-snapd-uhid is what I'm looking at for inspiration since it was closest to the type of thing I am testing [13:02] jdstrand, we have those branches to build the snapd and upload automatically to all the architectures [13:02] cachio_: ok, right. that is what it looked like. just wanted to make sure I was doing it the modern way [13:03] jdstrand, which is the other way? [13:04] niemeyer, not connecting to hangouts [13:04] cachio_: I've seen tests that just used snaps in the store, tests that build snaps in spread, etc [13:05] just trying to do it the right way [13:05] jdstrand, so we try to create the snaps that snapd test suite uses [13:06] yeah, that is why I asked about this :) [13:07] jdstrand, and we leave the code as part of the snapd code to have the code and see what the snap does [13:08] but sadly it requires to have the core replicated to make automatic builds for those snapd [13:08] jdstrand, just ping me once you have the code and I'll take a look [13:09] cachio_: that's fine. I think I understand how it works; I just wanted to double check. you confirmed my understanding [13:09] cachio_: all ask you to be a reviewer when I send up the PR [13:18] I'll* [13:22] jdstrand, can you specify the series to use to cleanbuild? it seems it's picking up xenial by default [14:40] Chipaca: actually, I think it's because of something we fixed [14:40] Chipaca: "lxd init --auto" was incorrectly not setting up a network interface, that's now been fixed in both branches [14:41] stgraber: aha [14:41] Chipaca: so if your test code calls "lxd init --auto", then you do end up with an eth0 device defined in your default profile, making it so that any change you do will end up as eth1 [14:41] stgraber: so in https://github.com/snapcore/snapd/blob/master/tests/main/lxd/task.yaml [14:42] stgraber: line ~60 is where we fiddle with the network [14:44] Chipaca: 63 and 64 shouldn't be needed anymore since you call --auto [14:44] stgraber: excellent [14:44] Chipaca: the --auto logic will create a lxdbrX device (starting with lxdbr0 and going up until it finds a free one) [14:50] Chipaca: trying that change (removing the lines) locally [14:50] pedronis: ditto :-) [14:51] and yeah, we released a ton of bugfixes to our stable channels yesterday, this was one of them [14:52] stgraber: good to know, happy that it'll mean less code on our side, and glad I asked [14:56] pedronis: we can drop that whole chunk \o/ [14:57] pedronis: should I, or will you? [14:58] Chipaca: whole chunk? two lines? [14:58] pedronis: and the dhclient call and the comment [15:00] Chipaca: ah, we don't need to setup network at all [15:00] it is already setup? [15:00] looks like it yes [15:01] Chipaca: please go ahead [15:01] ok [15:28] PR snapd#5240 opened: tests: add test to ensure /dev/input/event* for non-joysticks is denied [15:29] cachio: hey, there you go ^. I only tested locally with qemu 18.04-64 so may have to tweak the tests a bit after a full run (I'll of course do that) [15:30] jdstrand, perfect, I'll take a look after lunch [16:02] Chipaca: thanks [16:03] pedronis: fedora acting up now, but hopefully just network [16:25] PR snapd#5241 opened: interfaces/udev: call 'udevadm settle --timeout=3' after triggering events [16:26] and now travis lost a chunk of the log, dunno what's going on [16:40] Power outage.. home router down.. I will stop fighting the holiday gods now and step out [16:49] cachio: fedora's failing to prepare for 3 times in a row now [16:50] Chipaca, ok [16:50] Chipaca, I'll check it [16:50] cachio: https://travis-ci.org/snapcore/snapd/builds/386227367 fwiw [16:51] tx [17:03] cachio: run's finished now, if you need the logs [17:04] checking [17:09] soft EOD from me [17:09] i'll check back to see if i can't coax it to pass [17:19] PR snapcraft#2150 closed: Os release in manifest [18:24] cachio: hey, note that PR 5240 isn't about testing that an interface allows access. it is testing that access is always denied which can only be done with strict mode. this is why I bail early [18:24] PR #5240: tests: add test to ensure /dev/input/event* for non-joysticks is denied [18:27] cachio: I mean, I can put the connection of the joystick interface before strict, but I can't fake an evdev joystick in the test environment and the test isn't really about the joystick interface being connected and functioning. it is about a keyboard not being accessible if the joystick interface is connected [18:27] jdstrand, ok, makes sense [18:28] I initially tried to follow the pattern but then reworked it to what it is since it didn't really work. I am making the other adjustments now. thanks for the review! [18:28] jdstrand, it is ok [18:28] I get your point [18:28] k, I'll comment in the PR and send up the changes [18:30] jdstrand, is it possible to create fake devices and see if the test can read them? [18:30] jdstrand, I mean, to validate this kind of rules [18:30] --> /dev/input/js{[0-9],[12][0-9],3[01]} rw, [18:31] cachio: not in a way that would make udev recognize them [18:31] so the tagging wouldn't work [18:32] well, I'm not aware of a way to do that beyond hotplugging virtualized hardware [18:33] jdstrand, we often use a snap which makes sh [18:33] so we create a fake file simulating a device [18:33] and then chenck the snap is able to read it [18:33] not sure if it is needed in this case [18:34] we do it at least to validate the app armor rules are applied correctly [18:34] for what this test is trying to test, it isn't-- we want to make sure the evdev keyboard is *not* available. that is already in the vm [18:35] jdstrand, ok [18:35] if I were going to write a test-snapd-joystick test, it would be. the problem in this case is that udev is adding a property to evdev devices if it detects they are joysticks [18:35] jdstrand, I can do it [18:35] jdstrand, I already created bunch of interfaces tests [18:36] I could create something in /dev/input/eventN, but adding the myriad of udev properties I don't know how to do [18:36] jdstrand, sure, let me research a bit on this [18:36] I'll create a test for this interface [18:37] ok, cool. if you want me to review, holler [18:37] jdstrand, sure [18:37] I already deleted the comment on the review [18:37] I see, thanks [18:37] np [19:39] PR snapd#5237 closed: tests: fix lxd test - --auto now sets up networking [20:42] jdstrand, could you please merge with master the #5240 [20:42] PR #5240: tests: add test to ensure /dev/input/event* for non-joysticks is denied [20:42] it has the lxd test fixed [20:48] cachio: ok. fyi, I figured out a way to do the access test without evtest (ie, just bash) and am doing that in a separate PR. I think using evtest is kinda cool and might be useful for others later. thoughts on keeping it or using the new bash-only approach? [20:49] jdstrand, great [20:49] jdstrand, ping me, I'll review it [20:49] thanks [20:50] PR snapcraft#2151 opened: Debian [20:50] cachio: by 'separate PR' I mean, I am writing a new spread test for something else [20:50] cachio: so curious if you'd prefer I change 5240 to use bash only, or leave it as is since it might be a handy example for others later [20:50] jdstrand, something like interfaces-joystick [20:50] ? [20:50] no [20:51] I'm doing a PR that should help refreshes be less painful wrt udev trigger and I wanted to test something with the mir slot and plug [20:51] ah, ok [20:52] popey: you might be interested in that ^ [20:52] cachio: and I'm conincidentally playing with /dev/input/event* again [20:52] jdstrand, in a moment I'll create a snap pr to test the interface, mostly focused on apparmor rultes [20:53] cachio: cool. do you have an opinion on 5240 moving to bash-only or keeping evtest? [20:53] jdstrand, we try to move to bash when it is possible [20:54] ok, then I'll update the pr for that [20:54] jdstrand, because it is easier to understand reading the test [20:54] it'll be a few minutes since I'm in the middle of that other pr [20:56] jdstrand, sure, np [21:22] roadmr: hi! got another review tools request. can you pull r1082? [21:24] roadmr: also can you revoke test-snapd-event? I added it today and figured out how to do it without a published snap [21:24] hi jdstrand [21:24] jdstrand: yes to both [21:25] roadmr: thanks! [21:25] jdstrand: are you sure you want a revocation? that blacklists the snap name for all eternity, nobody will ever ever be able to use it [21:26] roadmr: well, really I want to pretend I didn't add the snap. if that isn't possible, I'd like to unpublish the revisions from any channels [21:26] roadmr: I guess that would allow us to transfer the name to someone [21:26] jdstrand: you can unpublish them by snapcraft close test-snapd-event stable edge beta candidate [21:26] jdstrand: if you hold on to the name even with no snaps published, it can be transferred [21:26] oh, I didn't know about close [21:27] * jdstrand does that [21:27] jdstrand: if it's revoked, it can NOT be transferred, it becomes scorched earth and can never be used again by anyone [21:27] that's fine then [21:27] jdstrand: yes, that's why the trashcan icon was removed, remember that? that's "revoke forever never to be seen again by anyone", and not "just delete all the uploads unpublish everything and start from scratch" [21:28] so since people wanted the 2nd and ended up in the middle of a desert, we decided to remove it :) [21:28] oh yes, I do remember that [21:28] ok, I closed it. just the pull then. thanks! [21:29] jdstrand: np, I prepared it but it'll likely not be deployed until Monday :/ [21:30] that's fine. this one isn't at all urgent [21:30] awesome :) [21:33] Bug #1774509 opened: system-user assertion should allow change-pw to be set [21:50] cachio: ok, 5240 updated. the tests are running [21:50] jdstrand, good [21:50] I'll take a look [22:41] PR snapcraft#2152 opened: many: automatically redo step for specified part