| mborzecki | morning | 05:06 |
|---|---|---|
| zyga | Hey | 05:25 |
| zyga | mborzecki: I found a hell of a bug yesterday | 05:25 |
| zyga | Working >12 hours but was worth it | 05:26 |
| mborzecki | zyga: hey, what bug? | 05:29 |
| zyga | Mount namespaces are seriously busted | 05:31 |
| zyga | This explains all the odd reports I got | 05:32 |
| zyga | I am tired a bit, still in bed | 05:32 |
| mborzecki | zyga: nice that you found it :) | 05:33 |
| zyga | I spent half of yesterday trying to nail what was going on | 05:34 |
| zyga | There are several bugs | 05:34 |
| zyga | I know of two for sure because those got fixed in my branch | 05:34 |
| zyga | The third one I know where it is but I was too tired to figure out where it is past 23:00 | 05:35 |
| zyga | Hehe | 05:35 |
| zyga | To figure out exactly where it is | 05:35 |
| zyga | Those are all serious enough I think we should do .2 | 05:43 |
| zyga | Hey mvo | 06:11 |
| zyga | I found a naaaasty bug last night | 06:11 |
| mvo | hey zyga ! good morning | 06:12 |
| mvo | zyga: uh, that sounds bad - can you tell me more please? | 06:12 |
| zyga | Mvo: mount namespaces have three bugs that cripple content sharing | 06:14 |
| zyga | 1) we unshare one too many times, this was fixed about 6 months ago but not merged, lost in a feature branch | 06:14 |
| zyga | 2) sharing is broken so user mount namespace does not get propagation correctly, breaking on refresh or reconnect depending on use | 06:15 |
| zyga | 3) ordering of mount operations is wrong, causing shadowing of past mounts | 06:15 |
| zyga | Lots of craze last night | 06:16 |
| zyga | I had a call with Jamie to discuss some of this | 06:16 |
| zyga | 1 is simple | 06:16 |
| zyga | 2 is todo, didn’t debug as I realized this was broken after 23:00 | 06:17 |
| zyga | 3 is complex and requires some algorithm work | 06:17 |
| zyga | Together those break gnome runtime sharing, theme sharing and perhaps other cases | 06:18 |
| mvo | zyga: uh, that sounds nasty | 06:18 |
| mvo | zyga: lets talk some more in some minutes, I make a cup of tea | 06:19 |
| zyga | Excellent idea :-) | 06:19 |
| mborzecki | mvo: morning | 06:27 |
| mvo | hey mborzecki | 06:39 |
| zyga | mvo: back in the office | 06:44 |
| zyga | slowly waking up | 06:52 |
| pedronis | morning | 07:03 |
| pedronis | could we get a 2nd review of #6775 | 07:03 |
| mup | PR #6775: devicestate: make Remodel() return a state.Change <Created by mvo5> <https://github.com/snapcore/snapd/pull/6775> | 07:03 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:11 |
| pedronis | pstolowski: hi, I have a question in #6793 | 07:12 |
| mup | PR #6793: cmd/snap: support for --ensure argument for snap debug timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6793> | 07:12 |
| mborzecki | pedronis: pstolowski: hey | 07:16 |
| pstolowski | pedronis: yes... you're right, i forgot about those | 07:17 |
| pstolowski | i mean about nesting them visually | 07:18 |
| mup | PR snapd#6790 closed: interfaces: add login-session-control interface <Created by AlanGriffiths> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6790> | 07:24 |
| mvo | zyga: was wondering about 6751, it seems it just misses a unit test to go into master, can I help you with that? I would love to land this before lyon | 07:26 |
| zyga | mvo: perhaps, I will try to devote an hour to it today | 07:26 |
| zyga | sorry for taking so long, yesterday was a marathon of debugging | 07:26 |
| mvo | zyga: I can look at it, I understand you are looking at important bugs | 07:27 |
| pedronis | pstolowski: thanks, so I wasn't confused, I think we do the same with ^ as for the change. | 07:33 |
| pstolowski | pedronis: yes | 07:33 |
| pedronis | pstolowski: let me make a comment in the PR itself | 07:33 |
| pedronis | mborzecki: made a couple of comments in 6750 | 07:34 |
| pedronis | one is not of immediate relevance | 07:34 |
| mborzecki | pedronis: thanks, reading through them now | 07:34 |
| pedronis | pstolowski: for Ensure, is the label of level 0 usually the same as the "ensure" tag, or is just for some ? | 07:36 |
| mup | Bug #1828175 opened: Lack of proxy support for snap prepare-image <Snappy:New> <https://launchpad.net/bugs/1828175> | 07:37 |
| pstolowski | pedronis: using refresh catalogs as an example: we have "ensure": "refresh-catalogs", then two nested measurements under it: with "get-sections" and "write-catalogs" labels | 07:40 |
| pedronis | pstolowski: thx, noticed the same | 07:41 |
| pedronis | pstolowski: I was thinking a bit about what to put in ID, but given that we don't want to make lines too long | 07:41 |
| pedronis | "ensure" seems fine (it's a debugging thing and one should know what they asked) | 07:41 |
| mvo | zyga: I will push something shortly | 07:42 |
| mborzecki | pstolowski: if we can tweak the formatting of timing entries a bit, may we use ---^ or --- to fill the line before ^ sign? | 07:48 |
| mborzecki | pstolowski: http://paste.ubuntu.com/p/7dWSfRbTrc/ this is what i mean, the ^ dashes feel a bit hard to follow | 08:05 |
| pstolowski | pedronis: actually, we won't see "^" nesting for ensures right now, the refresh-catalogs is the root node with tags, then get-sections and write-catalogs are at level 0. for tasks level 0 measurements appear nested visually because we put them under task line | 08:05 |
| mborzecki | Chipaca: welcome back | 08:06 |
| Chipaca | mborzecki: :) | 08:06 |
| pstolowski | mborzecki: yep, i tend to agree, but i'd leave it for a potential followup, this had already been disputed about in one of the first PR in these series ;) | 08:08 |
| mborzecki | pstolowski: mhm, sounds good to me, i don't have an immediate suggestion now either, but maybe we'll come up with something once people start using it | 08:09 |
| Chipaca | pedronis: you around? | 08:11 |
| mborzecki | got a quick errand to run, back in ~30 | 08:14 |
| pstolowski | pedronis: pushed some changes + reply to your comment | 08:43 |
| pstolowski | pedronis: also, i need to discuss with you some aspects of snap unset implementation that i touched breifly with mvo yesterday in the standup; would be great to meet (three of us) today | 08:45 |
| === ricab is now known as ricab|bbl | ||
| mborzecki | re | 09:05 |
| pedronis | pstolowski: sorry was in meetings, interesting about the 0 level, maybe we should have an articial one | 09:21 |
| pedronis | though maybe is just a wasted line, but it would clarify things | 09:21 |
| pstolowski | pedronis: yes, i can add this | 09:23 |
| pstolowski | pedronis: nb, can you merge master into your PRs? i'm about to do reviewing, will make diffs smaller | 09:24 |
| pstolowski | pedronis: eg #6822 (and it has a conflict) | 09:24 |
| mup | PR #6822: overlord/devicestate: introduce registrationContext <Created by pedronis> <https://github.com/snapcore/snapd/pull/6822> | 09:25 |
| pedronis | pstolowski: basically the articial line should contain "ensure" and somewhere the ensure tag | 09:29 |
| pedronis | pstolowski: can also be a follow up a this point though | 09:29 |
| pedronis | pstolowski: yes, need a little break after the meetings but will look at my PRs, I'm also doing reviews | 09:30 |
| pedronis | of some team PRs | 09:30 |
| pedronis | pstolowski: btw you can review mvo 6775 and 6776 if you are wating to review mines | 09:41 |
| pstolowski | pedronis: ok. yep i'd prefer a followup | 09:46 |
| pstolowski | pedronis: did you see my message about the need of discussing snap unset? | 09:46 |
| mborzecki | anyone up for a 2nd review of https://github.com/snapcore/snapd/pull/6798 ? | 09:50 |
| mup | PR #6798: gadget: introduce checkers for sanitizing structure updates <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6798> | 09:51 |
| * zyga woke up again | 09:51 | |
| zyga | sorry everyone, had a rough night | 09:51 |
| zyga | mvo: thank you for the tests | 09:52 |
| pedronis | pstolowski: yes, are you blocked? I can do after lunch or immeditately after standup, but not sure when mvo can | 09:52 |
| pstolowski | pedronis: a bit blocked yes, but i'm doing reviews so it can wait for later today | 09:53 |
| mup | PR snapd#6826 closed: tests: enable tests on centos 7 again <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6826> | 10:24 |
| === ricab|bbl is now known as ricab | ||
| * Chipaca afk for a while | 10:33 | |
| zyga | man that's so darn annoying | 11:26 |
| zyga | I'm staring the bug in the face | 11:26 |
| zyga | I see it's wrong | 11:26 |
| zyga | but yet WHY eludes me | 11:27 |
| === cachio_ is now known as cachio | ||
| cachio | mvo, hey | 11:35 |
| cachio | mvo, could you please merge #6694 to 2.39? I need that to finish snapd validation | 11:36 |
| mup | PR #6694: tests: improve how snaps are cached <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6694> | 11:36 |
| mvo | cachio: uh, 27 commits, let me see how we can do this | 11:42 |
| mvo | I can't cherry pick this indivudally | 11:42 |
| mvo | cachio: lets talk after (my) lunch, we get this in I might need to do it with conflicts instead of as cherry-picks | 11:43 |
| cachio | mvo, sure | 11:43 |
| cachio | thanks | 11:43 |
| zyga | brb | 11:45 |
| zyga | uhhhh | 11:45 |
| zyga | re | 11:49 |
| pedronis | pstolowski: we could chat now but maybe you and mvo are having lunch atm | 11:56 |
| === ricab is now known as ricab|lunch | ||
| pstolowski | pedronis: works for me if mvo is around | 12:10 |
| pedronis | pstolowski: do we need mvo? | 12:10 |
| pedronis | pstolowski: I'm in the standup channel | 12:11 |
| pstolowski | pedronis: ok, coming | 12:11 |
| mup | PR snapcraft#2560 opened: meta: do not wrap commands by default <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2560> | 12:12 |
| * Chipaca goes in quest of food | 12:23 | |
| mup | PR snapd#6821 closed: many: make which store to use contextual <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6821> | 12:35 |
| pedronis | Chipaca: ^ that provoked conflicts in your PRs I fear | 12:39 |
| pedronis | I can look into that myself in a bit | 12:39 |
| cmatsuoka | niemeyer: do you prefer adapter: none or no adapter line at all in the gnome extension? | 12:46 |
| cmatsuoka | (sergiusens is changing that now and we can do it in either way) | 12:47 |
| cachio | q | 12:47 |
| pedronis | #6828 can be reviewed (because of later pushes 6822 comes later in the chain now) | 12:52 |
| mup | PR #6828: many: use a fake assertion model in the device contexts for tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/6828> | 12:52 |
| mup | PR snapd#6840 opened: gadget: fix handling of positioning constrains for structures of MBR role <Gadget update> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6840> | 12:52 |
| mborzecki | simple PR ^^ cmatsuoka pstolowski maybe? | 12:53 |
| cmatsuoka | mborzecki: checking that | 12:54 |
| mborzecki | cmatsuoka: thanks | 12:54 |
| mvo | pedronis, pstolowski sorry, had lunch indeed | 12:56 |
| pstolowski | mvo: np, i think the solution is uncontroversial, we will brief you in a momentr | 12:57 |
| Chipaca | pedronis: conflict is life | 12:59 |
| mvo | pstolowski: \o/ | 12:59 |
| === ricab|lunch is now known as ricab | ||
| niemeyer | cmatsuoka: none or none at all seem similar | 13:20 |
| cmatsuoka | niemeyer: ack | 13:21 |
| niemeyer | cmatsuoka: But I'm still not sure I get what's going on there.. does adapter: full really mean no adapter? | 13:22 |
| niemeyer | That seems pretty absurd | 13:22 |
| cmatsuoka | From what I see there adapter: none means no adapter, "full" means command chain and "legacy" means wrappers | 13:22 |
| cmatsuoka | but sergiusens is changing the default to command chain | 13:23 |
| cmatsuoka | (I do agree that the choice of words isn't very clear) | 13:27 |
| mborzecki | off to school | 14:03 |
| * zyga is onto something! | 14:10 | |
| niemeyer | cmatsuoka: Yeah, the command chain isn't an adapter.. it's also under the control of the command-chain field itself, so there's no need to say anything else | 14:11 |
| pedronis | cachio: we got this: https://api.travis-ci.org/v3/job/529764900/log.txt | 14:20 |
| pedronis | internal error: a core16 snap is installed, earlier test cleanup did not work | 14:20 |
| sergiusens | niemeyer: as absurd as it feels now, it is was we concluded with kyrofa on https://forum.snapcraft.io/t/proposal-add-command-chain-to-apps-instead-of-generating-opaque-wrappers/6018 ... I'll see how we can get out of that, but it won't be as easy | 14:22 |
| mvo | cachio: I looked at 6694 but cherry-picking it in isolation to release/2.39 shows conflicts on the first patch already so I think there is another PR before that that modified this part of the prepare.sh. do you remember which one that might be? did we had something similar before? we may need to cherry-pick both | 14:29 |
| pedronis | mvo: I'll do the small fix pstolowski asked in your #6775 | 14:30 |
| mup | PR #6775: devicestate: make Remodel() return a state.Change <Created by mvo5> <https://github.com/snapcore/snapd/pull/6775> | 14:30 |
| niemeyer | sergiusens: We discussed that when introducing bases | 14:32 |
| niemeyer | sergiusens: We added the command chain concept at the same time so we would not break compatibility in the future | 14:33 |
| niemeyer | sergiusens: So I hope at least with a base, the default is no adapter.. is that the case? | 14:34 |
| niemeyer | Small? Large? | 14:36 |
| mvo | pedronis: thank you | 14:37 |
| pedronis | mvo: done | 14:37 |
| cachio | pedronis, checking | 14:37 |
| mvo | pedronis: \o/ | 14:37 |
| cachio | pedronis, this is on master right? | 14:38 |
| cachio | because that should be fixed | 14:38 |
| pedronis | cachio: one of my PRs | 14:39 |
| cachio | mvo, checking | 14:39 |
| pedronis | but I had merge with master today I think | 14:39 |
| cachio | pedronis, in that case I'll need to take a look, that should be fixed, which is the PR? | 14:40 |
| pedronis | cachio: this one: https://github.com/snapcore/snapd/pull/6828 (doesn't touch spread stuff) | 14:41 |
| mup | PR #6828: many: use a fake assertion model in the device contexts for tests <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6828> | 14:42 |
| cachio | pedronis, thanks | 14:42 |
| pedronis | it's actually all unit tests changes I think | 14:42 |
| ijohnson | hi folks, what's the status of building core18 snaps on travis (especially with respect to using build-snaps)? is launching a docker container still the thing to do on travis? | 14:48 |
| cachio | mvo, this is giivng conflicts? git cherry-pick 2e10db98657923a58fd7461586d150cfa97fc5b2 | 14:48 |
| cachio | mvo, I could cherry pick all of them | 14:52 |
| mvo | cachio: this one looks fine, let me see if that is the one I was missing | 14:53 |
| cachio | mvo, the problem with this PR is that I tried many alternative during time until the last one was choosend | 14:54 |
| mvo | cachio: ohhhh, so only the last one is relevant? and that applies cleanly? | 14:54 |
| mvo | cachio: in this case we are good :) | 14:54 |
| cachio | mvo, no | 14:55 |
| cachio | mvo, it is a mix | 14:55 |
| mvo | zyga: a re-review of 6820 would be great, it already has a +0.9 from you :) | 14:56 |
| cachio | mvo, let me check which are needed | 14:56 |
| cachio | I'll give you a list | 14:56 |
| mvo | cachio: thanks | 14:57 |
| mvo | cachio: alternatively, feel free to branch off releae/2.39 and cherry-pick as needed | 14:57 |
| mvo | cachio: it seems like we just have to live with some conflicts when merigng back but thats ok | 14:57 |
| sergiusens | niemeyer: it is not, we can discuss the reasons next week; we did discuss this with bases, but at the end of last cycle, command-chain had not made the release cut in snapd ... | 15:00 |
| zyga | mvo: looking | 15:01 |
| zyga | mvo: +1 | 15:03 |
| cachio | pedronis, this seems to be new, I'll try to reproduce it locally, thanks for the log | 15:03 |
| niemeyer | sergiusens: This is extremely unfortunate.. the whole point of command-chain was to avoid breaking compatibility in the future after bases were introduced | 15:07 |
| niemeyer | sergiusens: What's your plan now to make them the default and adapters gone without breaking people? | 15:08 |
| niemeyer | There's zero gain in command-chain if everybody has adapters | 15:08 |
| niemeyer | :/ | 15:08 |
| sergiusens | niemeyer: I will bring a proposal to discuss with you for next week, migrating is something we already discussed with kyrofa | 15:10 |
| pstolowski | mvo, pedronis hotplug mystery wrt core18 solved | 15:17 |
| pstolowski | mvo, pedronis serial-port interface doesn't contain hotplug changes in 2.38.1. hotplug subsystem is triggered, just 0 interfaces support it. i have no idea how that happened that it didn't land in release brach :( | 15:18 |
| ijohnson | sil2100: hey where is the "official" repository for pi gadgets these days? is it https://github.com/snapcore/pi-gadget ? | 15:19 |
| mvo | pstolowski: so 2.39 fixes it? | 15:20 |
| mvo | ijohnson: this looks correct | 15:20 |
| ijohnson | mvo: cool thanks, we need to add the bt-serial interface back to the gadget there for uc18 | 15:21 |
| mvo | ijohnson: oh, that got lost? yeah, totally | 15:22 |
| * mvo wonders why :( | 15:22 | |
| mvo | ijohnson: are you looking into this or sil2100 ? | 15:22 |
| ijohnson | I was just wondering because the snapcore repo is more active but there's also github.com/CanonicalLtd/pi-gadget | 15:22 |
| ijohnson | mvo: I'm actually looking into this because I wasn't able to use hotplug for the bluetooth adapter serial port, then learned that the gadget is supposed to include a slot for that and it's missing from the gadget on uc18 for some reason | 15:23 |
| ijohnson | mvo: I was just going to file a PR to quick add it since it's 3 lines | 15:23 |
| ijohnson | mvo: but I'm not sure which repo is watched for PR's :-) | 15:24 |
| mvo | ijohnson: it should show up here :) | 15:24 |
| pstolowski | mvo: 2.39 has the serial-port changes so yes, should work. i'm going to verify that | 15:24 |
| mvo | ijohnson: mup should tell us | 15:24 |
| mvo | pstolowski: it will work once the gagdet is fixed? or today? | 15:24 |
| pedronis | pstolowski: did you look whether system snap setting up is correct overall? | 15:25 |
| pstolowski | pedronis: yes, it looks ok (mapper says it's "snapd"). however i haven't checked seeding etc. i'm not sure how my manual testing affects it | 15:28 |
| pedronis | pstolowski: ok, I'll try to look at that myself (I don't remember the details) | 15:34 |
| sil2100 | ijohnson: yes, that's the right repository | 15:41 |
| sil2100 | ijohnson: (snapcore) | 15:41 |
| ijohnson | sil2100: great thanks for confirmation | 15:41 |
| sil2100 | ijohnson: I need to remove the CanonicalLtd ones, I created those when Foundations had no powers to manage the snapcore ones ;) | 15:42 |
| ijohnson | ah I see that makes sense | 15:42 |
| sil2100 | (sorry for the confusion) | 15:42 |
| ijohnson | np | 15:42 |
| sil2100 | ijohnson: just in case https://wiki.ubuntu.com/UbuntuCore/Development should be up-to-date with this things | 15:42 |
| ijohnson | thanks sil1200 that's really helpful I wasn't aware of that page | 15:43 |
| ogra | should be promoted on the forum and snapcraft docs | 15:44 |
| ijohnson | +1 | 15:44 |
| ijohnson | also, question for mvo and pedronis if it's quick (if it's not quick/easy let me know and I'll start a forum post instead), how does snapd handle gadget slots for devices like a serial port that doesn't actually exist? | 15:47 |
| ijohnson | the idea here being that we declare a serial port slot on a gadget for pi2 and pi3, but the serial port actually only exists on the pi3 and not on the pi2 | 15:48 |
| ogra | yeah, specifically with interfaces that define a device path in their interface declaration, is snapd checking the device actually exists before exposing the interface ? | 15:49 |
| pedronis | ijohnson: I don't think we check/supress atm, we do trust the dgadget | 15:49 |
| ogra | (thats what i would expect actually) | 15:49 |
| pedronis | it could be considered a bug | 15:49 |
| pedronis | but that's current behavior | 15:49 |
| ogra | ouch | 15:49 |
| ijohnson | ok, do you want me to start a conversation on the forum for this? | 15:49 |
| pedronis | yes | 15:50 |
| ijohnson | ack thanks | 15:50 |
| cachio | mvo, change cherry picked to 2.39 | 15:55 |
| cachio | mvo, pushed to branch on snapcore, is it ok or I should push to my own copy and then create a PR? | 15:57 |
| mvo | cachio: thanks! doing in a PR would be ideal but if travis is happy thats fine. thanks for doing this | 15:58 |
| cachio | mvo, ok, sorry, lets see if it works | 15:58 |
| mvo | cachio: aha, nice! it looks like it all merges back into master nicely, no conflict afaict. cool | 15:59 |
| mvo | cachio: yeah, I wasn't clear in my original question/request so no worries | 15:59 |
| cachio | mvo, I found another improvement to implement by reviewing the change :) | 16:00 |
| pstolowski | mvo, pedronis: there is a bug though with core18 related to snapd transition and hotplug; serial-port hotplug slot doesn't pass sanitization because of "if slot.Snap.Type != snap.TypeOS && slot.Snap.Type != snap.TypeGadget" check | 16:00 |
| pedronis | ah | 16:00 |
| mvo | cachio: nice | 16:00 |
| mvo | pstolowski: ha! good catch | 16:01 |
| ijohnson | pedronis: posted as https://forum.snapcraft.io/t/gadget-slots-for-devices-that-dont-exist/11278 | 16:01 |
| pedronis | thx | 16:01 |
| pedronis | pstolowski: does this come from the base declaration or so something else? | 16:01 |
| pedronis | I thought we made core mean snapd or core at that level | 16:02 |
| * cachio lunch | 16:03 | |
| pstolowski | pedronis: no, we have a few helpers (sanitizeSlotReservedForOSOrGadget, sanitizeSlotReservedForOS...) that various interfaces call in their sanitize methods, they check SlotInfo.Snap.Type | 16:04 |
| pedronis | ah, I think we should drop those if I understand things correctly | 16:05 |
| pedronis | that job is done by the base declaration now | 16:05 |
| pstolowski | pedronis: hmm, interesting | 16:05 |
| Chipaca | ok, I'm going offline, ttfn ttyl | 16:05 |
| pstolowski | pedronis: right, slot-snap-type: in base decl does that | 16:06 |
| pedronis | yes | 16:06 |
| pedronis | I mean there might be reason to keep them | 16:06 |
| pstolowski | pedronis: does it treat "snapd" special though? | 16:06 |
| pedronis | yes | 16:06 |
| pedronis | as I said there is code to make core mean (core or snapd) | 16:06 |
| pedronis | you can find it in policy I think | 16:07 |
| pedronis | we should maybe sanitize that at some point but is not trivial | 16:07 |
| pedronis | I mean switch to something like system instead of core | 16:07 |
| pstolowski | pedronis: i don't see a point in keeping these helpers anymore then | 16:09 |
| pstolowski | or they should special-case "snapd" if we want to keep them for a while | 16:10 |
| pedronis | pstolowski: that might be a smaller change? | 16:17 |
| pedronis | for now | 16:17 |
| pedronis | not sure | 16:17 |
| pstolowski | pedronis: around 12 interface files call them, but then over 80 test files are affected too (because of common interface). the change should be pretty mechanical though, as long as base declarations for them are complete in that regard | 16:21 |
| pstolowski | pedronis: for 2.39 though might be better to make a simple fix in the helpers, and then a followup which removes them all | 16:23 |
| pedronis | pstolowski: yes | 16:24 |
| pstolowski | ok, will do | 16:24 |
| pstolowski | ok, i've a tentative fix, need to test it on pi3 though to see if that's the only issue, will do that tomorrow morning | 16:33 |
| === pstolowski is now known as pstolowski|afk | ||
| mup | PR snapd#6775 closed: devicestate: make Remodel() return a state.Change <Remodel :train:> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6775> | 16:38 |
| mvo | 6776 is now a very simple review :) | 16:39 |
| mup | PR snapcraft#2556 closed: cli: snapcraft promote <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2556> | 16:52 |
| mup | PR snapd#6820 closed: snap-confine: improve error when running on a not /home homedir <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6820> | 18:17 |
| mup | PR snapd#6840 closed: gadget: fix handling of positioning constrains for structures of MBR role <Gadget update> <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6840> | 18:26 |
| mup | PR snapd#6828 closed: many: use a fake assertion model in the device contexts for tests <Remodel :train:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6828> | 18:27 |
| cachio | zyga, hey this is interesting https://paste.ubuntu.com/p/tG5MmWSH8n/ | 20:14 |
| cachio | base snaps mounted after snap remove | 20:14 |
| cachio | in the tests | 20:14 |
| mup | PR snapd#6841 opened: overlord: make changes conflict with remodel <Created by pedronis> <https://github.com/snapcore/snapd/pull/6841> | 20:36 |
| cachio | zyga, I already fixed the issue | 20:44 |
| mup | PR snapd#6842 opened: tests: fix how the base snap are deleted when there are multiple to deleted on reset <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6842> | 21:07 |
| mup | PR snapcraft#2559 closed: manifest: expose snapcraft-started-at <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2559> | 22:20 |
| mup | PR snapd#6843 opened: tests: avoid removing snaps which are cached to speed up the prepare on boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6843> | 22:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!