[06:08] <mborzecki> morning
[06:08] <mborzecki> starting a bit later, need to drive the kids to school
[06:27] <mup> PR snapd#7954 closed: changelog: fix typos <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7954>
[06:35] <mup> PR snapd#7959 closed: tests: fix classic-ubuntu-core-transition-two-cores after refactor of MATCH -v <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7959>
[06:45] <mup> PR snapd#7962 opened: tests: cherry-pick fixes for  snap-set-core-config/ubuntu-core-config-defaults-once <Created by mvo5> <https://github.com/snapcore/snapd/pull/7962>
[06:46] <mup> PR snapd#7949 closed: cmd/snap, daemon: stop over-normalising channels <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7949>
[07:07] <zyga> good morning!
[07:08] <zyga> hey mvo
[07:08] <zyga> mvo: anything to keep in mind regarding yesterday?
[07:09] <mborzecki> re
[07:09] <zyga> hey mborzecki :)
[07:09] <mborzecki> one kid at school, the other sick at home
[07:09] <mvo> hey zyga, good morning
[07:09] <mborzecki> zyga: mvo: hey
[07:09] <zyga> mborzecki: two at school, one still sleeping
[07:09] <mvo> mborzecki: good morning and happy new year
[07:09] <mvo> zyga: yesterday> nay, all good
[07:09] <mborzecki> mvo: happy new year to you too! that was a looong break
[07:10] <mvo> mborzecki: yeah, long and refreshing I hope :)
[07:10] <mvo> (it was for me!)
[07:11] <zyga> I must admit that after about a week of anxiety I really started resting
[07:11] <zyga> and ended up not touching coding for most of the time
[07:18] <mborzecki> mvo: thanks for uploading release tarballs to github releases!
[07:19] <mvo> mborzecki: my pleasure, sorry that I was a bit late
[07:37] <mborzecki> updated arch package to 2.42.5
[07:38] <mborzecki> hm arch switched to zstd compression for packages, but i don't see any changes to makepkg.conf in https://git.archlinux.org/pacman.git/log/etc/makepkg.conf.in looks like they didn't push it yet
[07:40] <mup> PR snapd#7955 closed: tests: remove "test-snapd-tools" in smoke/sandbox on restore <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7955>
[08:02] <pstolowski> morning
[08:02] <zyga> hey pawel
[08:02] <mvo> hey pstolowski !
[08:02] <pstolowski> hey hey
[08:05] <mborzecki> pstolowski: hey
[08:11] <mvo> a quick sanity-check of 7951 and 7962 would be nice, pedning 2.43 PRs
[08:15] <pstolowski> mvo: there is one file less in 7951 than it was in the original PR, not sure if it's intentional?
[08:17] <mvo> pstolowski: let me look to refresh my memories, it might be that this file is not in 2.43 yet
[08:18] <abeato> mvo, hey, happy new year! I have been told that snapd does not yet support default tracks, when will that happen?
[08:20] <zyga> re
[08:20] <mvo> abeato: it's very close to land in edge, chipaca is landing PRs as we speak
[08:20] <mvo> abeato: he should be here in ~1h or so - my (probably wrong) estimate is EOW but please double check with him on that :)
[08:21] <abeato> mvo, awesome! mind pointing me to the MPs?
[08:21] <mvo> abeato: this is edge, it missed the boat for 2.43 so most likely in stable for 2.44 unless it's crtitical
[08:21] <pstolowski> mvo: tests/main/parallel-install-remove-after/task.yaml missing in 7951 if that helps
[08:21] <mvo> abeato: sure, one sec
[08:22] <mvo> pstolowski: I just checked, it seems like this test does not yet exist in 2.43
[08:22] <pstolowski> mvo: good
[08:23] <mvo> abeato: https://github.com/snapcore/snapd/pull/7950 and there is one more needed AIUI
[08:23] <mup> PR #7950: overlord/snapstate: tracks are now sticky <Created by chipaca> <https://github.com/snapcore/snapd/pull/7950>
[08:24] <abeato> mvo, thanks - and no, not critical for the moment, but we plan to use the feature from some snaps when available
[08:24] <abeato> s/from/for/
[08:33] <mvo> abeato: ack
[08:34] <mup> PR snapd#7951 closed: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 (2.43) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7951>
[09:10] <zyga> I think https://forum.snapcraft.io/t/snap-layouts/7207/37?u=zyga should be split into a separate thread
[09:10] <zyga> it's less about layouts and more about troubleshooting snapcraft and containers
[09:13] <jamesh> mvo: do you think there is any interest in adopting the Github action I wrote as an official project?
[09:14] <Chipaca> zyga: I can do that
[09:14] <Chipaca> zyga: tell me what to do tho :-)
[09:14] <zyga> thank you Chipaca :)
[09:14] <Chipaca> zyga: is it all following?
[09:14] <zyga> Chipaca: split it after the first message where the reporter is debugging snapcraft
[09:14] <zyga> I think so
[09:14] <zyga> based on my quick reading
[09:14] <Chipaca> zyga: ok. SUggestions for title of the new thread?
[09:14] <zyga> hmmm
[09:15] <zyga> Building with snapcraft in docker?
[09:15] <zyga> brb
[09:15] <zyga> I was about to go upstairs for tea
[09:16] <Chipaca> upstairs-tea sounds fancy
[09:17] <mvo> jamesh: in a meeting right now, I will get back to you. do you have a link with more information?
[09:17] <Chipaca> zyga: https://forum.snapcraft.io/t/building-with-snapcraft-in-docker/14946
[09:17] <jamesh> mvo: https://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/14930
[09:18] <zyga> Chipaca: thank you :)
[09:18] <zyga> jamesh: hey, happy new year :)
[09:18] <jamesh> hi zyga
[09:18] <Chipaca> jamesh: that's probably more a sergiusens Q than an mvo Q
[09:18] <Chipaca> jamesh: unless mvo is becoming our über-manager
[09:18]  * Chipaca mangles languages for fun and/or profit
[09:19] <zyga> Chipaca: we have a cat now
[09:19] <jamesh> Chipaca: I wasn't quite sure who was in charge of projects under the "snapcore" org
[09:19] <zyga> Chipaca: it wandered in when it was cold and doesn't want to leave
[09:19] <Chipaca> jamesh: it might still be our CTO
[09:19] <Chipaca> zyga: we have developers like that also
[09:19] <zyga> hahaha
[09:21] <Chipaca> jamesh: in any case mvo is in a better place to help than I am :-)
[09:21] <Chipaca> also he's awake, which is an advantage over sergiusens
[09:22] <Chipaca> (sergiusens might be technically awake but given it's 6am for him, I wouldn't trust it)
[09:53] <Chipaca> sdhd-sascha: duuude
[09:53] <Chipaca> sdhd-sascha: what do you mean they are not optional
[09:53] <Chipaca> sdhd-sascha: I'm telling you they are optional
[09:53] <Chipaca> I'm not asking :)
[09:54] <Chipaca> sdhd-sascha: most people don't even know 'list' can take positional arguments
[09:54] <sdhd-sascha> Chipaca: oh, sorry. Good morning ;-)
[09:54] <Chipaca> sdhd-sascha: non-required is the default
[09:56] <sdhd-sascha> Chipaca: i look further. Because i never worked with reflection in golang, did you know where the tags behind the arguments are parsed?
[09:56] <Chipaca> sdhd-sascha: https://godoc.org/github.com/jessevdk/go-flags
[09:56] <Chipaca> sdhd-sascha: it sounds like you're digging too deep for what you're wanting to do
[09:57] <Chipaca> which is alright, if you intend to learn a lot from it
[09:57] <Chipaca> if you're wanting to get things done, then you've gone too far -- if it's educational you're doing great :-D
[10:03] <sdhd-sascha> Chipaca: you are right. Often i'm annoyed to have asked a question shortly after. Because the answer was obvious. I want to improve myself there.
[10:03] <sdhd-sascha> I can postpone learning that later. Most of the things in go are very simple - only my memory is sometimes not persistent enough ...
[10:03] <Chipaca> heh
[10:04] <Chipaca> sdhd-sascha: BTW, don't make it a string
[10:04] <Chipaca> use a flags.Filename
[10:10] <mvo> jamesh: back from the meeting, reading your post now, I need to check if I have enough privs to enable github actions
[10:11] <jamesh> mvo: this is more about where to host the repo.  My action is usable by anyone right now, but I don't know if we'd want to be recommending people create workflows referencing "jhenstridge/snapcraft-build-action@v1"
[10:12] <Chipaca> jamesh: flashbacks of jhbuild
[10:13] <jamesh> Chipaca: jhbuild was hosted in a CVS repo that any GNOME dev could commit to
[10:14] <Chipaca> jamesh: I meant about having your name immortalised in the build recipes :)
[10:14] <Chipaca> the way those things are cargo-culted, it's never going away :D
[10:15] <jamesh> Chipaca: I guess I could add other contributors to the repo under my personal user account, but I'm not sure that's the best way forward
[10:16] <Chipaca> agreed, i think snapcore would be a better place
[10:17] <Chipaca> jamesh: mvo: FWIW I can create the repository if there's agreement (mvo can also do so)
[10:17] <zyga> mborzecki: help me out
[10:17] <Chipaca> jamesh: you might be able to too, dunno
[10:17] <zyga> mborzecki: I just don't get it and I must be missing something utterly obvious
[10:17] <Chipaca> jamesh: https://github.com/organizations/snapcore/repositories/new
[10:17] <mborzecki> zyga: hmm?
[10:17] <zyga> mborzecki: I have a .c file that uses O_PATH, I defined _GNU_SOURCE, I included the required files
[10:17] <zyga> yet it's not defined
[10:18] <zyga> what could I be missing?
[10:18] <jamesh> Chipaca: I don't have that permission, and if I did I wouldn't want to use it unilaterally
[10:19] <Chipaca> jamesh: with you on that
[10:19] <mborzecki> zyga: defined _GNU_SOURCE too late? canyou pass it to gcc -D_GNU_SOURCE?
[10:19] <zyga> it's on the first line in the .c file
[10:20] <Chipaca> zyga: mborzecki: what's O_PATH got to do with _GNU_SOURCE?
[10:20] <zyga> Chipaca: you have to get it to get the other
[10:20] <zyga> Chipaca: it's a linux thing
[10:20] <zyga> Chipaca: so the headers don't give it unless you ask for it
[10:20] <mborzecki> Chipaca: manpage says _GNU_SOURCE must be defined for O_PATH
[10:21] <Chipaca> ah
[10:22] <Chipaca> zyga: how are you defining it?
[10:22] <jamesh> If you're building with e.g. -std=c18, it disables some non-standard features from headers by default
[10:22] <zyga> Chipaca: I tried #define _GNU_SOURCE in the 1st line in .c
[10:22] <jamesh> unless you define _GNU_SOURCE
[10:22] <zyga> Chipaca: tried -D_GNU_SOURCE just now
[10:22] <zyga> it's odd
[10:22] <zyga> with -D_GNU_SOURCE it compiles
[10:23] <zyga> with this and the #define it says it's already defined
[10:23] <zyga> but without -D_GNU_SOURCE it doesn't define O_PATH
[10:23] <zyga> what am I missing:
[10:23]  * zyga rechecks
[10:23] <Chipaca> zyga: did you read what james said?
[10:24] <zyga> Chipaca: yeah but I do define it, that's the point
[10:24] <zyga> Chipaca: I'm not building with std=c18
[10:24] <Chipaca> zyga: fwiw both work here (on 16.04)
[10:24] <zyga> and it finds it in other .c files
[10:24]  * zyga must be missing something
[10:24] <zyga> I'm using it in every other file we have
[10:26] <zyga> doh
[10:26] <zyga> I get it
[10:26] <zyga> I misread
[10:26] <zyga> thanks guys!
[10:26] <Chipaca> zyga: maybe you wrote Ο_ΡАΤН instead of O_PATH
[10:26] <zyga> it's -test.c that combines .c and .h that didn't work
[10:26] <zyga> the .c file built fine
[10:26] <Chipaca> heh
[10:27] <Chipaca> zyga: (that was omicron, under, rho, cyrillic a, tau, cyrillic en)
[10:27] <zyga> hahaha
[10:27] <zyga> nice
[10:27] <zyga> I'm happy C is so old-school
[10:29] <jamesh> modern C supports unicode identifiers
[10:31] <zyga> jamesh: we are doomed then ;)
[10:32] <Chipaca> zyga: but now you can have O_Pᴀᴛʜ!
[10:33] <jamesh> using small caps makes your code less shouty
[10:33] <zyga> Chipaca: I won't be satisfied until C allows ansi-escape codes in identifiers so that we can call all variables var just with varying colors
[10:33] <Chipaca> zyga: and D_𝔇𝔢𝔭𝔯𝔢𝔠𝔞𝔱𝔢𝔡
[10:34] <Chipaca> zyga: I'd be very disappointed if that didn't exist already
[10:35] <Chipaca> like brainfuck but with colours
[10:35] <zyga> Chipaca: cc -nyan
[10:35]  * zyga gets back to work
[10:36] <jamesh> the standard lists particular code point ranges, so probably no ANSI escapes
[10:37] <mup> PR snapd#7963 opened: xdgopenproxy: forward requests to the desktop portal <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7963>
[10:37] <mborzecki> jamesh: hi, can you take a look ^^ ?
[10:37] <jamesh> mborzecki: sure!
[10:37] <zyga> I was about to say the same
[10:37] <zyga> interesting
[10:37] <zyga> I didn't know the portal handled URLs
[10:37] <mborzecki> jamesh: thanks!
[10:37] <zyga> but if so let's use it :)
[10:38] <jamesh> mborzecki: it's actually something I had on my todo list to investigate, so I'm very interested
[10:38] <mborzecki> zyga: yeah, we can move all bugs to the portals package then :P
[10:38] <zyga> at least the list will be consistent
[10:38] <mvo> mborzecki: very cool stuff
[10:39] <mborzecki> duh, forgot to add fixes: https://bugs.launchpad.net/snappy/+bug/1857128 in the commit message
[10:39] <mup> Bug #1857128: Missing configuration option to allow a snap to openFile without prompting <Snappy:Confirmed> <https://launchpad.net/bugs/1857128>
[10:50] <mvo> can someone on fedora quickly check if "brave" installs/runs ? context is bug 1759219
[10:50] <mup> Bug #1759219: Brave browser fails to launch on fedora <snapd:Triaged> <https://launchpad.net/bugs/1759219>
[10:55] <zyga> mvo: checking
[10:55] <zyga> mvo: last time I tried it did not but even firefox has issues
[10:56] <Chipaca> it's brave, but not brave enough for fedora
[10:56]  * Chipaca hides
[10:58] <zyga> mvo: it actually runs
[10:59] <zyga> I opened it from a terminal with "snap run brave"
[10:59] <mvo> zyga: nice
[10:59] <zyga> mvo: on x86_64 fedora 31
[10:59] <mvo> zyga: I guess we can close this bug then :)
[10:59] <zyga> mvo: I read some reports that indicate it may be different via launcher
[10:59] <zyga> one sec
[10:59] <zyga> let me try that
[11:00] <zyga> mvo: that also worked
[11:00] <zyga> I logged out to be sure
[11:00] <zyga> so ... yeah
[11:00] <zyga> close it
[11:00] <zyga> WFM on
[11:00] <zyga> snapd 2.42.2
[11:00] <zyga> brb, I need a short break
[11:10] <mvo> cachio: hey, good morning. just fyi - I fixed an issue with core20-spread-2, this should fix that you couldn't login anymore
[11:11] <cachio> mvo, hi, yes I am checking that
[11:11] <cachio> yesterday I was tryin to make that work but I couldn't
[11:11] <cachio> mvo, thanks for the fix
[11:12] <mvo> cachio: yeah, sorry for that, it was complicated :/ the pc gadget changed and part of the snapd code needed an update
[11:13] <cachio> mvo, yes, I supposed that was something else that changed asn was affecting the uc20 boot
[11:13] <cachio> I'll continue enabling tests now
[11:13] <mvo> cachio: \o/ thank you
[11:14] <mvo> cachio: if you could review the updated 7943, that would be great
[11:15] <cachio> mvo, sure
[11:16] <mvo> pedronis: how do you feel about 7963 for 2.43? a bit of risk but a really nice improvement from a UI perspective (and 2.43 will be in beta/candidate for ~2 weeks still)
[11:17] <mvo> ^- (cc mborzecki )
[11:39] <Chipaca> #7961 could use a second +1 (and then I'll push tests as a separate PR)
[11:39] <mup> PR #7961: cmd: sign: add filename param <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7961>
[12:02] <mup> PR snapd#7961 closed: cmd: sign: add filename param <Created by sd-hd> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7961>
[12:03] <Chipaca> mvo: tks
[12:03] <mvo> Chipaca: thank you!
[12:04] <mborzecki> jamesh: thanks for the feedback, i'm runnig the spread test now
[12:04] <Chipaca> maybe we should thank sdhd-sascha also :-D
[12:04]  * mvo hugs sdhd-sascha
[12:04] <Chipaca> tests coming up (re-running them locally just to make sure)
[12:04] <sdhd-sascha> Chipaca: and i have thank you too
[12:05] <mborzecki> jamesh: btw. I do not see the OpenDirectory() method in dbus api docs https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.OpenURI was it dropped at some point?
[12:12] <mborzecki> heh, Ping was blocked by apparmor :/
[12:17] <mup> PR snapd#7950 closed: overlord/snapstate: tracks are now sticky <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7950>
[12:19] <pedronis> mvo: sorry, missing something, is there a bug related to it?
[12:20] <Chipaca> pedronis: yep (linked from there)
[12:20] <Chipaca> pedronis: https://bugs.launchpad.net/snappy/+bug/1857128
[12:21] <mup> Bug #1857128: Missing configuration option to allow a snap to openFile without prompting <Snappy:Confirmed> <https://launchpad.net/bugs/1857128>
[12:21] <pedronis> ok
[12:21] <pedronis> still doesn't feel like something we should add late to 2.43
[12:21] <pedronis> 2.43 is big enough at it is
[12:22]  * zyga goes afk
[12:22] <zyga> we managed to catch the cat
[12:22] <zyga> going to the vet to see if it is chipped
[12:22] <mup> PR snapd#7964 opened: tests/main/snap-sign: add test for non-stdin signing <Created by chipaca> <https://github.com/snapcore/snapd/pull/7964>
[12:27] <mup> PR snapd#7935 closed: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7935>
[12:30] <pedronis> Chipaca: I rebase and force pushed 7937 but your +1 didn't have any punctual comments so shouldn't be too much of a problem. I didn't change anything in the commits of that PR itself
[12:30] <Chipaca> tsk, tsk
[12:30] <Chipaca> :)
[12:30] <Chipaca> pedronis: I reviewed the delta, anyway
[12:47] <Chipaca> opensuse is a mystery to me -- https://forum.snapcraft.io/t/opensuse-snap-repository-missing-primary-xml-gz-file/14951
[12:48] <mborzecki> zyga: ^^ something you need to poke obs for?
[12:48] <mborzecki> zyga: though it'd expect the repo setup to be automatic
[12:49]  * Chipaca hunts for lunch
[12:50] <zyga> In a moment
[12:59] <pedronis> mborzecki: mvo: I made a review pass on #7947 with some suggestions
[13:00] <mup> PR #7947: boot/many: support new UC20 style kernel extraction <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7947>
[13:12] <zyga> Back home, I’ll be in the office in a minute
[13:14] <zyga> snapcraft.io is down?
[13:15] <zyga> or rather, the forum is down
[13:17] <roadmr> zyga: it's being worked on :)
[13:17] <roadmr> (yes it's down)
[13:17] <zyga> cool, thank you Daniel :)
[13:17] <roadmr> 👍
[13:55] <cachio> mvo, hey, do you know if the snapd.snap-repair.timer should be active in uc20?
[13:58] <mvo> pedronis: thanks
[13:58] <mvo> cachio: it should, sounds like a bug if it's not
[13:59] <cachio> mvo, good
[14:05] <mvo> cachio: I think I know what the issue is, will push a fix in a wee bit
[14:13] <zyga> niemeyer: hello
[14:13] <zyga> niemeyer: happy new year :)
[14:13] <zyga> niemeyer: could you please let me know when would be a good time to chat/call about the output of snap run --explain?
[14:13] <zyga> niemeyer: it doesn't have to be now, just wanted to plan something for the week
[14:32] <Chipaca> zyga: if you cat is chipped, call it 'fish'
[14:32] <zyga> Chipaca: I think after calling the dog Bit my wife will have some opinions on animal names :)
[14:32] <zyga> Chipaca: she was not happy about the name "edge"
[14:32] <zyga> as in "edges and nodes'
[14:32] <zyga> graphs and all that
[14:33] <degville> forum is back up.
[14:33] <Chipaca> zyga: cat is part of coreutils
[14:33] <Chipaca> zyga: jus' sayin'
[14:33] <ogra> you called the dog bit ? you should really have called it byte !
[14:33] <Chipaca> ogra: it's a really small dog
[14:34] <Chipaca> ogra: you need for of them to even nibble
[14:34] <zyga> yeah
[14:34] <zyga> *exactly* :D
[14:34] <zyga> brb, lunch and tea
[14:35] <ogra> even chihuahuas can cause bad ankles ;)
[14:38] <ogra> oh, the forum seems back \o/
[14:54] <mup> PR snapd#7952 closed: snap-bootstrap: trigger udev after filesystem creation <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7952>
[14:56] <vidal72[m]> I just saw wierd glitch: firefox suddenly got downgraded to 68esr, after snap refresh it went back to 71
[14:56] <vidal72[m]> fat finger at mozilla?
[14:58] <niemeyer> zyga: Heya
[14:58] <niemeyer> zyga: Tomorrow afternoon would be nice as there are plenty of meetings already
[14:58] <zyga> sounds great
[14:59] <zyga> at around 14:00 ?
[14:59] <zyga> I'll ping you in the afternoon to see when it will work perhaps
[15:00] <cachio> mvo, I see the state.json file does not contain the last-refresh-hints value
[15:00] <cachio> is it intentional?
[15:00] <mup> PR snapcraft#2740 closed: crystal plugin: add flags to use during shards build <Created by mamantoha> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2740>
[15:02]  * zyga goes for lunch
[15:10] <mvo> cachio: that's a good question - in uc20?
[15:10] <cachio> yes
[15:11] <mvo> cachio: hm, that should work, maybe something network related is not quite right, I did not expect this to break, interessting!
[15:11] <cachio> mvo, all the refreshes are failing btw
[15:13] <mvo> cachio: aha, interessting - anything in the logs that might give us a hint?
[15:16] <cachio> mvo, the only error I see is this https://paste.ubuntu.com/p/Rk4CfZdPpk/
[15:16] <sdhd-sascha> Chipaca: do i see that correctly? `snap prepare-image` has no option to for local kernel and/or gadget ?
[15:16] <cachio> I think refresh is not done when serial cannot be set
[15:17] <Chipaca> sdhd-sascha: --snap=....?
[15:18] <cachio> mvo, in that case it should automatically be fixed once we have the actual model, right?
[15:18] <pedronis> cachio: to be precise, if we cannot get a serial we will refresh but only after some tentatives
[15:18] <sdhd-sascha> Chipaca: thank you, i will try it later
[15:19] <Chipaca> sdhd-sascha: but in general 'snap prepare-image' isn't something you yourself call directly
[15:19] <cachio> pedronis, ah, ok, and is there any workaround for that?
[15:19] <pedronis> not really
[15:19] <pedronis> it's the expected behavior if the model doesn't let us get a serial
[15:19] <pedronis> in the future the latter will be easier
[15:19] <pedronis> but not atm
[15:20] <cachio> pedronis, ok, I'll skip those tests in that case
[15:20] <pedronis> cachio: you can set something in the state if you really want but not sure it's worth it or it
[15:20] <cachio> for uc20
[15:20] <sdhd-sascha> Chipaca: i have called it directly, like ubuntu-image it does. To see better understand
[15:20] <cachio> pedronis, do what?
[15:21] <cachio> set manually the time fot the refresh?
[15:22] <pedronis> no, actually is internal state of snapd
[15:22] <pedronis> at runtime
[15:22] <pedronis> so the only way would be a debug command
[15:22] <pedronis> a new debug command
[15:23] <sdhd-sascha> `snap prepare-image --channel=beta rock.model /tmp/tmpzojkf7e2/unpack`
[15:25] <cachio> pedronis, ah, ok, it is already implemented?
[15:25] <pedronis> no
[15:25] <cachio> pedronis, ok, np
[15:25] <pedronis> cachio: mvo: if we have a problems with the model we should fix it
[15:28] <mvo> pedronis: yeah, irrc we have no grade: dangerous official model and there was the question if we should have that or not
[15:29] <pedronis> mvo: for a while it sounded like we should have only a dangerous model, but then we went the other way around
[15:29] <pedronis> mvo: we probably need one though,  because even if we allow to set channels for signed models
[15:29] <pedronis> it still not enough for our tests I suppose
[15:30] <pedronis> I mean the spread tests
[15:30] <pedronis> mvo: something to talk about with foundations
[15:31]  * mvo nods
[15:35] <pedronis> mvo: but I'm missing something we use a self signed image also for core18
[15:35] <pedronis> what's the difference?
[15:35] <mvo> pedronis: I think we just ignore the registration errors in the spread test
[15:36]  * mvo is also in a meeting
[15:37] <pedronis> ah, no
[15:37] <pedronis> we use the real model
[15:45] <pedronis> (we just have a copy in-tree)
[16:07]  * cachio lunch
[16:12] <om26er> How to know if a snap name is already taken without a name registration attempt ?
[16:14] <zyga> om26er: hmm, I don't think there's a way
[16:15] <ogra> well, you can surely check if a snap has been uploaded under that name by simply searching the store ... but not if the name has been claimed without any uploaded package
[16:18] <om26er> yeah in some cases people just "claim" the name but never upload anything
[16:19] <ogra> right, in that case you can only try to claim it yourself and wait for the resolution i guess
[16:20] <ogra> note also that most .deb package names are auto-blocked without an actual person having claimed them
[16:20] <ogra> (to avoid peope from just grabbing such names)
[16:58] <mup> PR snapd#7964 closed: tests/main/snap-sign: add test for non-stdin signing <Simple 😃> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7964>
[16:58] <Chipaca> mvo: pstolowski: thanks for the reviews
[16:58] <pstolowski> yw
[16:59] <mvo> my pleasure
[17:10] <cachio> mvo, I see the permissions for the snaps on /var/lib/snapd/seed/snaps/ are 0700 instead of 0600
[17:10] <cachio> mvo, on uc20
[17:13] <zyga> one more test run
[17:13] <zyga> then commit, push and EOD
[17:13] <zyga> or maybe that and one more fixup to another PR
[17:13] <ijohnson> pedronis: I assume that #7939 is based on top of #7937, correct?
[17:13] <mup> PR #7939: boot,o/devicestate: refactor MarkBootSuccessful over bootState <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7939>
[17:13] <mup> PR #7937: boot,o/snapstate: SetNextBoot/LinkSnap return whether to reboot, use the information <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7937>
[17:15] <ijohnson> pedronis: 7937 has 2 +1's also shall I merge 7939 and then merge master into 7937? that would make the diff easier to review I think
[17:39] <zyga> this gid handling is such a rabbit hole
[17:39] <zyga> as soon as it passes I'll EOD, patches tomorrow
[17:39] <zyga> I need to split them,
[17:52]  * zyga gives up
[17:52] <zyga> ttyl
[18:00]  * Chipaca EODs
[18:10] <Facu> Hello! From any given snap, how can I tell which "start points" or "scripts" it installed? like, for example installing `foobar` but to run it I need to do `foo`
[18:11] <zyga> Facu: snap info --verbose foovar
[18:11] <zyga> it will tell you about the commands that are defined for that snap
[18:12] <zyga> Facu: you can also run "snap aliases" to see if any commands are aliased as other commands
[18:12] <Facu> zyga, under which title? I'm trying with `snap info --verbose mosaic`
[18:12] <zyga> Facu: some snaps come with aliases out of the box
[18:12] <zyga> Facu: look for "commands" in the output of snap info --verbose
[18:12] <Facu> zyga, and if no commands at all?
[18:13] <zyga> then you probably have not installed it
[18:13] <zyga> the output of info varies if the snap is installed or not
[18:13] <zyga> for me it printed: commands (newline) - mosaic
[18:13] <Facu> zyga, oh, thanks!
[18:13] <zyga> good luck :)
[18:13]  * zyga runs upstairs to do homework with kids
[18:23] <mup> PR snapd#7937 closed: boot,o/snapstate: SetNextBoot/LinkSnap return whether to reboot, use the information <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7937>
[18:24] <pedronis> #7939 is ready for review (I merged master into it)
[18:24] <mup> PR #7939: boot,o/devicestate: refactor MarkBootSuccessful over bootState <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7939>
[18:32] <ijohnson> thanks pedronis, will review this afternoon
[18:40] <mvo> cachio: aha, interessting, I wonder why this is
[18:40] <mvo> cachio: does the changed permissions make a test fail?
[18:42] <cachio> mvo, yes
[18:42] <cachio> mvo, install-sideload test
[18:43] <cachio> mvo, also something interesting is snap set core proxy.https=http://localhost:3128
[18:43] <cachio> error: cannot perform the following tasks:
[18:43] <cachio> - Run configure hook of "core" snap (run hook "configure": open /etc/environment: read-only file system)
[18:45] <mvo> cachio: aha, nice
[18:45] <cachio> I am writing all the findings in the standup doc
[18:45] <mvo> cachio: the /etc/environment sounds like a potentially low-hanging fruit
[18:45] <cachio> mvo, yes
[18:45] <mvo> cachio: the dir permission too, it's just a bit annoying to track down where it is set incorrectly :)
[18:45] <cachio> and it breaks more than 1 test
[18:58] <cachio> mvo, if you push a fix just tell me so I can merge it with my branch
[19:04] <mvo> cachio: cool, will probably look into it tomorrow
[19:05] <cachio> mvo, nice, thanks
[19:06] <mvo> cachio: thank you for all these findings!
[19:06] <cachio> mvo, yaw
[19:27] <mup> PR snapcraft#2853 opened: meta: do not set snapcraft-runner when adapter is "none" <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2853>
[19:30] <mup> PR snapcraft#2836 closed: meta: fix command-chain handling when Application adapter == "none" <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2836>
[20:10]  * ijohnson takes a break
[21:27] <mup> PR snapd#7965 opened: tests: enabling main and regression test suites for core20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7965>
[21:55] <mup> PR snapcraft#2850 closed: hooks: enable command-chain <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2850>
[22:16] <mup> PR snapcraft#2846 closed: base plugin: use shlex quoting for logged command in run() <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2846>
[23:17] <sdhd-sascha> Today I started to build my first snap command. I have copied the cmd_sign.go. Then I fell into shock-freeze. All definitions and functions of a command are visible in the complete main scope?! What if i misspell the Execute function, or something else?


[07:49] <PaulePanter> Hi. https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10-rc1/
[07:49] <PaulePanter> failed to build on x86{,_64}.
[07:50] <PaulePanter> Is the build error going to be fixed, and rebuild packages uploaded?
[12:42] <tjaalton> that build error is supposed to be fixed in 5.9
[12:42] <tjaalton> d5efc2e6b98fe661dbd8dd0d5d5bfb961728e57a
[15:49] <PaulePanter> tjaalton: Interesting. I am suprised that build errors happen despite all the kbuild bots out there.