=== tedg_ is now known as tedg === stgraber_ is now known as stgraber [04:18] 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:19] Does anyone know what I need to include to get it working so I don't have to trial and error it? [04:19] I've tried adding "build-packages: python3-setuptools" to the part [05:00] morning [05:02] PR snapd#5614 closed: interfaces: parallel instances support, extend unit tests [06:04] mborzecki: did you see the comment from zyga on 5705 ? looks like one govendor add is missing [06:10] 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:12] 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:14] mborzecki: hm, in the past we used some older revision of things just to avoid the x/sys/unix [06:14] mborzecki: the x/sys/unix fails on powerpc so we need to avoid it currently [06:32] mvo: interestingly, latest master of kr/pretty has go.mod already :) [06:48] PR snapd#5709 opened: configcore,snapstate: add new core.experimental.snapd-snap option === pstolowski|afk_ is now known as pstolowski [07:03] mornings [07:03] Hello :-) [07:03] o/ [07:04] mborzecki: what is go.mod? [07:04] 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] zyga: https://github.com/golang/go/wiki/Modules [07:04] zyga: go 1.11 thing [07:05] pstolowski: zyga: and hi :) [07:05] Ah, interesting === mpt_ is now known as mpt [07:10] 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] pstolowski: what git are you looking for? [07:10] pstolowski: i.e. whats the id? [07:11] 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:12] pstolowski: hi, why do you need such an old revision? I'm probably missing something [07:13] + snap install test-snapd-tools test-snapd-control-consumer [07:13] error: unable to contact snap store [07:13] hmm again? [07:16] mvo: hi, did you see my new comment in #5703 ? [07:16] PR snapd#5710 opened: cmd: support re-exec into the "snapd" snap [07:16] PR #5703: firstboot: sort by type when installing the firstboot snaps [07:17] 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:18] mvo: the sorting is right but as your comment says you don't sort things that are added manually before the loops [07:20] maybe I'm missing something though [07:20] pedronis: looking, I though thats ok because we already "manually" sort and add the waits but let me double check [07:21] mvo: I think the issue shows up only if gadget has a base != model base, which maybe is strange [07:21] but we need to do something about it either way [07:21] pedronis: aha, I get the issue now, yes, thats a problem [07:21] either error or fix the order [07:21] pedronis: +1 [07:21] pedronis: I think I will just error for now [07:21] pedronis: because its slightly strange to have a gadget base that is not the model base [07:21] pedronis: we I add a todo that we can reeval this [07:21] pedronis: sounds sensible? [07:22] yes [07:22] pedronis: cool, thanks again for spotting this :) [07:23] mvo: do the new gadgets we made have base: core18 set ? [07:23] pedronis: they don't have any bases set yet, I think we need to fix this [07:23] ok [07:23] mvo: probably worth adding a check in image too [07:23] * mvo goes and fixes that as well [07:23] pedronis: yeah [07:26] 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] pstolowski: what revision is it you are looking for in 2.17? [07:27] pstolowski: yes, think so [07:27] zyga: how's your spreadfmt tool coming along? [07:27] if I understand what we need [07:28] PR snapd#5711 opened: tests: shellchecks part 8 [07:33] 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:34] It is a background task so I open it each time I get stuck on something [07:39] zyga: haha, same with shellchecks for me :) [07:39] ok, back to UpdateMany tests [07:56] hmm ... why do i see /var/lib/snapd/void in my LD_LIBRARY_PATH ? [07:57] Odd [07:57] Perhaps something uses current working directory [07:58] pstolowski: revision are different per arch, 5145 is the amd64 revision, but there are higher revision in stable because of other archs [07:58] it actually seems to come from SNAP_LIBRARY_PATH [07:59] pedronis: ah /o\ [08:01] pstolowski: also not sure if we should use stable or cand or beta for the number [08:01] pedronis: this is going to be a little messy... perhaps we can think of some other way of finding 6.0 level out [08:02] pstolowski: worst case we rerun some idempotent patch, no? [08:03] I mean by using somethin higher [08:03] 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:07] pedronis: yes, worst case we re-run an idempotent patch [08:08] (thanks, that curl hint will be handy) [08:14] ogra: is it visible with any snap or with a particular one [08:15] ogra: and what is the working directory where you are trying? [08:16] zyga, i'm actually in a rather evil setup ;) https://snapcraft.io/wmx-kiosk-session [08:16] the working dir by default is $SNAP_DATA and i'm root [08:17] (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] it may though not sure how [08:17] I mean [08:18] we cd /var/lib/snapd/void in _some_ cases [08:18] so perhaps something is using $(pwd) [08:18] well, i'm not cd'ed to it ... it is just in SNAP_LIBRARY_PATH [08:18] I mean snapd does that for you [08:18] if $(pwd) cannot be represented in a snap [08:19] 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] (being root obviously) [08:19] (and on ubuntu core) [08:20] PR snapd#5712 opened: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates [08:20] it doesnt seem to do any harm btw ... i only noticed it shows up un the lib path variables everywhere [08:22] wow [08:23] the adb debian package uses runpath! [08:23] that's so wierd [08:23] I thought rpath-like things were forbidden [08:23] adb *is* weird ... why should a debian package with it be any better ? :) [08:26] ogra: is there something like x86_64-linux-gnu in the form of a variable [08:27] ogra: my snapcraft.yaml is non-portable because of those [08:27] zyga: #5705 is green now [08:27] PR #5705: testutil: have File* checker produce more useful error output [08:27] zyga, didnt mvo add SNAP_ARCH_TRIPLET ? ... oh, wait, thats runtime ... there is SNAPCRAFT_ARCH_TRIPLET for build-time [08:28] I don't know, I'll try that [08:28] 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] PR #5697: overlord/snapstate: fix UpdateMany() to work with parallel instances [08:29] mborzecki: ok [08:30] ogra: I did not, that PR got rejected [08:30] boo [08:30] mborzecki: reviewed [08:30] mvo: :( [08:30] zyga, well, then you want some case statement based on SNAP_ARCH in your app wrapper .... one sec, i have a paste [08:31] (in case you need it at runtime) [08:31] $SNAPCRAFT_ARCH_TRIPLET works [08:31] I didn't want to add any wrappers [08:31] yeah, thats for build time [08:31] if your app gets along then thats fine [08:32] (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] yeah but it expands at build time [08:32] so that's fine [08:33] mvo: lots of red because of problems get gcloud tokens [08:33] getting [08:34] pedronis: hm,hm,is that a gcloud issue or is it on our side somehow? [08:35] mvo: actually is tls handshake might be networking somewhere [08:35] pedronis: and force pushed [08:37] mborzecki: ok, will look at it again in a little bit [08:37] pedronis: thanks [08:41] PR snapd#5686 closed: overlord/ifacestate: introduce connectOpts [08:55] ok, little by little :-) [09:03] PR pc-amd64-gadget#9 opened: snapcraft.yaml: add `base: core18` [09:03] PR pc-i386-gadget#7 opened: snapcraft.yaml: add `base: core18` [09:29] zyga: thanks for the approvals [09:29] zyga: there are more for pi2,3,cm3,dragon [09:29] woot [09:29] zyga: but mup does not pick those up [09:29] adb works now [09:29] zyga: \o/ [09:29] mvo: I'll look now :) [09:29] I need to tweak my test snap to start adb as a service [09:30] but I can get it to do the right thing out of the box now :) [09:30] and the interface is not that scary actually :-) [09:45] mvo: let me know if there are any I missed please [09:46] ok [09:46] ta [09:46] hmm [09:46] 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] core18 based adb snap [09:46] it works when I run it as a user command [09:46] crashes when I run it as a service (type: forking) [09:50] zyga: crashes with denials? [09:50] no, just segvfault [09:51] this is all of journal when I install the package: [09:51] adb crashes when started as a service https://www.irccloud.com/pastebin/PTPzjlyC/ [10:09] anyone using opera snap on ubuntu? does it work? [10:09] I used it on Fedora [10:10] it worked but fonts weren't perfect [10:10] especially "normal" fonts, web fonts were ok [10:11] zyga: can you install it and check if it works still? [10:11] let me figure out why gnome shell is crashing onw [10:12] I cannot log in with zsh as my shell [10:12] hmm [10:12] I'll reboot [10:15] haha omg :) [10:15] rebooting fixed it [10:15] (I switched back to bash) [10:15] installing opera nonw [10:15] *now [10:16] PR pc-amd64-gadget#9 closed: snapcraft.yaml: add `base: core18` [10:16] PR pc-i386-gadget#7 closed: snapcraft.yaml: add `base: core18` [10:16] mborzecki: yes, it works [10:17] zyga: can you snap info? [10:17] snap info opera https://www.irccloud.com/pastebin/qJTN75jk/ [10:20] zyga: can you ls -l /snap/opera/7/usr/lib/x86_64-linux-gnu/opera/opera_sandbox ? [10:20] -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] zyga: and unsquashfs -ll /var/lib/snapd/snaps/opera_7.snap |grep opera/opera_sandbox [10:22] -rwxr-xr-x root/root 212632 2018-08-13 23:04 squashfs-root/usr/lib/x86_64-linux-gnu/opera/opera_sandbox [10:23] zyga: this is what happens on arch https://paste.ubuntu.com/p/BPr6THsF7d/ [10:23] snap run --shell opera [10:23] cat /etc/os-release [10:23] I wonder if this is related [10:23] zyga: ubuntu core [10:24] hmm [10:24] magic :) [10:24] no idea then [10:25] zyga: well the file is not seuid root so there's that [10:25] it cannot be setuid root [10:25] snaps cannot do that [10:25] zyga: right, but it complains hard about that here but not on ubuntu (?) [10:25] yeah, that _is_ odd [10:25] and also not on fedora [10:26] zyga: when have you tried it on fedora? maybe it was some older rev of the snap? [10:26] I tried it and it worked [10:26] same rev IIRC [10:26] i'll try chomium from snaps, it also does sandboxing via a helper [10:29] zyga: well, chromium snap works [10:29] anyone using fedora/opensuse? [10:30] I can boot both [10:30] zyga: do you have desktop installations? i only have cloud images [10:30] yes [10:31] I always use desktop versions [10:31] chromium works fine - https://paste.ubuntu.com/p/s2pgFqXNzB/ You are adequately sandboxed. [10:32] fedora works fine [10:32] same revision [10:32] I need to fix my suse installation now but I'll let you know [10:53] 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:57] pedronis: yeah, I just saw the rejects [10:57] installing most of opensuse desktop packages back [10:57] I wonder what caused zypper to remove pretty much all the packages that it could [10:57] I have grub back, installing gnome-shell [10:58] 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] pedronis: feels slightly magic but that may not be bad [10:59] 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 [11:00] pedronis: wdyt? [11:11] is it actually a code problem ? not just review tools (pushing then through manually should work too, no ) [11:11] *them [11:16] mvo: that sound optimistic , as I said any place doing .Base might have to be considered [11:18] PR snapd#5711 closed: tests: shellchecks part 8 [11:19] mvo: we might probably just need to be clever and some central places, but is not a trivial change [11:19] s/and some/in some/ [11:20] pedronis: hm,hm,it sounds like something we should talk about during the standup. [11:20] pedronis: I guess we need to figure out what feels most "correct" [11:21] 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] to be clear I'm not against [11:22] pedronis: yeah, I'm sitting on the fence [11:22] I just don't think is trivial path to unblock us [11:22] it might be correct but needs thinking/some work === pstolowski is now known as pstolowski|lunch [11:23] 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:29] mvo, with that base: core18 in the gadgets, how do we upload changes for core 16 ? [11:30] mvo, dont we need separate source trees/branches for the core 16 and 18 ones then ? [11:30] ogra: you would need branches corrresponding to tracks, but as we were discussing that was hasty and might need a rediscussion [11:35] 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] master is still core16 [11:36] (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:53] http://paste.ubuntu.com/p/gD7ty4jygC/ [11:54] * zyga failed to recover his opensuse installationn [11:54] grub works but there's no kernel or initrd [11:54] eh [11:57] kernels are overrated [11:57] write your own ;-p [11:57] in shell ! [11:57] !! [11:58] I seen someone working on a .NET kernel [11:58] heh [11:58] ref: https://github.com/mosa/MOSA-Project [12:00] hey, I found my crash [12:00] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858764 [12:00] adb sucks :/ [12:01] why would you run it in forking mode anyway ? [12:01] that's how it works [12:01] * ogra has in fact never seen a snap use daemon: forking yet [12:01] I wanted the service separatio [12:01] separation* [12:01] did you at least try with daemon: simple ? [12:02] it cannot be used this way because adb start-server forks [12:02] niemeyer, about the config done in the spread-cron project [12:03] niemeyer, is it possible to see how it is done? [12:04] niemeyer, because it is forcing us to create a project called "target" and run tests from there [12:04] but for the update the gce images I have some branches which require to do something different [12:05] and I can't see where/how this is configured [12:24] ogra: we have a "18" track for the gadgets already (was that the question?) [12:24] ogra: and a corresponding code branch but I see you discussed this already === pstolowski|lunch is now known as pstolowski [12:33] mvo, yeah, sorry, i only noticed it after asking [12:37] ok [12:37] dab works! :) [12:37] adb works [12:37] ogra: no worries [12:38] mvo: shall I register "adb" and push a snap there? :) [12:38] popey_: ^ [12:38] I have a working adb snap [12:40] stupid irc [12:41] zyga: does it contain _only_ adb? I know often people will install adb and fastboot and other bits and bobs [12:41] yes, only adb [12:43] Cool. you gonna maintain it? [12:44] no but I can hand it over to $someone [12:44] and it requires future snapd to work [12:45] ahh, worth holding back until you have a maintainer and it works ? :) [12:50] PR snapd#5713 opened: many: mount namespace mapping for parallel installs of snaps [12:50] zyga: fun fun ^^ [12:50] mmm [12:50] it uses layouts ... which is currently painful [12:51] (since it means every commit/build needs manual approval) [12:51] hmm ... weird [12:51] $ snap find falkon [12:51] Name Version Publisher Notes Summary [12:51] falkon 3.0.1 kde - Web Browser [12:51] $ snap info falkon [12:51] error: no snap found for "falkon" [12:52] * ogra pokes the store with a long pointy stick [12:52] https://snapcraft.io/falkon has it though [12:52] mborzecki: https://github.com/snapcore/snapd/pull/5713/files#r212296528 [12:52] PR #5713: many: mount namespace mapping for parallel installs of snaps [12:53] cachio: Let's get that fixed later today [12:53] niemeyer, sure, thanks [12:53] zyga: hahah omg, yeah [12:54] zyga: idk, maybe we could just pass $HOME and drop that silly part mauling SNAP_INSTANCE_USER_DATA, wdyt? [12:54] can you give me an example of how that would look like? [12:54] sorry for silly questions [12:57] nah, $HOME is silly [12:57] 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] PR #5713: many: mount namespace mapping for parallel installs of snaps [12:58] zyga, popey: I bet the ubports folks wouldn't mind adding it to their installer snap as an implementation detail [12:58] zyga: ok, we could use SNAP_REVISION and SNAP_INSTANCE_NAME, and work with this to get to /home/joe/snap [12:58] zyga: those are set by snap run [12:58] sergiusens: the interface work I'm doing is specifically for ubuports [12:59] zyga: is this generic hotplug for usb or very specific to adb/fastboot? [13:00] 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:02] oh [13:02] standup! [13:08] zyga: got this locally: https://paste.ubuntu.com/p/sgdyy3XqwX/ [13:42] ooo [13:42] the infamous mount error [13:42] collect anything you can think of [13:42] and add that to the forum thread [13:42] man, that's interesting! [13:42] mvo: reviewed the shorter one [13:42] mvo: I'll do the next one after eating lunch [13:43] zyga: heh, there's literally nothing to collect, journal has 'protocol' error and nothing more [13:43] look for two things: [13:43] dmesg logs IO error - check which loop devices are logged [13:43] zyga: btw. i was installing 2 snaps `snap install hello-world_foo hello-world_bar`, one got installed :P [13:43] dd the loop devices (all if you have space) [13:43] zyga: yeah, nothing in dmesg either [13:43] 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:44] and compare them to reference images [13:44] s/people/relevant people/ [13:44] are the loop devices corrupt? [13:44] mborzecki: I'm starving so I'll go now but please don't unmount, don't reboot [13:44] dd the loopback devices [13:44] collect losetup data [13:45] pedronis: sounds good [13:46] 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:55] mvo: I'm creating it [13:56] pedronis: thanks for that [13:59] mvo: https://forum.snapcraft.io/t/new-snap-type-snapd/7021 [13:59] pedronis: ta [14:01] zyga: heh, i'm stracing systemd, obviously this doesn't happen, the mment i stop strace, boom [14:06] mborzecki: that's interesting [14:06] I need to go to the post office to pick up a package [14:06] I'll break for some time now, then be back [14:09] PR snapcraft#2223 opened: snap: prepare override scripts to allow rebuilding [14:26] re :) [14:28] mvo: btw about transitioning to the new snapd type remember that we store it also in "snaps" SnapState [14:36] PR snapd#5705 closed: testutil: have File* checker produce more useful error output [14:40] * niemeyer is back, and happy.. all sorted [14:41] niemeyer: \o/ [14:48] mvo: about 5710, is it already safe to remove ubuntu-core support? [14:49] While it will be older some of our tests may repackage it [14:49] 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] zyga: I mean, we don't make new ones of these anymore [14:49] Right [14:49] * zyga resumes reading [14:56] mvo: LGTM except a/core/system/ on config access (unless you disagree) === 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 [15:18] zyga: thank you, looking === pstolowski is now known as pstolowski|afk [17:15] mvo, hey, I see this error in the snapd-vendor branch on spread cron [17:15]