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