| mup | PR snapcraft#3129 opened: schema: add support for the daemon-scope property on apps <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/3129> | 03:43 |
|---|---|---|
| davido_ | Does this channel support issues with the snap management tool? | 03:46 |
| davido_ | or is it only developer focused? | 03:46 |
| mup | PR snapcraft#3130 opened: build_providers: don't show an error if there are no auto-refresh changes <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/3130> | 03:58 |
| mborzecki | morning | 06:25 |
| mvo | hey mborzecki | 06:28 |
| mborzecki | mvo: hey, can you take a look at https://github.com/snapcore/snapd/pull/8604 ? | 06:29 |
| mup | PR #8604: interfaces/builtin/desktop: do not mount fonts cache on distros with quirks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8604> | 06:29 |
| mvo | mborzecki: sure | 06:30 |
| mborzecki | mvo: thanks | 06:30 |
| mvo | mborzecki: thanks, done, we should also squash it I think | 06:31 |
| mborzecki | mvo:yeah, easier to cherry pick | 06:31 |
| mvo | +1 | 06:33 |
| zyga | hey | 06:45 |
| mvo | good morning zyga | 06:45 |
| mborzecki | zyga: hey | 06:48 |
| zyga | how was Friday? | 06:48 |
| mborzecki | zyga: that opensuse go thing is weird, looks like there's a parallel install of go1.13 and go1.12, and the packages are conflicgting on who owns /usr/bin/go | 06:49 |
| zyga | yeah | 06:49 |
| zyga | maybe it is some kind of vendor change situation | 06:49 |
| zyga | but I really don't know | 06:49 |
| mborzecki | actually, afaiu both packages ship /usr/bin/go ? | 06:49 |
| zyga | I never experienced this myself | 06:50 |
| zyga | yeah | 06:50 |
| mborzecki | zyga: we also ahve `BuildRequires: go >= 1.9` so go1.13 should be just fine, unless it doesn't provide go? | 06:51 |
| zyga | maybe something else depends | 06:52 |
| zyga | or maybe we just mass-upgrade | 06:52 |
| zyga | I didn't look that deeply | 06:52 |
| mborzecki | maybe it's confused when we ask for go >= 1.9 :/ | 06:53 |
| mborzecki | it's funny, bc we end up with older go than we had :P | 06:53 |
| zyga | mmm, as in doesn't understand that dependency is satisfied? | 06:53 |
| zyga | I think that's unlikely | 06:53 |
| zyga | btw, suse does roll back packages normally | 06:53 |
| zyga | their repo points to the truth | 06:53 |
| zyga | and systems adjust | 06:54 |
| zyga | and it's not unheard of packages going to older releases | 06:54 |
| zyga | maybe that's what going on | 06:54 |
| pstolowski | morning | 07:01 |
| zyga | hey pawel | 07:01 |
| zyga | rainy morning | 07:01 |
| zyga | perfect for Monday | 07:01 |
| mvo | good morning pstolowski | 07:06 |
| pstolowski | zyga: same here | 07:10 |
| mborzecki | pstolowski: hey | 07:29 |
| mborzecki | zyga: heh, zypper insists on installing 1.12, however what provides lists many options https://paste.ubuntu.com/p/P8NbcSGpRR/ | 07:30 |
| pstolowski | mborzecki: your hunch about selinux denials & go doing enumeration of network interfaces was good.. https://paste.ubuntu.com/p/JQQDrTqsg8/ | 07:47 |
| mborzecki | pstolowski: heh, no a question which part of the code does that | 07:47 |
| mborzecki | pstolowski: maybe pulling in net package triggers is | 07:48 |
| pedronis | it's the randutil code | 07:49 |
| mborzecki | omg, i see now, it's listing interfaces | 07:50 |
| pstolowski | ah | 07:51 |
| mborzecki | / mix in net interfacles hw addresses (MACs etc) | 07:51 |
| mborzecki | if ifaces, err := net.Interfaces(); err == nil { | 07:51 |
| pedronis | but it's inderect | 07:51 |
| pedronis | it you neeed to be using RandDuration | 07:51 |
| pedronis | but we have a few places that use RandomDuration at the top level | 07:51 |
| pstolowski | it's only in my PR, apparently indirectly pulled (by configcore?) | 07:52 |
| pedronis | https://github.com/snapcore/snapd/blob/master/randutil/rand.go#L93 | 07:52 |
| pedronis | pstolowski: let me think a second, we had something in mind that we might have forgotten | 07:54 |
| pstolowski | pedronis: for clarity, this is now triggered by snap cli, not snapd | 07:55 |
| pedronis | pstolowski: yes, we have worked toward a way to build configcore without pulling in the mangers | 07:55 |
| pedronis | but we haven't finished the work | 07:55 |
| pedronis | we really don't want the managers in snap | 07:55 |
| pedronis | this is showing that very indirectly | 07:55 |
| mvo | good morning pedronis ! | 07:56 |
| pedronis | pstolowski: we need to finish that work | 07:59 |
| pedronis | and it's going to be a of a pain as we learned from nosecboot | 08:00 |
| mborzecki | zyga: addeda note under https://github.com/snapcore/snapd/pull/8685#issuecomment-630014236 perhaps it's worth checking with go packaging guidelines or in #opensuse about the best solution | 08:01 |
| mup | PR #8685: opensuse: zypper --replacefiles <Created by zyga> <https://github.com/snapcore/snapd/pull/8685> | 08:01 |
| pstolowski | mborzecki: btw i also saw some selinux denials that for some reason were not reported when using --checkpoint ..., only shown with ausearch -i -m AVC. i haven't investigated it and i don't know if it is anyhow related to my branch or also present in master - https://pastebin.ubuntu.com/p/TBRdbCFvkS/ | 08:02 |
| zyga | mborzecki: 1:1 | 08:02 |
| pedronis | pstolowski: am I making sense? | 08:03 |
| pstolowski | pedronis: yes, i remember the general idea/desire we discussed some time ago. don't know what does this entail yet | 08:05 |
| pedronis | pstolowski: mostly usinh build flags, except for some of the distro they don't quite work :/ | 08:05 |
| pstolowski | pedronis: in this particular case, is there a concern of entropy? could we land this early-config PR by temporarily relaxing selinux check in these tests? | 08:06 |
| pedronis | pstolowski: temporarely for how long? we really don't want to pull in the managers in snapd | 08:07 |
| pstolowski | pedronis: i can start working on proper fix today, just don't know how annoying/long will it be and for long early config will be blocked because of this | 08:09 |
| pedronis | pstolowski: to be clear I'm not too concerned about relaxing the selinux rules otoh is completely not the work we need | 08:09 |
| mborzecki | pstolowski: i saw those only in our tests though, i suspect it's because we repack the core snap and try to prevent the new squashfs from picking up default label (home_t) by passing unlabeled_t epxliciltly, however we also expliclity set the context=.. when mounting the squashfs, but that doesn't stop the denials due to unlabeled_t when running hooks to appear, i suspect there may be some race | 08:19 |
| mborzecki | between snapd accessing the contents and desired label set at the fs level | 08:19 |
| mborzecki | pstolowski: iirc if you go an ls -lZ those locations they have snappy_snap_t as expected | 08:20 |
| mup | PR snapd#8676 closed: tests: port interfaces-dbus to session-tool <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8676> | 08:24 |
| pstolowski | mborzecki: ack | 08:28 |
| zyga | re | 08:44 |
| zyga | mborzecki: looking | 08:44 |
| zyga | mborzecki: nice work! | 08:46 |
| zyga | brb, tea and back into the fray :) | 08:47 |
| pedronis | pstolowski: are you blocked atm? | 08:56 |
| pstolowski | pedronis: no | 08:57 |
| zyga | and back | 08:57 |
| pedronis | pstolowski: we can chat after lunch about what to do, I have a meeting now | 08:58 |
| pstolowski | pedronis: ok, thanks | 08:58 |
| mup | PR snapd#8686 opened: o/devicestate: cleanup system actions supported by recover mode <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8686> | 09:17 |
| pedronis | pstolowski: can you setup a meeting before the standup when is convenient for you? | 10:02 |
| pstolowski | pedronis: will do | 10:03 |
| mup | PR snapd#8687 opened: [RFC] overlord: show what manager throws a state ensure error <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8687> | 10:09 |
| mup | PR snapd#8688 opened: [RC] state: log task errors in the journal too <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8688> | 10:19 |
| mup | PR snapd#8689 opened: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689> | 10:46 |
| mup | PR snapd#8690 opened: devicestate: do not report "ErrNoState" for seeded up <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8690> | 10:48 |
| mborzecki | mvo: left a comment under https://github.com/snapcore/snapd/pull/8687#discussion_r426544961 | 11:14 |
| mup | PR #8687: [RFC] overlord: show what manager throws a state ensure error <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8687> | 11:14 |
| mvo | mborzecki: yeah, saw it, looks interessting. I guess we samuele to decide if we should consider this at all but yeah, if we do maybe doing something smarter would be good. | 11:15 |
| pedronis | yes, I think we touch this, it's better to the work, it shouldn' be too hard to something sensible, it will need more than 1 line though | 11:16 |
| mvo | pedronis: shall I close it given that it need to be reworked? | 11:17 |
| mborzecki | btw. devicemgr seems to dtrt, maybe it's enough we add error wrappers for other managers and still log it in stateengine? | 11:18 |
| mborzecki | xerrors would be nice too | 11:18 |
| mup | PR snapd#8688 closed: [RFC] state: log task errors in the journal too <Needs Samuele review> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8688> | 11:19 |
| mborzecki | it captures the frame info so we'd have exact line in the manager | 11:19 |
| mvo | mborzecki: nice | 11:19 |
| mup | PR snapd#8688 opened: [RFC] state: log task errors in the journal too <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8688> | 11:20 |
| pedronis | mborzecki: I'm not sure I want to invest in xerrors atm | 11:20 |
| pedronis | I pressed close by mistake | 11:21 |
| pedronis | mvo: you want to land these things in 2.45 I imagine? | 11:21 |
| mvo | pedronis: yeah, mostly to give us slightly better error reporting. I know it's not ideal but it seems not like a step backwards and we can always improve it | 11:22 |
| mvo | pedronis: I care less about 8687 | 11:22 |
| mvo | pedronis: the other one 8688 is a bit more interessting I feel because I noticed when we ask for logs for install failure we tend to lack information | 11:23 |
| mvo | pedronis: anyway, up to you - I totally understand if you prefer something better that is less "ad-hoc" | 11:23 |
| pedronis | mvo: I have a old PR to address that, doing the right thing is quite a bit of work | 11:23 |
| pedronis | though, it's probably time to do it, but not 2.45 | 11:24 |
| * mvo nods | 11:25 | |
| mvo | pedronis: for which one do you have a PR? or for the stateengine errors one? | 11:25 |
| mvo | s/or// | 11:25 |
| pedronis | for logging task errors | 11:25 |
| pedronis | it's a PR from 2016 to give you a sense of things | 11:26 |
| mborzecki | 8688 would be nice, it was super annoying debugging why install failed when running with too small image, there was no other way but to use the debug shell, not sure if even https://github.com/CanonicalLtd/subiquity/pull/771 will be enough | 11:26 |
| mup | PR CanonicalLtd/subiquity#771: console-conf-wrapper: show snapd log during install <Created by mvo5> <https://github.com/CanonicalLtd/subiquity/pull/771> | 11:26 |
| mvo | pedronis: woah :) ok | 11:26 |
| mvo | mborzecki: 771 will be enough but I still think it would be nice to have task error in our log but again, I will not fight over this | 11:27 |
| pedronis | mvo: to be clear, I'm not against the logging, the biggest issue is what to log | 11:28 |
| pedronis | summaries are long, task numbers are not informative | 11:28 |
| pedronis | I'm not sure all summaries are complete enough | 11:29 |
| pedronis | the latter is less of an issue | 11:29 |
| mvo | pedronis: right - I was thinking about this too and it seemed like the summary is usually ok but yeah, it's not ideal in all cases. | 11:30 |
| mborzecki | mvo: i see xnox raised the same issue, i think there's a problem when snap watch/change is called to early | 11:30 |
| mvo | pedronis, mborzecki fwiw, I created an image too small to install and tested all my changes against that to see if my changes improve the error/log output | 11:30 |
| mvo | mborzecki: yes, I need to look, it did not happen in my testing but I was probably lucky | 11:31 |
| mvo | mborzecki: for me it was the other way around actually, usually install-system was already done in the error case by the time this code was reached, but again, I think there is no gurantee :/ | 11:31 |
| mvo | mborzecki: I need to think | 11:31 |
| mvo | pedronis: I think you raise an important point, *if* we log the task error we probably need the id there too for cross reference at least. my pr is not doing this right now | 11:32 |
| * mvo shuts up for a couple of minutes to give others the chance to talk too :) | 11:34 | |
| pedronis | mvo: we don't display task numbers though usually | 11:35 |
| * mvo nods | 11:35 | |
| mup | PR snapd#8680 closed: tests: port interfaces-autopilot-introspection to session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8680> | 11:36 |
| zyga | brb | 11:42 |
| mup | PR snapd#8684 closed: tests: add a note about broken test sequence <Skip spread> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8684> | 12:05 |
| mborzecki | mvo: in the context of https://bugs.launchpad.net/snapd/+bug/1878943 it'd be nice if we made use of the timinigs we have in the install-system handler | 12:09 |
| mup | Bug #1878943: armhf core20 image unusable on rpi2, rpi3 <uc20> <snapd:New> <https://launchpad.net/bugs/1878943> | 12:09 |
| mborzecki | mvo: there's still a question how to show the timings before reboot | 12:09 |
| pedronis | mvo: I made a proposal | 12:14 |
| pedronis | in #8688 | 12:15 |
| mup | PR #8688: [RFC] state: log task errors in the journal too <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8688> | 12:15 |
| pstolowski | pedronis: i'm in the HO | 12:24 |
| mborzecki | mvo: do you think we could cherry pick https://github.com/snapcore/snapd/pull/8580 to 2.45.1? | 12:51 |
| mup | PR #8580: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8580> | 12:52 |
| mborzecki | i'll distro patch it in arch and fedora for now | 12:52 |
| mborzecki | mvo: i can open a PR with relevant patches for 2.45 branch | 12:52 |
| mup | PR snapd#8691 opened: tests/lib/bin: a TODO to improve the naming and uniformatiy of utilities <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691> | 12:57 |
| mvo | mborzecki: yeah, let's cherry-pick the zsh | 12:58 |
| mvo | mborzecki: let me look | 12:58 |
| mup | PR snapcraft#3130 closed: build providers: don't show an error if there are no auto-refresh changes <bug> <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3130> | 13:11 |
| mup | PR snapcraft#2843 closed: snap: only ship .pyc files, strip shared objects <Created by om26er> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2843> | 13:32 |
| mup | PR snapd#8690 closed: devicestate: do not report "ErrNoState" for seeded up <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8690> | 13:40 |
| mborzecki | hmm i cannot open files via xdg-desktop-portal anymore in 2.45 | 13:41 |
| mborzecki | maj 18 15:40:27 galeon xdg-desktop-por[466975]: g_desktop_app_info_get_string: assertion 'G_IS_DESKTOP_APP_INFO (info)' failed | 13:41 |
| mborzecki | maj 18 15:40:27 galeon xdg-desktop-por[466975]: g_app_info_launch_uris: assertion 'G_IS_APP_INFO (appinfo)' failed | 13:41 |
| ijohnson | oh no | 13:41 |
| mborzecki | (on arch) | 13:41 |
| mborzecki | pff, zip/pdf/directories open fine though | 13:42 |
| mborzecki | graphical files do not | 13:42 |
| mborzecki | they do open outside of snap tho | 13:43 |
| * zyga -> lunch | 13:52 | |
| cachio | zyga, we need google-compute-engine availlable for fedora-32 https://paste.ubuntu.com/p/V58T6xCv3v/ | 14:36 |
| zyga | cachio: where is that package coming from? | 14:37 |
| cachio | Pharaoh_Atem, hey, you are the owner of the google-compute-engine package in fedora right? | 14:37 |
| zyga | that's a copr repo | 14:37 |
| zyga | perhaps we don't need it? | 14:37 |
| cachio | zyga, I think Neal owners it | 14:38 |
| zyga | cachio: no, he owns the copr we use to get it from | 14:38 |
| zyga | cachio: perhaps we don't need the copr at all? | 14:38 |
| zyga | cachio: or perhaps the package in general | 14:38 |
| cachio | zyga, ah, ok, I'll try | 14:38 |
| zyga | cachio: does the stock f32 cloud image have this package installed? | 14:38 |
| cachio | zyga, let me check | 14:39 |
| cachio | zyga, seems to be installed | 14:43 |
| zyga | great, then we don't need anything, just use that | 14:43 |
| zyga | (no need for copr) | 14:43 |
| cachio | zyga, yes, now creating the image again | 14:46 |
| zyga | sounds good | 14:46 |
| pedronis | mborzecki: in your chain of PRs when did you plan to create systems.go ? | 15:01 |
| mborzecki | pedronis: it's in this one: https://github.com/snapcore/snapd/pull/8689 | 15:01 |
| mup | PR #8689: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689> | 15:01 |
| pedronis | mborzecki: ok, thx | 15:02 |
| MattJ | Curious if there is a reason /snap/bin is added in profile.d only, and therefore isn't added to non-interactive sessions? | 15:04 |
| MattJ | e.g. snap install aws on server, then `ssh user@server aws` fails with 'command not found' | 15:04 |
| pedronis | mborzecki: I reviewed #8672 and #8686 | 15:26 |
| mup | PR #8672: o/devicestate: change how current system is reported for different modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8672> | 15:27 |
| mup | PR #8686: o/devicestate: cleanup system actions supported by recover mode <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8686> | 15:27 |
| mup | PR snapd#8692 opened: configcore: add nomanagers buildtag for conditional build <Created by stolowski> <https://github.com/snapcore/snapd/pull/8692> | 15:30 |
| pstolowski | pedronis: ^ this seems to be sufficient. i can do ConfGetter change separately, didn't do it in this PR as it would create noise in the diff | 15:31 |
| pedronis | pstolowski: as I said it matters less | 15:31 |
| pedronis | pstolowski: I will look at it in a bit | 15:31 |
| mup | PR snapcraft#3131 opened: plugin handler: debug build commands if developer debug enabled <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3131> | 15:38 |
| mborzecki | pedronis: thanks! | 15:49 |
| pedronis | ijohnson: thanks for setting up a meeting | 15:49 |
| ijohnson | pedronis: sure let me know if there's anything I can do to help or if we should try and pull in somebody from cloud-init | 15:49 |
| pedronis | ijohnson: don't think so, I'll try to prepare a bit in my morning | 15:51 |
| ijohnson | ack | 15:51 |
| * cachio lunch | 15:52 | |
| pedronis | ijohnson: I did a pass on #8683 | 16:18 |
| mup | PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683> | 16:18 |
| ijohnson | thank you looking now | 16:19 |
| zyga | cachio: hey, can you please update the tw image | 17:02 |
| zyga | cachio: a "zypper dup" is enough to resolve our issue | 17:02 |
| zyga | cachio: I could bake it into the prepare section but I think this is just better | 17:03 |
| mup | PR snapd#8685 closed: opensuse: zypper --replacefiles <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8685> | 17:05 |
| * zyga EODs | 17:07 | |
| ijohnson | pedronis: hmm while looking for documentation on the format of DM_UUID and/or the dm/uuid sysfs value it seems that we may have a slight problem | 17:07 |
| ijohnson | according to some of the back and forth on https://bugzilla.redhat.com/show_bug.cgi?id=1322110, the DM_UUID is meant to be an implementation detail and ought not to be parsed because it could be broken at any time | 17:07 |
| ijohnson | now that may be true generally, but I'm wondering if we can rely on it for now because 1) we are in control of the thing creating the volume (snap-bootstrap calling systemd-cryptsetup) , 2) the thing creating the volume is from other software version we kinda control, in that systemd version 245/luks/cryptsetup seems unlikely to bump and change significantly over the lifetime of the core20 snap | 17:09 |
| ijohnson | 3) the version of systemd in the initramfs should always match what's in the core20 snap I think(?) | 17:10 |
| cachio | zyga, sure, I am finishing fedora 32 | 17:10 |
| ijohnson | so all the things poking / creating this device mapper volume (which is where the DM_UUID value comes from) should be stable over the lifetime of uc20/core20 I think | 17:10 |
| ijohnson | if that's not good enough then I will need to seriously think about how we can re-write this code, and moreover why we do not have the additional udev params that we expect in the initrd | 17:11 |
| cachio | zyga, in 10 minutes will be ready | 17:11 |
| cachio | and Ill fix tw | 17:11 |
| === ijohnson is now known as ijohnson|lunch | ||
| mborzecki | zyga: https://github.com/snapcore/snapd/pull/8685#issuecomment-630315807 what do you mean by unlucky snapshot? does it install the latest aviablel go version (eg. go1.14) or rather the `go` package in version 1.12.sth? | 17:15 |
| mup | PR #8685: opensuse: zypper --replacefiles <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8685> | 17:15 |
| cachio | Saviq, hey, are you using fedora 28 and 29 images for testing? | 17:40 |
| cachio | Saviq, we want to rmemove them | 17:40 |
| cachio | Saviq, is it ok for you? | 17:40 |
| Saviq | cachio: remove away https://github.com/MirServer/mir/blob/master/spread.yaml#L5 | 17:40 |
| cachio | sergiusens, same question for you | 17:40 |
| sergiusens | cachio: we do not. | 17:41 |
| cachio | Saviq, good, hopefully we will have fedora 32 today | 17:41 |
| sergiusens | feel free to remove | 17:41 |
| cachio | sergiusens, thanks | 17:41 |
| === ijohnson|lunch is now known as ijohnson | ||
| mup | PR snapd#8672 closed: o/devicestate: change how current system is reported for different modes <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8672> | 17:47 |
| pedronis | ijohnson: well we either parse the uuid, or we call cryptsetup status <device-mapper-name> and parse the output | 18:14 |
| ijohnson | pedronis: which do you think we should do? As I said it seems unlikely that the dm uuid will change for the lifetime of uc20, but then again it could since upsteam devs don't think it's meant to be inspected | 18:15 |
| pedronis | ijohnson: it's probably easier to use cryptsetup status, otoh the output doesn't seem super machine friendly (differently for other tools it doesn't seem a way to control the output format) | 18:16 |
| ijohnson | let me boot into the initrd and see how the output looks there | 18:17 |
| ijohnson | pedronis: let me boot into the initrd to see how it looks there | 18:18 |
| mup | PR snapcraft#3132 opened: go v1 plugin: warn when using go.mod and go < 1.13 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3132> | 18:51 |
| ijohnson | pedronis: after some other new hurdles I learned about (now I have to always also re-build pc gadget to test initramfs changes), I now find that cryptsetup isn't even in the initramfs | 19:23 |
| ijohnson | afaict we only have systemd-cryptsetup which doesn't understand the "status" argument | 19:24 |
| pedronis | ijohnson: no, it can only setup things, so much fun | 19:24 |
| ijohnson | yep! | 19:24 |
| pedronis | ijohnson: let's pursue the parsing to unblock us, and then reconsider this I suppose | 19:32 |
| ijohnson | pedronis: ok, I will add a TODO to the code about sorting this out perhaps | 19:32 |
| mup | PR snapd#8693 opened: tests: adding fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693> | 19:49 |
| cachio | zyga, ~ | 19:49 |
| cachio | tests breacking on fedora 32 | 19:49 |
| cachio | zyga, https://paste.ubuntu.com/p/vfQqBG2SCG/ | 19:50 |
| * cachio afk | 20:10 | |
| pedronis | ijohnson: are you now unblocked on what to do with #8683 ? also if you think is risky keep reading the dm files directly | 20:22 |
| mup | PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683> | 20:22 |
| ijohnson | pedronis: yes I'm unblocked I will address your comments | 20:22 |
| pedronis | ok, thx, going to call it a day | 20:23 |
| ijohnson | sounds good, talk to you tomorrow | 20:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!