[05:23] <mborzecki> morning
[05:32] <mborzecki> new kernel, brb
[05:35] <mborzecki> re
[06:09] <zyga> Hey hey
[06:22] <zyga> mborzecki: yesterday was very productive
[06:22] <zyga> I will have nice stuff to share today.
[06:22] <mborzecki> zyga: hey
[06:22] <zyga> I want to add some polish and shine still
[06:22] <zyga> And maybe setup primitive ci
[06:23] <zyga> Now taking a small detour to get kids to school on time
[06:50] <mup> PR snapd#6896 closed: cmd/snap: tweak the output of snap debug timings --ensure= <Simple 😃> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6896>
[07:03] <pstolowski> morning
[07:03] <zyga> hey pawel
[07:06] <mborzecki> pstolowski: hey
[07:09] <zyga> quick breakfast
[07:18] <zyga> pok
[07:18] <zyga> breakfast over, time to get stuff done :)
[07:21] <zyga> anyone wants to look at https://github.com/snapcore/snapd/pull/6891
[07:21] <mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
[07:23] <zyga> mborzecki: or perhaps 2nd review on https://github.com/snapcore/snapd/pull/6909
[07:23] <mup> PR #6909: spread.yaml,tests: change MATCH and REBOOT to cmds <Created by zyga> <https://github.com/snapcore/snapd/pull/6909>
[07:30] <mborzecki> zyga: 'll add it to my queue, looking at #6900 now
[07:30] <mup> PR #6900: [RFC] snapstate: support base = "none" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6900>
[07:30] <zyga> thank you!
[07:50] <pstolowski> thanks mborzecki!
[07:56] <mborzecki> pstolowski: if we go down the route of snap.Validate() in 6900 then the check_snap piece can probably be dropped
[07:57] <mborzecki> btw. do we validate that base: <foo> looks like a valid snap name?
[08:00] <pstolowski> let me check
[08:04] <mborzecki> mvo: pedronis: hey
[08:06] <pstolowski> mborzecki: heh, it seems we don't. not super critical afaict since we will simply fail on prerequsites, but i'll address it (in a separate PR as it's not strictly related to base:none PR)
[08:15] <mborzecki> pstolowski: sgtm
[08:19] <mup> PR snapd#6882 closed: cmd: add snap-verify stub binary (UC20) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6882>
[08:26] <zyga> mvo: do you know how to get in touch with the canonical web team?
[08:36] <pedronis> pstolowski: mborzecki: hi, I think we might even have a card about missing some sanity checks on base itself
[08:38] <pedronis> pstolowski: we have this  (not about the name) but could fir in that new PR: https://trello.com/c/KNa3zFfQ/146-check-early-that-declared-bases-have-actually-type-base
[08:39] <pstolowski> pedronis: ack
[08:41] <pedronis> pstolowski: I assigned it to you and move the base none card to doning
[08:41] <pedronis> *moved
[08:41] <pstolowski> pedronis: ok, thanks
[09:07] <zyga> snap download hangs for me, hmm
[09:09] <zyga> error: received an unexpected http response code (503) when trying to download https://fastly.cdn.snapcraft.io/download-origin/fastly/pYVQrBcKmBa0mZ4CCN7ExT6jH8rY1hza_216.snap?token=1559048400_9a35b33e1aa3a9d811a4ee1c835fbdf663e027ed
[09:09] <zyga> anyone seeing store woes?
[09:09] <mborzecki> well, at least it's not 418 :)
[09:10] <mborzecki> zyga: status.snapcraft.io seems fine
[09:10] <zyga> odd, trying again
[09:10] <zyga> well, this is fastly
[09:10] <mborzecki> maybe something about fastly
[09:10] <zyga> yeah
[09:12] <zyga> fluke, it's working now
[09:14] <Eighth_Doctor> zyga, mborzecki: so Flock 2019 CfP deadline is June 1
[09:14] <mborzecki> Eighth_Doctor: you're reminding me of my univestity days :P
[09:15] <Eighth_Doctor> do we have something we want to do for Flock?
[09:15] <Eighth_Doctor> we've done quite a fair bit since last year... :)
[09:16] <Eighth_Doctor> between the SELinux stuff and the prep work we did for bases...
[09:16] <mborzecki> idk, selinux doesn't feel like much, zyga do you have anything?
[09:16] <zyga> mborzecki: I think selinux is the thing, it'd be a nice way to meet people that know a lot about it
[09:16] <zyga> I think you should go :)
[09:17] <zyga> where is flock this year?
[09:17] <zyga> mvo: do you know how to get in touch with the canonical web team?
[09:17] <Eighth_Doctor> Budapest
[09:17] <zyga> mborzecki: talk to mvo
[09:17] <zyga> I think you should go
[09:20] <Eighth_Doctor> zyga, mborzecki: do either of you think we could do something about getting fedora-based snaps something people could make by flock?
[09:20] <Eighth_Doctor> if we could get there, we could also propose a workshop for making fedora-based snaps
[09:24] <pedronis> mborzecki: #6750 has a conflict btw
[09:25] <mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
[09:25] <mborzecki> wow, again? hmm
[09:28] <zyga> Eighth_Doctor: I think that's unlikely, we're prepping a demo for something and even regular work is lower priority
[09:35] <mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705,
[09:35] <mup> snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6825, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871, snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899,
[09:35] <mup> snapd#6900, snapd#6904, snapd#6905, snapd#6909, snapd#6913, snapd#6917, snapd#6919
[09:35] <mvo> zyga: the web team? yeah, I can get you in touch with people, let me look, one sec
[09:35] <zyga> thank!
[09:36] <mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705,
[09:36] <mup> snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6825, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871, snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899,
[09:36] <mup> snapd#6900, snapd#6904, snapd#6905, snapd#6909, snapd#6913, snapd#6917, snapd#6919
[09:36] <mborzecki> pedronis: ok #6750 and #6836 updated
[09:36] <mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
[09:36] <mup> PR #6836: overlord/snapstate: add update-gadget task when needed, block other changes <Gadget update> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6836>
[09:41] <pstolowski> pedronis: fyi, i figured out my issues with base decl and policy checks wrt to the WIP branch removing sanitizeReservedForOS/Gadget/... helpers
[09:42] <pstolowski> pedronis: it all boiled down to the default "allow-installation: false" in base decl taking affect in my minimal install check
[09:58] <mup> PR snapd#6904 closed: timings: always store ensure timings as long as they have an associated change <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6904>
[09:59] <mvo> 6804 needs a second review
[10:05] <Chipaca> pedronis: you got a minute?
[10:17] <mup> PR snapd#6920 opened: timings: tweak the conditional for ensure timings <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6920>
[10:17] <pstolowski> doh, that was wrong branch
[10:18] <mup> PR snapd#6920 closed: timings: tweak the conditional for ensure timings <Simple 😃> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/6920>
[10:22] <mup> PR snapd#6921 opened: timings: tweak the conditional for ensure timings <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6921>
[10:24] <Saviq> zyga: hey, what's the status of "base: core16 → core18" migration these days? we're getting more and more headaches being stuck at core16 still…
[10:25] <Saviq> like, how likely is it that things will break?
[10:30] <zyga> Saviq: no change, deprioritized
[10:30] <zyga> some bugs fixed, some remain
[10:30] <zyga> Saviq: online updates still not supported
[10:38] <mup> PR snapcraft#2571 opened: cli: refactor re-execution into legacy <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2571>
[10:59] <zyga> small break
[11:00] <Chipaca> pedronis: request for a minute cancelled
[11:00] <mup> PR snapd#6917 closed: Add endpoint for snap download in the daemon <Created by glower> <Closed by glower> <https://github.com/snapcore/snapd/pull/6917>
[11:04] <mup> PR snapd#6922 opened: gadget: mounted filesystem writer <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6922>
[11:05] <mborzecki> zyga: split out the writer part ^^
[11:16] <mup> PR snapd#6923 opened: interfaces/policy: minimal policy check for replacing sanitizeReservedFor... helpers (1/2) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6923>
[11:22]  * pstolowski lunch
[11:23] <mup> PR snapd#6921 closed: timings: tweak the conditional for ensure timings <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6921>
[11:24] <zyga> mborzecki: ack
[11:38] <zyga> mborzecki: can you please document things like Deploy and DeployContent
[11:44] <zyga> mborzecki: reviewed
[11:45] <mborzecki> zyga: thanks, pushing the comments in a minute
[11:47] <mborzecki> zyga: the 3rd point is actually something that is done by the updater with the anlysis/rollback-preparation pass
[11:47] <zyga> hmm, but the code has hard-coded sync flag?
[11:47] <zyga> did I misunderstand that?
[11:48] <mborzecki> zyga: no, the updater actually directly calls deploy{File,Directory} when needed
[11:52] <zyga> hmm, that wasn't my point
[11:52] <zyga> if you deploy a tree with 3 files
[11:52] <zyga> you sync on each one
[11:52] <zyga> in practice that is expensive
[11:52] <zyga> you could deploy all three and then sync once
[11:52] <zyga> (even with old-fashioned sync as sync APIs are a bit limited)
[12:03] <mborzecki> off to pick up the kids
[12:21] <zyga> hmmm
[12:23] <zyga> cmatsuoka: ping
[12:23] <cmatsuoka> zyga: o/
[12:24] <zyga> question, one sec
[12:25] <zyga> ok
[12:25] <zyga> so
[12:25] <zyga> the pc-kernel snap
[12:25] <zyga> in the 18 track
[12:25] <zyga> if you unsquash that
[12:25] <zyga> there's an initrd.img file
[12:25] <zyga> it's 3MB more or less
[12:26] <zyga> and contains a simple initrd with a bunch of stuff
[12:26] <zyga> not sure why but I cannot seem to unpack it correclty
[12:26] <diddledan> who's in charge of the forum? https://forum.snapcraft.io/t/code-block-syntax-highlighting-no-longer-works/11004/4
[12:26] <zyga> if I do it only contains intel microcode, at 32KB
[12:26] <zyga> diddledan: don't know, perhaps mvo_ does
[12:26] <cmatsuoka> are you using unmkinitramfs?
[12:27] <zyga> cmatsuoka: no, I was using cpio directly
[12:27] <cmatsuoka> zyga: try with unmkinitramfs, it's easier than using binwalk and cpio
[12:27] <zyga> there's no such binary on opensuse
[12:27] <zyga> but do you know what's going on
[12:28] <zyga> is this the appended cpio with some malformed stuff that causes this?
[12:28] <zyga> if you cpio --list it will show you that the initrd contains the microcode
[12:28] <zyga> what does unmkinitramfs do?
[12:29] <cmatsuoka> so the initramfs can have multiple sections, the microcode is in the first one. if you run binwalk on the initramfs file you'll see the different sections
[12:29] <cmatsuoka> but binwalk can get confused sometimes and list something that doesn't exist
[12:30] <cmatsuoka> unmkinitramfs does the right thing and reads all sections
[12:30] <zyga> I see now, that's odd
[12:30] <zyga> thanks!
[12:31] <cmatsuoka> I don't know the exact unmkinitramfs mechanism, but it works better than doing it by hand
[12:31] <zyga> I was working with a custom initrd but I wanted to play with something derived from the original
[12:32] <zyga> googling suggests that our official initrd has the wrong alignment
[12:32] <cmatsuoka> it's a short script, perhaps you can replicate or just run it on suse as well?
[12:32] <zyga> yeah, now I'm good
[12:35] <cmatsuoka> the mechanism is: split all parts based on magic, uncompress/unarchive each part
[12:36] <cmatsuoka> magic bytes, not real magic
[12:44] <Eighth_Doctor> cmatsuoka: unmkinitramfs is a initramfs-tools specific tool
[12:47] <Eighth_Doctor> for dracut based initramfs, you need to use skipcpio and then extract the compressed payload with the appropriate tool
[12:49] <Eighth_Doctor> like so: https://www.thegeekdiary.com/centos-rhel-7-how-to-extract-initramfs-image-and-editview-it/
[12:49] <Eighth_Doctor> or this: https://doc.rogerwhittaker.org.uk/extract-dracut-initrd/
[12:50] <Eighth_Doctor> zyga: manipulating dracut-based initramfs is typically done by adjusting dracut configuration or passing in commandline options: https://www.mankier.com/8/dracut
[12:51] <zyga> Eighth_Doctor: I don't want to use dracut,
[12:51] <zyga> it's really not anything close to useful now
[12:51] <zyga> (as in dracut)
[12:57] <cmatsuoka> Eighth_Doctor: ah interesting. But is the actual file format different? I mean, if you split parts and uncompress/unarchive each of them on a dracut-built initramfs, shouldn't it work as well?
[12:58] <Eighth_Doctor> cmatsuoka: I don't know, maybe?
[12:58] <Eighth_Doctor> it'd be nice if someone had contributed those tools into dracut though
[12:58] <cmatsuoka> my guess is that the final format is the same, but I didn't actually check it
[13:05] <Eighth_Doctor> cmatsuoka: you can try this by generating a dracut-based initramfs on Ubuntu and seeing if the tool works
[13:11]  * Chipaca adds a /v2/irc so people can chat with us from snapd
[13:54]  * cachio afk
[14:00] <mborzecki> heh -ldflags "-linkmode external -extldflags '-static'" does what we need
[14:01] <Chipaca> mborzecki: --dammit
[14:01] <Chipaca> --static-or-die
[14:02] <mborzecki> hahah
[14:02] <mborzecki> otherwise it's guesswork whether to CGO_ENABLED or not
[14:03] <mborzecki> oh and -buildmode=pie triggers external linker
[14:22] <mup> PR snapd#6924 opened: packaging/fedora: force external linker to ensure static linking and -extldflags use <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6924>
[14:23] <mborzecki> that should do it ^^
[14:24] <mup> PR snapcraft#2567 closed: remote build: add warning before sending data <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2567>
[15:01] <zyga> dinner
[15:06] <diddledan> that sounds like a plan, zyga ! :-)
[15:22] <webmind> hi, I've got a nextcloud service installed via snap, but it should only run after an encrypted partition has been unlocked and mounted
[15:22] <webmind> how do I prevent the service to be run on boot?
[16:00] <zyga> cmatsuoka, mvo_, pedronis: go works in initrd now
[16:00] <zyga> I'll continue more tomorrow
[16:42] <webmind> is there a neat way to run a nextcloud snap on an encrypted storage?
[16:46] <mup> PR snapcraft#2572 opened: catkin spread tests: stop testing indigo <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2572>
[16:51] <mup> PR snapd#6825 closed: cmd: rework `snap run --gdb` to work as user <⛔ Blocked> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6825>
[17:25] <mup> PR snapcraft#2573 opened: catkin spread tests: stop testing indigo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2573>
[17:25] <mup> PR snapcraft#2574 opened: remote build: retrieve build log files <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2574>
[17:41] <pedronis> reviews of #6855 would be appreciated
[17:41] <mup> PR #6855: overlord: implement store switch remodeling  <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6855>
[17:53] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
[17:54] <mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
[18:12] <wmww_> sergiusens: It appears Snapcraft is stripping my build-ids, which is causing mesa to break (only when the snap is built with new versions of Snapcraft). Full details of the problem here: https://github.com/MirServer/egmde-snap/pull/3, It seems to have been fixed by add no-patchelf, but it was quite difficult to diagnose. I'm wondering if this should be reported as a bug in Snapcraft.
[18:12] <mup> PR MirServer/egmde-snap#3: Resolve i965_dri.so crash by not stripping mesa build IDs <Created by wmww> <https://github.com/MirServer/egmde-snap/pull/3>
[18:19] <mup> PR snapcraft#2575 opened: catkin spread tests: use kinetic instead of indigo <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2575>
[18:39] <mup> PR snapd#6541 closed: tests: change how xdg-desktop-portal is prepared and restored for desktop-portal-* tests <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
[19:07] <mup> PR snapcraft#2572 closed: [legacy] catkin spread tests: stop testing indigo <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2572>
[19:07] <mup> PR snapcraft#2573 closed: catkin spread tests: restrict tests to Ubuntu 16.04 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2573>
[19:17] <jdstrand_> sergiusens[m], kyrofa: hey, I converted an older snap (the review-tools) to use 'base: core' and I'm finding that PYTHONPATH is not set like it was when I didn't specify a base. am I expected to set the PYTHONPATH myself?
[19:19] <sergiusens> jdstrand_: no, it is all inferred from the path to python inside the snap
[19:19] <sergiusens> jdstrand: I think we got rid of that even before moving to bases
[19:19] <jdstrand> sergiusens: I have: #!/usr/bin/env python3
[19:19] <jdstrand> sergiusens: should that be something else?
[19:19] <sergiusens> jdstrand: that is fine, this is not classic, right?
[19:19] <mup> PR snapcraft#2576 opened: [legacy] catkin plugin: remove default rosdistro <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2576>
[19:20] <jdstrand> sergiusens: strivt
[19:20] <jdstrand> strict
[19:20] <jdstrand> sergiusens: well, that may be 'fine' but have to do something like:
[19:20] <jdstrand> snap run --shell review-tools.snap-review
[19:21] <jdstrand> $ PYTHONPATH=$SNAP/lib/python3.5/site-packages/:$SNAP/usr/lib/python3/dist-packages/ snap/command-chain/snapcraft-runner $SNAP/command-snap-review.wrapper ...
[19:22] <sergiusens> jdstrand: can I see your snapcraft.yaml, you shouldn't need that python path, look at "black" in the store as a reference for something using bases
[19:23] <jdstrand> sergiusens: https://paste.ubuntu.com/p/Z9g4sFX46b/
[19:23] <jdstrand> sergiusens: maybe because PATH doesn't find python3 in the snap?
[19:23] <jdstrand> from snap run: $ which python3
[19:23] <jdstrand> /usr/bin/python3
[19:24] <sergiusens> jdstrand: the environment is still set through the command wrapper
[19:25] <sergiusens> jdstrand: so use of --shell will still have its quirks
[19:25] <jdstrand> snap/command-chain/snapcraft-runner which python3 gives me /snap/review-tools/x1/usr/bin/python3
[19:25] <jdstrand> sergiusens: sure. ok, so that isn't it
[19:26] <sergiusens> jdstrand: so what is the error if you do not set PYTHONPATH? IIRC, we have not set PYTHONPATH for the past 2 years
[19:26] <jdstrand> $ review-tools.snap-review
[19:26] <jdstrand> Traceback (most recent call last):
[19:26] <jdstrand>   File "/snap/review-tools/x1/bin/snap-review", line 3, in <module>
[19:26] <jdstrand>     from reviewtools import modules
[19:26] <jdstrand> ImportError: No module named 'reviewtools'
[19:27] <sergiusens> jdstrand: whats the shebang in /snap/review-tools/x1/bin/snap-review ?
[19:27] <jdstrand> $ head /snap/review-tools/x1/bin/snap-review
[19:27] <jdstrand> #!/usr/bin/env python3
[19:27] <sergiusens> jdstrand: can you wormhole me the resulting snap?
[19:28] <sergiusens> thanks
[19:28] <jdstrand> sergiusens: sent via privmsg
[19:29] <sergiusens> meeting starting in 1', but will look right after
[19:29] <jdstrand> sergiusens: so, fyi, I'm clenning up a lot with this, but review-tools.swift I didn't touch and it has the same problem (it is py2)
[19:30] <jdstrand> sergiusens: I don't think it has anything to do with the internal renaming though since if I set PYTHONPATH, it works
[20:13] <jdstrand> sergiusens: fyi, I pushed all my updates to: https://git.launchpad.net/review-tools?h=master, including PYTHONPATH, which I'm happy to update if you find anything. note, I searched the forum for PYTHONPATH and there are quite a few people using. I don't know if that is related
[20:24] <jdstrand> roadmr: hey, can you pull 20190528-2014UTC? note, this is the big cleanup with internal renamings, etc. besides that there is one change to overrides.py
[20:25] <roadmr> jdstrand: sure
[20:25] <jdstrand> roadmr: please note that for the store, I preserved bin/click-review (it is a symlink to bin/snap-review now) and data/snapd-base-declaration.yaml, which is a symlink to reviewtools/data/snapd-base-declaration.yaml
[20:26] <jdstrand> (I think snapstore may be using that 2nd one for the brand store decls)
[20:32] <sergiusens> jdstrand: you wiped `$SNAP/usr/lib/python3.5` (https://git.launchpad.net/review-tools/tree/snapcraft.yaml#n79)
[20:33] <sergiusens> jdstrand: which takes away our sitecustomize
[20:33] <jdstrand> sergiusens: ah, ok. that probably wasn't wiped before because I combined two parts
[20:34] <jdstrand> sergiusens: and I was removing clashing bits
[20:34]  * jdstrand updates
[20:35] <jdstrand> oh, swiftclient is py3 (it is swift itself that is py2)
[20:35] <jdstrand> ok, this makes sense
[20:36] <jdstrand> sergiusens: also, is your black snapcraft.yaml anywhere?
[20:37] <jdstrand> sergiusens: and thanks for looking at this! :)
[20:38] <sergiusens> jdstrand: let me make it so for the former and no problem for the latter
[20:54] <jdstrand> sergiusens: yep, removing that line fixed it right up. thanks again for your keen eyes :)
[21:17] <roadmr> jdstrand: sorry, was otp - I'll put this in the queue, our tests should catch any big-cleanup trouble
[21:18] <jdstrand> roadmr: sounds good (I also tested this a lot). lemme know if you see anything weird and I'll jump right on it
[21:19] <roadmr> +1
[21:43] <zyga> jdstrand: hey
[21:44] <zyga> jdstrand: that thing from Friday, that was test system setup bug specific to 14.04
[21:44] <zyga> jdstrand: I've put further changes on hold until more people review it
[21:50] <jdstrand> zyga: yes, jjohansen said he'd look at it and I hope to tomorrow as well
[21:51] <jjohansen> zyga: yeah I am looking into it
[21:53] <zyga> thanks!