| === tedg_ is now known as tedg | ||
| === stgraber_ is now known as stgraber | ||
| stub | I've got a version-script that contains 'python3 setup.py -V' in it, which is failing in Launchpad builds with "ImportError: No module named 'setuptools'" | 04:18 |
|---|---|---|
| stub | Does anyone know what I need to include to get it working so I don't have to trial and error it? | 04:19 |
| stub | I've tried adding "build-packages: python3-setuptools" to the part | 04:19 |
| mborzecki | morning | 05:00 |
| mup | PR snapd#5614 closed: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5614> | 05:02 |
| mvo | mborzecki: did you see the comment from zyga on 5705 ? looks like one govendor add is missing | 06:04 |
| mborzecki | mvo: yup, added it alredy, but i'm checking if fedora package builds fine as i had github.com/kr/{pretty,text} to the spec too | 06:10 |
| mborzecki | mvo: interestingly govendor also lists golang.org/x/sys/unix as an external dep and it's imported by some of the pacakges https://paste.ubuntu.com/p/bjKD2dJ93C/ but we do not vendor it, any idea why? | 06:12 |
| mvo | mborzecki: hm, in the past we used some older revision of things just to avoid the x/sys/unix | 06:14 |
| mvo | mborzecki: the x/sys/unix fails on powerpc so we need to avoid it currently | 06:14 |
| mborzecki | mvo: interestingly, latest master of kr/pretty has go.mod already :) | 06:32 |
| mup | PR snapd#5709 opened: configcore,snapstate: add new core.experimental.snapd-snap option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5709> | 06:48 |
| === pstolowski|afk_ is now known as pstolowski | ||
| pstolowski | mornings | 07:03 |
| zyga | Hello :-) | 07:03 |
| pstolowski | o/ | 07:03 |
| zyga | mborzecki: what is go.mod? | 07:04 |
| pstolowski | mvo: hey, 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) | 07:04 |
| mborzecki | zyga: https://github.com/golang/go/wiki/Modules | 07:04 |
| mborzecki | zyga: go 1.11 thing | 07:04 |
| mborzecki | pstolowski: zyga: and hi :) | 07:05 |
| zyga | Ah, interesting | 07:05 |
| === mpt_ is now known as mpt | ||
| mvo | pstolowski: hey, did you see my reply from last night? you can "git checkout release/2.17" and then look into that branch if the commit is in there | 07:10 |
| mvo | pstolowski: what git are you looking for? | 07:10 |
| mvo | pstolowski: i.e. whats the id? | 07:10 |
| zyga | I think that the separate commit IDs from the vendorized tree are still a thing though so complexity in looking up snapd version to git hash in the repo is still harder | 07:11 |
| pedronis | pstolowski: hi, why do you need such an old revision? I'm probably missing something | 07:12 |
| mborzecki | + snap install test-snapd-tools test-snapd-control-consumer | 07:13 |
| mborzecki | error: unable to contact snap store | 07:13 |
| mborzecki | hmm again? | 07:13 |
| pedronis | mvo: hi, did you see my new comment in #5703 ? | 07:16 |
| mup | PR snapd#5710 opened: cmd: support re-exec into the "snapd" snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/5710> | 07:16 |
| mup | PR #5703: firstboot: sort by type when installing the firstboot snaps <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5703> | 07:16 |
| mvo | pedronis: yes, need to look at this but I thought we already sort snapd->core18->kernel->gadget and add the right waits. if thats not the case I need to re-check this | 07:17 |
| pedronis | mvo: the sorting is right but as your comment says you don't sort things that are added manually before the loops | 07:18 |
| pedronis | maybe I'm missing something though | 07:20 |
| mvo | pedronis: looking, I though thats ok because we already "manually" sort and add the waits but let me double check | 07:20 |
| pedronis | mvo: I think the issue shows up only if gadget has a base != model base, which maybe is strange | 07:21 |
| pedronis | but we need to do something about it either way | 07:21 |
| mvo | pedronis: aha, I get the issue now, yes, thats a problem | 07:21 |
| pedronis | either error or fix the order | 07:21 |
| mvo | pedronis: +1 | 07:21 |
| mvo | pedronis: I think I will just error for now | 07:21 |
| mvo | pedronis: because its slightly strange to have a gadget base that is not the model base | 07:21 |
| mvo | pedronis: we I add a todo that we can reeval this | 07:21 |
| mvo | pedronis: sounds sensible? | 07:21 |
| pedronis | yes | 07:22 |
| mvo | pedronis: cool, thanks again for spotting this :) | 07:22 |
| pedronis | mvo: do the new gadgets we made have base: core18 set ? | 07:23 |
| mvo | pedronis: they don't have any bases set yet, I think we need to fix this | 07:23 |
| pedronis | ok | 07:23 |
| pedronis | mvo: probably worth adding a check in image too | 07:23 |
| * mvo goes and fixes that as well | 07:23 | |
| mvo | pedronis: yeah | 07:23 |
| pstolowski | pedronis: i wanted to know the range of core revisions that were on patch level 6 (for the patch sublevel PR). on second thought i probably actually only need the current core revision at the time we release the new code | 07:26 |
| mvo | pstolowski: what revision is it you are looking for in 2.17? | 07:26 |
| pedronis | pstolowski: yes, think so | 07:27 |
| mborzecki | zyga: how's your spreadfmt tool coming along? | 07:27 |
| pedronis | if I understand what we need | 07:27 |
| mup | PR snapd#5711 opened: tests: shellchecks part 8 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5711> | 07:28 |
| zyga | mborzecki: it makes small one time difference but otherwise is useful to apply. I haven’t spent much time on task.yaml, just spread.yaml has look and feel hints | 07:33 |
| zyga | It is a background task so I open it each time I get stuck on something | 07:34 |
| mborzecki | zyga: haha, same with shellchecks for me :) | 07:39 |
| mborzecki | ok, back to UpdateMany tests | 07:39 |
| ogra | hmm ... why do i see /var/lib/snapd/void in my LD_LIBRARY_PATH ? | 07:56 |
| zyga | Odd | 07:57 |
| zyga | Perhaps something uses current working directory | 07:57 |
| pedronis | pstolowski: revision are different per arch, 5145 is the amd64 revision, but there are higher revision in stable because of other archs | 07:58 |
| ogra | it actually seems to come from SNAP_LIBRARY_PATH | 07:58 |
| pstolowski | pedronis: ah /o\ | 07:59 |
| pedronis | pstolowski: also not sure if we should use stable or cand or beta for the number | 08:01 |
| pstolowski | pedronis: this is going to be a little messy... perhaps we can think of some other way of finding 6.0 level out | 08:01 |
| pedronis | pstolowski: worst case we rerun some idempotent patch, no? | 08:02 |
| pedronis | I mean by using somethin higher | 08:03 |
| pedronis | pstolowski: btw you can see the info for all archs and channels with this: curl -s -H "Snap-Device-Series: 16" https://api.snapcraft.io/v2/snaps/info/core|jq '."channel-map"' | 08:03 |
| pstolowski | pedronis: yes, worst case we re-run an idempotent patch | 08:07 |
| pstolowski | (thanks, that curl hint will be handy) | 08:08 |
| zyga | ogra: is it visible with any snap or with a particular one | 08:14 |
| zyga | ogra: and what is the working directory where you are trying? | 08:15 |
| ogra | zyga, i'm actually in a rather evil setup ;) https://snapcraft.io/wmx-kiosk-session | 08:16 |
| ogra | the working dir by default is $SNAP_DATA and i'm root | 08:16 |
| ogra | (planning to change that to cd to $HOME, but not there yet ... i'm surprised it would have any influence on the lib path) | 08:17 |
| zyga | it may though not sure how | 08:17 |
| zyga | I mean | 08:17 |
| zyga | we cd /var/lib/snapd/void in _some_ cases | 08:18 |
| zyga | so perhaps something is using $(pwd) | 08:18 |
| ogra | well, i'm not cd'ed to it ... it is just in SNAP_LIBRARY_PATH | 08:18 |
| zyga | I mean snapd does that for you | 08:18 |
| zyga | if $(pwd) cannot be represented in a snap | 08:18 |
| ogra | the snap starts a daemon app --- which in turn starts a WM on top of mir-kiosk ... and inside that i'm running an xterm | 08:19 |
| ogra | (being root obviously) | 08:19 |
| ogra | (and on ubuntu core) | 08:19 |
| mup | PR snapd#5712 opened: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712> | 08:20 |
| ogra | it doesnt seem to do any harm btw ... i only noticed it shows up un the lib path variables everywhere | 08:20 |
| zyga | wow | 08:22 |
| zyga | the adb debian package uses runpath! | 08:23 |
| zyga | that's so wierd | 08:23 |
| zyga | I thought rpath-like things were forbidden | 08:23 |
| ogra | adb *is* weird ... why should a debian package with it be any better ? :) | 08:23 |
| zyga | ogra: is there something like x86_64-linux-gnu in the form of a variable | 08:26 |
| zyga | ogra: my snapcraft.yaml is non-portable because of those | 08:27 |
| mborzecki | zyga: #5705 is green now | 08:27 |
| mup | PR #5705: testutil: have File* checker produce more useful error output <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5705> | 08:27 |
| ogra | zyga, didnt mvo add SNAP_ARCH_TRIPLET ? ... oh, wait, thats runtime ... there is SNAPCRAFT_ARCH_TRIPLET for build-time | 08:27 |
| zyga | I don't know, I'll try that | 08:28 |
| mborzecki | pedronis: i'll drop the commits that fiddled with ordering in #5697 and push an update to the test on top if you don't mind | 08:28 |
| mup | PR #5697: overlord/snapstate: fix UpdateMany() to work with parallel instances <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5697> | 08:28 |
| pedronis | mborzecki: ok | 08:29 |
| mvo | ogra: I did not, that PR got rejected | 08:30 |
| ogra | boo | 08:30 |
| zyga | mborzecki: reviewed | 08:30 |
| zyga | mvo: :( | 08:30 |
| ogra | zyga, well, then you want some case statement based on SNAP_ARCH in your app wrapper .... one sec, i have a paste | 08:30 |
| ogra | (in case you need it at runtime) | 08:31 |
| zyga | $SNAPCRAFT_ARCH_TRIPLET works | 08:31 |
| zyga | I didn't want to add any wrappers | 08:31 |
| ogra | yeah, thats for build time | 08:31 |
| ogra | if your app gets along then thats fine | 08:31 |
| ogra | (if you need any subdirs in your lib path that snapcrafts command wrapper doesnt cover, you need an extra wrapper with the above though) | 08:32 |
| zyga | yeah but it expands at build time | 08:32 |
| zyga | so that's fine | 08:32 |
| pedronis | mvo: lots of red because of problems get gcloud tokens | 08:33 |
| pedronis | getting | 08:33 |
| mvo | pedronis: hm,hm,is that a gcloud issue or is it on our side somehow? | 08:34 |
| pedronis | mvo: actually is tls handshake might be networking somewhere | 08:35 |
| mborzecki | pedronis: and force pushed | 08:35 |
| pedronis | mborzecki: ok, will look at it again in a little bit | 08:37 |
| mborzecki | pedronis: thanks | 08:37 |
| mup | PR snapd#5686 closed: overlord/ifacestate: introduce connectOpts <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5686> | 08:41 |
| zyga | ok, little by little :-) | 08:55 |
| mup | PR pc-amd64-gadget#9 opened: snapcraft.yaml: add `base: core18` <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/9> | 09:03 |
| mup | PR pc-i386-gadget#7 opened: snapcraft.yaml: add `base: core18` <Created by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/7> | 09:03 |
| mvo | zyga: thanks for the approvals | 09:29 |
| mvo | zyga: there are more for pi2,3,cm3,dragon | 09:29 |
| zyga | woot | 09:29 |
| mvo | zyga: but mup does not pick those up | 09:29 |
| zyga | adb works now | 09:29 |
| mvo | zyga: \o/ | 09:29 |
| zyga | mvo: I'll look now :) | 09:29 |
| zyga | I need to tweak my test snap to start adb as a service | 09:29 |
| zyga | but I can get it to do the right thing out of the box now :) | 09:30 |
| zyga | and the interface is not that scary actually :-) | 09:30 |
| zyga | mvo: let me know if there are any I missed please | 09:45 |
| mvo | ok | 09:46 |
| mvo | ta | 09:46 |
| zyga | hmm | 09:46 |
| zyga | Aug 23 11:43:18 fyke kernel: adb[54153]: segfault at 5564b3a9e000 ip 00007f449172f885 sp 00007ffd7002edf8 error 6 in libcrypto.so.1.0.0[7f44916ca000+219000] | 09:46 |
| zyga | core18 based adb snap | 09:46 |
| zyga | it works when I run it as a user command | 09:46 |
| zyga | crashes when I run it as a service (type: forking) | 09:46 |
| mvo | zyga: crashes with denials? | 09:50 |
| zyga | no, just segvfault | 09:50 |
| zyga | this is all of journal when I install the package: | 09:51 |
| zyga | adb crashes when started as a service https://www.irccloud.com/pastebin/PTPzjlyC/ | 09:51 |
| mborzecki | anyone using opera snap on ubuntu? does it work? | 10:09 |
| zyga | I used it on Fedora | 10:09 |
| zyga | it worked but fonts weren't perfect | 10:10 |
| zyga | especially "normal" fonts, web fonts were ok | 10:10 |
| mborzecki | zyga: can you install it and check if it works still? | 10:11 |
| zyga | let me figure out why gnome shell is crashing onw | 10:11 |
| zyga | I cannot log in with zsh as my shell | 10:12 |
| zyga | hmm | 10:12 |
| zyga | I'll reboot | 10:12 |
| mborzecki | haha omg :) | 10:15 |
| zyga | rebooting fixed it | 10:15 |
| zyga | (I switched back to bash) | 10:15 |
| zyga | installing opera nonw | 10:15 |
| zyga | *now | 10:15 |
| mup | PR pc-amd64-gadget#9 closed: snapcraft.yaml: add `base: core18` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/9> | 10:16 |
| mup | PR pc-i386-gadget#7 closed: snapcraft.yaml: add `base: core18` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/7> | 10:16 |
| zyga | mborzecki: yes, it works | 10:16 |
| mborzecki | zyga: can you snap info? | 10:17 |
| zyga | snap info opera https://www.irccloud.com/pastebin/qJTN75jk/ | 10:17 |
| mborzecki | zyga: can you ls -l /snap/opera/7/usr/lib/x86_64-linux-gnu/opera/opera_sandbox ? | 10:20 |
| zyga | -rwxr-xr-x 1 root root 212632 Aug 13 23:04 /snap/opera/7/usr/lib/x86_64-linux-gnu/opera/opera_sandbox | 10:20 |
| mborzecki | zyga: and unsquashfs -ll /var/lib/snapd/snaps/opera_7.snap |grep opera/opera_sandbox | 10:20 |
| zyga | -rwxr-xr-x root/root 212632 2018-08-13 23:04 squashfs-root/usr/lib/x86_64-linux-gnu/opera/opera_sandbox | 10:22 |
| mborzecki | zyga: this is what happens on arch https://paste.ubuntu.com/p/BPr6THsF7d/ | 10:23 |
| zyga | snap run --shell opera | 10:23 |
| zyga | cat /etc/os-release | 10:23 |
| zyga | I wonder if this is related | 10:23 |
| mborzecki | zyga: ubuntu core | 10:23 |
| zyga | hmm | 10:24 |
| zyga | magic :) | 10:24 |
| zyga | no idea then | 10:24 |
| mborzecki | zyga: well the file is not seuid root so there's that | 10:25 |
| zyga | it cannot be setuid root | 10:25 |
| zyga | snaps cannot do that | 10:25 |
| mborzecki | zyga: right, but it complains hard about that here but not on ubuntu (?) | 10:25 |
| zyga | yeah, that _is_ odd | 10:25 |
| zyga | and also not on fedora | 10:25 |
| mborzecki | zyga: when have you tried it on fedora? maybe it was some older rev of the snap? | 10:26 |
| zyga | I tried it and it worked | 10:26 |
| zyga | same rev IIRC | 10:26 |
| mborzecki | i'll try chomium from snaps, it also does sandboxing via a helper | 10:26 |
| mborzecki | zyga: well, chromium snap works | 10:29 |
| mborzecki | anyone using fedora/opensuse? | 10:29 |
| zyga | I can boot both | 10:30 |
| mborzecki | zyga: do you have desktop installations? i only have cloud images | 10:30 |
| zyga | yes | 10:30 |
| zyga | I always use desktop versions | 10:31 |
| mborzecki | chromium works fine - https://paste.ubuntu.com/p/s2pgFqXNzB/ You are adequately sandboxed. | 10:31 |
| zyga | fedora works fine | 10:32 |
| zyga | same revision | 10:32 |
| zyga | I need to fix my suse installation now but I'll let you know | 10:32 |
| pedronis | mvo: so review-tools seems not to accept base on a gadget, there are two ways to address this, one is to change them, the other is to fix the base of the gadget to be the base of the model (that means double checking all places using Base tough) | 10:53 |
| mvo | pedronis: yeah, I just saw the rejects | 10:57 |
| zyga | installing most of opensuse desktop packages back | 10:57 |
| zyga | I wonder what caused zypper to remove pretty much all the packages that it could | 10:57 |
| zyga | I have grub back, installing gnome-shell | 10:57 |
| mvo | pedronis: I like option (2), it de-couples the model and the gadget to some extend, i.e. one could use the same pc gadget on core16 and core18 | 10:58 |
| mvo | pedronis: feels slightly magic but that may not be bad | 10:58 |
| mvo | pedronis: also I wonder how much ugliness it adds to the code but hopefully not much, snap run hopefully just needs to learn to handle gadgets specially for hooks | 10:59 |
| mvo | pedronis: wdyt? | 11:00 |
| ogra | is it actually a code problem ? not just review tools (pushing then through manually should work too, no ) | 11:11 |
| ogra | *them | 11:11 |
| pedronis | mvo: that sound optimistic , as I said any place doing .Base might have to be considered | 11:16 |
| mup | PR snapd#5711 closed: tests: shellchecks part 8 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5711> | 11:18 |
| pedronis | mvo: we might probably just need to be clever and some central places, but is not a trivial change | 11:19 |
| pedronis | s/and some/in some/ | 11:19 |
| mvo | pedronis: hm,hm,it sounds like something we should talk about during the standup. | 11:20 |
| mvo | pedronis: I guess we need to figure out what feels most "correct" | 11:20 |
| pedronis | mvo: there also some subtle questions like given that is "implicit" should we show in the api or not etc | 11:21 |
| * mvo nods | 11:21 | |
| pedronis | to be clear I'm not against | 11:21 |
| mvo | pedronis: yeah, I'm sitting on the fence | 11:22 |
| pedronis | I just don't think is trivial path to unblock us | 11:22 |
| pedronis | it might be correct but needs thinking/some work | 11:22 |
| === pstolowski is now known as pstolowski|lunch | ||
| mvo | pedronis: agreed, lets talk during the standup which of the two solutions is best for the users/fits best into the system design and then we go for it :) | 11:23 |
| * mvo also lunch | 11:23 | |
| ogra | mvo, with that base: core18 in the gadgets, how do we upload changes for core 16 ? | 11:29 |
| ogra | mvo, dont we need separate source trees/branches for the core 16 and 18 ones then ? | 11:30 |
| pedronis | ogra: you would need branches corrresponding to tracks, but as we were discussing that was hasty and might need a rediscussion | 11:30 |
| ogra | pedronis, well, i was more concerned about the source trees, but i see mvo actually created a branch ... i just didnt see it at first ... so all is fine | 11:35 |
| ogra | master is still core16 | 11:35 |
| ogra | (i dont really care how the sotre later deals with it ... but i want to be able to still push fixes to core16 if needed) | 11:36 |
| zyga | http://paste.ubuntu.com/p/gD7ty4jygC/ | 11:53 |
| * zyga failed to recover his opensuse installationn | 11:54 | |
| zyga | grub works but there's no kernel or initrd | 11:54 |
| zyga | eh | 11:54 |
| ogra | kernels are overrated | 11:57 |
| diddledan | write your own ;-p | 11:57 |
| ogra | in shell ! | 11:57 |
| diddledan | !! | 11:57 |
| diddledan | I seen someone working on a .NET kernel | 11:58 |
| ogra | heh | 11:58 |
| diddledan | ref: https://github.com/mosa/MOSA-Project | 11:58 |
| zyga | hey, I found my crash | 12:00 |
| zyga | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858764 | 12:00 |
| zyga | adb sucks :/ | 12:00 |
| ogra | why would you run it in forking mode anyway ? | 12:01 |
| zyga | that's how it works | 12:01 |
| * ogra has in fact never seen a snap use daemon: forking yet | 12:01 | |
| zyga | I wanted the service separatio | 12:01 |
| zyga | separation* | 12:01 |
| ogra | did you at least try with daemon: simple ? | 12:01 |
| zyga | it cannot be used this way because adb start-server forks | 12:02 |
| cachio | niemeyer, about the config done in the spread-cron project | 12:02 |
| cachio | niemeyer, is it possible to see how it is done? | 12:03 |
| cachio | niemeyer, because it is forcing us to create a project called "target" and run tests from there | 12:04 |
| cachio | but for the update the gce images I have some branches which require to do something different | 12:04 |
| cachio | and I can't see where/how this is configured | 12:05 |
| mvo | ogra: we have a "18" track for the gadgets already (was that the question?) | 12:24 |
| mvo | ogra: and a corresponding code branch but I see you discussed this already | 12:24 |
| === pstolowski|lunch is now known as pstolowski | ||
| ogra | mvo, yeah, sorry, i only noticed it after asking | 12:33 |
| zyga | ok | 12:37 |
| zyga | dab works! :) | 12:37 |
| zyga | adb works | 12:37 |
| mvo | ogra: no worries | 12:37 |
| zyga | mvo: shall I register "adb" and push a snap there? :) | 12:38 |
| zyga | popey_: ^ | 12:38 |
| zyga | I have a working adb snap | 12:38 |
| popey | stupid irc | 12:40 |
| popey | zyga: does it contain _only_ adb? I know often people will install adb and fastboot and other bits and bobs | 12:41 |
| zyga | yes, only adb | 12:41 |
| popey | Cool. you gonna maintain it? | 12:43 |
| zyga | no but I can hand it over to $someone | 12:44 |
| zyga | and it requires future snapd to work | 12:44 |
| popey | ahh, worth holding back until you have a maintainer and it works ? :) | 12:45 |
| mup | PR snapd#5713 opened: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713> | 12:50 |
| mborzecki | zyga: fun fun ^^ | 12:50 |
| zyga | mmm | 12:50 |
| ogra | it uses layouts ... which is currently painful | 12:50 |
| ogra | (since it means every commit/build needs manual approval) | 12:51 |
| ogra | hmm ... weird | 12:51 |
| ogra | $ snap find falkon | 12:51 |
| ogra | Name Version Publisher Notes Summary | 12:51 |
| ogra | falkon 3.0.1 kde - Web Browser | 12:51 |
| ogra | $ snap info falkon | 12:51 |
| ogra | error: no snap found for "falkon" | 12:51 |
| * ogra pokes the store with a long pointy stick | 12:52 | |
| ogra | https://snapcraft.io/falkon has it though | 12:52 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/5713/files#r212296528 | 12:52 |
| mup | PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713> | 12:52 |
| niemeyer | cachio: Let's get that fixed later today | 12:53 |
| cachio | niemeyer, sure, thanks | 12:53 |
| mborzecki | zyga: hahah omg, yeah | 12:53 |
| mborzecki | zyga: idk, maybe we could just pass $HOME and drop that silly part mauling SNAP_INSTANCE_USER_DATA, wdyt? | 12:54 |
| zyga | can you give me an example of how that would look like? | 12:54 |
| zyga | sorry for silly questions | 12:54 |
| mborzecki | nah, $HOME is silly | 12:57 |
| zyga | mvo: is this TODO done now? I think it is but I wanted to check: https://github.com/snapcore/snapd/pull/5713/files#diff-57dc34ab6f4bf9730b356d0439daa0fdR305 | 12:57 |
| mup | PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713> | 12:57 |
| sergiusens | zyga, popey: I bet the ubports folks wouldn't mind adding it to their installer snap as an implementation detail | 12:58 |
| mborzecki | zyga: ok, we could use SNAP_REVISION and SNAP_INSTANCE_NAME, and work with this to get to /home/joe/snap | 12:58 |
| mborzecki | zyga: those are set by snap run | 12:58 |
| zyga | sergiusens: the interface work I'm doing is specifically for ubuports | 12:58 |
| sergiusens | zyga: is this generic hotplug for usb or very specific to adb/fastboot? | 12:59 |
| zyga | sergiusens: it's specific to adb/fastboot but it doesn't handle hot plug as you might think (by creating new interfaces), instead it can talk to hot-plugged usb devices corresponding to a built-in list of known vendors | 13:00 |
| zyga | oh | 13:02 |
| zyga | standup! | 13:02 |
| mborzecki | zyga: got this locally: https://paste.ubuntu.com/p/sgdyy3XqwX/ | 13:08 |
| zyga | ooo | 13:42 |
| zyga | the infamous mount error | 13:42 |
| zyga | collect anything you can think of | 13:42 |
| zyga | and add that to the forum thread | 13:42 |
| zyga | man, that's interesting! | 13:42 |
| zyga | mvo: reviewed the shorter one | 13:42 |
| zyga | mvo: I'll do the next one after eating lunch | 13:42 |
| mborzecki | zyga: heh, there's literally nothing to collect, journal has 'protocol' error and nothing more | 13:43 |
| zyga | look for two things: | 13:43 |
| zyga | dmesg logs IO error - check which loop devices are logged | 13:43 |
| mborzecki | zyga: btw. i was installing 2 snaps `snap install hello-world_foo hello-world_bar`, one got installed :P | 13:43 |
| zyga | dd the loop devices (all if you have space) | 13:43 |
| mborzecki | zyga: yeah, nothing in dmesg either | 13:43 |
| pedronis | mvo: about the snapd snap type, maybe the easiest thing is to create a short forum post about the needs for it and point people to that | 13:43 |
| zyga | and compare them to reference images | 13:44 |
| pedronis | s/people/relevant people/ | 13:44 |
| zyga | are the loop devices corrupt? | 13:44 |
| zyga | mborzecki: I'm starving so I'll go now but please don't unmount, don't reboot | 13:44 |
| zyga | dd the loopback devices | 13:44 |
| zyga | collect losetup data | 13:44 |
| mvo | pedronis: sounds good | 13:45 |
| mborzecki | zyga: heh, can reproduce it `while true; do sudo snap install hello-world_foo hello-world_bar hello-world_baz && sudo snap remove hello-world_foo hello-world_bar hello-world_baz || break; done` | 13:46 |
| pedronis | mvo: I'm creating it | 13:55 |
| mvo | pedronis: thanks for that | 13:56 |
| pedronis | mvo: https://forum.snapcraft.io/t/new-snap-type-snapd/7021 | 13:59 |
| mvo | pedronis: ta | 13:59 |
| mborzecki | zyga: heh, i'm stracing systemd, obviously this doesn't happen, the mment i stop strace, boom | 14:01 |
| zyga | mborzecki: that's interesting | 14:06 |
| zyga | I need to go to the post office to pick up a package | 14:06 |
| zyga | I'll break for some time now, then be back | 14:06 |
| mup | PR snapcraft#2223 opened: snap: prepare override scripts to allow rebuilding <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2223> | 14:09 |
| zyga | re :) | 14:26 |
| pedronis | mvo: btw about transitioning to the new snapd type remember that we store it also in "snaps" SnapState | 14:28 |
| mup | PR snapd#5705 closed: testutil: have File* checker produce more useful error output <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5705> | 14:36 |
| * niemeyer is back, and happy.. all sorted | 14:40 | |
| mvo | niemeyer: \o/ | 14:41 |
| zyga | mvo: about 5710, is it already safe to remove ubuntu-core support? | 14:48 |
| zyga | While it will be older some of our tests may repackage it | 14:49 |
| mvo | zyga: in a meeting right now. I think it is because this is re-exec and I can't think why we ever wanted to re-exec into a *new* ubuntu-core snap | 14:49 |
| mvo | zyga: I mean, we don't make new ones of these anymore | 14:49 |
| zyga | Right | 14:49 |
| * zyga resumes reading | 14:49 | |
| zyga | mvo: LGTM except a/core/system/ on config access (unless you disagree) | 14:56 |
| === Trevinho is now known as Trevinyo | ||
| === Trevinyo is now known as Trevinho | ||
| === Trevinho is now known as Trevi | ||
| === Trevi is now known as MarcoTrevisan | ||
| === MarcoTrevisan is now known as Trevinho | ||
| === Trevinho is now known as _3v1n0_ | ||
| === _3v1n0_ is now known as Trevinho | ||
| mvo | zyga: thank you, looking | 15:18 |
| === pstolowski is now known as pstolowski|afk | ||
| cachio | mvo, hey, I see this error in the snapd-vendor branch on spread cron | 17:15 |
| cachio | https://paste.ubuntu.com/p/xv5nxPFZKD/ | 17:15 |
| cachio | any idea if something changes on the launchpad project? | 17:16 |
| cjwatson | More likely the ~snappy-m-o user | 17:18 |
| cjwatson | https://pastebin.canonical.com/p/P42gjNpybw/ | 17:18 |
| cjwatson | ~snappy-m-o was suspended yesterday | 17:19 |
| cjwatson | See https://rt.admin.canonical.com/Ticket/Display.html?id=108842 | 17:19 |
| cjwatson | Contact IS | 17:19 |
| cjwatson | (And somebody who actually still works for Canonical will need to take over as the bot's owner) | 17:19 |
| cjwatson | Though one thing I'd say there ... that repository is public. What's the point of cloning it over SSH, assuming this is a read-only operation? You could just do "git clone https://git.launchpad.net/snapd-vendor ..." instead | 17:25 |
| cjwatson | (Maybe you need that account for other reasons, I don't know) | 17:26 |
| popey | i enabled debug in /etc/environment, and now I have disabled it and restarted snapd, i still get debug output. How to I completely disable the DEBUG lines? | 17:26 |
| jdstrand | mvo: hi! it seems that pc-i386-18, pc-amd64-18, dragonboard-18, pi2-18, cm3-18 and pi3-18 all need approvals and updates for the review tools? | 17:27 |
| zyga | jdstrand: hey | 17:51 |
| zyga | jdstrand: I think so though I think mvo and pedronis came up with some other idea | 17:52 |
| zyga | jdstrand: do you think you will have time to look at https://github.com/snapcore/snapd/pull/5307 today? | 17:52 |
| mup | PR #5307: cmd,interfaces,tests: add /mnt to removable-media interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5307> | 17:52 |
| pedronis | jdstrand: we are not sure we are going to pursue attaching explicitly bases to gadget right now | 17:57 |
| pedronis | jdstrand: they can be rejected I think atm, need mvo really | 17:57 |
| jdstrand | zyga, pedronis (cc mvo): ok, I just saw the rejections so asked | 17:57 |
| jdstrand | zyga: maybe? it is on the list and I hope to burn down it a bit today | 17:58 |
| anarcat | hello | 18:17 |
| anarcat | after upgrading from debian stretch to debian buster, i'm seeing this error when starting a snap (signal-desktop): snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks | 18:17 |
| zyga | anarcat: hello | 18:21 |
| mvo | jdstrand: yeah, please ignore the "base: core18" on the gadgets for now, we will discuss this tomorrow/early next week. sorry for the noise here | 18:21 |
| mvo | cachio: uh, hmm | 18:21 |
| zyga | anarcat: that's interesting, do you have /etc/apparmor.d/usr.lib.snapd.snap-confine* ? | 18:21 |
| mvo | cachio: could you try what colin suggested and just clone using a read-only connection? | 18:22 |
| mvo | cachio: oh, nevermind | 18:22 |
| mvo | cachio: I think the problem is that it first is cloned and then updated/commited :/ | 18:22 |
| cachio | mvo, I just saw the cjwatson comments | 18:23 |
| cachio | mvo, we need to commit | 18:24 |
| cachio | and push | 18:24 |
| cachio | cjwatson, sorry for the delay, why it was suspended? | 18:25 |
| mvo | cachio: hm,hm,we just need it for the deb building | 18:25 |
| * mvo scratches head | 18:25 | |
| anarcat | zyga: checking | 18:41 |
| anarcat | zyga: there is /etc/apparmor.d/usr.lib.snapd.snap-confine.real | 18:41 |
| cachio | zyga, I see this denial running a test with uses cifs-mount interface [ 4721.716187] audit: type=1400 audit(1535049578.061:44): apparmor="DENIED" operation="exec" profile="snap.test-snapd-cifs-mount.sh" name="/bin/mount" pid=2417 comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 | 18:41 |
| cachio | zyga, is something else required apart of the plug/slot connection? | 18:42 |
| zyga | anarcat: ok, can you check if the profile is loaded, run aa-status | 18:42 |
| zyga | (as root) | 18:43 |
| zyga | cachio: I don't remember, let me check | 18:43 |
| anarcat | 55 profiles are in enforce mode. | 18:43 |
| zyga | anarcat: can you look for "snap-confine" there please | 18:44 |
| anarcat | [...] /usr/lib/snapd/snap-confine, /usr/lib/snapd/snap-confine//mount-namespace-capture-helper, /usr/lib/snapd/snap-confine//snap_update_ns... | 18:44 |
| cachio | zyga, I am running this | 18:44 |
| cachio | with the interface connected | 18:44 |
| anarcat | zyga: it's under the "enforce mode" line | 18:44 |
| zyga | anarcat: that looks okay | 18:44 |
| cachio | and get the denial | 18:44 |
| cachio | if I run the mount command directly it works | 18:44 |
| zyga | anarcat: do you see a profile that looks like "/snap/core/$NUMBER/usr/lib/snapd/snap-confine"? | 18:44 |
| anarcat | zyga: a profile? in aa-status? | 18:45 |
| zyga | anarcat: yes, | 18:45 |
| anarcat | zyga: here's the full list: https://ptpb.pw/TwrM | 18:45 |
| zyga | snap-confine has multiple profiles (it's complex) | 18:45 |
| anarcat | zyga: and the answer is no, i don't | 18:45 |
| zyga | and you may need both, depending on the circumstances | 18:45 |
| anarcat | ... | 18:45 |
| zyga | ok | 18:45 |
| anarcat | well that thing used to just work before buster :) | 18:45 |
| zyga | does "snap list | grep core" show that core is installed? | 18:45 |
| anarcat | yes, core 16-2.34.3 5145 stable canonical core | 18:46 |
| zyga | ok | 18:46 |
| anarcat | /usr/bin/snap info core | 18:47 |
| anarcat | oops, wrong win | 18:47 |
| zyga | hmmm | 18:47 |
| * zyga thinks | 18:47 | |
| anarcat | i'm not sure that matters, but i have ~/bin/snap that's my screenshot tool that sometimes override snap depending on the path | 18:47 |
| zyga | that should not be a factor | 18:47 |
| zyga | so | 18:47 |
| anarcat | indeed, renaming it doesn't fix the problem | 18:47 |
| zyga | snapd should have compiled a profile for the core snap | 18:48 |
| anarcat | okay | 18:48 |
| zyga | it manifests itself as a new file in /etc/apparmor.d/ | 18:48 |
| zyga | that looks like snap.core.$NUMBER.usr.lib.snapd.snap-confine | 18:48 |
| anarcat | no such file | 18:48 |
| zyga | if that file is missing snapd has probably decided not to enable apparmor for some reason | 18:48 |
| zyga | can you run "snap debug snadbox-features" | 18:48 |
| anarcat | http://paste.debian.net/1039051/ | 18:49 |
| zyga | anarcat: interesting, I think there's a bug in snapd | 18:49 |
| zyga | anarcat: I need to check | 18:49 |
| * anarcat grumbles | 18:49 | |
| anarcat | okay | 18:49 |
| zyga | anarcat: it's late, can you jump in tomorrow | 18:49 |
| anarcat | this is snapd 2.30-5+b1 in debian buster | 18:50 |
| anarcat | for sure | 18:50 |
| anarcat | i can grep around the debian bugtracker as well | 18:50 |
| zyga | anarcat: note that the version of the debian package is not that critical | 18:50 |
| anarcat | debsums: changed file /usr/share/dbus-1/services/io.snapcraft.Launcher.service (from snapd package) | 18:50 |
| zyga | anarcat: as you will see "snap version" | 18:50 |
| anarcat | odd | 18:50 |
| zyga | shows more recent version | 18:50 |
| zyga | the version of the core snap matters more here | 18:51 |
| zyga | but it's clearly not working as expected | 18:51 |
| anarcat | i guess i could file this as a regression in the snapd package on debian, in any case? | 18:51 |
| zyga | can you run "snap version" and paste hat | 18:51 |
| zyga | that | 18:51 |
| zyga | so that I can cross ref that tomorrow and not forget | 18:51 |
| zyga | I have installations of various debian versions and I should be able to reproduce this | 18:51 |
| anarcat | http://paste.debian.net/1039052/ | 18:52 |
| zyga | thank you | 18:55 |
| * zyga updates | 18:57 | |
| * cachio afk | 19:00 | |
| sergiusens | plars, joc: just in case https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43/7024 | 19:14 |
| anarcat | zyga: could this be because snap-confine is suid root? | 19:16 |
| zyga | no | 19:16 |
| zyga | it's a security feature we've built in | 19:16 |
| anarcat | okay | 19:17 |
| mup | PR snapcraft#2221 closed: spread: stop running catkin tests on 18.10 <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2221> | 19:30 |
| cjwatson | cachio: I explained why it was suspended in the lines immediately following where I said that it had been suspended ... | 19:31 |
| cjwatson | 18:19 <cjwatson> See https://rt.admin.canonical.com/Ticket/Display.html?id=108842 | 19:31 |
| cjwatson | 18:19 <cjwatson> Contact IS | 19:31 |
| cjwatson | 18:19 <cjwatson> (And somebody who actually still works for Canonical will need to take over as the bot's owner) | 19:31 |
| cjwatson | We can't have bot accounts lying around with no human owner who can be responsible for them | 19:32 |
| cjwatson | So this is the LP account equivalent of pulling the plug to see who complains and who thus might make a good new owner :-) | 19:32 |
| plars | sergiusens: thanks, our tests already detected it and ran about 2 hours ago. Everything looked good for us | 19:54 |
| cachio | cjwatson, ok, I'll discuss tomorrow about who should be reponsible for that | 20:09 |
| cachio | cjwatson, thanks for the explanation | 20:09 |
| zyga | anarcat: I updated my installation, trying to reproduce now | 20:12 |
| zyga | anarcat: I am on 4.17.0-3-amd64 kernel but otherwise the same | 20:12 |
| zyga | anarcat: I have /etc/apparmor.d/snap.core.5145.usr.lib.snapd.snap-confine | 20:13 |
| zyga | anarcat: can you please provide me with snapd logs, "sudo journalctl -u snapd.service" should be it | 20:14 |
| sergiusens | plars: nice, if you haven't already and do not mind, a comment on the forum post would be nice | 20:15 |
| plars | sergiusens: sure | 20:15 |
| anarcat | zyga: sure, hold on | 20:17 |
| zyga | thank you | 20:17 |
| anarcat | zyga: http://paste.debian.net/1039060/ | 20:17 |
| zyga | ha | 20:18 |
| zyga | aoû 22 15:28:06 curie snapd[1189]: 2018/08/22 15:28:06.844606 backend.go:303: cannot create host snap-confine apparmor configuration: cannot synchronize snap-confine apparmor profile: open /var/lib/snapd/apparmor/profiles/snap-confine.core.5145.dDP25MCqBC0L~: no such file or directory | 20:18 |
| zyga | that's the bug | 20:18 |
| zyga | can you ls /var/lib/snapd/apparmor/profiles/ | 20:18 |
| anarcat | zyga: http://paste.debian.net/1039061/ | 20:20 |
| zyga | hmm hmm | 20:20 |
| zyga | ok, can you try this please | 20:20 |
| zyga | sudo systemctl stop snapd.{socket, service} | 20:20 |
| zyga | sudo /usr/lib/snapd/snapd | 20:21 |
| zyga | (this will run snapd in the foreground) | 20:21 |
| anarcat | done | 20:21 |
| zyga | did it print the same error?: | 20:21 |
| zyga | about "cannot synchronise snap-confine apparmor profile" | 20:21 |
| anarcat | signal-desktop fails the same way | 20:21 |
| anarcat | snapd output: http://paste.debian.net/1039062/ | 20:22 |
| anarcat | no error from sudo snapd | 20:22 |
| zyga | ok, ctrl-c to have it exit | 20:22 |
| zyga | sudo rm /var/lib/snapd/system-key | 20:22 |
| zyga | and re-start snapd in the foregground | 20:22 |
| zyga | system-key is a cache of input factors that affect security profiles | 20:22 |
| zyga | removing it just makes snapd re-generate those | 20:23 |
| zyga | (system-key contains kernel version, snapd version, etc) | 20:23 |
| zyga | s/version/features/ | 20:23 |
| anarcat | 2018/08/23 16:23:31.104021 helpers.go:119: error trying to compare the snap system key: system-key missing on disk | 20:23 |
| zyga | right, that's ok | 20:23 |
| anarcat | signal-desktop starts | 20:23 |
| zyga | (that's expected) | 20:23 |
| anarcat | at least it's trying | 20:23 |
| zyga | can you check if /etc/apparmor.d now contains that other profile (snap.core.$number.usr.lib.snapd.snap-confine*) | 20:24 |
| zyga | I think we fixed it for you but the origin of the error is unclear | 20:24 |
| anarcat | it of course needs to load a N'th copy of a gigantic virtual machine that masquerades as a web browser (aka Electron AKA Chrome) | 20:24 |
| anarcat | /etc/apparmor.d does n't have snap.core.$number.usr.lib.snapd.snap-confine* | 20:25 |
| zyga | you can probably ctrl-c snapd and restart the socket and the service (sudo systemctl start snapd.{socket,service}) | 20:25 |
| zyga | oh | 20:25 |
| zyga | but ... | 20:25 |
| zyga | but snap applications now work? | 20:25 |
| anarcat | yeeep | 20:25 |
| zyga | hmmm! | 20:25 |
| zyga | any output from journald? | 20:25 |
| anarcat | not bad eh? | 20:25 |
| zyga | any errors? | 20:25 |
| zyga | it's actually still bad | 20:25 |
| anarcat | nothing peculiar | 20:26 |
| zyga | we should have got /etc/apparmod.d/snap.core.5145.usr.lib.snapd.snap-confine | 20:26 |
| zyga | er | 20:26 |
| zyga | I meant /etc/apparmor.d/ | 20:26 |
| anarcat | maybe there's a different search path on debian? | 20:26 |
| zyga | can you check using sudo aa-status if the profile is loaded | 20:26 |
| zyga | no, it's exactly the same AFAIR | 20:26 |
| zyga | I mean | 20:26 |
| anarcat | yes, it's loaded | 20:26 |
| zyga | I see it on my Sid installation | 20:26 |
| anarcat | http://paste.debian.net/1039064/ | 20:26 |
| zyga | so it's loaded but it's not in /etc/apparmor.d? | 20:26 |
| zyga | can you check if /etc/apparmor.d has some odd permissions? | 20:27 |
| zyga | hmm, that's correct | 20:27 |
| zyga | ah | 20:27 |
| zyga | sorry :D | 20:27 |
| zyga | it's all good | 20:27 |
| zyga | you are right | 20:27 |
| zyga | please look at /var/lib/snapd/apparmor/profiles | 20:27 |
| zyga | you should see snap-confine.core.5145 | 20:27 |
| zyga | we moved it! | 20:27 |
| zyga | and we didn't clean up the old spot | 20:27 |
| zyga | so I have it because I updated (and it worked for me for some reason) | 20:28 |
| zyga | and on your system you didn't have it but the profile was loaded non the less :) | 20:28 |
| zyga | because it is stored in other place | 20:28 |
| zyga | ok, that's good | 20:28 |
| zyga | as a final check you could try to reboot | 20:28 |
| zyga | and re-check with sudo aa-status | 20:28 |
| zyga | to ensure it's still loaded | 20:28 |
| anarcat | ugh, reboot | 20:28 |
| zyga | if not we can inspect the loading logic | 20:28 |
| zyga | to see if it is buggy | 20:28 |
| zyga | perhaps it was there all along | 20:29 |
| zyga | but was not loaded | 20:29 |
| anarcat | this exists now /var/lib/snapd/apparmor/profiles/snap-confine.core.5145 | 20:29 |
| zyga | and just got loaded by snapd when we removed the system-key from your machine | 20:29 |
| zyga | anarcat: ok, please stay in touch if this persists as an issue | 20:31 |
| zyga | anarcat: and thank you for using snaps :) | 20:31 |
| anarcat | of course! | 20:31 |
| anarcat | i promise to reboot soon, but i have some work to complete first | 20:31 |
| anarcat | thank you very much for your help! | 20:31 |
| anarcat | should this be filed as a bug somewhere? | 20:32 |
| zyga | anarcat: if you want please write a new thread about this on the forum | 20:32 |
| zyga | anarcat: especially include the error message you pasted | 20:32 |
| zyga | anarcat: and that you upgraded | 20:33 |
| zyga | anarcat: perhaps something in the upgrade process is broken | 20:33 |
| zyga | or our assumptions about system key were insufficient | 20:33 |
| zyga | (system-key is meant to fix issues like this) | 20:33 |
| zyga | anarcat: the forum is on forum.snapcraft.io, we prefer it instead of bug reports as it is more encouraging to engage than traditional bug trackers for some people | 20:34 |
| * anarcat shrugs | 20:36 | |
| anarcat | okay | 20:36 |
| zyga | thank you :) | 20:36 |
| anarcat | commented there before, in https://forum.snapcraft.io/t/snapped-firefox-unable-to-use-smart-card/5719/5?u=anarcat | 20:37 |
| anarcat | but thanks to the upgrade, i don't need a snap for firefox anymore :) | 20:37 |
| anarcat | well at least not on this machine, on the buggy machine i still do :/ | 20:37 |
| anarcat | https://forum.snapcraft.io/t/apparmor-error-after-debian-buster-upgrade/7026 | 20:44 |
| zyga | thank you :) | 20:44 |
| anarcat | np | 20:44 |
| mup | PR snapd#5714 opened: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714> | 21:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!