=== chihchun_afk is now known as chihchun === JanC is now known as Guest10980 === JanC_ is now known as JanC [07:01] good morning [07:01] mvo: hey, do you prefer to talk here or do a hangout to introduce the problem quickly and then talk here? [07:08] zyga: here or in the forum so that other may also benefit [07:08] mvo: ok, let's do a quick conversation here, the rest can be done on the update-ns thread [07:09] mvo: the first thing to look at is the general algorithm of the tool: https://github.com/snapcore/snapd/pull/3216/files [07:09] PR snapd#3216: cmd/snap-update-ns: add actual implementation [07:09] That code is fairly well commented and simple [07:09] there are two kinds of input apart from the snap name [07:09] the snapd-created mount profile [07:10] and the kernel-maintained mount table [07:10] if you have a look at the code there you can see that we read the desired mount profile (what we want to have in the mount namespace of a given snap) and compare it to what is currently there (what we wrote on prior run of snap-update-ns or snap-confine) [07:11] from there we compute what to do, this is so far all the old code and there's nothing wrong with it AFAIK [07:11] now once we know what to do we represent that as a list of mount changes to perform: either mount something or unmount something [07:12] because we work with the simplistic fstab-like files written by snapd we don't really know what got mounted (e.g. by older version of snap-confine or by the snap itself) [07:12] so we cross check each change with the mountinfo table [07:12] and here is where the dragons are [07:13] the interfaces/mount.Change.Needed function is non trivial [07:14] before we jump into that, please let me know if this makes sense so far and if you have any questions? [07:18] zyga: so far so good [07:24] ok [07:25] so I looked at the mountinfo table and talked to the kernel guys (initially I wanted to make a patch for the kernel to make this information easier to grok but later abandoned that idea) [07:25] the mountinfo table has records with several fields, the most obviously important are MountDir which says where something is mountd (relative to the root filesystem) and MountSource (which says what is mounted) [07:26] super important though not obviously so is the Root field which tells us the "root of the mount within the filesystem" (to quote kernel documentation) [07:26] PR snapcraft#1272 opened: tests: initial setup for the snapcraft snap tests with spread [07:27] as an example, I mounted tmpfs in my home directory "/home/zyga/data" [07:27] then the Root field of that entry is "/" as the "whole" tmpfs is mounted there [07:28] then I created a directory "/home/zyga/data/foo" and similarly "bar" [07:28] and bind mounted foo over bar [07:28] so now the subtree rooted at "/foo" (relative to the tmpfs itself) is mounted [07:29] and the mountinfo entry for that speaks about MountDir: "/home/zyga/data/bar", with Root: "/foo" [07:29] what is problematic now is that it's hard to know what is "/foo" relative to, we only see "tmpfs" filesystem name [07:29] and arbitrary and irrelevant "none" that I passed as device name (via mount -t tmpfs none /home/zyga/data) [07:30] so on quick look it's hard to say that "/foo" refers to a directory on the same filesystem that is mounted in /home/zyga/data/ [07:30] there are two more pieces of information [07:30] each mount entry has two numeric values: MountID and ParentID [07:31] in the example I was describing so far the root filesystem has MountID of 25 [07:31] the /home/zyga/data tmpfs has MountID of 392 and ParentID of 25 [07:32] the /home/zyga/data/foo -> /home/zyga/data/bar bind-mount has MountID 400 and ParentID of 392 [07:32] so here's my issue now: [07:33] is this sufficient to create a tree of mounts and figure out the answer of Change.Needed or do we need additional information (e.g. collected by walking and stat'in the filesystem) [07:33] I was hoping we don't [07:33] the algorithm for solving the issue that I wrote so far was based on the following idea: [07:33] when we are asked to perform a mount change [07:34] to check if that thing is mounted already (for bind mounts) [07:34] (because only bind mounts are harder) [07:34] (perhaps I should explain why: because regular mounts describe what is mounted and where it is to be mounted fully [07:34] while bind mounts describe the source indirectly [07:35] as we don't know what is the nature of /home/zyga/data/foo from the fstab-like entry [07:35] we just know we need to mount it on /home/zyga/data/bar [07:35] so the idea behind that algorithm is as follows: [07:35] look at the source of the bind mount (/home/zyga/data/foo) and resolve it to something absolute [07:36] I chose to use the mounted device (e.g. /dev/sda2, but this breaks apart with tmpfs) [07:36] and a path relative to that device [07:36] (or to a filesystem on that device) [07:36] and then compute all the things that are exactly the same [07:36] so we get a set in return [07:36] and if the destination of a bind mount is in that set we don't need to perform the change [07:37] this works well for simple examples but for this tmpfs example I referred to it falls apart [07:37] and I think I need to start using the MountID and ParentID [07:37] unfortunately there's no easier way to check as far as I know [07:37] let me know if this makes sense, I can show you what I have (the implementation of interfaces/mount/AliasesOf) [07:37] and the array of tests I wrote [07:38] mvo: regarding dbus session bus activation, just give me a ping when the PR is ready and I will give it a try and do a review [07:38] I can also convert this to a forum topic [07:38] zyga: I think it does make sense [07:38] zyga: this is all in the PR, right? [07:39] morphis_: the most important missing piece is creating of /etc/dbus-1/session.d/snapd.conf in the re-exec case, that should be finish in some minutes I hope [07:39] mvo: great! [07:39] mvo: I'll break to eat some breakfast and be back here soon [07:39] zyga: what should I do next? review the PR ? or poke at the mountinfo stuff to see if there is an easier way to figure out the bind mounts? [07:40] mvo: maybe look at mountinfo and see what you make of it [07:40] mvo: specifically look how it looks like for snaps [07:40] mvo: for tmpfs'es [07:40] mvo: and regular filesystems [07:40] mvo: just to build some extra intuition [07:40] mvo: note that mountinfo is specific to the namespace your are observing it from [07:41] mvo: so you may want to nsenter to a snap mount namespace as well [07:41] zyga: ta [07:41] * zyga -> breakfast [07:44] mvo, zyga: do you guys have time for another review on https://github.com/snapcore/snapd/pull/3177 today? [07:44] PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment [07:49] morphis_: yes [07:52] mvo: thanks [08:05] pstolowski: hm,hm, I would love to merge 3119 but I think we need a gustavo review first? [08:05] mvo, indeed [08:11] hi mvo: wrt the sru verification all is good for trusty, xenial and yakkety, we have an error that afaik is not a regression in the tests on zesty http://paste.ubuntu.com/24425481/ "snap create-key" hangs [08:12] mvo: we found this in the branch that enabled expect tests for ubuntu-core systems, not until now on classic [08:12] fgimenez: and it also hangs outside the tests? [08:13] mvo: yep, i've tried manually on an up to date zesty and it hangs [08:13] fgimenez: could you do a quick check if previous versions of snapd on zesty were also affected? [08:13] mvo: sure on it [08:13] fgimenez: thank you! if its a regression we need to do something, otherwise its ok, but obviously this needs attention :) [08:17] PR snapcraft#1273 opened: Check snap name [08:22] mvo: with 2.23.6+17.04.1 it hangs too http://paste.ubuntu.com/24425510/ [08:23] fgimenez: ok, "great" [08:24] fgimenez: at least not a regression but this needs urgent attention, can you please create a forum topic and tag upcoming? [08:24] fgimenez: strace of the hanging thing would be nice but I can check that in a bit on my zesty machine when I finished my current task [08:25] mvo: sure, i'll update the sru bug too once the test run ends, only a few of them remaining [08:30] ta [08:37] mvo: https://forum.snapcraft.io/t/snap-create-key-timeouts/359 [08:38] q [08:43] $ snap changes everything [08:43] Yes, yes it does. [08:43] :) [08:55] fgimenez: hm, confusing, I just tried snap create-key in a 17.04 vm with 2.23.6 /2.24 it works [08:55] fgimenez: so maybe test related afterall? I ran the commands manually [08:56] mvo: mm i tried manually too, let me check again [08:57] fgimenez: what kind of machine? maybe I just need a different vm/machine. I can also test on real HW [08:58] fgimenez: if you can reproduce it, a ps afx would be nice, also an strace [08:58] mvo: yes, it hangs here, is your system up to date? maybe this is related to another package [08:58] fgimenez: i.e. ps to see if there is gpg running [08:58] Is there a web catalogue of existing snaps? I can't find it on https://snapcraft.io/ [08:58] mvo: sure, this is the strace http://paste.ubuntu.com/24425544/ [08:58] fgimenez: I upgraded it some minutes ago, but I did only install snapd from proposed, I can try everything from proposed now [08:59] mvo: same here, this is a vm created with "adt-buildvm-ubuntu-cloud -a amd64 -r zesty" [08:59] martyix: hi, closest you can find as a website is https://uappexplorer.com/apps?type=snappy&release=16 that lists all stable snaps. You can also simply use "snap find" on the command line [09:00] mvo: this is ps afx http://paste.ubuntu.com/24425624/ [09:00] davidcalle: I know about "snap find". It looks good, thanks [09:00] yw === JanC is now known as Guest18582 === JanC_ is now known as JanC [09:03] fgimenez: thanks, I will build a new vm just to be sure mine is not contaimiated ;) [09:04] mvo: great thanks, i'll do the same :) === alan_g_ is now known as alan_g [09:31] mvo, fgimenez: I see the create-key issue too, on Linode (latest git) and on my desktop (2.23.6) [09:34] morphis_: thanks a lot for confirming! :) i'm seeing it too in my desktop, 2.23.1+16.10 [09:34] mvo, pedronis: any idea what that can be? [09:35] morphis_: it works here with 2.24 [09:35] morphis_: is the test that hangs, or just the command? [09:35] both [09:35] morphis_: I still cannot reproduce [09:36] I see it on https://github.com/snapcore/snapd/pull/3156 for debian too [09:36] PR snapd#3156: many: support debian in our CI [09:36] pedronis: happy to provide more data [09:37] mvo: yea, it works here too [09:37] pedronis: it doesn't seem to work with SNAP_REEXEC=0 too [09:39] morphis_: what is your gpg --version ? [09:39] also tried after removing my $HOME/.snap dir [09:39] 1.4.20 [09:39] 1.4.20-1ubuntu3.1 [09:40] same here [09:44] guys, i'm going to head back to bed and wait for this to boil over [09:44] see you on the other side [09:45] mvo: updated https://github.com/snapcore/snapd/pull/3177 with all requested changes [09:45] PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment [09:47] pedronis, fgimenez: ok, now it worked again [09:48] fgimenez: do we purge $HOME/.snap during the spread tests before every test is executed? [09:48] morphis_: ? [09:48] pedronis: I did: mv $HOME/.snap $HOME/.snap-old and ran create-key again [09:48] morphis_: i don't think so, let me check [09:48] it took quite some time but finished now [09:49] pedronis: interestingly I have now two default keys [09:49] well if you are creating the same key it should fail [09:49] in which sense two default keys? [09:50] pedronis: https://paste.ubuntu.com/24425759/ [09:50] that is very weird [09:50] it is [09:50] trying to reproduce that [09:50] pedronis: do we save any state information outside of $HOME/.snap? [09:51] hi all: i am tryìng to register a kernel, gadget, and assertion for a custom board on public store: how can i make sure that the assertion model is present on the store? i just upload kernel and gadget with the user owning the the signing key for the model assertion [09:51] morphis_: no [09:51] but we don't do locking either, wondering if gpg itself does locking [09:51] anyway that looks like create-key was run twice [09:52] pedronis: your answwer are to me [09:52] ? [09:52] NicolinoCuralli: no [09:53] morphis_: \o/ - I have a look [09:53] NicolinoCuralli: there is no way to upload a model assertion to the store, it's also not strictly necessary, the thing that need to be in the store is key that signed it [09:53] I mean the corresponding account-key [09:54] Hi, guys! =) It's Renat from Screenly. [09:54] this might change but atm is not a requirement nor are there tools to get it there [09:55] I have a question about the timezone-control interface and the following ticket:https://bugs.launchpad.net/snappy/+bug/1650688 [09:55] Bug #1650688: timedatectl set-timezone fails on UC16 [09:56] That part is pretty critical for our system and I wasn't able to make it working. [09:56] What do you think about enabling write access to the /etc/writable/localtime? [09:56] For those who connected to the timezone-control slot, of course. [09:57] pedronis: a further question: what is the procedure to publish a kernel on public store? i upload kernel and gadget with a user owning the gpg key with i sign my model assertion: what I also need to make? [09:58] pedronis: ok, couldn't reproduce this a second time [09:58] pedronis: feels like I had another `snap create-user` process still running in the background [09:58] morphis_: yes [09:59] NicolinoCuralli: it needs to be approved by a reviewer which is a bit adhoc, notice that only devices with a model signed by the publisher of the kernel can use it [10:00] fgimenez: maybe we need to give the test case just a higher timeout [10:02] entropy issues? [10:02] pedronis: ok : for me this restriction is ok; what about the time for a answer about problems with kernel and gaddget i uploaded? [10:03] morphis_: yes, i'm trying to measure how much, in a zesty vm it has been stuck for 13min so far, let's see.. [10:03] NicolinoCuralli: I don't understand that question? [10:03] fgimenez: wow, that is a lot [10:05] pedronis: how many time the review for kernel and/or gadget takes ? [10:06] NicolinoCuralli: ah, I don't know, I would ping jdstrand when is around here, he might know who to ping [10:12] pedronis : thanks, i pinged jdstrand [10:21] mvo: I wrote on the forum about my problem: https://forum.snapcraft.io/t/fixing-live-propagation-of-mount-changes/23 [10:22] morphis_: ^^ insight appreciated [10:25] zyga: yeah, just reading. so the kernel doc says that the mount-id is unique, does that help us? [10:25] it is unique, yes (otherwise it'd be a poor ID); the issue is that we don't know what is really being shared in bind mounts [10:26] the MountSource is useless (it's the device, that's fine but for virtual filesystems like tmpfs or others it's not unique) [10:26] the end of the message contains this information, not sure if you read that far [10:26] I also worry because gustavo wants to use this for overmount [10:26] and I want to have a generic solution, not something that only sometimes kind of works [10:26] I also suspect it's going to get more hairy if we use overlayfs [10:27] but I didn't try [10:27] zyga: ok, I clearly have not dived deep enough yet [10:27] I'm trying from simple towards complex and I already got to a point where I feel stuck [10:27] mvo: if the create-key problem is hard to reproduce we can go ahead with the sru verification and add a link to the bug (which wouldn't be a regression in any case), wdyt? [10:29] zyga: looking [10:29] stgraber: hey, if you have a moment I could really use your insight: with https://forum.snapcraft.io/t/fixing-live-propagation-of-mount-changes/23/14 [10:29] * zyga rallies all the people that know more than he does [10:31] pedronis: after adding "-device virtio-rng-pci" to the kvm command line create-key finally ended taking "only" 9min, so seems to be related to the available entropy as you pointed out [10:31] fgimenez: so on a linode instance its taking more than 15 min already [10:31] fgimenez: do you know if there is something we added to the ubuntu images on linode to improve things? [10:32] I guess we have rng-tools installed there [10:32] morphis_: not sure, we should try to find a way, with a regular kvm invokation here it takes more than 30min [10:34] fgimenez: ok, activate rng-tools on the debian image with HRNGDEVICE=/dev/urandom and that makes things pretty fast [10:35] morphis_: \o/ we should do the same for the ubuntu images [10:35] fgimenez: https://www.howtoforge.com/helping-the-random-number-generator-to-gain-enough-entropy-with-rng-tools-debian-lenny [10:36] I am hacking that for now into my PR [10:36] morphis_: great thanks! [10:39] fgimenez: https://github.com/snapcore/snapd/pull/3156/commits/1ea78835c4aebd911a5702d3d352c3f5e9a0fa7a [10:39] PR snapd#3156: many: support debian in our CI [10:39] lets see how that goes [10:42] morphis_: ha, interesting [10:42] morphis_: so debian defaults to /dev/random which uses real randomness [10:42] morphis_: but we somehow default to /dev/urandom [10:42] yes [10:43] morphis_: so a fresh VM without any entropy has a hard time generating all those keys [10:43] * zyga really thinks VM providers should offer virtualized randomness [10:44] fgimenez: seems to work well :-) [10:46] zyga: a bit confusing that we have two test cases: classic-confinement and confinement-classic :-) [10:46] morphis_: yes, I know; I think we could roll them into one but they do slightly different checks [10:46] zyga: just use this: http://phoeagon.github.io/dev-random-as-a-service/ ;-þ [10:47] tbr: I'd rather use a virtio passthru from the VM provider [10:53] morphis_: there are new bug reports on redhat bugzilla [10:53] morphis_: are you tracking those? [10:54] tbr, oh, cool they also offer /dev/null and /dev/zero as a service! [10:55] ogra_: full spectrum offering! [10:55] yea, now thats a business model one can relate to ... [10:56] ogra_: /etc/passwd as a service :D [10:56] zyga, you should suggest that to them ... shadow as well :) [10:57] zyga: I am wondering why I don't get notifications for those [10:58] morphis_: not sure, just wanted to ask [10:58] zyga: but yeah, see them [10:58] morphis_: great, thanks for checking [10:59] zyga: I see four open bugs, https://apps.fedoraproject.org/packages/snapd/bugs [10:59] yep [10:59] good [11:07] mvo: do you have the commands at hand you use to generate the vendored releae tarball for snapd? [11:10] mvo, morphis: any ideas on the mount questions I posted? [11:12] morphis_: I just use the snapd orig.tar.gz from the ubuntu upload and rename the dir, why? [11:12] morphis_: I had meant to write a proper script but not happend yet [11:13] mvo: as we miss certain assembler files in the tarball [11:13] morphis_: oh? which ones? [11:13] mvo: like the .s files from https://github.com/golang/crypto/tree/master/salsa20/salsa [11:13] morphis_: the vendor tree is generated from ./get-deps.sh [11:13] * mvo looks [11:14] mvo: do we build with gccgo on Ubuntu? [11:14] morphis_: no, but we have a test that excercises gccgo [11:14] hm [11:14] mvo: as https://github.com/golang/crypto/blob/master/salsa20/salsa/salsa20_amd64.go has an explicit !gccgo and refers to the .s file for amd64 builds [11:15] zyga: not yet [11:16] morphis_: I downloaded https://github.com/snapcore/snapd/releases/tag/2.24 the vendor.tar.xz and I have the salsa2020_amd64.s file here [11:17] mvo: hm, why do we miss it then on fedora [11:19] mvo: ok, nevermind I will find out why [11:20] morphis_: keep me updated please [11:20] will do [11:21] mvo: thanks for approval! [11:28] morphis_: the vendor.tar.xz is a full tarball [11:28] it's not just snapd-2.24/vendor/ [11:29] if I were to apply it on top of the regular tarball, it'd be wasteful [11:48] PR snapcraft#1270 closed: release changelog for 2.29 === chihchun is now known as chihchun_afk [11:56] PR snapd#3217 opened: snap: support for snap tasks --last= [12:02] ogra_: just fyi - I'm going to build a new core with the stock xenial systemd to help steve with diagnosing the systemd issue we were seeing [12:04] mvo, fine with me if that doesnt get in the way of the release [12:05] (i actually held back any manual builds til next week to not interfer ... i,.e. for the cound-init stuff) [12:05] ogra_: hm, good point. I will revert right after I created an image then [12:06] mvo, also ... bug 1650688 seems to go in the direction you proposed ... which means we'll need patches in the systemd package again ... [12:06] Bug #1650688: timedatectl set-timezone fails on UC16 [12:06] (orthogonal ... but relevant i think) [12:08] ogra_: aha, thanks, I have not checked. I think I prepared a patch for this (iirc), its pretty small and close to the atomic_rename so hopefully things will not be a (huge) pain to maintain [12:09] mvo, right, that patch was what i meant ... i think we should test it soon ... but that means we'll again carry a patched systemd [12:09] PR snapcraft#1274 opened: Simple explanation of what the test groups mean [12:09] ogra_: yeah, its slightly horrible but I see no real alternative currently [12:09] yep [12:12] mvo: is 2.24 going out today? [12:19] Son_Goku: there is an ongoing discussion with JamieBennett and awe about this right now [12:19] I'd really like to know if I should be pushing the button now [12:19] as I was previously told I should hold everything back for Ubuntu... [12:20] Son_Goku, we have a release that needs to happen with the current stable on Monday, we have been asked to hold off the 2.24 promotion to stable until then [12:20] I will talk to awe again today about it [12:21] Son_Goku: my (personal) opinion is that 2.24 is fine to push into fedora or anywhere, it had its source release. its fine IMO if the core snap is not yet on 2.24 [12:21] Son_Goku: I agree with mvo here, [12:21] mvo, Son_Goku I agree [12:21] but thats just me :) [12:21] we should send it out [12:21] I'd rather push it now then :D [12:21] aha, apparently not just me! [12:21] :-) [12:21] * zyga bangs head on the kernel [12:21] and mount namespaces come out [12:21] we also pushed it into ubuntu-proposed [12:21] push for F24 done [12:22] thank you! [12:22] * zyga updates [12:22] push for F25 done [12:22] We will not change the 2.24 release now, just delay it due to another dependency that the core team do not control [12:22] btw, I will create a new interface [12:22] zyga: for me its systemd-network that I push my head against [12:22] thanks Son_Goku [12:22] simple one but ... cool and something I wanted for a long time [12:22] zyga, so for proper namespace support we need to ship your head with the kernel ? [12:22] push for F26 done [12:22] Rawhide already has it [12:22] yeah, exactly. 2.24 is done. there might be an official 2.24.1 or something but that would be a new release [12:23] mvo: I really like this, I just wish it wasn't going in circles; the mount backend is very important for users [12:23] zyga: +100 [12:23] I have 6 tests now but with a new approach only one passes [12:24] I think the kernel interface for this is really terrible [12:24] I need to look at what the kernel does again :/ [12:24] I'd say that one bit is missing [12:24] NicolinoCuralli (cc pedronis): re kernel reviews> for the irc backlog, it normally doesn't take very long, but sometimes further discussion is required. I'm answering NicolinoCuralli's specific questions in privmsg [12:24] the mount source disambiguator [12:24] of some kind [12:24] JamieBennett, mvo, zyga: snapd 2.24 will sync out to updates to all supported Fedora releases later today [12:24] hopefully [12:24] either today or tomorrow, depending on when the update masher runs [12:25] Thank you! [12:25] it doesn't look like it's been kicked off yet, so it might even be today [12:44] mvo: could you please review https://github.com/snapcore/snapd/pull/3209 [12:44] PR snapd#3209: interfaces/mount: add partial implementation of Change.Needed [12:44] and https://github.com/snapcore/snapd/pull/3138 if you don't mind [12:44] PR snapd#3138: interfaces/mount: add Change.Perform [12:44] mvo and https://github.com/snapcore/snapd/pull/3216 [12:44] PR snapd#3216: cmd/snap-update-ns: add actual implementation [12:53] davidcalle: https://github.com/CanonicalLtd/snappy-docs/pull/71 [12:53] PR CanonicalLtd/snappy-docs#71: Update Fedora snapd version to 2.24 [13:04] Son_Goku: you submitted to stable already? [13:04] morphis_: yes, now I just have to wait for Bodhi masher to sync them out [13:05] despite that 2.24 isn't yet official? [13:06] morphis_: yes, read above please [13:07] zyga: I did, however the rational from my side to hold back until 2.24 (or any other release) is marked official is, that there might be changes which depend on the corresponding core snap [13:07] in this case I am sure there are not but that is general thing we need to keep in mind [13:08] morphis_: we are currently a bit out of sync because of soemthing else going on. normally it would all be in sync [13:08] zyga: like if we do the /etc change in snap-confine we have a dependency [13:08] morphis_: yes, that's true [13:08] mvo: yeah [13:09] mvo, zyga: wouldn't it make sense to label a release when we announce it more as a candidate? [13:09] as that is what we do, we push a new core snap to candidate and start extensive testing before we move to stable [13:09] if we can enforce somehow that we put use release-candidate releases instead o stable once that would make it obvious to the public that the release isn't done yet [13:14] morphis_: (in a meeting so a bit slow) - worth to discuss it. to me 2.24 is the upstream release, the other parts are downstream. just like e.g. libreoffice releases but distros take a bit to push it into their system. [13:15] mvo: right but isn't a core snap always aligned with a snapd release? [13:15] mvo: but we can discuss later when you have more time [13:17] hi all: i want to enable i2c by gadget on my board. my board offer /sys/devices/platform/soc/1c2b000.i2c/i2c-0/0-0062/leds/pca963x:red/brightness - is it correct to set in gadget the following [13:17] slots: [13:17] i2c_leds: [13:17] interface: i2c [13:17] path: /sys/devices/platform/soc/1c2b000.i2c/i2c-0 [13:17] i infer this from test of snapd [13:17] NicolinoCuralli: you may (perhaps) even just give the symbolic path, but not sure [13:17] NicolinoCuralli: I did this a while ago [13:17] * zyga is in a call [13:18] Son_Goku: any idea about this: https://paste.ubuntu.com/24426706/ [13:18] Son_Goku: I see this with mock --with vendorized [13:19] seems like the tarball has a problem? [13:22] Son_Goku: no, but I figured it out [13:22] what was the issue? [13:23] Son_Goku: problem is that we install the go code and run tests afterwards [13:23] so snapd source end up /usr/share/.. [13:23] then tests are running and they take the vendor dir from /usr/share/... which don't have the .s files [13:24] ah [13:24] so for vendorized build, the .s files need to be copied too :) [13:26] Son_Goku: right [13:26] fixing that [13:26] Son_Goku: btw. we need to land another package for running tests with a non-vendorized build [13:26] huh? [13:26] oh, a new godep? [13:27] https://github.com/snapcore/snapd/blob/master/tests/lib/fakestore/store/store.go#L34 [13:28] at least go test github.com/snapcore/snapd/... wants to build and run the test case for that one too [13:28]