| === chihchun_afk is now known as chihchun | ||
| === JanC is now known as Guest10980 | ||
| === JanC_ is now known as JanC | ||
| zyga | good morning | 07:01 |
|---|---|---|
| zyga | mvo: hey, do you prefer to talk here or do a hangout to introduce the problem quickly and then talk here? | 07:01 |
| mvo | zyga: here or in the forum so that other may also benefit | 07:08 |
| zyga | mvo: ok, let's do a quick conversation here, the rest can be done on the update-ns thread | 07:08 |
| zyga | mvo: the first thing to look at is the general algorithm of the tool: https://github.com/snapcore/snapd/pull/3216/files | 07:09 |
| mup | PR snapd#3216: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3216> | 07:09 |
| zyga | That code is fairly well commented and simple | 07:09 |
| zyga | there are two kinds of input apart from the snap name | 07:09 |
| zyga | the snapd-created mount profile | 07:09 |
| zyga | and the kernel-maintained mount table | 07:10 |
| zyga | 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:10 |
| zyga | 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 |
| zyga | 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:11 |
| zyga | 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 |
| zyga | so we cross check each change with the mountinfo table | 07:12 |
| zyga | and here is where the dragons are | 07:12 |
| zyga | the interfaces/mount.Change.Needed function is non trivial | 07:13 |
| zyga | before we jump into that, please let me know if this makes sense so far and if you have any questions? | 07:14 |
| mvo | zyga: so far so good | 07:18 |
| zyga | ok | 07:24 |
| zyga | 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 |
| zyga | 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:25 |
| zyga | 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 |
| mup | PR snapcraft#1272 opened: tests: initial setup for the snapcraft snap tests with spread <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1272> | 07:26 |
| zyga | as an example, I mounted tmpfs in my home directory "/home/zyga/data" | 07:27 |
| zyga | then the Root field of that entry is "/" as the "whole" tmpfs is mounted there | 07:27 |
| zyga | then I created a directory "/home/zyga/data/foo" and similarly "bar" | 07:28 |
| zyga | and bind mounted foo over bar | 07:28 |
| zyga | so now the subtree rooted at "/foo" (relative to the tmpfs itself) is mounted | 07:28 |
| zyga | and the mountinfo entry for that speaks about MountDir: "/home/zyga/data/bar", with Root: "/foo" | 07:29 |
| zyga | what is problematic now is that it's hard to know what is "/foo" relative to, we only see "tmpfs" filesystem name | 07:29 |
| zyga | and arbitrary and irrelevant "none" that I passed as device name (via mount -t tmpfs none /home/zyga/data) | 07:29 |
| zyga | 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 |
| zyga | there are two more pieces of information | 07:30 |
| zyga | each mount entry has two numeric values: MountID and ParentID | 07:30 |
| zyga | in the example I was describing so far the root filesystem has MountID of 25 | 07:31 |
| zyga | the /home/zyga/data tmpfs has MountID of 392 and ParentID of 25 | 07:31 |
| zyga | the /home/zyga/data/foo -> /home/zyga/data/bar bind-mount has MountID 400 and ParentID of 392 | 07:32 |
| zyga | so here's my issue now: | 07:32 |
| zyga | 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 |
| zyga | I was hoping we don't | 07:33 |
| zyga | the algorithm for solving the issue that I wrote so far was based on the following idea: | 07:33 |
| zyga | when we are asked to perform a mount change | 07:33 |
| zyga | to check if that thing is mounted already (for bind mounts) | 07:34 |
| zyga | (because only bind mounts are harder) | 07:34 |
| zyga | (perhaps I should explain why: because regular mounts describe what is mounted and where it is to be mounted fully | 07:34 |
| zyga | while bind mounts describe the source indirectly | 07:34 |
| zyga | as we don't know what is the nature of /home/zyga/data/foo from the fstab-like entry | 07:35 |
| zyga | we just know we need to mount it on /home/zyga/data/bar | 07:35 |
| zyga | so the idea behind that algorithm is as follows: | 07:35 |
| zyga | look at the source of the bind mount (/home/zyga/data/foo) and resolve it to something absolute | 07:35 |
| zyga | I chose to use the mounted device (e.g. /dev/sda2, but this breaks apart with tmpfs) | 07:36 |
| zyga | and a path relative to that device | 07:36 |
| zyga | (or to a filesystem on that device) | 07:36 |
| zyga | and then compute all the things that are exactly the same | 07:36 |
| zyga | so we get a set in return | 07:36 |
| zyga | and if the destination of a bind mount is in that set we don't need to perform the change | 07:36 |
| zyga | this works well for simple examples but for this tmpfs example I referred to it falls apart | 07:37 |
| zyga | and I think I need to start using the MountID and ParentID | 07:37 |
| zyga | unfortunately there's no easier way to check as far as I know | 07:37 |
| zyga | let me know if this makes sense, I can show you what I have (the implementation of interfaces/mount/AliasesOf) | 07:37 |
| zyga | and the array of tests I wrote | 07:37 |
| morphis_ | 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 |
| zyga | I can also convert this to a forum topic | 07:38 |
| mvo | zyga: I think it does make sense | 07:38 |
| mvo | zyga: this is all in the PR, right? | 07:38 |
| mvo | 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 |
| morphis_ | mvo: great! | 07:39 |
| zyga | mvo: I'll break to eat some breakfast and be back here soon | 07:39 |
| mvo | 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:39 |
| zyga | mvo: maybe look at mountinfo and see what you make of it | 07:40 |
| zyga | mvo: specifically look how it looks like for snaps | 07:40 |
| zyga | mvo: for tmpfs'es | 07:40 |
| zyga | mvo: and regular filesystems | 07:40 |
| zyga | mvo: just to build some extra intuition | 07:40 |
| zyga | mvo: note that mountinfo is specific to the namespace your are observing it from | 07:40 |
| zyga | mvo: so you may want to nsenter to a snap mount namespace as well | 07:41 |
| mvo | zyga: ta | 07:41 |
| * zyga -> breakfast | 07:41 | |
| morphis_ | mvo, zyga: do you guys have time for another review on https://github.com/snapcore/snapd/pull/3177 today? | 07:44 |
| mup | PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177> | 07:44 |
| mvo | morphis_: yes | 07:49 |
| morphis_ | mvo: thanks | 07:52 |
| mvo | pstolowski: hm,hm, I would love to merge 3119 but I think we need a gustavo review first? | 08:05 |
| pstolowski | mvo, indeed | 08:05 |
| fgimenez | 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:11 |
| fgimenez | mvo: we found this in the branch that enabled expect tests for ubuntu-core systems, not until now on classic | 08:12 |
| mvo | fgimenez: and it also hangs outside the tests? | 08:12 |
| fgimenez | mvo: yep, i've tried manually on an up to date zesty and it hangs | 08:13 |
| mvo | fgimenez: could you do a quick check if previous versions of snapd on zesty were also affected? | 08:13 |
| fgimenez | mvo: sure on it | 08:13 |
| mvo | fgimenez: thank you! if its a regression we need to do something, otherwise its ok, but obviously this needs attention :) | 08:13 |
| mup | PR snapcraft#1273 opened: Check snap name <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1273> | 08:17 |
| fgimenez | mvo: with 2.23.6+17.04.1 it hangs too http://paste.ubuntu.com/24425510/ | 08:22 |
| mvo | fgimenez: ok, "great" | 08:23 |
| mvo | fgimenez: at least not a regression but this needs urgent attention, can you please create a forum topic and tag upcoming? | 08:24 |
| mvo | 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:24 |
| fgimenez | mvo: sure, i'll update the sru bug too once the test run ends, only a few of them remaining | 08:25 |
| mvo | ta | 08:30 |
| fgimenez | mvo: https://forum.snapcraft.io/t/snap-create-key-timeouts/359 | 08:37 |
| wligtenberg | q | 08:38 |
| pstolowski | $ snap changes everything | 08:43 |
| pstolowski | Yes, yes it does. | 08:43 |
| pstolowski | :) | 08:43 |
| mvo | fgimenez: hm, confusing, I just tried snap create-key in a 17.04 vm with 2.23.6 /2.24 it works | 08:55 |
| mvo | fgimenez: so maybe test related afterall? I ran the commands manually | 08:55 |
| fgimenez | mvo: mm i tried manually too, let me check again | 08:56 |
| mvo | fgimenez: what kind of machine? maybe I just need a different vm/machine. I can also test on real HW | 08:57 |
| mvo | fgimenez: if you can reproduce it, a ps afx would be nice, also an strace | 08:58 |
| fgimenez | mvo: yes, it hangs here, is your system up to date? maybe this is related to another package | 08:58 |
| mvo | fgimenez: i.e. ps to see if there is gpg running | 08:58 |
| martyix | Is there a web catalogue of existing snaps? I can't find it on https://snapcraft.io/ | 08:58 |
| fgimenez | mvo: sure, this is the strace http://paste.ubuntu.com/24425544/ | 08:58 |
| mvo | fgimenez: I upgraded it some minutes ago, but I did only install snapd from proposed, I can try everything from proposed now | 08:58 |
| fgimenez | mvo: same here, this is a vm created with "adt-buildvm-ubuntu-cloud -a amd64 -r zesty" | 08:59 |
| davidcalle | 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 | 08:59 |
| fgimenez | mvo: this is ps afx http://paste.ubuntu.com/24425624/ | 09:00 |
| martyix | davidcalle: I know about "snap find". It looks good, thanks | 09:00 |
| davidcalle | yw | 09:00 |
| === JanC is now known as Guest18582 | ||
| === JanC_ is now known as JanC | ||
| mvo | fgimenez: thanks, I will build a new vm just to be sure mine is not contaimiated ;) | 09:03 |
| fgimenez | mvo: great thanks, i'll do the same :) | 09:04 |
| === alan_g_ is now known as alan_g | ||
| morphis_ | mvo, fgimenez: I see the create-key issue too, on Linode (latest git) and on my desktop (2.23.6) | 09:31 |
| fgimenez | morphis_: thanks a lot for confirming! :) i'm seeing it too in my desktop, 2.23.1+16.10 | 09:34 |
| morphis_ | mvo, pedronis: any idea what that can be? | 09:34 |
| pedronis | morphis_: it works here with 2.24 | 09:35 |
| pedronis | morphis_: is the test that hangs, or just the command? | 09:35 |
| morphis_ | both | 09:35 |
| mvo | morphis_: I still cannot reproduce | 09:35 |
| morphis_ | I see it on https://github.com/snapcore/snapd/pull/3156 for debian too | 09:36 |
| mup | PR snapd#3156: many: support debian in our CI <Created by morphis> <https://github.com/snapcore/snapd/pull/3156> | 09:36 |
| morphis_ | pedronis: happy to provide more data | 09:36 |
| pedronis | mvo: yea, it works here too | 09:37 |
| morphis_ | pedronis: it doesn't seem to work with SNAP_REEXEC=0 too | 09:37 |
| pedronis | morphis_: what is your gpg --version ? | 09:39 |
| morphis_ | also tried after removing my $HOME/.snap dir | 09:39 |
| morphis_ | 1.4.20 | 09:39 |
| morphis_ | 1.4.20-1ubuntu3.1 | 09:39 |
| pedronis | same here | 09:40 |
| Chipaca | guys, i'm going to head back to bed and wait for this to boil over | 09:44 |
| Chipaca | see you on the other side | 09:44 |
| morphis_ | mvo: updated https://github.com/snapcore/snapd/pull/3177 with all requested changes | 09:45 |
| mup | PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177> | 09:45 |
| morphis_ | pedronis, fgimenez: ok, now it worked again | 09:47 |
| morphis_ | fgimenez: do we purge $HOME/.snap during the spread tests before every test is executed? | 09:48 |
| pedronis | morphis_: ? | 09:48 |
| morphis_ | pedronis: I did: mv $HOME/.snap $HOME/.snap-old and ran create-key again | 09:48 |
| fgimenez | morphis_: i don't think so, let me check | 09:48 |
| morphis_ | it took quite some time but finished now | 09:48 |
| morphis_ | pedronis: interestingly I have now two default keys | 09:49 |
| pedronis | well if you are creating the same key it should fail | 09:49 |
| pedronis | in which sense two default keys? | 09:49 |
| morphis_ | pedronis: https://paste.ubuntu.com/24425759/ | 09:50 |
| pedronis | that is very weird | 09:50 |
| morphis_ | it is | 09:50 |
| morphis_ | trying to reproduce that | 09:50 |
| morphis_ | pedronis: do we save any state information outside of $HOME/.snap? | 09:50 |
| NicolinoCuralli | 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 |
| pedronis | morphis_: no | 09:51 |
| pedronis | but we don't do locking either, wondering if gpg itself does locking | 09:51 |
| pedronis | anyway that looks like create-key was run twice | 09:51 |
| NicolinoCuralli | pedronis: your answwer are to me | 09:52 |
| NicolinoCuralli | ? | 09:52 |
| pedronis | NicolinoCuralli: no | 09:52 |
| mvo | morphis_: \o/ - I have a look | 09:53 |
| pedronis | 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 |
| pedronis | I mean the corresponding account-key | 09:53 |
| renat | Hi, guys! =) It's Renat from Screenly. | 09:54 |
| pedronis | this might change but atm is not a requirement nor are there tools to get it there | 09:54 |
| renat | I have a question about the timezone-control interface and the following ticket:https://bugs.launchpad.net/snappy/+bug/1650688 | 09:55 |
| mup | Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688> | 09:55 |
| renat | That part is pretty critical for our system and I wasn't able to make it working. | 09:56 |
| renat | What do you think about enabling write access to the /etc/writable/localtime? | 09:56 |
| renat | For those who connected to the timezone-control slot, of course. | 09:56 |
| NicolinoCuralli | 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:57 |
| morphis_ | pedronis: ok, couldn't reproduce this a second time | 09:58 |
| morphis_ | pedronis: feels like I had another `snap create-user` process still running in the background | 09:58 |
| pedronis | morphis_: yes | 09:58 |
| pedronis | 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 | 09:59 |
| morphis_ | fgimenez: maybe we need to give the test case just a higher timeout | 10:00 |
| pedronis | entropy issues? | 10:02 |
| NicolinoCuralli | pedronis: ok : for me this restriction is ok; what about the time for a answer about problems with kernel and gaddget i uploaded? | 10:02 |
| fgimenez | 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 |
| pedronis | NicolinoCuralli: I don't understand that question? | 10:03 |
| morphis_ | fgimenez: wow, that is a lot | 10:03 |
| NicolinoCuralli | pedronis: how many time the review for kernel and/or gadget takes ? | 10:05 |
| pedronis | NicolinoCuralli: ah, I don't know, I would ping jdstrand when is around here, he might know who to ping | 10:06 |
| NicolinoCuralli | pedronis : thanks, i pinged jdstrand | 10:12 |
| zyga | mvo: I wrote on the forum about my problem: https://forum.snapcraft.io/t/fixing-live-propagation-of-mount-changes/23 | 10:21 |
| zyga | morphis_: ^^ insight appreciated | 10:22 |
| mvo | zyga: yeah, just reading. so the kernel doc says that the mount-id is unique, does that help us? | 10:25 |
| zyga | 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:25 |
| zyga | 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 |
| zyga | the end of the message contains this information, not sure if you read that far | 10:26 |
| zyga | I also worry because gustavo wants to use this for overmount | 10:26 |
| zyga | and I want to have a generic solution, not something that only sometimes kind of works | 10:26 |
| zyga | I also suspect it's going to get more hairy if we use overlayfs | 10:26 |
| zyga | but I didn't try | 10:27 |
| mvo | zyga: ok, I clearly have not dived deep enough yet | 10:27 |
| zyga | I'm trying from simple towards complex and I already got to a point where I feel stuck | 10:27 |
| fgimenez | 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:27 |
| morphis_ | zyga: looking | 10:29 |
| zyga | 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:29 | |
| fgimenez | 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 |
| morphis_ | fgimenez: so on a linode instance its taking more than 15 min already | 10:31 |
| morphis_ | fgimenez: do you know if there is something we added to the ubuntu images on linode to improve things? | 10:31 |
| morphis_ | I guess we have rng-tools installed there | 10:32 |
| fgimenez | morphis_: not sure, we should try to find a way, with a regular kvm invokation here it takes more than 30min | 10:32 |
| morphis_ | fgimenez: ok, activate rng-tools on the debian image with HRNGDEVICE=/dev/urandom and that makes things pretty fast | 10:34 |
| fgimenez | morphis_: \o/ we should do the same for the ubuntu images | 10:35 |
| morphis_ | fgimenez: https://www.howtoforge.com/helping-the-random-number-generator-to-gain-enough-entropy-with-rng-tools-debian-lenny | 10:35 |
| morphis_ | I am hacking that for now into my PR | 10:36 |
| fgimenez | morphis_: great thanks! | 10:36 |
| morphis_ | fgimenez: https://github.com/snapcore/snapd/pull/3156/commits/1ea78835c4aebd911a5702d3d352c3f5e9a0fa7a | 10:39 |
| mup | PR snapd#3156: many: support debian in our CI <Created by morphis> <https://github.com/snapcore/snapd/pull/3156> | 10:39 |
| morphis_ | lets see how that goes | 10:39 |
| zyga | morphis_: ha, interesting | 10:42 |
| zyga | morphis_: so debian defaults to /dev/random which uses real randomness | 10:42 |
| zyga | morphis_: but we somehow default to /dev/urandom | 10:42 |
| morphis_ | yes | 10:42 |
| zyga | 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:43 | |
| morphis_ | fgimenez: seems to work well :-) | 10:44 |
| morphis_ | zyga: a bit confusing that we have two test cases: classic-confinement and confinement-classic :-) | 10:46 |
| zyga | morphis_: yes, I know; I think we could roll them into one but they do slightly different checks | 10:46 |
| tbr | zyga: just use this: http://phoeagon.github.io/dev-random-as-a-service/ ;-þ | 10:46 |
| zyga | tbr: I'd rather use a virtio passthru from the VM provider | 10:47 |
| zyga | morphis_: there are new bug reports on redhat bugzilla | 10:53 |
| zyga | morphis_: are you tracking those? | 10:53 |
| ogra_ | tbr, oh, cool they also offer /dev/null and /dev/zero as a service! | 10:54 |
| tbr | ogra_: full spectrum offering! | 10:55 |
| ogra_ | yea, now thats a business model one can relate to ... | 10:55 |
| zyga | ogra_: /etc/passwd as a service :D | 10:56 |
| ogra_ | zyga, you should suggest that to them ... shadow as well :) | 10:56 |
| morphis_ | zyga: I am wondering why I don't get notifications for those | 10:57 |
| zyga | morphis_: not sure, just wanted to ask | 10:58 |
| morphis_ | zyga: but yeah, see them | 10:58 |
| zyga | morphis_: great, thanks for checking | 10:58 |
| morphis_ | zyga: I see four open bugs, https://apps.fedoraproject.org/packages/snapd/bugs | 10:59 |
| zyga | yep | 10:59 |
| morphis_ | good | 10:59 |
| morphis_ | mvo: do you have the commands at hand you use to generate the vendored releae tarball for snapd? | 11:07 |
| zyga | mvo, morphis: any ideas on the mount questions I posted? | 11:10 |
| mvo | morphis_: I just use the snapd orig.tar.gz from the ubuntu upload and rename the dir, why? | 11:12 |
| mvo | morphis_: I had meant to write a proper script but not happend yet | 11:12 |
| morphis_ | mvo: as we miss certain assembler files in the tarball | 11:13 |
| mvo | morphis_: oh? which ones? | 11:13 |
| morphis_ | mvo: like the .s files from https://github.com/golang/crypto/tree/master/salsa20/salsa | 11:13 |
| mvo | morphis_: the vendor tree is generated from ./get-deps.sh | 11:13 |
| * mvo looks | 11:13 | |
| morphis_ | mvo: do we build with gccgo on Ubuntu? | 11:14 |
| mvo | morphis_: no, but we have a test that excercises gccgo | 11:14 |
| morphis_ | hm | 11:14 |
| morphis_ | 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:14 |
| morphis_ | zyga: not yet | 11:15 |
| mvo | 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:16 |
| morphis_ | mvo: hm, why do we miss it then on fedora | 11:17 |
| morphis_ | mvo: ok, nevermind I will find out why | 11:19 |
| mvo | morphis_: keep me updated please | 11:20 |
| morphis_ | will do | 11:20 |
| morphis_ | mvo: thanks for approval! | 11:21 |
| Son_Goku | morphis_: the vendor.tar.xz is a full tarball | 11:28 |
| Son_Goku | it's not just snapd-2.24/vendor/ | 11:28 |
| Son_Goku | if I were to apply it on top of the regular tarball, it'd be wasteful | 11:29 |
| mup | PR snapcraft#1270 closed: release changelog for 2.29 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1270> | 11:48 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#3217 opened: snap: support for snap tasks --last= <Created by stolowski> <https://github.com/snapcore/snapd/pull/3217> | 11:56 |
| mvo | 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:02 |
| ogra_ | mvo, fine with me if that doesnt get in the way of the release | 12:04 |
| ogra_ | (i actually held back any manual builds til next week to not interfer ... i,.e. for the cound-init stuff) | 12:05 |
| mvo | ogra_: hm, good point. I will revert right after I created an image then | 12:05 |
| ogra_ | 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 |
| mup | Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688> | 12:06 |
| ogra_ | (orthogonal ... but relevant i think) | 12:06 |
| mvo | 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:08 |
| ogra_ | 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 |
| mup | PR snapcraft#1274 opened: Simple explanation of what the test groups mean <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1274> | 12:09 |
| mvo | ogra_: yeah, its slightly horrible but I see no real alternative currently | 12:09 |
| ogra_ | yep | 12:09 |
| Son_Goku | mvo: is 2.24 going out today? | 12:12 |
| mvo | Son_Goku: there is an ongoing discussion with JamieBennett and awe about this right now | 12:19 |
| Son_Goku | I'd really like to know if I should be pushing the button now | 12:19 |
| Son_Goku | as I was previously told I should hold everything back for Ubuntu... | 12:19 |
| JamieBennett | 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 |
| JamieBennett | I will talk to awe again today about it | 12:20 |
| mvo | 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 |
| zyga | Son_Goku: I agree with mvo here, | 12:21 |
| JamieBennett | mvo, Son_Goku I agree | 12:21 |
| mvo | but thats just me :) | 12:21 |
| zyga | we should send it out | 12:21 |
| Son_Goku | I'd rather push it now then :D | 12:21 |
| mvo | aha, apparently not just me! | 12:21 |
| zyga | :-) | 12:21 |
| * zyga bangs head on the kernel | 12:21 | |
| zyga | and mount namespaces come out | 12:21 |
| mvo | we also pushed it into ubuntu-proposed | 12:21 |
| Son_Goku | push for F24 done | 12:21 |
| zyga | thank you! | 12:22 |
| * zyga updates | 12:22 | |
| Son_Goku | push for F25 done | 12:22 |
| JamieBennett | 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 |
| zyga | btw, I will create a new interface | 12:22 |
| mvo | zyga: for me its systemd-network that I push my head against | 12:22 |
| JamieBennett | thanks Son_Goku | 12:22 |
| zyga | simple one but ... cool and something I wanted for a long time | 12:22 |
| ogra_ | zyga, so for proper namespace support we need to ship your head with the kernel ? | 12:22 |
| Son_Goku | push for F26 done | 12:22 |
| Son_Goku | Rawhide already has it | 12:22 |
| mvo | yeah, exactly. 2.24 is done. there might be an official 2.24.1 or something but that would be a new release | 12:22 |
| zyga | mvo: I really like this, I just wish it wasn't going in circles; the mount backend is very important for users | 12:23 |
| mvo | zyga: +100 | 12:23 |
| zyga | I have 6 tests now but with a new approach only one passes | 12:23 |
| zyga | I think the kernel interface for this is really terrible | 12:24 |
| zyga | I need to look at what the kernel does again :/ | 12:24 |
| zyga | I'd say that one bit is missing | 12:24 |
| jdstrand | 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 |
| zyga | the mount source disambiguator | 12:24 |
| zyga | of some kind | 12:24 |
| Son_Goku | JamieBennett, mvo, zyga: snapd 2.24 will sync out to updates to all supported Fedora releases later today | 12:24 |
| Son_Goku | hopefully | 12:24 |
| Son_Goku | either today or tomorrow, depending on when the update masher runs | 12:24 |
| zyga | Thank you! | 12:25 |
| Son_Goku | it doesn't look like it's been kicked off yet, so it might even be today | 12:25 |
| zyga | mvo: could you please review https://github.com/snapcore/snapd/pull/3209 | 12:44 |
| mup | PR snapd#3209: interfaces/mount: add partial implementation of Change.Needed <Created by zyga> <https://github.com/snapcore/snapd/pull/3209> | 12:44 |
| zyga | and https://github.com/snapcore/snapd/pull/3138 if you don't mind | 12:44 |
| mup | PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138> | 12:44 |
| zyga | mvo and https://github.com/snapcore/snapd/pull/3216 | 12:44 |
| mup | PR snapd#3216: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3216> | 12:44 |
| Son_Goku | davidcalle: https://github.com/CanonicalLtd/snappy-docs/pull/71 | 12:53 |
| mup | PR CanonicalLtd/snappy-docs#71: Update Fedora snapd version to 2.24 <Created by Conan-Kudo> <https://github.com/CanonicalLtd/snappy-docs/pull/71> | 12:53 |
| morphis_ | Son_Goku: you submitted to stable already? | 13:04 |
| Son_Goku | morphis_: yes, now I just have to wait for Bodhi masher to sync them out | 13:04 |
| morphis_ | despite that 2.24 isn't yet official? | 13:05 |
| zyga | morphis_: yes, read above please | 13:06 |
| morphis_ | 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 |
| morphis_ | in this case I am sure there are not but that is general thing we need to keep in mind | 13:07 |
| mvo | morphis_: we are currently a bit out of sync because of soemthing else going on. normally it would all be in sync | 13:08 |
| morphis_ | zyga: like if we do the /etc change in snap-confine we have a dependency | 13:08 |
| zyga | morphis_: yes, that's true | 13:08 |
| morphis_ | mvo: yeah | 13:08 |
| morphis_ | mvo, zyga: wouldn't it make sense to label a release when we announce it more as a candidate? | 13:09 |
| morphis_ | 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 |
| morphis_ | 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:09 |
| mvo | 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:14 |
| morphis_ | mvo: right but isn't a core snap always aligned with a snapd release? | 13:15 |
| morphis_ | mvo: but we can discuss later when you have more time | 13:15 |
| NicolinoCuralli | 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 |
| NicolinoCuralli | slots: | 13:17 |
| NicolinoCuralli | i2c_leds: | 13:17 |
| NicolinoCuralli | interface: i2c | 13:17 |
| NicolinoCuralli | path: /sys/devices/platform/soc/1c2b000.i2c/i2c-0 | 13:17 |
| NicolinoCuralli | i infer this from test of snapd | 13:17 |
| zyga | NicolinoCuralli: you may (perhaps) even just give the symbolic path, but not sure | 13:17 |
| zyga | NicolinoCuralli: I did this a while ago | 13:17 |
| * zyga is in a call | 13:17 | |
| morphis_ | Son_Goku: any idea about this: https://paste.ubuntu.com/24426706/ | 13:18 |
| morphis_ | Son_Goku: I see this with mock --with vendorized | 13:18 |
| Son_Goku | seems like the tarball has a problem? | 13:19 |
| morphis_ | Son_Goku: no, but I figured it out | 13:22 |
| Son_Goku | what was the issue? | 13:22 |
| morphis_ | Son_Goku: problem is that we install the go code and run tests afterwards | 13:23 |
| morphis_ | so snapd source end up /usr/share/.. | 13:23 |
| morphis_ | then tests are running and they take the vendor dir from /usr/share/... which don't have the .s files | 13:23 |
| Son_Goku | ah | 13:24 |
| Son_Goku | so for vendorized build, the .s files need to be copied too :) | 13:24 |
| morphis_ | Son_Goku: right | 13:26 |
| morphis_ | fixing that | 13:26 |
| morphis_ | Son_Goku: btw. we need to land another package for running tests with a non-vendorized build | 13:26 |
| Son_Goku | huh? | 13:26 |
| Son_Goku | oh, a new godep? | 13:26 |
| morphis_ | https://github.com/snapcore/snapd/blob/master/tests/lib/fakestore/store/store.go#L34 | 13:27 |
| morphis_ | at least go test github.com/snapcore/snapd/... wants to build and run the test case for that one too | 13:28 |
| Son_Goku | morphis_: make a review request and we'll go from there | 13:28 |
| morphis_ | Son_Goku: yeah will do | 13:28 |
| === alan_g is now known as alan_g|afk | ||
| zyga | pedronis: thanks, I think you nailed it | 14:02 |
| zyga | The code is far shorter now and the two failing tests are not related, and looking at one of those (symmetry test) I think I understand how to fix it | 14:02 |
| Facu | sergiusens, elopio, this PR is all green and approved, but not merged... is anything missing from me in the procedure? thanks! https://github.com/snapcore/snapcraft/pull/1261 | 14:13 |
| mup | PR snapcraft#1261: storeapi: improve the error message for the case the Store answers an upload needs manual review <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1261> | 14:13 |
| lutostag | can somebody weigh in if this is expected? https://bugs.launchpad.net/snappy/+bug/1679210 | 14:24 |
| mup | Bug #1679210: snap install --revision tracks stable by default <Snappy:New> <https://launchpad.net/bugs/1679210> | 14:24 |
| ogra_ | lutostag, i think the point there is the "tracking" entry ... if you had done "snap install etcd --revision=48 --edge" it would switch to track edge and only upgrade to a new edge upload (not sure that helps your actual problem though, there is no pinning currently) | 14:27 |
| morphis_ | zyga, mvo: is it correct that we use CoreLibExecDir here https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_run.go#L249 ? | 14:27 |
| morphis_ | zyga, mvo: shouldn't that be DistroLibExecDir ? | 14:28 |
| lutostag | ogra_: yeah, I think pinning would work except for that it is still tracking a channel, the only way I can pin is if I specifically download, ack and install from disk, which is quite a silly thing to do | 14:29 |
| lutostag | ogra_: thanks for peeking at it though | 14:29 |
| morphis_ | zyga, mvo: looks to like we should only use CoreLibExecDir if want to reexec and otherwise use the distro one | 14:29 |
| mvo | morphis_: when snap-exec runs we are already inside the core snap, snap-confine has done all the setup, except for classic snaps i think | 14:32 |
| morphis_ | mvo: right but at this point (snap run) we decide which snap-exec we want to execute | 14:33 |
| morphis_ | but maybe the test case is then wrong instead | 14:33 |
| morphis_ | as the test case only uses DistroLibExecDir | 14:33 |
| morphis_ | which clashes when both CoreLibExecDir and DistroLibExecDir are different like on Fedora | 14:33 |
| mvo | morphis_: oh, that sounds like the test is wrong then. unless I miss something (classic mode is the exception) there is no way to run the host snap-exec, it always runs from core because the setup has already happend then | 14:34 |
| mvo | (the setup == the snap-confine chroot/mount magic) | 14:34 |
| morphis_ | ok | 14:34 |
| morphis_ | must be like this as its working well on Fedora just the test isn't :-) | 14:35 |
| morphis_ | niemeyer: if I am going to change the debian image on Linode again can you snapshot it? | 14:35 |
| sergiusens | Facu: we are in SRU release phase so don't land anything unless it is really urgent until we get a green light to land in -updates | 14:46 |
| === elfgoh_ is now known as elfgoh | ||
| zyga | morphis_: looking | 15:06 |
| zyga | morphis_: yes, we perhaps should tie this to reexec case | 15:06 |
| mvo | morphis_: 2592 is ready for a look, it still needs some love to move bits into the new "spec" interfaces code, but the basic idea is ready I think | 15:08 |
| ogra_ | jdstrand, should snaps actually be able to access i2c devices via sysfs (i wouldnt think so, but perhaps we need to improve the interface here) ? ... https://forum.snapcraft.io/t/how-can-i-declare-i2c-slot/364 | 15:09 |
| Facu | sergiusens, ah, thanks! | 15:10 |
| jdstrand | ogra_: responded in the forum | 15:22 |
| ogra_ | jdstrand, yeap, just "liked" it ;) | 15:22 |
| niemeyer | morphis_: Definitely.. I'd prefer to do that on Monday if that's okay, though, as today it's a national holiday here and I'm planning to take some time off the keyboard | 15:25 |
| morphis_ | niemeyer: sounds good! | 15:26 |
| jdstrand | mvo: that is a PR I'm interested in too. I gave a lot of feedback in the past, is it ready for me to look at again or are you just bringing morphis_ into the discussion? | 15:27 |
| === alan_g|afk is now known as alan_g | ||
| zyga | Pharaoh_Atem: is `dnf install --enablerepo=updates-testing` enabling that forever or just for one transaction? | 15:41 |
| Pharaoh_Atem | just for the one transaction | 15:42 |
| zyga | aha | 15:42 |
| Pharaoh_Atem | if you want to enable it permanently, use the following: | 15:42 |
| zyga | well, I have 2.24 now | 15:42 |
| Pharaoh_Atem | `dnf config-manager --set-enabled updates-testing` | 15:42 |
| zyga | no that's fine I was just surprised to see 2.24 on my machine :) | 15:42 |
| zyga | I'm spinning just one one problem wrt mount stuff | 15:42 |
| zyga | shadowing | 15:42 |
| zyga | everything else is good | 15:42 |
| Pharaoh_Atem | well 2.24 has been around for about a week in updates-testing | 15:43 |
| zyga | but I think I know how to fix it as well :-) | 15:43 |
| zyga | mvo: drama is (mostly) over I think | 16:04 |
| zyga | I'm adding tests now but I will soon open a PR | 16:04 |
| zyga | mvo: the advice from pedronis was brilliant and unblocked me | 16:04 |
| cachio | niemeyer, is there any way to rever the snap create-user? | 16:29 |
| genii | revert, reverse, revere? | 16:30 |
| cachio | niemeyer, It would simplify the tests that I am doing for the console conf | 16:30 |
| cachio | genii, revert | 16:31 |
| cachio | or delete | 16:31 |
| sborovkov | Hi. So I am bit confused by documentation of REST API of /v2/changes/id. I want to check 3 scenarios - error (that's covered by code 401). In progress and Done? So status code for both would be 200. Where is the documentation on what it will return for both cases? | 16:32 |
| elopio | Facu: we are just in the release process, so we will land new things on monday probably. | 16:36 |
| elopio | oh, sorry, I didn't see the reply from Sergio. What he said :) | 16:37 |
| mvo | jdstrand: I think its ready for a second look, there are some technicalities that I want to fix, so its fine to wait too, I want to make sure of the new "spec" system for interfaces, that needs some work still but the principle should be there now for sesson services at least | 16:40 |
| zyga | sborovkov: this is something chipaca would be best to answer | 16:45 |
| zyga | sborovkov: but I think you should ask this on forum.snapcraft.io | 16:45 |
| zyga | sborovkov: so that other people can find it and reuse the response | 16:45 |
| jdstrand | mvo: ack, at this point it probably won't be today, but I should be able to look at it early next week | 16:46 |
| mvo | jdstrand: hpefully I finished the remaining warts by then :) | 16:50 |
| jdstrand | :) | 17:02 |
| zyga | jdstrand: hey | 17:09 |
| zyga | jdstrand: would you have some time to look at https://github.com/snapcore/snapd/pull/3216 | 17:09 |
| mup | PR snapd#3216: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3216> | 17:09 |
| zyga | jdstrand: and perhaps https://github.com/zyga/snapd/commit/fa7fb5206ba87609729c494bf9b6ccaaed93ea9b | 17:10 |
| zyga | jdstrand: just RFC | 17:10 |
| zyga | that last commit is meaty in low level stuff | 17:10 |
| jdstrand | zyga: I've got a couple of things in front of it today, but I'll add it to the list | 17:20 |
| zyga | jdstrand: thanks, next week is fine | 17:21 |
| zyga | jdstrand: with some luck I'll resolve the TODOs by then :) | 17:22 |
| jdstrand | zyga: I say the forum post. yucky that mountinfo is being so annoying | 17:23 |
| jdstrand | saw* | 17:23 |
| zyga | jdstrand: pedronis gave me the tip that st_dev (aka major:minor numbers) is the key | 17:23 |
| zyga | jdstrand: now I'm down to shadowing | 17:24 |
| zyga | jdstrand: if you fetch my remote and look at the feature/update-ns/needed-2 branch | 17:24 |
| zyga | jdstrand: and "go test" in interfaces/mount | 17:24 |
| zyga | jdstrand: you will see the one test that fails because of overmount/shadowed mounts | 17:24 |
| zyga | jdstrand: but this is a huge improvement over the state in the morning :) | 17:25 |
| jdstrand | cool | 17:25 |
| zyga | jdstrand: I must say I wasn't aware what those numbers represent | 17:25 |
| zyga | jdstrand: especially since there's the "mount id" that was so confusing | 17:25 |
| zyga | jdstrand: st_dev doesn't shout like "unique device identifier" | 17:25 |
| jdstrand | heh | 17:25 |
| stgraber | zyga: ah good, I was about to point out that you can use the major:minor to see if a path comes from the expected device. Won't do you much good with virtual filesystems, but for anything block based it should help. | 17:25 |
| zyga | stgraber: it seems to work for tmpfs too | 17:26 |
| zyga | jdstrand: I'm still worried about effect of one mount hiding effect of earlier entries | 17:26 |
| zyga | jdstrand: not just simple shadowing but something more generic (e.g. bind mount something over /snap/core/ (which is not a mount point) | 17:27 |
| zyga | jdstrand: so I'm looking for a generic solution | 17:27 |
| zyga | I commented on the forum to update the state | 17:29 |
| zyga | /me -> break | 18:00 |
| === elfgoh_ is now known as elfgoh | ||
| mup | PR snapd#3218 opened: interfaces: allow writing to /run/systemd/journal/stdout by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3218> | 19:25 |
| Facu | somebody may help me with some snapcraft tests? I have a test case that uses the FakeTerminal fixture; the test currently errors, but the last thing I see is the "E", no other output (my guess is because terminal is being captured) | 19:37 |
| mup | PR snapd#3219 opened: interfaces/i2c: allow modifying device-specific sysfs entries <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3219> | 19:37 |
| mup | PR snapcraft#1275 opened: init: add a newline at the end of the file <Created by roxyd> <https://github.com/snapcore/snapcraft/pull/1275> | 20:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!