[01:15] <amurray> so am sure I am doing something daft but am trying to add autostart support to my snap and snapcraft is complaining that 'autostart' is not a valid property
[01:15] <amurray> (using snapcraft 2.43.1+18.04)
[01:16] <amurray> Issues while validating snapcraft.yaml: The 'apps/indicator-sensors' property does not match the required schema: Additional properties are not allowed ('autostart' was unexpected)
[03:05] <amurray> ok so I guess this is some distinction between snapcraft.yaml and snap.yaml - how do I add autostart support to my snapcraft.yaml ?
[06:02] <mborzecki> morning
[06:02] <mvo> hey mborzecki - good morning
[06:03] <mborzecki> mvo: hey, aything interesting happened on thu/fri?
[06:04] <mvo> mborzecki: I took those days off so I don't really know. a bit of debugging on vscode and why it was relatively slow to start, turned out to be a fontconfig issue
[06:04] <mvo> i.e. incompatible cache formats
[06:04] <mvo> between library versions
[06:06] <mborzecki> mvo: mhm, saw that, i recall this being discussed before 18.04 as a potential issue, but it was never in the context of performance
[06:24] <amurray> fyi - I figured it out - need to use passthrough to be able to specify autostart in snapcraft.yaml
[06:56] <zyga> good morning
[06:57] <mvo> zyga: hey, good morning
[06:57] <mborzecki> zyga: hey
[06:57] <zyga> hey :)
[06:58] <zyga> one other interesting thing that happened yesterday
[06:58] <zyga> systemd maintainer produced base snaps for fedora29 :)
[06:58] <zyga> using parts of systemd
[06:58] <zyga> :-)
[06:58] <mborzecki> mkosi?
[06:59] <zyga> yes
[06:59] <zyga> it works, I will try to upload it to the store
[06:59] <zyga> last time I tried the store chocked on it
[06:59] <zyga> we also found three bugs:
[06:59] <zyga> I'll file them now
[07:02] <mborzecki> mvo: can you look at the latest changes in https://github.com/snapcore/snapd/pull/6039 ?
[07:02] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[07:04] <zyga> hmm, no mup for launchpad bugs?
[07:05] <zyga> I filed: https://bugs.launchpad.net/snapd/+bug/1801663 https://bugs.launchpad.net/snapd/+bug/1801664 https://bugs.launchpad.net/snapd/+bug/1801665
[07:05] <mvo> mborzecki: sure, let me do this now
[07:05] <mup> Bug #1801663: Cannot find snap-exec when fedora29 is the only installed base <snapd:Confirmed> <https://launchpad.net/bugs/1801663>
[07:05] <mup> Bug #1801664: Snapd fails to work in pure v2 cgroup system <snapd:Confirmed> <https://launchpad.net/bugs/1801664>
[07:05] <mup> Bug #1801665: Base snaps are not validated to be devoid of apps <snapd:Confirmed> <https://launchpad.net/bugs/1801665>
[07:33] <mup> PR snapd#6078 closed: ifacestate/ifacemgr: don't reload hotplug-gone connections on startup <Hotplug 🔌> <Simple 😃> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6078>
[07:40] <mup> PR snapd#6081 closed: overlord/ifacestate: mark connections disconnected by hotplug with hotplug-gone <Hotplug 🔌> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6081>
[07:45] <mup> PR snapd#6092 opened:  tests,store,daemon: ensure proxy settings are honored in auth/userinfo too (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6092>
[07:45] <mborzecki> looks like #5897 is almost ripe for landing, i'll push some updates there and it should be good to go
[07:46] <mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
[07:50] <mwhudson> zyga: do you know if anyone still uses / cares for plainbox?
[07:50] <zyga> no, it's been fused back into checkbox
[07:50] <zyga> (+1 to kill)
[07:52] <mwhudson> zyga: would you be able to file a bug asking for removal?
[07:52] <mwhudson> (obviously i can too but it might look better coming from you!)
[07:52] <zyga> I can try, what is the three-letter-acronym for that?
[07:52] <mwhudson> zyga: https://bugs.launchpad.net/ubuntu/+source/plainbox/+filebug
[07:53] <mwhudson> zyga: there is no three letter acronym for ubuntu :)
[07:53] <mwhudson> (it would be RoM == request of maintainer in debian i think)
[07:53] <zyga> oh, just on launchpad?
[07:53] <zyga> I was thinking in debian
[07:54] <mvo> 6070 needs a secnd review (should be simple)
[07:54] <mwhudson> zyga: in that case https://wiki.debian.org/ftpmaster_Removals#How_to_request_removal
[07:55] <mwhudson> zyga: but a launchpad bug would be great in addition
[07:55] <mwhudson> zyga: (it fails tests with python 3.7)
[07:55] <zyga> mborzecki: I'm double checking with CE but I suspect they don't need it anymore
[07:55] <zyga> they moved on to snaps now
[07:56] <mwhudson> zyga: hmm there are some reverse-depends
[07:56] <mwhudson> zyga: checkbox-ng, plainbox-provider-checkbox, plainbox-provider-resource-generic
[07:56] <zyga> yeah
[07:56] <zyga> but all of those are equally dead as debian packages
[08:00] <mvo> mborzecki: 6039 looks good, thanks for all the updates you did to this one!
[08:00] <mborzecki> mvo: np, heppy to move things forwards
[08:01] <mup> PR snapd#5996 closed: [RFC] daemon: support `snap logs snapd` to get snapd logs <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5996>
[08:09] <pstolowski> morning
[08:09] <mvo> hey pstolowski - good morning
[08:09] <mvo> fwiw, I really love the new distro name
[08:11] <pstolowski> indeed :)
[08:18] <mborzecki> disco dingo?
[08:18] <mvo> yeah
[08:31] <mborzecki> zyga: i've updated #5897, we can either close it or land it, i still think the interface is useful, defining gpios as keys is super convenient and imo people use it (i used it for a couple of custom devices)
[08:31] <mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
[08:33] <zyga> mborzecki: yeah, I think we want jdstrand to review it and kola to ack that it still works on their hardware
[08:33] <zyga> thank you for refreshing it
[08:39] <kyrofa> zyga, I just a got a bug report from someone who's snap stopped working. Logs are filled with "cannot perform operation: mount --bind /snap/core/current//etc/alternatives /tmp/snap.rootfs_PA4OiD/etc/alternatives: No such file or directory"
[08:40] <kyrofa> Any ideas?
[08:45] <zyga> kyrofa: yes, apparently there are no /etc/alternatives on the filesystem
[08:45] <zyga> unless we yanked them from core itself
[08:46] <zyga> and we indeed did just that
[08:46] <zyga> hmmm
[08:46] <zyga> kyrofa: what is the snap version?
[08:46] <kyrofa> zyga, I'm checking. Stable hasn't updated though, right?
[08:46] <kyrofa> Wonder if they're following a different channel
[08:47] <zyga> stable is 2.35.5 which looks slightly updated
[08:47] <zyga> but not 2.36
[08:49] <kyrofa> When you say you did indeed just do that, what were you referring to?
[08:49] <zyga> I mean that on my system /etc/alternatives is no longer in core
[08:49] <zyga> it looks like old snap-confine that is not matching the current core
[08:50] <kyrofa> Doesn't that get re-exec'd?
[08:53] <zyga> in a way, we run the right snap-confine directly
[09:03] <mup> PR snapd#6067 closed: tests/main/snap-service-after-before-install: verify after/before in snap install <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6067>
[09:04] <mborzecki> what shall we do about #5946 ?
[09:04] <mup> PR #5946: cmd/snap: unhide --name parameter to snap install, tweak help message <Parallel installs ⛓> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5946>
[09:08] <mup> PR snapd#6093 opened: daemon: spool sideloaded snap into blob dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/6093>
[09:08] <Chipaca> good morning peeps
[09:08] <pstolowski> mornings Chipaca !
[09:09] <Chipaca> i woke up early and got caught up in some snapd work instead of having breakfast
[09:09] <Chipaca> so now i'm going to go fix that, brb :-)
[09:10] <mvo> hey Chipaca !
[09:19] <Chipaca> mvo: o/ !
[09:19] <Chipaca> mvo: how've you been?
[09:20] <mvo> Chipaca: very well, thank you! nice and relaxing long weekend, just some debugging around fontconfig issues with snaps mixed in but beside this all great
[09:20] <mvo> Chipaca: and you?
[09:21] <Chipaca> mvo: no fontconfig debugging here
[09:21] <Chipaca> mvo: but, wondering if we can't expose a "this snap uses fontconfig x.y.z" flag somewhere
[09:22] <Chipaca> mvo: also wondering about per-user hooks
[09:22] <mvo> Chipaca: yeah, I think there are some things we don't fully understand yet. for example on 18.04 I get a ~/.cache/fontconfig dir populated when I run with an older fontconfig. but that does not happen with the same snap on 18.10
[09:23] <mvo> Chipaca: yeah, per-user cache with per-user hook would solve this
[09:24] <kyrofa> zyga, look at that `snap version`: https://github.com/nextcloud/nextcloud-snap/issues/776#issuecomment-435803559
[09:24] <kyrofa> How is that possible?
[09:24] <mvo> Chipaca: but some work ahead, also versionizing the font-config cache files
[09:25] <Chipaca> kyrofa: no re-exec
[09:25] <mvo> Chipaca: if they are not already, the trouble is we don't really know (yet). but maybe james hensdrige knows more or someone from the desktop team
[09:26] <Chipaca> here's hoping the solution or workaround isn't  ubuntu-centric
[09:27] <Chipaca> zyga: btw you semi-reviewed #6065, before I went and split it as you requested. Could use another semi review :-D
[09:28] <mup> PR #6065: cmd: make coreSupportsReExec faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6065>
[09:28] <kyrofa> Chipaca, how would that get disabled in xenial?
[09:28] <kyrofa> Doesn't that require setting an environment variable in the systemd unit?
[09:29] <Chipaca> kyrofa: pseudo-user on a pseudo-terminal
[09:32] <kyrofa> Chipaca, that shouldn't effect which snapd is actually running then, right?
[09:33] <zyga> kyrofa: looking
[09:34] <Chipaca> kyrofa: that was a joke :-) AFAIK 2.20 already re-exec'ed, on ubuntu, so having it not do so requires user (sysadmin) action
[09:34] <zyga> Chipaca: enqueued
[09:34] <Chipaca> 2.10ish was when we flipped that particular switch iirc
[09:34] <Chipaca> zyga: enthanked
[09:34] <kyrofa> Chipaca, oh thank goodness. I respect you too much, I thought this was technology with which I was very much unfamiliar :P
[09:35] <Chipaca> i should shave my beard and start a youtube channel, to get the respect dialed back a bit
[09:35] <kyrofa> Agreed
[10:02] <mborzecki> Chipaca: do you have any suggestions about https://github.com/snapcore/snapd/pull/5946 ?
[10:02] <mup> PR #5946: cmd/snap: unhide --name parameter to snap install, tweak help message <Parallel installs ⛓> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5946>
[10:05] <Chipaca> mborzecki: what about?
[10:05] <Chipaca> mborzecki: degville suggested things there already :-)
[10:06] <Chipaca> mborzecki: and you have two +1's
[10:07] <mborzecki> Chipaca: thought you meant that we should add more changes
[10:07] <mborzecki> Chipaca: which in fact i'll do just now, the last paragraph is a bit off
[10:07] <Chipaca> heh
[10:07] <mborzecki> last paragraph of the help message
[10:08] <Chipaca> mborzecki: ok
[10:12] <Chipaca> mborzecki: _the_ instance name?
[10:13] <mborzecki> heh, let me force push that
[10:13] <Chipaca> mborzecki: did you implement graham's suggestion? i can't see it but then i'm sleepy
[10:14] <mborzecki> Chipaca: yup, both of them
[10:14] <Chipaca> k
[10:26] <kyrofa> zyga, any thoughts on that?
[10:26] <zyga> kyrofa: on the version?
[10:26] <kyrofa> Yeah
[10:26] <zyga> no, no idea, logs would confirm why snapd doesn't reexec
[10:27] <zyga> if you can collect logs from snapd.service it would tell us
[10:27] <Chipaca> brb, reboot
[10:29] <kyrofa> zyga, alright, requested
[10:32]  * cachio afk
[10:33] <ackk> hi, I'm having an issue with bash completion in a (classic) snap. it doesn't seem to work, but if I snap run --shell and source the completion file, it does work there. is there perhaps something different in how snapd handles that?
[10:39] <Chipaca> ackk: https://forum.snapcraft.io/t/debugging-tab-completion/4198
[10:39] <ackk> Chipaca, thanks
[10:39] <sparkiegeek> ackk: can you share your snapcraft.yaml, and `snap version`?
[10:39] <sparkiegeek> well, Chipaca's link is better :)
[10:39] <Chipaca> :-D
[10:40] <ackk> sparkiegeek, https://git.launchpad.net/~sshoot/sshoot/+git/packaging/tree/snap/snapcraft.yaml
[10:41] <Chipaca> ackk: please let me know how the debugging goes (specifically: at which step of the debugging things break down)
[10:43] <sparkiegeek> ackk: sshoot-completion != shell-completion
[10:44] <sparkiegeek> ackk: you have the former defined in the app, and the latter in your part
[10:44] <ackk> sparkiegeek, shell-completion is a dir, in which sits sshoot which is copied as sshoot-completion
[10:44] <ackk> Chipaca, should I run the "complete -p" inside the snap run or from my system?
[10:45] <Chipaca> ackk: no
[10:46] <Chipaca> ackk: in my defence it does tell you to exit the snap run --shell :-)
[10:46] <ackk> Chipaca, sorry, missed it :)
[10:52] <ackk> Chipaca, so, the -x shows something different: https://paste.ubuntu.com/p/h2TkVGxprm/
[10:53] <Chipaca> ackk: that looks almost exactly the same
[10:53] <ackk> Chipaca, yeah but see it fails?
[10:54] <Chipaca> ah, yes
[10:54] <ackk> Chipaca, there seems to be an error mesage like "cannot..." being parsed
[10:54] <Chipaca> ackk: so go on to the next step :-)
[10:54] <Chipaca> i'm starting to guess where the issue is
[10:54] <Chipaca> but go ahead
[10:56] <ackk> Chipaca, so if I snap run and source the bash completion it doesn't work
[10:56] <ackk> Chipaca, what do you think the issue is?
[10:56] <Chipaca> ackk: looking at the completer, I guessed wrong
[10:56] <Chipaca> :-)
[10:57] <ackk> Chipaca, fwiw the snap run --command=complete returns "default"
[10:57] <Chipaca> ackk: when you say that sourcing the bash completion doesn't work, what do you mean?
[10:58] <ackk> Chipaca, oh, wait
[10:58] <ackk> Chipaca, n/m, so step 5 works
[10:59] <ackk> Chipaca, so everything works, except it doesn't :)
[10:59] <Chipaca> ackk: ok, let's rewind a bit
[11:00] <Chipaca> ackk: what should it do, that it isn't doing?
[11:00] <Chipaca> what should it complete with?
[11:00] <ackk> Chipaca, the command options
[11:00] <Chipaca> ackk: but it completes with filenames, here
[11:01] <Chipaca> also
[11:01] <Chipaca> also
[11:01] <ackk> right, because it's falling back to the default completer I guess
[11:01] <Chipaca> bah, maybe i'm looking at an old version :-)
[11:01] <Chipaca> yes probably
[11:01] <Chipaca> ackk: what do you get when you do the 'snap run --command=complete yadda yadda' step?
[11:01] <ackk> Chipaca, https://paste.ubuntu.com/p/NS3m5St8mz/
[11:02] <Chipaca> ackk: that's the non-snapped one I presume
[11:02] <ackk> Chipaca, no, it's the snap, from inside a snap run, as per step 5
[11:02] <Chipaca> ackk: what's the output on step 4?
[11:03] <ackk> Chipaca, https://paste.ubuntu.com/p/7gbVwVM7Sv/
[11:03] <ackk> (I used the number from the bash -x from the step before
[11:03] <ackk> Chipaca, I wonder if something in my bash setup is messing the compelter up
[11:03] <Chipaca> hm, I don't get that
[11:03] <ackk> although that has never happened for any other completion
[11:03] <Chipaca> but I've installed the one in stable
[11:03] <ackk> oh?
[11:04] <Chipaca> which might be different
[11:04] <ackk> Chipaca, they're the same
[11:04] <ackk> Chipaca, 72?
[11:04] <Chipaca> ackk: https://pastebin.ubuntu.com/p/gFD7KsRVpR/
[11:04] <Chipaca> ackk: and then all the files
[11:04] <ackk> Chipaca, which version of the snap do you have?
[11:05] <Chipaca> ackk: revision 72
[11:05] <Chipaca> ackk: also, also:
[11:05] <Chipaca> ~$ sshoot
[11:05] <popey> cjwatson: is there a timeline on when the "('Connection aborted.', gaierror(-3, 'Temporary failure in name resolution')) " store upload fails might be fixed?
[11:05] <Chipaca> /snap/sshoot/72/command-sshoot.wrapper: 2: exec: /snap/sshoot/72/usr/bin/python3: not found
[11:05] <popey> https://launchpad.net/~build.snapcraft.io/+snap/b2218f767981315ff64384e4f403d972-xenial/+build/370290 for example
[11:05] <ackk> Chipaca, https://paste.ubuntu.com/p/bVfBTFdVDW/
[11:06] <Chipaca> ackk: I'm not sure what you're showing me :-)
[11:06] <Chipaca> ackk: this is a classic snap, yes?
[11:06] <ackk> Chipaca, yes
[11:06] <ackk> this is really weird
[11:06] <Chipaca> no not that weird
[11:06] <Chipaca> just classic weird
[11:06] <mborzecki> opened a topic with cross-snap service ordering proposal https://forum.snapcraft.io/t/cross-snap-service-ordering/8319 feel free to comment
[11:06] <Chipaca> ackk: do this
[11:06] <ackk> Chipaca, does "sshoot list" work for you?
[11:06] <Chipaca> ackk: get into 'snap run --shell'
[11:07] <Chipaca> ackk: i mean 'snap run --shell sshoot'
[11:08] <ackk> Chipaca, and then?
[11:08] <Chipaca> ackk: /usr/bin/python3
[11:08] <Chipaca> ackk: and then
[11:08] <Chipaca> ackk: import argcomplete
[11:08] <Chipaca> ackk: and them
[11:08] <ackk> not found
[11:08] <ackk> but why is it trying /usr/bin/python3
[11:09] <Chipaca> ackk: /usr/bin/env python3
[11:09] <Chipaca> ackk: unless your wrapper is rewriting PATH?
[11:09] <ackk> Chipaca, so I need to put $SNAP/usr/bin in path first
[11:09]  * Chipaca looks
[11:10] <ackk> no it doesn't
[11:10] <Chipaca> ackk: also, the python3 you're shipping doesn't work here
[11:10] <ackk> what?
[11:10] <Chipaca> ackk: bah, agian let me look at the wrapper
[11:11] <Chipaca> ackk: so, the wrapper should be fine on the path front (it execs $SNAP/yadda), but the completion script needs the same treatment
[11:11] <Chipaca> ackk: or tweaking the path
[11:12] <Chipaca> ackk: but
[11:12] <ackk> Chipaca, ok, I'll just include a copy of that script in the snap, it's one line anyway :)
[11:12] <Chipaca> /snap/sshoot/72$ ./usr/bin/python3
[11:12] <Chipaca> bash: ./usr/bin/python3: No such file or directory
[11:12] <ackk> Chipaca, yeah it's just "python" I think
[11:12] <Chipaca> ackk: nope, it's python3, a symlink to python3.6
[11:13] <Chipaca> ackk: but the libraries are messed up
[11:13] <ackk> $ ./usr/bin/python3 -c "print('hello')"
[11:13] <ackk> hello
[11:13] <ackk> Chipaca, ^
[11:14] <ackk> Chipaca, are you running it inside the snap run?
[11:14] <Chipaca> ackk: you're on 18.04, running a core18 snap, i presume
[11:14] <ackk> Chipaca, yeah
[11:14] <Chipaca> ackk: yeah
[11:14] <Chipaca> ackk: that doesn't exactly test the libraries are being picked up from where you expect them to be ;-)
[11:14] <ackk> I see
[11:14] <ackk> sigh
[11:14] <ackk> ok, I'll take a look, thanks for the help Chipaca
[11:15] <Chipaca> ackk: fun
[11:15] <mup> PR snapd#6091 closed: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6091>
[11:15] <ackk> yeah...
[11:15] <mborzecki> mvo: can you cherry-pick that PR to 2.36? ^^
[11:16] <Chipaca> ackk: classic is tricky this way (and others, but this way)
[11:16] <Chipaca> ackk: good luck
[11:16] <ackk> Chipaca, thanks :)
[11:18] <popey> Hm, is there some way to re-run console conf by removing some file on the sd card?
[11:19] <mvo> mborzecki: sure, doing now
[11:19] <mborzecki> mvo: ta
[11:19] <popey> (I have moved my pi from home to office, and need to re-run console conf to connect to wifi)
[11:19] <ogra> popey, yes, there is a file ... one sec
[11:19]  * Chipaca afk
[11:19] <mvo> mborzecki: thank you! its in :)
[11:20] <popey> ogra: thanks
[11:25] <ogra> popey, /writable/system-data/var/lib/console-conf/complete
[11:26] <popey> $ sudo mount /dev/mmcblk0p2 /mnt/writable/
[11:26] <popey> mount: /mnt/writable: cannot mount /dev/mmcblk0p2 read-only.
[11:26] <popey> :(
[11:27] <ogra> weird ... anything in dmesg ?
[11:27] <popey> [10917.675750] EXT4-fs (mmcblk0p2): write access unavailable, cannot proceed (try mounting with noload)
[11:27] <popey> huh, not sen that before
[11:27] <popey> ahh, [10917.675746] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[11:28] <ogra> wants an fsck it seems
[11:28] <popey> Disk write-protected; use the -n option to do a read-only
[11:28] <popey> stupid sd card adapter :)
[11:28] <ogra> yeah
[11:29] <cjwatson> popey: Not at this point
[11:29] <cjwatson> It's very very weird and has resisted understanding so far
[11:30] <popey> cjwatson: ok, so just keep re-triggering builds until it works?
[11:31] <cjwatson> I don't have a better offer at the moment
[11:31] <popey> ogra: /writable/system-data/var/lib/console-conf/complete doesn't exist
[11:31] <cjwatson> But do tell us when it happens because it generally means we need to restart a thing
[11:31] <popey> ok
[11:31] <cjwatson> Once it's in that state there's a 1/3 chance of any given upload failing that way, until we restart it
[11:32] <ogra> popey, hmm, then console-conf should run ... unless something changed ... in which case mwhudson is your man i think
[11:32] <popey> cjwatson: i re-triggered the one above
[11:32] <popey> ogra: ok
[11:32] <popey> ogra: might start a thread on the forum, because this is something undocumented afaict
[11:33] <cjwatson> I've requested that the cursed worker be killed
[11:33] <popey> cjwatson: thanks
[11:38] <popey> file:///home/alan/Pictures/Screenshot_20181105_113742.png https://usercontent.irccloud-cdn.com/file/1JYDSny9/aargh%20%3A)
[11:38] <popey> ogra: ^
[11:39] <popey> using an hdmi capture card as I don't have a monitor
[11:39] <ogra> popey, modern art ?
[11:39] <popey> thats - i assume - some message about a lack of ip address
[11:39] <popey> I guess I need an ethernet cable
[11:41] <cjwatson> popey: Should be happier now, at least for the time being
[11:44] <popey> Ubuntu Core 16 on <no ip address> (ttyS0)
[11:44] <popey> You cannot log in until the system has an IP address.
[11:44] <popey> (Is there supposed to be a DHCP server running on your network?)
[11:45] <popey> (is what it says)
[11:50] <ogra> popey, well, console-conf should override this if the completion file is missing, not sure why you dont have it
[11:52] <popey> I'll start a thread
[11:52] <mup> PR snapd#6092 closed:  tests,store,daemon: ensure proxy settings are honored in auth/userinfo too (2.36) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6092>
[11:57] <zyga> [   52s] snapd-2.33.1/gopath/src/github.com/snapcore/snapd/overlord/snapstate/autorefresh.go:182: Noticef format %s has arg int(maxPostponement.Hours() / 24) of wrong type int
[12:00] <mborzecki> zyga: wasn't that fixed in master already?
[12:00] <zyga> this is 2.33.1 :)
[12:00] <mborzecki> oh
[12:01] <zyga> one more failiure https://www.irccloud.com/pastebin/np5xC9Mc/
[12:01] <zyga> perhaps test keys?
[12:01] <zyga> but on the upsdie
[12:01] <ogra> stop playing with that old cruft :P
[12:01] <zyga> no more golang-packaging macros
[12:01] <zyga> logs are short
[12:01] <zyga> code is simple
[12:01] <mborzecki> zyga: opensuse?
[12:01] <zyga> errors make sense
[12:01] <zyga> yes, wrapping up that work
[12:01] <mborzecki> that looks like a piece from rpmbuild log
[12:02] <zyga> yes
[12:02] <zyga> I rewrote parts of the packaging to drop the golang-packaging macros
[12:02] <zyga> to unbreak our builds
[12:19] <zyga> on the upside master is green on suse now
[12:42] <mborzecki> hmm might have found a bug in generated service wrappers with Before=
[12:43] <zyga> oh?
[12:43] <mborzecki> something for .1 i belive
[12:44] <mborzecki> damn, go templatles are both fun to use and really frustrating
[12:44] <Chipaca> mborzecki: funstration is best stration
[12:44] <Chipaca> I mean, it beats defenestration at least
[12:45] <mborzecki> need to look that up :)
[12:45] <mborzecki> 'Defenestration is the act of throwing someone or something out of a window'
[12:45] <mborzecki> wonder why 'someone' comes first
[12:45] <zyga> mborzecki: wow really?
[12:45] <zyga> I mean, school has burned that word into my head
[12:46] <Chipaca> mborzecki: because it's not usually used literally
[12:46] <zyga> I have 2.36 packaged for suse, if you want to review mborzecki
[12:46] <zyga> I'll figure out how to create a diff in osc
[12:47] <mborzecki> isn't there osc diff? :)
[12:49] <zyga> I mean I want to push this
[12:49] <zyga> but I started in system:snappy
[12:49] <zyga> osc just sucks for workflow
[12:49] <zyga> and I already have "a branch" so I cannot branch again
[12:49] <mborzecki> just imaging it's svn
[12:50] <mborzecki> right, so when there's more than one serivce in before: ..., we generate Before=.. without whitespace separating service names
[12:51] <zyga>  oops
[12:53] <mborzecki> mvo: ^^ i'll push a PR for this and we'll need to cherry pick it to 2.36
[12:58] <zyga> Chipaca: hmm
[12:58] <zyga> around?
[13:00] <Chipaca> zyga: yes
[13:00] <Chipaca> zyga: standup
[13:00] <zyga> oh
[13:00] <zyga> sure
[13:09] <Son_Goku> mborzecki, unfortunately, obs vcs is derived from svn
[13:10] <Son_Goku> zyga, you can branch again as much as you want, you just need a different branch project to use
[13:10] <Son_Goku> zyga, you can also use copr to build for opensuse if you'd prefer git-ish workflows :)
[13:10] <zyga> nah, that's fine - I'll just release it on OBS now
[13:12] <Son_Goku> JamieBennett, can we get RHEL 7 to wire up into spread?
[13:12] <mborzecki> Son_Goku: centos is wip in my branch, but we hit some problems with MNT_DETACH and an old-ish kernel
[13:13] <Son_Goku> mborzecki, if you have a Fedora system, you can trivially boot RHEL 7 using RHEL Developer licenses on your computer in a VM
[13:13] <Son_Goku> using gnome boxes
[13:14] <mborzecki> Son_Goku: do you know if there's any timeline for centos 7.6?
[13:14] <Son_Goku> current expectation is sometime in the next 2-3 weeks
[13:14] <Son_Goku> they've already started chewing through a good chunk of it since the code drop last week: https://twitter.com/JohnnyCentOS/status/1058359691628216320
[13:16] <mborzecki> Son_Goku: thx
[13:21] <amunizp> Hi all, any chance there are any IoT developers here?
[13:26] <zyga> amunizp: probably, what do you need?
[13:26] <ogra> amunizp, how about you just ask a question ? :)
[13:30] <mvo> mborzecki: uh, thanks, yeah, thats a show-stopper
[13:31] <amunizp> Well, the question might not be appropriate for the channel but here goes. I am looking for hands on mentors for a hackathon like event probably spring or summer 2019. The idea is to help develop IoT crowd system (size of about 4 million). The work will be paid for around 4 people managing a group of about 4 people. So my question is: what it the day rate for such a dev/hardware hacker? knowledge needed would be: is this a job for a beag
[13:31] <amunizp> le bone or an FPGA device? what kind of encryption should be needed on the hardware? would it be best on the server? Can these devices consume low battery?
[13:33] <amunizp> *lower battery?
[13:33] <amunizp> Does that answer your question zyga and ogra ?
[13:35] <ogra> amunizp, sounds like the #beagle channel might be a good fit for you (at least for the beaglebone part of the question)
[13:37] <zyga> amunizp: I'll answer after a meeting I'm in
[13:37] <mup> PR snapd#6094 opened: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6094>
[13:37] <mborzecki> mvo: ^^
[13:39] <amunizp> hi ogra, sorry my question is: Does the person I want to contract know about the different IoT hardware tech available? beagle bone vs fpga is an example.
[13:41] <zyga> amunizp: I think this is not the best question for things like that
[13:41] <zyga> amunizp: your question is very much dependent on the location and other parameters of the employer
[13:42] <zyga> er, I mean, not the best channel for questions like that
[13:42] <ogra> amunizp, the moore knowledgeable people in #bagle are definitely capable of answering that ... though you need to likely be a bit more detailed about your use case "IoT" is just a marketing buzzword ans doesnt explain what your implementation really needs
[13:43] <ogra> *more ... #beagle
[13:43] <ogra> (geez my typing)
[13:45] <amunizp> Thanks! Location is London. I'll pop by #beagle
[13:51] <mvo> mborzecki: ta!
[13:58] <popey> thresh: https://github.com/snapcore/snap-store-badges :)
[14:02] <kyrofa> zyga, these logs don't seem very helpful: https://github.com/nextcloud/nextcloud-snap/issues/776#issuecomment-435884175
[14:03] <zyga> kyrofa: I'll check soon
[14:03] <Chipaca> mborzecki: https://play.golang.org/p/Fv2i0k78LNK ?
[14:03] <zyga> I need to grab some food
[14:03] <Chipaca> mborzecki: is the second one not what you want?
[14:04] <mborzecki> Chipaca: i want Before=one two\n
[14:04] <Chipaca> mborzecki: y tho
[14:04] <Chipaca> i mean i get it looks neater :-)
[14:06] <mborzecki> off to pick up the kids
[14:07]  * pstolowski lunches
[14:24]  * cachio afk
[14:27] <mup> Bug #1801735 opened: Typo in model assertions <Snappy:New> <https://launchpad.net/bugs/1801735>
[14:35] <zyga> kyrofa: not much detali :/
[14:35] <zyga> Do you know more about that system? Is it a core device?
[14:42] <Chipaca> zyga: kyrofa: added a comment there
[14:45] <kyrofa> zyga, it's 16.04, but not much more detail than that
[14:45] <kyrofa> Chipaca, thanks, although now I'm worried we'll never know how the machine got into that state
[14:45] <kyrofa> But I suppose unblocking is really what they want
[14:46] <Chipaca> kyrofa: I'm downloading 16.04.1 to see if i can reproduce it
[14:48] <Chipaca> ok so 16.04.1 shipped 2.0.10
[14:49]  * Chipaca tries .2
[14:49] <zyga> Thank you chipaca!
[14:49] <Chipaca> we've come so far since 2.0.10
[14:50] <Chipaca> it had, like, 10 commands
[14:50] <Chipaca> :-)
[14:50] <zyga> 10 commandments ;-)
[14:51] <Chipaca> $ snap
[14:51] <Chipaca> error: Please specify one command of: abort, ack, change, changes, connect, create-user, disconnect, find, help, install, interfaces, known, list, login, logout, refresh, remove, run or try
[14:54] <Chipaca> zyga: kyrofa: and 16.04.2 ships 2.21
[14:55] <Chipaca> zyga: kyrofa: and I can confirm it re-execs into core just fine
[14:56] <zyga> So manually disabled probably
[14:56] <zyga> I think there are two lessons
[14:56] <zyga> One: core should “assumes: snapd2.35”
[14:57] <zyga> And another, we need snap debug reexec
[14:57] <kyrofa> I wonder why it would be manually disabled
[14:58] <Chipaca> kyrofa: they've tinkered with the environment, obviously
[14:58] <zyga> Doesn’t have to be
[14:58] <zyga> But probably is
[14:58] <Chipaca> um
[14:58] <Chipaca> those are DEBUG logs
[14:59] <Chipaca> so they _have_ tinkered with the environment
[14:59] <Chipaca> what i was about to say was that it wasn't too much of a stretch to think that they'd done more than just set debug :-)
[14:59] <Chipaca> we can ask
[14:59] <Chipaca> but see rule #1 about users
[15:05] <zyga> back at the office
[15:18] <ogra> seb128, yo ! ... there is a thing i noticed about the font handling in the dektop launchers ... wehn i build kiodk apps to run on ubuntu-core where there is no dekto i always have to patch the fonts.conf file to make fontconfig work at all ... (it has a hardcoded /usr/share a fonts search path), i noticed your fontconfig discussion and was wondering if that could be a hint ... afaik the desktop launcher codde ddoes not modify the in-snap fonts.conf at
[15:18] <ogra> all (so shipped fonts are never in the search path)
[15:18] <ogra> oh man ...
[15:18] <ogra> my broken kbd really showss
[15:18] <seb128> ogra, it's not the issue, but thx for pointing it out
[15:19] <seb128> the cache is by dir
[15:19] <seb128> if some dirs are missing it means some fonts would be missing
[15:19] <seb128> but not impact the start time
[15:20] <ogra> seb128, well, if you set FONTCONFIG_FILE to $SNAP/etc/fonts/fonts.conf and that only has /usr/share/fonts, it will never consider the font files in $SNAP
[15:20] <ogra> but alway use the system dirs ... which go through an interface ...
[15:21] <seb128> most fonts are not bundled in the snap anyway
[15:21] <ogra> k
[15:23] <seb128> ogra, also https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L240
[15:23] <seb128>  for ((i = 0; i < ${#data_dirs_array[@]}; i++)); do
[15:23] <ogra> ah, k on desktop you re-generate it anyway
[15:24] <seb128> right
[15:24] <ogra> yeah, then you are likely fine ... (i cant do that on core ... well i could but for no benefit since there are no fonts ...) ... anyway, was just an observation
[15:55] <jdstrand> roadmr: hi! can you pull r1150?
[15:56] <roadmr> jdstrand: sure thing! coming up
[15:57] <jdstrand> roadmr: thanks!
[15:57] <zyga> jdstrand: hello, welcome back
[15:58] <jdstrand> zyga: thanks! I was actually back since last Wed :)
[15:58] <zyga> I was off since Thursday
[15:58] <jdstrand> heh
[15:58] <jdstrand> hope you had nice time off :)
[16:15] <mup> PR snapd#6095 opened: packaging/opensuse: stop using golang-packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/6095>
[16:15] <zyga> jdstrand: thanks, it was nice to spend more time with the family
[16:17] <roadmr> jdstrand: hey a question: if I want to exempt 3 specific gadget snaps from being red-flagged/manually reviewed, they'd have to be added to redflagged_snap_types_overrides['gadget'], right? Is it OK to do so with gadget snaps that live in a brand store/
[16:18] <roadmr> ?
[16:19] <zyga> roadmr: hey, do you remember that bug with fedora29?
[16:19] <zyga> roadmr: is there any update on that, I tried submitting it lately and it still fails on __all__
[16:20]  * roadmr hides behind a bush
[16:20] <jdstrand> roadmr: yes and yes. I'm right there if you want to privmsg me
[16:20] <roadmr> zyga: the latest I heard, it was fixed :/ the store can remove the evil fedora 555 files, the review tools can as well, and those updates are in production
[16:20] <zyga> roadmr: let me try
[16:21] <roadmr> zyga: I assumed you were satisfied with it because I saw some published f29 snaps already :(
[16:21] <zyga> roadmr: those were done earlier with the hack
[16:21] <zyga> hey, no worries though :-)
[16:22] <roadmr> zyga: oh I remember - I was supposed to push the f29 evil snap as root so snapcraft is also happy, and check what else the store says
[16:23] <roadmr> fwiw the hack should only be setting squashfs-root to 755, which doesn't sound horrible, does it? I mean, in fedora, is the mode for / 555? not writable by root? who are they fooling? :)
[16:24] <zyga> roadmr: yes
[16:24] <zyga> [zyga@faroe ~]$ ls -ld /
[16:24] <zyga> dr-xr-xr-x. 18 root root 4096 10-19 11:58 /
[16:25] <roadmr> zyga: right... ok, that's probably why squashfs-root itself has that weird mode
[16:25] <zyga> yeah
[16:28] <roadmr> zyga: I'll have another look in a bit
[16:28] <zyga> roadmr: thanks!
[16:28] <zyga> there's going to be a new build soon
[16:29] <zyga> now based on mkosi
[16:29] <zyga> but that should not change this
[16:29] <zyga> Wimpress: FYI, I'm prepping for a 2.36 across opensuse
[16:29] <zyga> it fixes many known issues
[16:29] <zyga> including unbreaking all of tumbleweed snap support
[16:48] <Chipaca> pstolowski: do we have 'snapctl status'?
[16:48] <zyga> cachio: hey
[16:48] <zyga> error: cannot pack "/home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/basic-desktop": write /tmp/.snap-pack-exclude-116402540: no space left on device
[16:48] <zyga> have you seen any issues with insufficient space on amazon instances?
[16:49] <pstolowski> Chipaca: nope
[16:50] <zyga> mvo: when do you anticipate 2.36.1
[16:51] <pstolowski> Chipaca: interesting... did we have 'snap services' from the beginning, or was it added later? i remember snapctl was modelled after snap start/stop/restart
[16:51] <Chipaca> pstolowski: services and logs were part of the same piece of work
[16:52] <cachio> zyga, hey
[16:52] <Chipaca> pstolowski: any reason not to add the missing two?
[16:52] <cachio> zyga, yes, this is the one I mentioned today
[16:52] <cachio> in the standup
[16:52] <zyga> oh, sorry I missed that
[16:52] <cachio> I'll push a PR today
[16:52] <zyga> thanks!
[16:53] <Chipaca> um
[16:53] <Chipaca> um
[16:53] <Chipaca> hold on
[16:53] <Chipaca> what's that doing?
[16:53] <cachio> zyga, I am still working on the spread issue but I'll back to that one later, thanks
[16:53] <zyga> thank :)
[16:53]  * Chipaca greps
[16:53] <zyga> Chipaca: ?
[16:54] <Chipaca> is it always that file?
[16:54] <Chipaca> cachio: zyga:?
[16:54] <zyga> ok, it's almost 18;00 and my head is dizzy from ABS fume
[16:54] <Chipaca> zyga: dude
[16:54] <zyga> Chipaca: first time I saw this
[16:54] <zyga> Chipaca: not sure
[16:54] <zyga> I'll head upstairs until I can vent this room
[16:54] <Chipaca> zyga: go smoke something healthy to give yourself a break
[16:55] <Chipaca> like, i dunno, bacon
[16:55] <zyga> abs shrinks and warps when cooled
[16:55] <mvo> zyga: there is the open question about "snapd 2.36 API "system" vs "core" slot name" - I sent a mail about this last week, you are on the CC i have no reply yet
[16:55] <pstolowski> Chipaca: no, we should have status at least i think, not sure about logs. and they should be narrowed to services of current snap of course
[16:55] <mvo> zyga: once we know what to do here we can continue
[16:55] <zyga> mvo: the one for our customers?
[16:55] <zyga> mvo: ok
[16:55] <zyga> mvo: thanks!
[16:55] <mvo> zyga: yeah, I ping htem now
[16:55] <zyga> thanks!
[16:55] <Chipaca> pstolowski: yeah not sure what purpose logs would serve
[16:55] <zyga> I'm asking because the base snap refresh bug fix is important for desktops
[16:55] <zyga> so perhaps I should cherry pick it
[16:56] <Chipaca> cachio: dunno if you saw my question, is the out-of-space error always about .snap-pack-exclude?
[16:56] <pstolowski> Chipaca: i can only think of having 'logs' for consistency, but that's probably not enough
[16:56] <mvo> zyga: cherry pick to 2.36? absolutely if its important
[16:56] <cachio> Chipaca, no
[16:56] <Chipaca> cachio: ah, phew
[16:56] <zyga> yeah, I'll do that
[16:56] <cachio> I have seen it about other stuff too
[16:57] <zyga> Chipaca: tomorrow: I'd like to shrink packaging and grow a makefile
[16:57] <zyga> it's very annoying that we have so many things done in a build script that is distro specific
[16:57] <zyga> I'll bug you for reviews :)
[16:57] <cachio> Chipaca, i.e. https://travis-ci.org/snapcore/spread-cron/builds/450694163#L2503
[16:57] <Chipaca> cachio: i was worried because .snap-pack-exclude could very easily be a static file somewhere (it was just a faff to get it right on darwin)
[17:33] <roadmr> zyga: hm, I updated https://bugs.launchpad.net/snapstore/+bug/1786071 with the traceback I got with the fedora snap - looks like the click reviewer tools are still unhappy, we fixed the case where files/dirs inside squashfs-root have funny perms but may have obviated the "squashfs-root itself has funny perms" case :(
[17:42] <roadmr> jdstrand: ^^ the above sounds similar to https://bugs.launchpad.net/click-reviewers-tools/+bug/1712476 , which was about files inside squashfs-root having funny perms but it may have obviated funny perms on squashfs-root itself :/
[17:44] <zyga> roadmr: that's great, thank you for checking
[17:45] <roadmr> np, sorry we keep finding funny cleanup cases
[17:53] <jdstrand> roadmr: what revision of the snap? if seems the latest ones passed review
[17:54] <zyga> jdstrand: when I pushed myself it was not even registered by the store
[17:54] <zyga> prior revisions were hacked to pass
[17:56] <jdstrand> zyga: is it the fedora29.2018.10.09.x86_64.snap you wormholed to me?
[17:56] <zyga> I honestly don't recall now, I can quickly build a daily to test
[17:57] <zyga> but it was simply chmod ugo-w / that broke things AFAIK
[17:58] <jdstrand> dr-xr-xr-x root/root               269 2018-10-09 11:27 squashfs-root
[17:58] <jdstrand> that passes here
[17:58] <jdstrand> roadmr: what are you looking at? ^
[17:59] <jdstrand> roadmr: it should be fixed in r1132
[18:28] <jdstrand> roadmr: I commented in the bug
[18:31] <cachio> niemeyer, the reboot issue on spread I mentioned today is happening on some systems when the reboot command is executed
[18:32] <cachio> niemeyer, it is happening that the ssh hangs and then it finishes when the warn timeout hist
[18:32] <cachio> hits
[18:32] <cachio> I see this can be reproduced on systems which are rebooting so fast
[18:33] <cachio> i-e- debian 9 is rebotting in about 8 seconds
[18:33] <cachio> or less
[18:33] <cachio> I could fix it by running reboot on background
[18:33] <cachio> niemeyer, I'll create a PR with this
[18:46] <cachio> niemeyer, https://github.com/snapcore/spread/pull/70
[18:46] <mup> PR spread#70: Reboot on backgraound to avoid spread wait for long time <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70>
[19:14] <zyga> jdstrand: offtopic: https://github.com/snapcore/snapd/pull/5644#discussion_r228444370
[19:14] <roadmr> jdstrand: I'll check your comment now. Yes, I recall that was supposed to be fixed :/ and the store is on >1132 anyway... checking
[19:14] <mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
[19:14] <zyga> jdstrand: I wrote some POC code for that
[19:15] <zyga> jdstrand: where snapd is a trust store itself that apps could query
[19:25] <jdstrand> zyga: I responded. I think that is interesting and possibly something for the future, but the patches already exist and are working their way in via SRU for pulseaudio (but see comment)
[19:26] <jdstrand> roadmr: if you have a specific snap where it is failing, I'm happy to look at it. I was going by a snap zyga wormholed me a while ago that had a 555 /, but maybe you have a different snap that causes trouble
[19:27] <roadmr> jdstrand: it's the same snap from zyga :/ I did have to unpack it and tweak it a bit so I could upload it to the store myself
[19:27] <roadmr> changed the name and type mainly
[19:29] <jdstrand> roadmr: $ sha256sum ./fedora29.2018.10.09.x86_64.snap
[19:29] <jdstrand> 15169bf33d889746a31828213ecf1adcd442ba82b13ad30d5b7c68eb164faf47  ./fedora29.2018.10.09.x86_64.snap
[19:30] <roadmr> jdstrand: yep, that's the one I based mine on
[19:30] <jdstrand> roadmr: it is working find here both as the review-tools snap and out of my bzr checkout of crt
[19:30] <jdstrand> fine*
[19:31] <jdstrand> roadmr: is it something in the store and not the review tools that is having trouble?
[19:32] <jdstrand> roadmr: can you give me your snap?
[19:32] <roadmr> jdstrand: sure! wormhole?
[19:32] <jdstrand> that's fine
[19:32] <roadmr> jdstrand: also, what's barfing is the review-tools themselves, but I notice this is when doing unpack-package. Is that what you're testing?
[19:33] <jdstrand> roadmr: I am simply running click-review/snap-review
[19:33] <jdstrand> roadmr: let me try unpack-package
[19:34] <jdstrand> roadmr: worked fine
[19:34] <roadmr> interesting!
[19:34] <jdstrand> $ PYTHONPATH=./ ./bin/unpack-package ~/Desktop/fedora29.2018.10.09.x86_64.snap /tmp/foo
[19:34] <jdstrand> Successfully unpacked to '/tmp/foo'
[19:34] <jdstrand> roadmr: is something wrong with your checkout?
[19:35] <roadmr> hm I don't think so :)
[19:38] <jdstrand> roadmr: $ PYTHONPATH=./ ./bin/unpack-package ~/Desktop/evil-roadmr-fedora-2018.11.05.01_amd64.snap /tmp/bar
[19:38] <jdstrand> Successfully unpacked to '/tmp/bar'
[19:38] <roadmr> jdstrand: ACTUALLY - I can try it on the very same store unit that had the error
[19:38]  * roadmr does so
[19:39] <jdstrand> roadmr: $ PYTHONPATH=./ ./bin/click-review ~/Desktop/evil-roadmr-fedora-2018.11.05.01_amd64.snap
[19:39] <jdstrand> Errors
[19:39] <jdstrand> ------
[19:39] <jdstrand>  - lint-snap-v2:external_symlinks
[19:39] <jdstrand> 	package contains external symlinks: usr/lib64/libnssckbi.so, usr/lib64/p11-kit-trust.so
[19:39] <jdstrand> /home/jamie/Desktop/evil-roadmr-fedora-2018.11.05.01_amd64.snap: FAIL
[19:39] <jdstrand> roadmr: it not tracing back here
[19:39] <jdstrand> it's*
[19:40] <roadmr> interesting... yes, if it were able to upload and then run the checks, I'd see something different
[19:40] <jdstrand> roadmr: maybe smething somewhere has an old crt?
[19:41] <jdstrand> roadmr: I need to step into a meeting but will watch backscroll
[19:41] <roadmr> jdstrand: sure! I'll triple-check everything. It's unlikely it's outdated but I'll leave no stone unturned
[19:58] <roadmr> BEHOOLD!
[19:59] <roadmr> jdstrand: instead of PYTHONPATH=./ ./bin/unpack-package ~/Desktop/evil-roadmr-fedora-2018.11.05.01_amd64.snap /tmp/bar try this
[19:59] <roadmr> jdstrand: 1- mkdir /tmp/baz
[19:59] <roadmr> 2- PYTHONPATH=./ ./bin/unpack-package ~/Desktop/evil-roadmr-fedora-2018.11.05.01_amd64.snap /tmp/baz/quux
[19:59] <roadmr> that will repro the crash. No rush, finish your meeting, I'll keep poking and maybe file a bug with a minimal reproducer snap
[20:05] <robert_ancell> cprov, did you expect /v2/find?section=gamesq=mmapper to return info on the mmapper snap (it doesn't)
[20:12] <robert_ancell> cprov, whoops, was missing the '&'. It does show.
[20:14] <cprov> robert_ancell: it does, right ?
[20:14] <robert_ancell> cprov, yes, it was my mistake.
[20:14] <cprov> robert_ancell: np
[20:17] <jdstrand> roadmr: ok, I can reproduce that
[20:18] <roadmr> jdstrand: the key is the extra directory level; this is what the store does, it creates a NamedTemporaryDir in /tmp to hold each snap and then e.g. says $THE_TEMP_DIR/unpacked for the unpack operation and so on. So that extra level is what's making things funky
[20:26] <roadmr> jdstrand: https://bugs.launchpad.net/click-reviewers-tools/+bug/1801788  with mini-snap exposing the problem
[20:26] <mup> Bug #1801788: Unpacking a snap with mode-555 top-level squashfs-root in a subdirectory of a subdirectory of /tmp fails <Canonical Click Reviewers tools:New> <https://launchpad.net/bugs/1801788>
[20:36] <zyga> roadmr, jdstrand: woot, nice!
[21:11] <jdstrand> roadmr: can you pull r1152 of the review-tools? it has a fix for ^
[21:12] <roadmr> jdstrand: thanks for the quick fix! sure thing
[21:14] <jdstrand> roadmr: np. thanks for the reproducer