/srv/irclogs.ubuntu.com/2018/05/31/#snappy.txt

=== phoenix_firebrd is now known as phoenix_firebrd_
=== phoenix_firebrd_ is now known as phoenix_firebrd
Chipacastgraber: are you around?08:33
mupPR snapd#5239 opened: client,cmd/snap,daemon,tests: expose base of a snap over API, show it in snap info --verbose <Created by pedronis> <https://github.com/snapcore/snapd/pull/5239>08:45
Chipacastgraber: 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 eth108:47
=== doko is now known as doko_
=== doko_ is now known as doko
Chipacastgraber: OTOH it also happens with --channel=3.0 so I _imagine_ it's not something lxd changed :-)09:29
Chipacabut i still don't know how to fix it09:29
pedronisChipaca: have you seen  https://github.com/snapcore/snapd/pull/523710:15
mupPR #5237: tests: fix lxd test - in current lxd we get eth1 instead of eth0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5237>10:15
pedronisI don't know if it's correct, but it passes10:17
Chipacapedronis: what's testbr0 attached to there10:29
pedronisChipaca: the network/ vbridge I suppose created some lines above10:51
pedronislxd.lxc network create testbr010:51
Chipacapedronis: right, but it then connects that to eth010:51
pedronisChipaca: I don't know10:53
pedronisChipaca: if I search for network attach , I see  a "default" between testbr0 and eth0 that here is not there11:00
pedronisChipaca: this seems relevant btw:  https://github.com/lxc/lxd/issues/287311:02
pedronisChipaca: trying something11:07
Chipacapedronis: i saw that, but it's fixed, with eth0 being set by default11:10
Chipacapedronis: something seems to be overriding it11:10
Chipacapedronis: (and i tried with --channel=3.0 with the same result)11:10
Chipacaanyway, i should go see about food11:10
pedronisChipaca: mmh11:12
mupPR snapcraft#2147 closed: recording: expose the version of snapcraft <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2147>11:19
mupPR snapcraft#2150 opened: Os release in manifest <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2150>11:22
jdstrandzyga: 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:42
jdstrandzyga: 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:43
jdstrandzyga: maybe I shouldn't care?11:44
jdstrand(about the collaboration feature)11:44
popeyjdstrand: thanks for the input on the xorg crasher bug. It's not easy to reproduce.11:45
zygaUmm11:46
zygaI think you have to just upload it11:46
zygaThen you can share it with another person11:46
jdstrandpopey: 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 know11:47
zygaLike mvo, cachio or me11:47
popeyjdstrand: I ran your for loop and it locked up my laptop for the period of the test.11:47
popeybut recovered after11:47
jdstrandzyga: hmm. ok. well, there is that 'shared account' for 'Canonical-maintained snaps'11:47
popey(my laptop always pauses when doing snap refreshes :( )11:47
popey(which is surprising given it's an i7 with 2xSSD and 64GB RAM)11:48
zygaI don’t know anything about the shared account11:48
jdstrandpopey: yeah, that is probably the remove/add of input devices. I bet the second for loop wouldn't do that11:48
jdstrandzyga: ok, I guess I'll ask mvo when he is back (is he off?)11:48
zygaI don’t know11:49
zygaI’m off :-)11:49
popeyjdstrand: will try later once I am not working :)11:49
pedronisjdstrand: if you upload it then it will need to be transfered11:49
jdstrandzyga: oh, sorry. you don't really act like you're off :)11:49
pedronisI think now it should be possible for m-vo to register it and share it already before you upload11:50
zygahehe, the bliss/bane of phone irc11:50
pedronisbut m-vo is off today11:50
zygaI 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 today11:51
jdstrandpedronis: it isn't a big deal. if I can do it after the fact, that's fine11:51
zygaso I'm tuning my 3D printer instead11:51
jdstrandpopey: just do `seq 1 10`. it shouldn't crash but also shouldn't pause11:52
jdstrandpopey: while it won't fix your nvidia issue, it should make refreshes more pleasant11:52
jdstrandpopey: (if you give me confirmation of no pauses, I could submit something then)11:52
pedronisChipaca: 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
Chipacasigh12:02
Chipacapedronis: but _why did it stop working_?12:02
pedronisfor that you need stgraber12:02
Chipacapedronis: yes :-)12:03
pedronisfor all I know it worked by chance before12:03
Chipacabah, maybe, but probably yes12:03
Chipacayeah, likely that12:03
pedronisbecause from what I can read the 2nd value is the relevant one here12:03
Chipacabut i'd rather not +1 random changes that make it work by chance now :-D12:03
pedronisChipaca: anyway atm from my understand I prefere this one over the one in the PR12:04
pedronisas random changes go :)12:04
Chipaca:-)12:04
=== chihchun_afk is now known as chihchun
jdstrandpopey: 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 hunch12:08
jdstrandpopey: in other words, it is now in the desktop team's court12:10
=== chihchun is now known as chihchun_afk
popeydesktop, or foundations?12:10
niemeyerMorning all12:11
jdstrandpopey: well, whoever handles xorg. I thought that was desktop, but maybe you know more than I12:11
popey:)12:14
ackkhi, 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
ackkwhen I build the snap locally those symlinks are not absolute12:21
jdstrandackk: what does 'unsquashfs -lls /path/to/your/snap | grep iab.txt' show?12:23
jdstrandgood morning niemeyer :)12:24
ackkjdstrand, https://paste.ubuntu.com/p/GmGg3DZ78m/12:25
jdstrandackk: right it is pointing at /var/lib/ieee-data/iab.txt12:25
ackkjdstrand, when the snap is built locally (either with latest snapcraft snap or the same deb as LP) they're relatiev12:25
ackkjdstrand, https://paste.ubuntu.com/p/7n8bssHrKx/12:26
ackkjdstrand, 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:26
niemeyerjdstrand: Hey, morning!12:27
ackkjdstrand, could it be related to that?12:27
jdstrandackk: you are using 'll', but you didn't show me the unsquashfs -lls output of both (your local and the one failing review)12:28
jdstrandackk: 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
ackkjdstrand, the first one is from a mounted snap (with mount -t squashfs)12:29
ackkjdstrand, the latter is from a prime/ dir of a locally built snap12:29
ackkjdstrand, ah, I see, so this happens because LP doesn't install the package system-wide12:30
ackkjdstrand, does LP use cleanbuild?12:30
jdstrandackk: it will use something equivalent iirc12:30
jdstrandie, a small chroot12:30
ackkjdstrand, so how would a snap using a package like python3-netaddr that has external symlink would fix the issue?12:31
ackk$ ll /usr/lib/python3/dist-packages/netaddr/eui/iab.txt12:31
ackklrwxrwxrwx 1 root root 26 Oct 23  2017 /usr/lib/python3/dist-packages/netaddr/eui/iab.txt -> /var/lib/ieee-data/iab.txt12:31
ackkjdstrand, ^^ FTR12:31
jdstrandI'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
ackkjdstrand, it's  the same in the locally built .snap12:32
jdstrandackk: 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 symlink12:33
ackkjdstrand, maybe adding ieee-data (the package that contains the /var/lib/ieee-data files would fix the issue?12:33
jdstrandpossibly12:33
jdstrandackk: do you actually need those files? the other route if you don't is to use 'organize' and remove the symlinks12:34
ackkjdstrand, although python3-netaddr has it as dependency12:34
ackkjdstrand, I suspect we might (the lib probably does)12:34
ackkjdstrand, this seems a more general problem though? what about packages that symlink to extenral files?12:34
jdstrandackk: 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 installed12:36
jdstrandackk: 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 not12:37
ackkjdstrand, I certainly have locally, as I build with "snacraft build"12:38
jdstrandackk: I strongly suggest using 'snapcraft cleanbuild' as a final step to most closely replicate LP12:39
ackkjdstrand, sure, but that means the snap I build will be rejected as well :)12:39
jdstrandackk: that gives you the opportunity to debug locally though12:39
ackkjdstrand, sure. yeah I'll try the route of removing those symlinks and linking to the right place in the snap12:41
jdstrandackk: perhaps try to stage ieee-data and see if that helps. if it doesn't, file a bug12:41
jdstrandmaybe 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 meantime12:42
ackkjdstrand, ieee-data is a dependency of python3-netaddr so it must be pulled in as we have the latter in stage-packages12:42
jdstrandackk: unless there is a bug in dependencyy resolution in snapcraft. you can probably look in the LP build log and see if it was downloaded12:44
ackkjdstrand, yes, is does get installed12:51
jdstrandcachio_: 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
cachio_jdstrand, hey13:01
jdstrandtest-snapd-uhid is what I'm looking at for inspiration since it was closest to the type of thing I am testing13:02
cachio_jdstrand, we have those branches to build the snapd and upload automatically to all the architectures13:02
jdstrandcachio_: ok, right. that is what it looked like. just wanted to make sure I was doing it the modern way13:02
cachio_jdstrand, which is the other way?13:03
cachio_niemeyer, not connecting to hangouts13:04
jdstrandcachio_: I've seen tests that just used snaps in the store, tests that build snaps in spread, etc13:04
jdstrandjust trying to do it the right way13:05
cachio_jdstrand, so we try to create the snaps that snapd test suite uses13:05
jdstrandyeah, that is why I asked about this :)13:06
cachio_jdstrand, and we leave the code as part of the snapd code to have the code and see what the snap does13:07
cachio_but sadly it requires to have the core replicated to make automatic builds for those snapd13:08
cachio_jdstrand, just ping me once you have the code and I'll take a look13:08
jdstrandcachio_: that's fine. I think I understand how it works; I just wanted to double check. you confirmed my understanding13:09
jdstrandcachio_: all ask you to be a reviewer when I send up the PR13:09
jdstrandI'll*13:18
ackkjdstrand, can you specify the series to use to cleanbuild? it seems it's picking up xenial by default13:22
stgraberChipaca: actually, I think it's because of something we fixed14:40
stgraberChipaca: "lxd init --auto" was incorrectly not setting up a network interface, that's now been fixed in both branches14:40
Chipacastgraber: aha14:41
stgraberChipaca: 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 eth114:41
Chipacastgraber: so in https://github.com/snapcore/snapd/blob/master/tests/main/lxd/task.yaml14:41
Chipacastgraber: line ~60 is where we fiddle with the network14:42
stgraberChipaca: 63 and 64 shouldn't be needed anymore since you call --auto14:44
Chipacastgraber: excellent14:44
stgraberChipaca: the --auto logic will create a lxdbrX device (starting with lxdbr0 and going up until it finds a free one)14:44
pedronisChipaca: trying that change (removing the lines) locally14:50
Chipacapedronis: ditto :-)14:50
stgraberand yeah, we released a ton of bugfixes to our stable channels yesterday, this was one of them14:51
Chipacastgraber: good to know, happy that it'll mean less code on our side, and glad I asked14:52
Chipacapedronis: we can drop that whole chunk \o/14:56
Chipacapedronis: should I, or will you?14:57
pedronisChipaca: whole chunk?  two lines?14:58
Chipacapedronis: and the dhclient call and the comment14:58
pedronisChipaca: ah, we don't need to setup network at all15:00
pedronisit is already setup?15:00
Chipacalooks like it yes15:00
pedronisChipaca: please go ahead15:01
Chipacaok15:01
mupPR snapd#5240 opened: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5240>15:28
jdstrandcachio: 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:29
cachiojdstrand, perfect, I'll take a look after lunch15:30
pedronisChipaca: thanks16:02
Chipacapedronis: fedora acting up now, but hopefully just network16:03
mupPR snapd#5241 opened: interfaces/udev: call 'udevadm settle --timeout=3' after triggering events <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5241>16:25
Chipacaand now travis lost a chunk of the log, dunno what's going on16:26
niemeyerPower outage.. home router down.. I will stop fighting the holiday gods now and step out16:40
Chipacacachio: fedora's failing to prepare for 3 times in a row now16:49
cachioChipaca, ok16:50
cachioChipaca, I'll check it16:50
Chipacacachio: https://travis-ci.org/snapcore/snapd/builds/386227367 fwiw16:50
cachiotx16:51
Chipacacachio: run's finished now, if you need the logs17:03
cachiochecking17:04
Chipacasoft EOD from me17:09
Chipacai'll check back to see if i can't coax it to pass17:09
mupPR snapcraft#2150 closed: Os release in manifest <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2150>17:19
jdstrandcachio: 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 early18:24
mupPR #5240: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5240>18:24
jdstrandcachio: 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 connected18:27
cachiojdstrand, ok, makes sense18:27
jdstrandI 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
cachiojdstrand, it is ok18:28
cachioI get your point18:28
jdstrandk, I'll comment in the PR and send up the changes18:28
cachiojdstrand, is it possible to create fake devices and see if the test can read them?18:30
cachiojdstrand, I mean, to validate this kind of rules18:30
cachio--> /dev/input/js{[0-9],[12][0-9],3[01]} rw,18:30
jdstrandcachio: not in a way that would make udev recognize them18:31
jdstrandso the tagging wouldn't work18:31
jdstrandwell, I'm not aware of a way to do that beyond hotplugging virtualized hardware18:32
cachiojdstrand, we often use a snap which makes sh18:33
cachioso we create a fake file simulating a device18:33
cachioand then chenck the snap is able to read it18:33
cachionot sure if it is needed in this case18:33
cachiowe do it at least to validate the app armor rules are applied correctly18:34
jdstrandfor 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 vm18:34
cachiojdstrand, ok18:35
jdstrandif 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 joysticks18:35
cachiojdstrand, I can do it18:35
cachiojdstrand, I already created bunch of interfaces tests18:35
jdstrandI could create something in /dev/input/eventN, but adding the myriad of udev properties I don't know how to do18:36
cachiojdstrand, sure, let me research a bit on this18:36
cachioI'll create a test for this interface18:36
jdstrandok, cool. if you want me to review, holler18:37
cachiojdstrand, sure18:37
cachioI already deleted the comment on the review18:37
jdstrandI see, thanks18:37
cachionp18:37
mupPR snapd#5237 closed: tests: fix lxd test - --auto now sets up networking <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5237>19:39
cachiojdstrand, could you please merge with master the #524020:42
mupPR #5240: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5240>20:42
cachioit has the lxd test fixed20:42
jdstrandcachio: 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:48
cachiojdstrand, great20:49
cachiojdstrand, ping me, I'll review it20:49
cachiothanks20:49
mupPR snapcraft#2151 opened: Debian <Created by transdigiware> <https://github.com/snapcore/snapcraft/pull/2151>20:50
jdstrandcachio: by 'separate PR' I mean, I am writing a new spread test for something else20:50
jdstrandcachio: 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 later20:50
cachiojdstrand, something like interfaces-joystick20:50
cachio?20:50
jdstrandno20:50
jdstrandI'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 plug20:51
cachioah, ok20:51
jdstrandpopey: you might be interested in that ^20:52
jdstrandcachio: and I'm conincidentally playing with /dev/input/event* again20:52
cachiojdstrand, in a moment I'll create a snap pr to test the interface, mostly focused on apparmor rultes20:52
jdstrandcachio: cool. do you have an opinion on 5240 moving to bash-only or keeping evtest?20:53
cachiojdstrand, we try to move to bash when it is possible20:53
jdstrandok, then I'll update the pr for that20:54
cachiojdstrand, because it is easier to understand reading the test20:54
jdstrandit'll be a few minutes since I'm in the middle of that other pr20:54
cachiojdstrand, sure, np20:56
jdstrandroadmr: hi! got another review tools request. can you pull r1082?21:22
jdstrandroadmr: also can you revoke test-snapd-event? I added it today and figured out how to do it without a published snap21:24
roadmrhi jdstrand21:24
roadmrjdstrand: yes to both21:24
jdstrandroadmr: thanks!21:25
roadmrjdstrand: are you sure you want a revocation? that blacklists the snap name for all eternity, nobody will ever ever be able to use it21:25
jdstrandroadmr: 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 channels21:26
jdstrandroadmr: I guess that would allow us to transfer the name to someone21:26
roadmrjdstrand: you can unpublish them by snapcraft close test-snapd-event stable edge beta candidate21:26
roadmrjdstrand: if you hold on to the name even with no snaps published, it can be transferred21:26
jdstrandoh, I didn't know about close21:26
* jdstrand does that21:27
roadmrjdstrand: if it's revoked, it can NOT be transferred, it becomes scorched earth and can never be used again by anyone21:27
jdstrandthat's fine then21:27
roadmrjdstrand: 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:27
roadmrso since people wanted the 2nd and ended up in the middle of a desert, we decided to remove it :)21:28
jdstrandoh yes, I do remember that21:28
jdstrandok, I closed it. just the pull then. thanks!21:28
roadmrjdstrand: np, I prepared it but it'll likely not be deployed until Monday :/21:29
jdstrandthat's fine. this one isn't at all urgent21:30
roadmrawesome :)21:30
mupBug #1774509 opened: system-user assertion should allow change-pw to be set <Snappy:New> <https://launchpad.net/bugs/1774509>21:33
jdstrandcachio: ok, 5240 updated. the tests are running21:50
cachiojdstrand, good21:50
cachioI'll take a look21:50
mupPR snapcraft#2152 opened: many: automatically redo step for specified part <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2152>22:41

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!