| mborzecki | morning | 04:15 |
|---|---|---|
| mup | PR snapd#5694 closed: tests/main/layout: cleanup after the test <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5694> | 05:39 |
| mborzecki | mvo: hey | 05:39 |
| mvo | hey mborzecki | 05:41 |
| mvo | zyga: can I merge 5307? | 05:41 |
| mvo | zyga: I would like to squash it, I would love to cherry pick this to 2.35 to fix core18s extrausers | 05:42 |
| mborzecki | mvo: could you take a look at https://github.com/snapcore/snapd/pull/5614 ? tha's a small change to the code + some tests | 05:54 |
| mup | PR #5614: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5614> | 05:54 |
| mvo | sure | 05:59 |
| * mvo looks | 06:00 | |
| mborzecki | mvo: thanks! | 06:00 |
| mvo | mborzecki: added some comments, sorry probably not strictly related to your pr but it seems its a good opportunity to improve this area | 06:26 |
| mborzecki | mvo: thanks, looking | 06:26 |
| mup | PR snapd#5698 closed: osutil: reorg and stub out things to get it building on darwin <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5698> | 06:27 |
| zyga | good morning! | 06:40 |
| zyga | mvo: looking | 06:40 |
| mvo | zyga: thanks | 06:41 |
| zyga | mvo: while jamie did not comment on the final look of the branch he didn't -1 the earlier version that wasn't much different | 06:41 |
| zyga | mvo: so I think yeah but the final call is up to you | 06:41 |
| zyga | mvo: in case jamie objects after the fact we can always roll out a .1 | 06:41 |
| * zyga had a small success by waking up the kids two hours earlier than usual | 06:41 | |
| mborzecki | zyga: hey | 06:42 |
| zyga | hey hey | 06:42 |
| mvo | zyga: ok, I see. hm,hm | 06:45 |
| zyga | jamie mentioned he was going to look at it | 06:45 |
| zyga | so it's in his queue | 06:45 |
| zyga | while fighting spread yesterday (the unexpected failure I saw over and over) I refreshed all of the images on https://spread.zygoon.pl/images/ | 06:47 |
| zyga | I'm wondering why they grow so much though, 18.10 is 2.5x bigger than 14.04 | 06:47 |
| mborzecki | zyga: maybe 1G of it is all 0s | 06:50 |
| zyga | the images are qcow2, that would not be needed | 06:50 |
| zyga | and indeed they are not zero as they took a while to send there | 06:50 |
| mborzecki | zyga: maybe cached packages were left behind? | 06:54 |
| zyga | mborzecki: hmm, maybe but I used the same tool for all of those | 06:55 |
| zyga | I'll jump into those images if I have some time | 06:55 |
| zyga | I was just curious | 06:55 |
| mborzecki | zyga: a trick i use to be able to quick revert back to the clean image is to do a clean install, then use that image a backing file for qcow2 images, then you just have the diff images that you can rebase/commit once they are good enough | 07:00 |
| zyga | mborzecki: how do you rebase/diff things? | 07:00 |
| zyga | I never did that myself | 07:00 |
| mborzecki | qemu-img create -f qcow2 -b your-clean-install.img img-with-diff.img; do stuff inside, then qemu-img commit to move the changes back to the original image, or qemu-img rebase if you have an image chain | 07:03 |
| mborzecki | zyga: real life saver in case you screw up the os in the image at some point :P | 07:03 |
| zyga | interesting, and are the images aware of each other directly or do I need to tell qemu to use a chain somehow? | 07:03 |
| mborzecki | zyga: it's recorded in the image file | 07:03 |
| zyga | brb | 07:08 |
| mborzecki | mvo: pushed the changes to https://github.com/snapcore/snapd/pull/5614 | 07:09 |
| mup | PR #5614: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5614> | 07:09 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:10 |
| mborzecki | pstolowski: hey | 07:11 |
| mborzecki | wonder if i could push the parallel-installs-interfaces spread test to 5614 | 07:13 |
| zyga | re | 07:13 |
| mborzecki | got to go out for a while, back in ~1h or so | 07:15 |
| === doko_ is now known as doko | ||
| Gargoyle | zyga: jdstrand: Same problem with snap 2.35 and kernel 4.18.3. :-/ | 07:59 |
| zyga | can you provide the detailed denial please? | 08:00 |
| mborzecki | re | 08:01 |
| Gargoyle | Just trying to get it to spit one out | 08:02 |
| zyga | mvo: review on 5699 | 08:04 |
| mvo | zyga: thanks, looking | 08:05 |
| mvo | zyga: thanks for the review, I will fix the issue(s) | 08:06 |
| zyga | did you mean the sleep 1h? | 08:07 |
| zyga | that was the most curious thing to me | 08:07 |
| mvo | zyga: I replied, no I did not, I hit the wrong key | 08:07 |
| mvo | zyga: or maybe a freudian slip, my mind wanted to go to sleep for 1h (at least ;) | 08:07 |
| zyga | haha :-) | 08:07 |
| mvo | zyga: replied, I will look into alternatives to squid I think, something in a snap | 08:09 |
| Gargoyle | zyga: These are the only messages from "dmesg -w" while I ran "snap remove lxd" (which doesn't seem to have worked) and "snap remove postman", "snap install postman" which both seemed to work fine, but postman is not available to run. | 08:11 |
| Gargoyle | https://paste.ubuntu.com/p/Z5C742DfZ8/ | 08:11 |
| zyga | Gargoyle: STATUS messages are just information, they are not a denial yet. What happens when you install and run the "hello-world" snap? | 08:11 |
| mborzecki | mvo: pushed a spread test for parallel instances & interfaces to #5614 | 08:11 |
| mup | PR #5614: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5614> | 08:11 |
| Gargoyle | zyga: No errors from snap - seems to have installed fine, but I have no "hello-world" command to run. (Syslog output during the installation: https://paste.ubuntu.com/p/jgDwrkyK4k/) | 08:14 |
| zyga | how about snap run hello-world | 08:14 |
| mup | PR snapd#5700 opened: tests: significantly reduce execution time for managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/5700> | 08:15 |
| Gargoyle | zyga: Yup. That works! | 08:16 |
| zyga | ok | 08:16 |
| zyga | Gargoyle: can you try the snap you wanted to use before | 08:16 |
| Gargoyle | "snap run postman" works too. | 08:17 |
| Gargoyle | same for discord. | 08:17 |
| zyga | so the issue is fixed? | 08:17 |
| Gargoyle | Oh. No. | 08:18 |
| zyga | so what is the issue? | 08:19 |
| Gargoyle | They only work with "snap run discord". I cannot run just "discord" nor do they show in gnome. | 08:19 |
| zyga | log out and back in | 08:19 |
| Gargoyle | ok | 08:19 |
| Gargoyle | No joy. And now not even happy booting back into 4.15 kernel! :/ | 08:25 |
| zyga | welcome back, so what happened? | 08:25 |
| Gargoyle | same situation. "snap run discord" works, but as far as the rest of the system is concerned, discord doesn't exist. Same for postman. | 08:26 |
| zyga | so gnome doesn't see the application, right? | 08:26 |
| zyga | what does "which discord" tell you? | 08:27 |
| Gargoyle | correct | 08:27 |
| Gargoyle | "discord not found" | 08:27 |
| zyga | and what does "echo $PATH" print? | 08:27 |
| Gargoyle | . /home/paul/bin:/home/paul/.composer/vendor/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games | 08:28 |
| zyga | Gargoyle: interesting, are you setting PATH in your startup scripts anywhere? it seems to be influencing the default value that ought to also include /snap/bin/ | 08:28 |
| Gargoyle | zyga: Only in .zshrc where I have: "export PATH=$HOME/bin:$HOME/.composer/vendor/bin:/usr/local/bin:$PATH" | 08:30 |
| zyga | ah, you are using zsh | 08:30 |
| zyga | perhaps that's the reason stuff is not working for you | 08:31 |
| Gargoyle | yup | 08:31 |
| zyga | mborzecki: once you are back, do you remember if we had a way to inject environment into zsh; I recall a new systemd feature but I don't know if we ended up using it | 08:31 |
| mborzecki | zyga: iirc mvo came up with something that was shell agnostic | 08:32 |
| mborzecki | Gargoyle: are you using konsole by any chance? | 08:33 |
| zyga | Gargoyle: can you please do one more experiment, switch to bash, check of this fixes it; it will helps us scope the issue to just zsh | 08:33 |
| zyga | then we can go after that separately from any kernel issues | 08:34 |
| mvo | zyga: environment.d | 08:34 |
| zyga | mvo: anything I can man search for; I don't remember the details | 08:34 |
| mborzecki | updated arch package to 2.35 | 08:36 |
| Gargoyle | mborzecki: Nope. Default Gnome terminal | 08:36 |
| Gargoyle | zyga: yup. One sec | 08:36 |
| zyga | Gargoyle: I switched to zsh now, checking what shows up | 08:36 |
| mup | PR snapd#5701 opened: image: add type to seed.yaml to allow sorting in firstboot <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5701> | 08:38 |
| mborzecki | Gargoyle: are you on ubuntu? | 08:38 |
| mvo | pedronis: high level feedback on -^ would be great. if this looks sensible I will continue this path otherwise derive in firstboot | 08:38 |
| zyga | hm | 08:38 |
| zyga | I switched to zsh and I cannot log in | 08:38 |
| Gargoyle | mborzecki: Yup | 08:38 |
| * zyga wonders | 08:38 | |
| mborzecki | Gargoyle: can you post /etc/zsh/zprofile ? | 08:39 |
| Gargoyle | No difference in bash. | 08:39 |
| * zyga can log in now | 08:40 | |
| zyga | Gargoyle: I suspect you may need to reboot | 08:40 |
| Gargoyle | mborzecki: Nope. It doesn't exist. /etc/zsh/zprofile is just comments, too. | 08:40 |
| zyga | depending on how early the profiles are picked up | 08:40 |
| zyga | Gargoyle: I confirm that there's no /snap/bin in PATH now | 08:40 |
| zyga | and that will also explain why gnome shell doesn't see any snap apps | 08:40 |
| mborzecki | zyga: in zsh on ubuntu? | 08:41 |
| zyga | I'll reboot my system now and then look at environment.d | 08:41 |
| zyga | mborzecki: I switched to zsh yes | 08:41 |
| mborzecki | zyga: yeah, so there's a problem that ubuntu's zsh setup does not source /etc/profile files (while it does so on arch for instance) | 08:41 |
| mvo | zyga: fwiw, we added /usr/lib/environment.d/990-snapd.conf | 08:41 |
| zyga | mvo: I'll rebuild the package and see if it is used | 08:42 |
| mborzecki | zyga: iir there's a bug report for this, from ogra maybe? | 08:42 |
| zyga | thanks! | 08:42 |
| zyga | mvo: yes, that works! | 08:42 |
| zyga | I have /snap/bin at the end of path | 08:42 |
| zyga | and I see snaps in gnome shell | 08:42 |
| zyga | Gargoyle: I'm running 2.35 from package built from master, reexec won't give you all of that yet | 08:43 |
| zyga | I'll rebuild the release branch | 08:43 |
| mvo | zyga: this is in 2.34.2 already so should be ok | 08:43 |
| zyga | I see | 08:44 |
| mvo | (sorry, haven't followed the previous discussion so I may miss things) | 08:44 |
| zyga | Gargoyle: what's the version of the debian package you have, you can check with "apt-cache policy snapd" | 08:44 |
| Gargoyle | brb, rebooting | 08:44 |
| zyga | k | 08:44 |
| ogra | mborzecki, not mine, but i was active in it ... | 08:44 |
| mborzecki | zyga: https://forum.snapcraft.io/t/gnome-3-shell-snaps-integration/2678/12 | 08:44 |
| ogra | bug #1640514 | 08:45 |
| mup | Bug #1640514: /snap/bin is not added to the PATH when using zsh <patch> <Snappy:New> <snapd (Ubuntu):Confirmed> <zsh (Ubuntu):Confirmed> <https://launchpad.net/bugs/1640514> | 08:45 |
| ogra | and along with that bug #1637220 | 08:45 |
| mup | Bug #1637220: zsh has no /snap/bin in PATH <snapd (Ubuntu):Triaged> <zsh (Ubuntu):Confirmed> <https://launchpad.net/bugs/1637220> | 08:45 |
| zyga | thank you ogra | 08:46 |
| zyga | I will update those bugs | 08:46 |
| ogra | well, the fix only helps if people actually went to 18.04 | 08:46 |
| ogra | so leave the 16.04 tasks open | 08:46 |
| zyga | ogra: yeah, this does depend on recent enough systemd, right? | 08:47 |
| ogra | right | 08:47 |
| zyga | how do I add 16.04 task? | 08:47 |
| ogra | nominate foir series | 08:47 |
| zyga | how do I do that | 08:47 |
| zyga | I never did that before, I may not have rights to do that | 08:48 |
| ogra | there is a link | 08:48 |
| Gargoyle | zyga: https://paste.ubuntu.com/p/jGgcYf8DX5/ | 08:48 |
| ogra | everyone can nominate | 08:48 |
| ogra | approving the nomination is restricted ... | 08:48 |
| zyga | what do I need to click on, there's no "nominate" on the page | 08:49 |
| zyga | Gargoyle: so that seems ok | 08:49 |
| zyga | Gargoyle: I wonder what's different between our installations | 08:49 |
| ogra | zyga, done | 08:49 |
| zyga | ogra: what did you do :) | 08:49 |
| ogra | (the link right underneath the bug tasks with the little clock icon) | 08:50 |
| Gargoyle | OK. Purged 4.18 from the system, force re-installed 4.15 and reverted back to "snap core --stable". and my $PATH is back! https://paste.ubuntu.com/p/YSNyg67xP4/ | 08:50 |
| ogra | next to "Also affects distribution/package" | 08:50 |
| zyga | aha | 08:50 |
| zyga | ogra: hmmm, | 08:51 |
| zyga | ogra: I don't see that icon, I only see it now after you did the nomination | 08:51 |
| ogra | weird, thats a common function that everyone should have access to | 08:51 |
| ogra | nomination isnt restricted ... only approving the nomination is | 08:52 |
| Gargoyle | Only thing I can't do is remove lxd properly (so I can re-install) : https://paste.ubuntu.com/p/Rfr9gnSdQk/ | 08:52 |
| mup | Bug #1640514 changed: /snap/bin is not added to the PATH when using zsh <patch> <Snappy:Fix Released> <snapd (Ubuntu):Confirmed> <zsh (Ubuntu):Invalid> <snapd (Ubuntu | 08:52 |
| mup | Xenial):Confirmed> <zsh (Ubuntu Xenial):Invalid> <snapd (Ubuntu Bionic):Fix Released> <zsh (Ubuntu Bionic):Invalid> <https://launchpad.net/bugs/1640514> | 08:52 |
| zyga | Gargoyle: you may need to stop the containers first but I defer to stgraber | 08:53 |
| ogra | zyga, also ... i dont think it is invalid in zsh xenial ... the fact that environment handling got improved doesnt fix the fact that zsh's env handling isnt using standards | 08:53 |
| zyga | yeah but for _this_ bug I think it is invalid now | 08:54 |
| mborzecki | zyga: hm so i dropped /etc/profile.d/snapd.sh, and have only /usr/lib/environment.d/990-snapd.conf, and I don't see $SNAP_MOUNT_DIR/bin being added to my PATH | 08:54 |
| Gargoyle | I've used zsh since day 1, and not had problems. | 08:54 |
| zyga | mborzecki: I'm rebuilding 2.35 now from the release branch | 08:55 |
| zyga | I'll know soon :) | 08:55 |
| mborzecki | zyga: i'm on 2.35 on arch now ;) | 08:55 |
| zyga | maybe packaging skew? | 08:55 |
| zyga | mborzecki: 2.35 still has /etc/profile.d/apps-bin-path.sh | 08:56 |
| zyga | but also has /usr/lib/environment.d/990-snapd.conf | 08:56 |
| mborzecki | zyga: yesh, removed that manually here to check if environment.d works | 08:56 |
| zyga | mborzecki: interesting, only PATH is set, XDG_DATA_DIRS is not set at all | 08:57 |
| mborzecki | zyga: oh, so you do have PATH set in your setup via environment.d? | 08:57 |
| zyga | mborzecki: I _suspect_ so because I have empty profiles otherwise, let me reboot to check | 08:58 |
| ogra | zyga, well, if you prefer to put the blame on snapd ... :) (people come back to that bug when they hit the issue in 16.04... ) | 08:58 |
| mborzecki | zyga: can you do systemctl --user show-environment | grep PATH ? | 08:58 |
| zyga | mborzecki: sure, one sec | 08:58 |
| zyga | fyke% systemctl --user show-environment | grep PATH | 08:59 |
| zyga | PATH=/home/zyga/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin | 08:59 |
| zyga | WINDOWPATH=1 | 08:59 |
| mborzecki | zyga: heh, you have snap there, I don't :) | 09:01 |
| zyga | mborzecki: what do you have in /etc/environment.d | 09:01 |
| mborzecki | zyga: nothing, the file goes to /usr/lib/environment.d/ by default | 09:01 |
| zyga | ah sorry | 09:02 |
| zyga | I meant that one | 09:02 |
| zyga | what do you have in /usr/lib/environment.d/990-snapd.conf | 09:02 |
| zyga | did you reboot after installing that update? | 09:02 |
| mborzecki | zyga: yup | 09:03 |
| mup | PR snapd#5701 closed: image: add type to seed.yaml to allow sorting in firstboot <Core18> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5701> | 09:03 |
| Gargoyle | Any ideas how I can get rid of my "disabled,broken" lxd snap? https://paste.ubuntu.com/p/G2d9XV5Tx5/ | 09:04 |
| mborzecki | zyga: hmm https://bugs.archlinux.org/task/56716 uhh and https://bugs.archlinux.org/task/56683 and https://bugs.archlinux.org/task/47884 looks like PATH is overwritten on arch in /etc/profile | 09:04 |
| zyga | mmm, can you snap install lxd | 09:04 |
| zyga | and then remove all the containers | 09:04 |
| zyga | and then remove it again? | 09:05 |
| Gargoyle | nope. it thinks its already installed. "snap "lxd" is already installed, see 'snap help refresh'" | 09:05 |
| zyga | mborzecki: uh | 09:05 |
| zyga | Gargoyle: and snap remove lxd? | 09:05 |
| zyga | mborzecki: I'm happy systemd helps to clean up this mes | 09:05 |
| zyga | mess | 09:05 |
| Gargoyle | zyga: That's in that pastebin. Complaining about readonly filesystem | 09:06 |
| zyga | Gargoyle: can you reboot again, I suspect some things are mounted there; you can try to unmount them or just reboot (maybe, no promises) | 09:06 |
| Gargoyle | I'll give it a whirl, but it;s been broken for the last few reboots already | 09:07 |
| zyga | ah | 09:07 |
| zyga | then wait | 09:07 |
| zyga | check what is mounted | 09:08 |
| Gargoyle | Maybe I am not seeing the wood for all the trees:- https://paste.ubuntu.com/p/D2j94chnMd/ | 09:09 |
| zyga | hmm | 09:10 |
| zyga | I don't see anything | 09:10 |
| zyga | what is in /var/snap/lxd | 09:10 |
| Gargoyle | "common" | 09:11 |
| zyga | and inside? | 09:12 |
| Gargoyle | it goes all the way along: /var/snap/lxd/common/lxd/storage-pools/default/images/de2ea148defc21d223376e53ab10ff1bccd003d92d5e6c6822398494ad934859 . No sign of a symlink anyhwere | 09:12 |
| zyga | and you cannot rm -rf that yourself, right? | 09:12 |
| Gargoyle | nope. Not even as root | 09:13 |
| zyga | I think you may need to ask stgraber for help | 09:13 |
| zyga | maybe it's a zfs pool or something | 09:13 |
| zyga | I don't know exactly | 09:13 |
| zyga | opk | 09:13 |
| zyga | I need to jump into some code | 09:13 |
| Gargoyle | Save me, stgraber. You're my only hope! :P | 09:13 |
| pedronis | mvo: I commented on #5701, I still think we should do it in firstboot code | 09:13 |
| zyga | mborzecki: about environment.d | 09:13 |
| zyga | mborzecki: we don't set XDG_DATA_DIRS | 09:14 |
| mup | PR #5701: image: add type to seed.yaml to allow sorting in firstboot <Core18> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5701> | 09:14 |
| mborzecki | zyga: something fishy on arch, by the time it gets to /etc/profile the PATH does not contain any sign of snap | 09:14 |
| zyga | mborzecki: I think we should, right/ | 09:14 |
| mborzecki | zyga: yeah, i think so | 09:15 |
| zyga | I'll try to change that | 09:15 |
| mvo | pedronis: yeah, I noticed and already closed it. thanks for the quick feedback | 09:16 |
| mup | PR snapd#5702 opened: snap: add ByType sorting <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5702> | 09:18 |
| mvo | zyga: we need a snapd type, one issue is that we need a patch for it, i.e. if snapd is already installed we need to transition it | 09:19 |
| mvo | zyga: maybe we can get away without | 09:20 |
| zyga | mvo: reviewed | 09:20 |
| mvo | zyga: given that core18 is not stable yet and its not instalable anywhere else | 09:20 |
| zyga | mvo:why would we need a patch? | 09:20 |
| mvo | zyga: if you have snapd installed already | 09:20 |
| zyga | mvo: I mean, it's just snap info that would change | 09:20 |
| zyga | ah | 09:20 |
| zyga | I see | 09:20 |
| zyga | yeah | 09:20 |
| zyga | well | 09:20 |
| mvo | zyga: but yeah, I would love to add it | 09:20 |
| zyga | we could do in memory tweak | 09:21 |
| zyga | because it's clear it's special case | 09:21 |
| mvo | zyga: aha, nice idea, that would be a nice way out | 09:21 |
| zyga | and special casing on name or snap id as in other parts is clearly showing its cost | 09:21 |
| zyga | mvo: yeah, would not break rollback | 09:21 |
| zyga | so anyway | 09:21 |
| zyga | +1 but I wanted to voice that | 09:21 |
| mvo | zyga: ok, I will do it | 09:21 |
| * zyga hugs mvo | 09:21 | |
| * mvo hugs zyga | 09:21 | |
| zyga | let's add a type in one pr | 09:22 |
| zyga | and then tackle the issues like in-memory migration | 09:22 |
| zyga | and various uses | 09:22 |
| zyga | (so let's land this one as is) | 09:22 |
| mvo | zyga: yeah, I agree | 09:22 |
| mvo | zyga: I am in the middle of something else (firstboot ordering) but once that is done I will do the cleanup | 09:23 |
| * zyga nods | 09:23 | |
| zyga | I'll jump into something too but please drag me back when you are into it | 09:23 |
| mvo | zyga: thanks, will do | 09:23 |
| mborzecki | zyga: can you post your /etc/profile? | 09:24 |
| zyga | probably vanilla /etc/profile from bionic https://www.irccloud.com/pastebin/cCczVjri/ | 09:25 |
| zyga | mborzecki: note that we also have /etc/profile.d/ | 09:25 |
| mborzecki | zyga: can you grep -n systemd-environment /etc/profile.d/* ? | 09:26 |
| zyga | empty | 09:26 |
| zyga | (I mean, I ran: grep -n systemd-environment /etc/profile.d/*) | 09:26 |
| zyga | unless you meant something more | 09:27 |
| mborzecki | zyga: no, that's fine, I have no clue how stuff from systemd-environment-d-generator gets to your session then | 09:27 |
| zyga | I rebooted | 09:28 |
| zyga | I think it's set by systemd when it starts the session proceses | 09:28 |
| zyga | is arch using systemd as a session manager?\ | 09:28 |
| zyga | brb, getting hungry over essentially no breakfast | 09:28 |
| mborzecki | zyga: yeah, the manpages are not too helpful either | 09:29 |
| pstolowski | https://www.irccloud.com/pastebin/IzURDL3V/ | 09:31 |
| pstolowski | zyga: ^ i suspect this is known? i've seen it some time ago; now failed on fedora | 09:31 |
| pstolowski | zyga: travis log - https://api.travis-ci.org/v3/job/418670092/log.txt | 09:32 |
| mup | PR snapd#5702 closed: snap: add ByType sorting <Core18> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5702> | 09:32 |
| niemeyer | Heyo | 09:35 |
| niemeyer | Chipaca: Moin | 09:35 |
| Chipaca | niemeyer: hi | 09:35 |
| Chipaca | niemeyer: ssh, I'm not here | 09:35 |
| niemeyer | Chipaca: Did the notes on the PR make the idea more clear, or do you still think we have an issue in terms of aptch sublevels | 09:35 |
| niemeyer | Chipaca: Oh, is that a day off? | 09:35 |
| Chipaca | niemeyer: I'm not sure it'll dtrt wrt reverts to a pre-sublevel snapd and back | 09:36 |
| mvo | Chipaca: I can't read ssh without reading ssh (but I guess you meant ssssssh) - anyway, enjoy your day off | 09:36 |
| Chipaca | mvo: i meant shh | 09:36 |
| niemeyer | Chipaca: Ah, I see it is, sorry.. I had understood the holidays were next week on, sorry for the force disturbance.. :) | 09:37 |
| Chipaca | niemeyer: no worries, I'm the one in the channel | 09:37 |
| pedronis | mvo: I left a comment in 5702 about an open issue | 09:37 |
| pedronis | though I saw you closed it | 09:38 |
| mvo | pedronis: yeah, I was thinking about zygas comment | 09:38 |
| mvo | pedronis: but maybe I just do that in a followup | 09:38 |
| niemeyer | Chipaca: Well, I'm always on the channel as well :) Anyway, the idea is that pre-sublevel patches are just like post sublevel patches.. the sublevel zero is the one that introduces backwards incompatible changes. So when a revert occurs, nothing is applied.. when the revert is undone to a more recent sublevel, the patches are reapplied | 09:38 |
| niemeyer | Bye Chipaca :) | 09:38 |
| mvo | pedronis: sorry for the flip-flop, I think I will reopen and just do a followup with the snapd type | 09:38 |
| niemeyer | Anyway, the point is that I think we're good, unless I'm missing something | 09:39 |
| niemeyer | We just need to be careful with non-zero sublevels as they need to be idempotent | 09:39 |
| mup | PR snapd#5702 opened: snap: add ByType sorting <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5702> | 09:40 |
| pedronis | niemeyer: how do we know we reverted, sublevel unaware snapds will not touch patch-sublevel | 09:41 |
| niemeyer | pedronis: The behavior across levels is still the same | 09:41 |
| niemeyer | pedronis: 6 => 5 will blow up still | 09:42 |
| mborzecki | zyga: mvo: fwiw the environment.d generator does not seem to have effect on fedora either | 09:42 |
| pedronis | niemeyer: yes, but we cannot afford that, wasn't it the point of doing this | 09:42 |
| niemeyer | pedronis: As will 7 => 6.X | 09:42 |
| niemeyer | pedronis: No.. the point is that we can patch as 6.1, and have 6.0 untouched | 09:43 |
| niemeyer | pedronis: Hmm.. I see.. 6.0 won't actually mark it back as 6.0, so we won't see 6.1 reapplied.. hmm | 09:43 |
| pedronis | yes | 09:43 |
| pedronis | the issue is the preexisting level 6 snapd out there already | 09:43 |
| pedronis | (sorry I thought we were at 5 not 6 atm) | 09:44 |
| pedronis | current level 6 snapd doesn't know about sublevels | 09:45 |
| niemeyer | Yeah.. that part is sort of okay.. the problem is how to detect when 6.1 is reinstalled that it needs to reapply.. :/ | 09:46 |
| pedronis | yes | 09:46 |
| === sparkieg` is now known as sparkiegeek | ||
| niemeyer | pedronis: Only choice I see is special casing 6.0 | 09:47 |
| niemeyer | Well, the whole 6 series really.. we'll never know whether a revert to a 6.0 happened | 09:48 |
| niemeyer | Oh.. or will we | 09:49 |
| pedronis | or do something like what chipaca suggested detect we are reverting to a pre sublevel core/snapd and reset sublevel before restarting | 09:49 |
| pedronis | not super clear how to do the detecting though | 09:49 |
| niemeyer | We might be nastier than that and look at the history.. we have it in the state | 09:50 |
| niemeyer | Well, that sounds less nasty actually, in terms of proper isolation | 09:50 |
| pedronis | you mean look at what was the previous revision? | 09:51 |
| niemeyer | Right.. we have some good data available | 09:52 |
| niemeyer | We have the history, and we have a refresh timestamp | 09:54 |
| niemeyer | If the state level is 6, we can easily tell whether the refresh time was touched since the last restart, and if so whether we've been in a sublevel-blind revision recently | 09:56 |
| niemeyer | All of that just looking at the state, which we have at hand | 09:56 |
| niemeyer | pstolowski: ^ | 09:57 |
| niemeyer | The good thing is that we only need to kick that logic when the state level is 6 | 09:58 |
| pstolowski | reading | 09:59 |
| pstolowski | niemeyer: right.. i understand the problem of reverting back to sublevel-blind 6.0... not yet clear on the details of proposed logic, will need to check the code | 10:03 |
| pstolowski | btw, thanks for the review | 10:03 |
| pstolowski | (i'm on it atm) | 10:03 |
| pstolowski | pedronis: can you take a look at https://github.com/snapcore/snapd/pull/5700 when you have a moment? | 10:07 |
| mup | PR #5700: tests: significantly reduce execution time for managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/5700> | 10:07 |
| pedronis | pstolowski: yes, in a bit | 10:08 |
| pedronis | mborzecki: I'm not sure I understand which tests need to switch to sorting by name 5697 | 10:09 |
| pedronis | mborzecki: I would really like that we switched to use code mvo is working on 5702, so IÂ would like to understand how strongly we need the change | 10:11 |
| mborzecki | pedronis: this was just to ensure that tasksets get stable sorting | 10:12 |
| pedronis | mborzecki: which tests fail without though? the one you added, others? | 10:12 |
| mborzecki | pedronis: the one i added | 10:13 |
| pedronis | it's a bit bizarre because you need to play with the order of udpates anyway there | 10:13 |
| pedronis | is that still true? | 10:13 |
| mborzecki | pedronis: yes, it's still true, but those snaps are apps, so there have no inter-dependencies, the issue is caused by refreshCandidates and iterating on what snapstate.All() returns, which can have random order | 10:17 |
| mborzecki | pedronis: fwiw the list of updated snaps returned by UpdateMany() is also random, but since I can easily tell which is which they are reodered in the test as needed | 10:19 |
| pedronis | yes, but that makes the exercise bizarre | 10:19 |
| pedronis | this list random, this one is sorted | 10:19 |
| pedronis | because of tests | 10:19 |
| pedronis | doesn't sound good as an api to me | 10:19 |
| pedronis | also is sorted only if some kind of tasks are needed | 10:20 |
| niemeyer | pedronis, pstolowski: I've detailed the algorithm in the PR | 10:20 |
| Gargoyle | Fixed lxd. It was a btrfs subvolume. manually removed it with btrfs tools, and then re-enabled lxd and re-ran "lxd init". Seems happy now! :) | 10:20 |
| Gargoyle | There's only one down-side... | 10:21 |
| Gargoyle | Now I have to do some actual work! :P | 10:21 |
| mborzecki | pedronis: well, technicaly it's not a regression, right now both updated snaps and tasks sets are randomly ordered, but i get your point | 10:21 |
| mborzecki | pedronis: well, tasksets are semi semi randomly ordered, by kind, but then within the same kind it's random | 10:22 |
| pedronis | IÂ know, IÂ don't see a problem with that atm | 10:22 |
| pedronis | I'm just questioning making the order requirements more strict for a test | 10:23 |
| pedronis | (given that it make some coming refactoring a bit harder) | 10:23 |
| pedronis | and it doesn't really give a full ordered behavior to the api anyway (because is kind of hard) | 10:24 |
| mborzecki | pedronis: is there a way to figure out which snap the taskset corresponds to aside from interrogating task summary of poking its data? | 10:26 |
| pedronis | no, but is not so bad, we poke at the data all over the place | 10:26 |
| pedronis | in the tests | 10:26 |
| pedronis | they are tests after all | 10:26 |
| mborzecki | pedronis: well, maybe i could just expect one tasksets to be of some lengths, if there's other then signal an error, otherwise just use the legths to make the guess about the order | 10:27 |
| mborzecki | pedronis: i'll revert that ordering change and 'll try to find another way | 10:28 |
| pedronis | thanks | 10:28 |
| pstolowski | niemeyer: ty | 10:30 |
| pedronis | mborzecki: to be clear I agree that making output deterministic is best when is cheap and clear-cut, I don't think it's clear-cut here | 10:41 |
| niemeyer | pstolowski: np, the whole series is unblocked.. we need to have a conversation about the third-level down PR when you get there, about the API of ConnectReload etc | 10:42 |
| pedronis | mborzecki: btw adding a helper in snapstate_test that takes a taskset that is an install of some kind and gets the name of the snap is probably cheap and readable | 10:45 |
| pstolowski | niemeyer: the algorithm you outlined looks fine, although i wonder if the introduction of snapd snap changes anything. i'm also wondering if the problem can be simplified, but can't think of anything | 10:46 |
| mborzecki | pedronis: will do, i'm looking into some update-ns issues atm | 10:46 |
| pstolowski | mvo: applied you suggestion to #5686 | 10:47 |
| mup | PR #5686: overlord/ifacestate: introduce connectOpts <Created by stolowski> <https://github.com/snapcore/snapd/pull/5686> | 10:47 |
| mvo | pstolowski: thank you! | 10:48 |
| mup | PR snapd#5703 opened: firstboot: sort by type when installing the firstboot snaps <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5703> | 10:50 |
| niemeyer | pstolowski: The snapd snap should support sublevels from the get go, so it shouldn't change much | 10:54 |
| niemeyer | pstolowski: We do have it out already, but mainly for testing | 10:54 |
| niemeyer | pstolowski: By the time this gets widely used, sublevels should be in already | 10:55 |
| pstolowski | right | 10:57 |
| mup | PR snapd#5704 opened: snap: add new type "TypeSnapd" and attach to the snapd snap <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5704> | 11:12 |
| === pstolowski is now known as pstolowski|lunch | ||
| cachio | mvo, hey, core 2.35 was promoted to candidate yesterday | 11:42 |
| pedronis | mvo: maybe I'm just super confused, but I don't see the attaching code in #5704 | 11:44 |
| mup | PR #5704: snap: add new type "TypeSnapd" and attach to the snapd snap <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5704> | 11:44 |
| mup | PR snapd#5705 opened: testutil: have File* checker produce more useful error output <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5705> | 11:47 |
| mborzecki | simple review ^^ | 11:47 |
| cachio | niemeyer, hey, there is a PR to review on spread https://github.com/snapcore/spread/pull/66 | 11:50 |
| mup | PR spread#66: Define storage at system level <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/66> | 11:50 |
| cachio | niemeyer, please when you have time could you take a look to that? | 11:51 |
| pedronis | pstolowski|lunch: I commented on #5700 | 12:15 |
| mup | PR #5700: tests: significantly reduce execution time for managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/5700> | 12:15 |
| mup | PR snapcraft#2219 closed: Release changelog for 2.43 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2219> | 12:22 |
| mvo | pedronis: sorry, a missed git add, pushed for real now | 12:28 |
| mvo | cachio: great, thank you | 12:28 |
| === pstolowski|lunch is now known as pstolowski | ||
| zyga | hey | 12:38 |
| zyga | github.com resolves to 192.30.253.11{2,3} to me and I cannot ssh in anymore | 12:38 |
| zyga | is anyone else experiencing this? | 12:38 |
| zyga | mvo: reviewed the type PR now | 12:39 |
| mvo | zyga: ta | 12:41 |
| zyga | mvo: can you pull/push to GitHub? | 12:46 |
| mborzecki | zyga: seems to work here | 12:48 |
| zyga | hmm hmm hmm | 12:49 |
| zyga | odd | 12:49 |
| mvo | zyga: yes | 12:51 |
| mborzecki | mvo: can we update go-check in our vendor tree? | 12:55 |
| mvo | mborzecki: yes | 12:56 |
| mborzecki | mvo: the one that we have now has the bug when non empty error message raises an error regardless of Not() being used | 12:56 |
| mvo | mborzecki: oh, ok | 13:00 |
| mvo | mborzecki: standup? | 13:01 |
| mvo | mborzecki: then you can tell me all about it | 13:01 |
| mvo | zyga: -^ | 13:01 |
| mvo | pedronis: -^ | 13:01 |
| zyga | yeah | 13:01 |
| zyga | joining | 13:01 |
| zyga | jdstrand: hey, do you remember if we wanted to call the new adb interface "adb-support" or just "adb"? | 13:16 |
| niemeyer | zyga: There's a comment in the PR about it, and we are in the standup btw :) | 13:21 |
| zyga | niemeyer: you can switch camera later | 13:47 |
| zyga | if you join you can just go to the three dots in the lower-right corner | 13:47 |
| zyga | then go to settings there | 13:47 |
| zyga | and then pick the video / audio interface | 13:47 |
| zyga | niemeyer: I must have missed the adb vs adb-support decision, I remember reading that we _thought_ about it; thank you I will re-check | 13:48 |
| zyga | I think p2p video conferencing is not there yet | 13:50 |
| zyga | and hangouts work because google takes the traffic | 13:50 |
| niemeyer | Alright | 13:50 |
| niemeyer | That's super buggy unfortunately | 13:51 |
| niemeyer | I like the view, but it doesn't seem to work reliably at all | 13:51 |
| zyga | I'll break for lunch now | 13:51 |
| zyga | ttyl | 13:51 |
| niemeyer | I think that was a fail | 13:51 |
| niemeyer | The fact we spent most of the time asking whether we could hear each other and reconnecting is probably enough of a show stopper | 13:52 |
| mborzecki | it does bring back early skype memories though | 13:55 |
| roadmr | I see your skype and raise you ms netmeeting | 13:55 |
| roadmr | with those spherical webcams | 13:56 |
| roadmr | over a 64k ISDN line | 13:56 |
| mborzecki | or webex | 13:56 |
| roadmr | tandberg! | 13:56 |
| stgraber | Gargoyle: sorry, there's a lot of backlog in there, what can I do for you? | 13:56 |
| zyga | stgraber: cannot remove lxd data, some read-only filesystems | 13:58 |
| niemeyer | mborzecki: You mean the bad memories? :) | 13:58 |
| niemeyer | Zoom apparently needs an app/plugin to be installed, so also a no go.. | 13:59 |
| mborzecki | niemeyer: more like repressed memories :) | 13:59 |
| niemeyer | Man.. it's 2018 and video conferencing still sucks | 13:59 |
| mborzecki | wondering if someone came up with an idea of using cctv video feed for conferencing | 13:59 |
| zyga | Analog over IP | 14:01 |
| mup | PR snapd#5706 opened: snapstate: make InstallPath() return *snap.Info too <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5706> | 14:03 |
| roadmr | well clientless videoconferencing sucks, but nobody wants to install a proprietary client :P | 14:04 |
| roadmr | https://talky.io/ is not horrible | 14:06 |
| Son_Goku | niemeyer, in Mageia, we use jit.si for this stuff | 14:17 |
| niemeyer | Son_Goku: We just tried it.. it was crazy buggy :( | 14:17 |
| Son_Goku | damn :( | 14:17 |
| Son_Goku | how about Jangouts? | 14:17 |
| niemeyer | roadmr: talky.io is also pretty buggy.. it was responsible for one of the most hilarious bugs I've seen in a video conferencing application. One participant was only visible to half the participants | 14:18 |
| niemeyer | Can you imagine how funny the call was until we figured that out? :) | 14:18 |
| niemeyer | Son_Goku: Haven't tried that one | 14:18 |
| Son_Goku | https://github.com/jangouts/jangouts | 14:18 |
| niemeyer | zyga: Just reviewed #5469 | 14:19 |
| mup | PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469> | 14:19 |
| niemeyer | zyga: The main comments there are about pre-existing logic.. Alfonso may need a hand.. not sure. | 14:19 |
| Son_Goku | niemeyer, Red Hat uses Bluejeans | 14:19 |
| zyga | niemeyer: ack, I'll read that | 14:19 |
| Son_Goku | the few video calls I've had with teams at Red Hat were over that and it went pretty well | 14:20 |
| Son_Goku | https://www.bluejeans.com/ | 14:20 |
| niemeyer | Son_Goku: Yeah, bluejeans works a few times for me.. it was old fashioned, but worked okay | 14:20 |
| Son_Goku | it has an all-web mode too | 14:20 |
| niemeyer | Not sure if it works in the browser nowadays, though, or needs an app | 14:20 |
| niemeyer | Son_Goku: Ah, nice | 14:20 |
| Son_Goku | niemeyer: https://support.bluejeans.com/knowledge/join-from-browser | 14:21 |
| Son_Goku | the app is recommended (and really is a nicer experience), but the browser only option works in a pinch | 14:22 |
| Son_Goku | it's the principal reason Red Hat uses Bluejeans over other alternatives | 14:22 |
| niemeyer | We might even have a company account already.. I recall at least a couple of meetings over it in the past | 14:22 |
| roadmr | niemeyer: we (Canonical) do, yes. | 14:24 |
| roadmr | a problem with bluejeans is that some functionality on a computer still requires flash | 14:24 |
| Son_Goku | nope | 14:25 |
| Son_Goku | I don't even have Flash on my computer and pretty much the entire thing works now | 14:25 |
| Son_Goku | the only problem with it is that Macs will burn up because the WebRTC implementations on macOS suck | 14:26 |
| roadmr | Son_Goku: well some parts of it don't work here (Chromium on Ubuntu)... heh :( | 14:28 |
| Son_Goku | really? | 14:28 |
| roadmr | Son_Goku: I usually just use the app on my phone to see the video and use the web UI for the chat and QA stuff | 14:28 |
| roadmr | yes, really :) why would I pull your leg on this :D | 14:28 |
| Son_Goku | odd, I was using Chromium on Fedora for the last Koji Community Meeting and it worked okay | 14:28 |
| Son_Goku | but maybe I did something different? | 14:28 |
| roadmr | ah, it could also be somethingsomething on Canonical's settings/account. | 14:28 |
| roadmr | I've seen that with gotomeeting: unless the presenter enables it, browser access doesn't work and it pesters you to install a client. | 14:29 |
| * Son_Goku shrugs | 14:29 | |
| Son_Goku | that's probably the case | 14:29 |
| roadmr | hehe | 14:29 |
| niemeyer | roadmr: Thanks for the info, I'll try to find someone that can hand me access to an account | 14:29 |
| roadmr | inconsistent experiences! | 14:29 |
| Son_Goku | joy of joys, right? :D | 14:29 |
| roadmr | Son_Goku: absolutely \o/ (haha) | 14:29 |
| mup | PR snapd#5475 closed: WIP: remove unneeded calls to daemon-reload <Blocked> <Created by alfonsosanchezbeato> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5475> | 14:31 |
| Son_Goku | bbl g2g to work | 14:31 |
| mup | PR snapd#5495 closed: interfaces/builtin: initial version of the anbox-support interface <Created by morphis> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5495> | 14:34 |
| mup | PR snapd#5530 closed: tests: use file based markers in snap-service-stop-mode <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5530> | 14:38 |
| cachio | niemeyer, hey, I need this permission for the image-baker sa on gce https://paste.ubuntu.com/p/xbPwN6qnWd/ | 14:52 |
| mup | PR snapcraft#2221 opened: spread: stop running catkin tests on 18.10 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2221> | 14:58 |
| niemeyer | mvo: #5583 reviewed | 15:05 |
| mup | PR #5583: [RFC] many: go into socket activated mode if there are no snaps <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5583> | 15:05 |
| niemeyer | cachio: The image baker already has that permission | 15:07 |
| niemeyer | cachio: But probably not on eco-emissary.. what the heck is that project? :) | 15:08 |
| cachio | niemeyer, it is running as part of spread-cron project | 15:11 |
| cachio | It clones the pread images project and uses a lib to delete the tmp image | 15:12 |
| cachio | it is able to create a new image | 15:12 |
| niemeyer | cachio: It still doesn't clarify the point above | 15:12 |
| niemeyer | cachio: I don't know what that project is, and I have no control over it | 15:12 |
| niemeyer | cachio: The fact you cannot delete images on it is probably A Good Thing | 15:13 |
| cachio | niemeyer, it runs from travis, it is a spread-cron branch execution | 15:13 |
| niemeyer | cachio: That still sounds completely unrelated to the point I just made | 15:14 |
| cachio | niemeyer, I don't get the point! | 15:16 |
| cachio | if I log in with this sa, should I be able to create/delete images, right? | 15:16 |
| cachio | niemeyer, or it depends on another thing too? | 15:17 |
| niemeyer | cachio: What is "eco-emissary"? | 15:17 |
| niemeyer | cachio: It seems on my end that you haven't read what I said | 15:17 |
| cachio | niemeyer, I though it is a project where it can be executed | 15:18 |
| niemeyer | cachio: You are trying to delete projects on "eco-emissary".. I have no clue about what that project is, I don't maintain it, and I cannot give you permissions to delete images on it, and that's a good thing | 15:18 |
| cachio | niemeyer, perhaps it is not | 15:18 |
| niemeyer | cachio: I don't know what "it can be executed" means in this context | 15:18 |
| niemeyer | cachio: You are trying to delete images there.. who owns that project, and why are you trying to delete images there? | 15:19 |
| niemeyer | cachio: As I also said above, the image baker *already has* the permission to delete images, on our project, the one our images are stored on | 15:20 |
| cachio | my spread cron branch, creates a tmp image, it updates it, it tests it and the it clones the tmp image into a final one, then it needs to delete the tmp image | 15:20 |
| niemeyer | cachio: Where? | 15:20 |
| cachio | this spread-cron branch runs from a travis machine | 15:20 |
| cachio | and it is using the image-baker sa | 15:21 |
| niemeyer | cachio: You keep repeating that.. | 15:21 |
| niemeyer | cachio: It's not helping :) | 15:21 |
| cachio | niemeyer, agree | 15:22 |
| niemeyer | cachio: Let me be more prescriptive: these tools are attempting to delete images a project we don't control and shouldn't be storing images on in the first place. YOu'll need to find out why. | 15:22 |
| mvo | niemeyer: thanks for 5583! | 15:25 |
| cachio | niemeyer, ok, I'll try to do something different | 15:27 |
| niemeyer | cachio: It would be good to understand the problem first | 15:28 |
| cachio | and use spread-images to delete the image using the computeengine project | 15:28 |
| niemeyer | cachio: Our tools shouldn't be poking arbitrary projects like that | 15:29 |
| mvo | pedronis: when you have some free cycles, 5702 should be ready for a re-review, I applied your feedback | 15:29 |
| niemeyer | cachio: Please understand the problem before changing things | 15:29 |
| cachio | niemeyer, yes | 15:29 |
| mup | PR snapd#5707 opened: image: detect and error if bases are missing <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5707> | 15:31 |
| cachio | niemeyer, it is fixed | 15:49 |
| cachio | niemeyer, it was really simple | 15:49 |
| cachio | niemeyer, In fact was my fault | 15:50 |
| cachio | niemeyer, I didn't set the project when I did login with the sa | 15:50 |
| cachio | niemeyer, but it didn't fail, it made login to a generic project | 15:51 |
| cachio | niemeyer, to this one eco-emissary-99515 | 15:52 |
| niemeyer | cachio: Glad it's sorted, thanks for looking into it | 15:53 |
| cachio | niemeyer, yaw | 15:53 |
| mvo | niemeyer: I replied to your question in 5583, I hope this makes sense but I may miss some subtle bits here if so, my appolgies | 15:54 |
| niemeyer | mvo: Thanks, looking | 15:56 |
| mup | PR snapd#5340 closed: interfaces: add cifs-mount interface <Created by datenhahn> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5340> | 15:56 |
| pedronis | mvo: niemeyer: I wrote something there too | 16:00 |
| mvo | pedronis: aha, yeah, that makes sense. I will address it | 16:02 |
| niemeyer | mvo, pedronis: Yeah, what pedroins said.. I've made an additional comment there. Repeating here, we might prevent it from dying too fast, maybe | 16:05 |
| mvo | niemeyer: yeah, that makes sense, thank you | 16:06 |
| pedronis | we don't die too fast if there's a non-idle connection but at that point we will still shut down | 16:06 |
| pedronis | which is not quite what we want | 16:06 |
| pedronis | if there's an install | 16:06 |
| pedronis | mvo: a naive approach would be do the check, if it seems we should stop, wait a while, do the check again, if it's still the case ask to stop there | 16:10 |
| pedronis | maybe there is something more elegant though | 16:10 |
| mvo | pedronis: yeah, I was wondering if we need something like we do for outstanding hooks | 16:20 |
| mvo | pedronis: I will think a bit | 16:20 |
| pedronis | mvo: notice that code is also ignoring EnsureBefore unlike Settle | 16:22 |
| pedronis | put a not in the PR | 16:28 |
| pstolowski | mvo: is there a way to find what was the revision of core for given git commit id? the commit is from 17th Oct 2016, looking at the debian changelog the closest release was 2.17 on 2nd Nov 2016 (did we have release branches back then? i would need to check if that commit was really included in 2.17) | 16:36 |
| pstolowski | anyway eod.. will repeat the question tomorrow | 16:39 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | jdstrand: hey | 16:42 |
| zyga | jdstrand: I sent some updates to #5170 | 16:42 |
| mup | PR #5170: interfaces/builtin: add adb-support interface <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5170> | 16:42 |
| zyga | jdstrand: I'm working on testing but the look and feel of the interface is what I think you asked for | 16:42 |
| zyga | jdstrand: I've built a snap with adb inside and I'm trying to get to the point where it works end-to-end | 16:44 |
| zyga | jdstrand: as for a smaller request, https://github.com/snapcore/snapd/pull/5307 is ready and just needs your final ack to land | 16:45 |
| mup | PR #5307: cmd,interfaces,tests: add /mnt to removable-media interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5307> | 16:46 |
| pedronis | pstolowski|afk: what commit is that? | 16:49 |
| mvo | pstolowski|afk: sorry for the delay, was at dinner. you can do "git checkout release/2.17" and look at the diff there | 17:08 |
| mvo | pstolowski|afk: I mean, look if the commit is part of this branch | 17:09 |
| * zyga goes for a bike ride; I will be back with adb tests tonight | 17:10 | |
| mup | PR snapd#5702 closed: snap: add ByType sorting <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5702> | 17:10 |
| mup | PR snapd#5706 closed: snapstate: make InstallPath() return *snap.Info too <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5706> | 17:11 |
| === ahasenack is now known as Guest22561 | ||
| G33kDad | So, how resiliant is ubuntu core to power losses? Im thinking of an automotive application. | 17:36 |
| mup | PR snapd#5708 opened: snapstate: use new "snap.ByType" sorting <Created by mvo5> <https://github.com/snapcore/snapd/pull/5708> | 17:40 |
| === devil is now known as Guest64550 | ||
| mup | PR snapd#5661 closed: tests: normalize tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5661> | 18:28 |
| jdstrand | zyga: sorry, meetings and appt. ack on all fronts | 18:32 |
| mispp | hey all, anyway to force build.snapcraft.io to use newer toolchain (18.04)? | 18:36 |
| zyga | jdstrand: thank you and no worries about the meetings, I just got back from my ride | 18:46 |
| * zyga reads about side-channel LSM | 19:00 | |
| zyga | G33kDad: more resilient than traditional distributions | 19:05 |
| zyga | G33kDad: all application code is stored in read-only filesystem images | 19:07 |
| zyga | application upgrades are never partial | 19:07 |
| zyga | kernel upgrades are never partial | 19:08 |
| zyga | OS upgrades are never partial | 19:08 |
| zyga | the upgrade system uses transactions | 19:08 |
| zyga | the system can revert to earlier revision of the OS and kernel if upgrade fails | 19:08 |
| zyga | sudden power off can still affect the writable filesystem but the "damage surface" is smaller | 19:09 |
| mvo | zyga: I'm looking into that firstboot failure curently, no idea what is going on there yet | 19:22 |
| zyga | mvo: XK | 19:24 |
| zyga | ack | 19:24 |
| mvo | zyga: I hope we get a review on 5307 soon, can't wait | 19:25 |
| zyga | indeed :) | 19:26 |
| * zyga -> supper | 19:27 | |
| mup | PR snapcraft#2222 opened: lxd: support new style snap injection <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2222> | 20:01 |
| dave_uy | How should I debug my snapcraft build? I am creating a snap for Bisq. I need to put my build artifacts in the right place I think. | 20:27 |
| === d__ed is now known as d_ed | ||
| ogra | stgraber, so two days ago three ominous disks showed up in my unity panel ... turn out thats apparently the lxd snap ... what did change in lxd that makes this happen ? (no other snap does that) | 21:09 |
| ogra | annoyingly its all three versions ... | 21:09 |
| ogra | and it definitely didnt do that before | 21:10 |
| stgraber | ogra: can you pastebin /proc/self/mountinfo? | 21:12 |
| ogra | (i dont really see anything that could be special in mount or df) | 21:12 |
| ogra | one sec | 21:12 |
| ogra | http://paste.ubuntu.com/p/VWv9Xsztbj/ | 21:12 |
| ogra | ogra@acheron:~$ cat /proc/self/mountinfo |grep lxd | 21:13 |
| ogra | 960 563 0:3 mnt:[4026532557] /run/snapd/ns/lxd.mnt rw - nsfs nsfs rw | 21:13 |
| ogra | 362 29 7:69 / /snap/lxd/8358 ro,nodev,relatime shared:98 - squashfs /dev/loop69 ro | 21:13 |
| ogra | 388 29 7:94 / /snap/lxd/8393 ro,nodev,relatime shared:226 - squashfs /dev/loop94 ro | 21:13 |
| ogra | 256 29 7:88 / /snap/lxd/8415 ro,nodev,relatime shared:117 - squashfs /dev/loop88 ro | 21:13 |
| ogra | here is the filtered variant ... proably easier :) | 21:14 |
| ogra | i dont see anything soecial compared to the other gazillion snaps i have | 21:14 |
| * ogra notices lxd is the only snap using the lxd-support interface on his system ... probably related ... | 21:15 | |
| ogra | did the interface change recently ? | 21:16 |
| stgraber | nope, that interface has never changed | 21:16 |
| ogra | weird | 21:17 |
| stgraber | kinda hard to tell why LXD would show up in unity, clearly nothing that'd explain it in the mount table and without knowing what kind of event that unity launcher reacts to it's hard to tell what might cause it | 21:17 |
| ogra | but well ... they are there :) https://imgur.com/a/4PhinGS | 21:18 |
| ogra | (the bottom three disks) | 21:19 |
| stgraber | LXD does do a ton of special mount namespace setup, some of which in the host mount namespace, but as you can tell, there's nothing from that left behind, so even if the launcher noticed it happening, those entries should have immediately gone away | 21:19 |
| ogra | well, i can tell unity to simply hide them in the panel ... but be prepared that you'll get reports from 16.04 users | 21:20 |
| ogra | btw, just checked my desktop machine (where i never noticed it) and got the same three disks there | 21:23 |
| G33kDad | zyga: thanks for the thoughts! | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!