[06:08] morning [06:08] starting a bit later, need to drive the kids to school [06:27] PR snapd#7954 closed: changelog: fix typos [06:35] PR snapd#7959 closed: tests: fix classic-ubuntu-core-transition-two-cores after refactor of MATCH -v [06:45] PR snapd#7962 opened: tests: cherry-pick fixes for snap-set-core-config/ubuntu-core-config-defaults-once [06:46] PR snapd#7949 closed: cmd/snap, daemon: stop over-normalising channels [07:07] good morning! [07:08] hey mvo [07:08] mvo: anything to keep in mind regarding yesterday? [07:09] re [07:09] hey mborzecki :) [07:09] one kid at school, the other sick at home [07:09] hey zyga, good morning [07:09] zyga: mvo: hey [07:09] mborzecki: two at school, one still sleeping [07:09] mborzecki: good morning and happy new year [07:09] zyga: yesterday> nay, all good [07:09] mvo: happy new year to you too! that was a looong break [07:10] mborzecki: yeah, long and refreshing I hope :) [07:10] (it was for me!) [07:11] I must admit that after about a week of anxiety I really started resting [07:11] and ended up not touching coding for most of the time [07:18] mvo: thanks for uploading release tarballs to github releases! [07:19] mborzecki: my pleasure, sorry that I was a bit late [07:37] updated arch package to 2.42.5 [07:38] 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] PR snapd#7955 closed: tests: remove "test-snapd-tools" in smoke/sandbox on restore [08:02] morning [08:02] hey pawel [08:02] hey pstolowski ! [08:02] hey hey [08:05] pstolowski: hey [08:11] a quick sanity-check of 7951 and 7962 would be nice, pedning 2.43 PRs [08:15] mvo: there is one file less in 7951 than it was in the original PR, not sure if it's intentional? [08:17] pstolowski: let me look to refresh my memories, it might be that this file is not in 2.43 yet [08:18] mvo, hey, happy new year! I have been told that snapd does not yet support default tracks, when will that happen? [08:20] re [08:20] abeato: it's very close to land in edge, chipaca is landing PRs as we speak [08:20] 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] mvo, awesome! mind pointing me to the MPs? [08:21] 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] mvo: tests/main/parallel-install-remove-after/task.yaml missing in 7951 if that helps [08:21] abeato: sure, one sec [08:22] pstolowski: I just checked, it seems like this test does not yet exist in 2.43 [08:22] mvo: good [08:23] abeato: https://github.com/snapcore/snapd/pull/7950 and there is one more needed AIUI [08:23] PR #7950: overlord/snapstate: tracks are now sticky [08:24] mvo, thanks - and no, not critical for the moment, but we plan to use the feature from some snaps when available [08:24] s/from/for/ [08:33] abeato: ack [08:34] PR snapd#7951 closed: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 (2.43) [09:10] I think https://forum.snapcraft.io/t/snap-layouts/7207/37?u=zyga should be split into a separate thread [09:10] it's less about layouts and more about troubleshooting snapcraft and containers [09:13] mvo: do you think there is any interest in adopting the Github action I wrote as an official project? [09:14] zyga: I can do that [09:14] zyga: tell me what to do tho :-) [09:14] thank you Chipaca :) [09:14] zyga: is it all following? [09:14] Chipaca: split it after the first message where the reporter is debugging snapcraft [09:14] I think so [09:14] based on my quick reading [09:14] zyga: ok. SUggestions for title of the new thread? [09:14] hmmm [09:15] Building with snapcraft in docker? [09:15] brb [09:15] I was about to go upstairs for tea [09:16] upstairs-tea sounds fancy [09:17] jamesh: in a meeting right now, I will get back to you. do you have a link with more information? [09:17] zyga: https://forum.snapcraft.io/t/building-with-snapcraft-in-docker/14946 [09:17] mvo: https://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/14930 [09:18] Chipaca: thank you :) [09:18] jamesh: hey, happy new year :) [09:18] hi zyga [09:18] jamesh: that's probably more a sergiusens Q than an mvo Q [09:18] jamesh: unless mvo is becoming our über-manager [09:18] * Chipaca mangles languages for fun and/or profit [09:19] Chipaca: we have a cat now [09:19] Chipaca: I wasn't quite sure who was in charge of projects under the "snapcore" org [09:19] Chipaca: it wandered in when it was cold and doesn't want to leave [09:19] jamesh: it might still be our CTO [09:19] zyga: we have developers like that also [09:19] hahaha [09:21] jamesh: in any case mvo is in a better place to help than I am :-) [09:21] also he's awake, which is an advantage over sergiusens [09:22] (sergiusens might be technically awake but given it's 6am for him, I wouldn't trust it) [09:53] sdhd-sascha: duuude [09:53] sdhd-sascha: what do you mean they are not optional [09:53] sdhd-sascha: I'm telling you they are optional [09:53] I'm not asking :) [09:54] sdhd-sascha: most people don't even know 'list' can take positional arguments [09:54] Chipaca: oh, sorry. Good morning ;-) [09:54] sdhd-sascha: non-required is the default [09:56] 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] sdhd-sascha: https://godoc.org/github.com/jessevdk/go-flags [09:56] sdhd-sascha: it sounds like you're digging too deep for what you're wanting to do [09:57] which is alright, if you intend to learn a lot from it [09:57] 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] 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] 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] heh [10:04] sdhd-sascha: BTW, don't make it a string [10:04] use a flags.Filename [10:10] jamesh: back from the meeting, reading your post now, I need to check if I have enough privs to enable github actions [10:11] 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] jamesh: flashbacks of jhbuild [10:13] Chipaca: jhbuild was hosted in a CVS repo that any GNOME dev could commit to [10:14] jamesh: I meant about having your name immortalised in the build recipes :) [10:14] the way those things are cargo-culted, it's never going away :D [10:15] 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] agreed, i think snapcore would be a better place [10:17] jamesh: mvo: FWIW I can create the repository if there's agreement (mvo can also do so) [10:17] mborzecki: help me out [10:17] jamesh: you might be able to too, dunno [10:17] mborzecki: I just don't get it and I must be missing something utterly obvious [10:17] jamesh: https://github.com/organizations/snapcore/repositories/new [10:17] zyga: hmm? [10:17] mborzecki: I have a .c file that uses O_PATH, I defined _GNU_SOURCE, I included the required files [10:17] yet it's not defined [10:18] what could I be missing? [10:18] Chipaca: I don't have that permission, and if I did I wouldn't want to use it unilaterally [10:19] jamesh: with you on that [10:19] zyga: defined _GNU_SOURCE too late? canyou pass it to gcc -D_GNU_SOURCE? [10:19] it's on the first line in the .c file [10:20] zyga: mborzecki: what's O_PATH got to do with _GNU_SOURCE? [10:20] Chipaca: you have to get it to get the other [10:20] Chipaca: it's a linux thing [10:20] Chipaca: so the headers don't give it unless you ask for it [10:20] Chipaca: manpage says _GNU_SOURCE must be defined for O_PATH [10:21] ah [10:22] zyga: how are you defining it? [10:22] If you're building with e.g. -std=c18, it disables some non-standard features from headers by default [10:22] Chipaca: I tried #define _GNU_SOURCE in the 1st line in .c [10:22] unless you define _GNU_SOURCE [10:22] Chipaca: tried -D_GNU_SOURCE just now [10:22] it's odd [10:22] with -D_GNU_SOURCE it compiles [10:23] with this and the #define it says it's already defined [10:23] but without -D_GNU_SOURCE it doesn't define O_PATH [10:23] what am I missing: [10:23] * zyga rechecks [10:23] zyga: did you read what james said? [10:24] Chipaca: yeah but I do define it, that's the point [10:24] Chipaca: I'm not building with std=c18 [10:24] zyga: fwiw both work here (on 16.04) [10:24] and it finds it in other .c files [10:24] * zyga must be missing something [10:24] I'm using it in every other file we have [10:26] doh [10:26] I get it [10:26] I misread [10:26] thanks guys! [10:26] zyga: maybe you wrote Ο_ΡАΤН instead of O_PATH [10:26] it's -test.c that combines .c and .h that didn't work [10:26] the .c file built fine [10:26] heh [10:27] zyga: (that was omicron, under, rho, cyrillic a, tau, cyrillic en) [10:27] hahaha [10:27] nice [10:27] I'm happy C is so old-school [10:29] modern C supports unicode identifiers [10:31] jamesh: we are doomed then ;) [10:32] zyga: but now you can have O_Pᴀᴛʜ! [10:33] using small caps makes your code less shouty [10:33] 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] zyga: and D_𝔇𝔢𝔭𝔯𝔢𝔠𝔞𝔱𝔢𝔡 [10:34] zyga: I'd be very disappointed if that didn't exist already [10:35] like brainfuck but with colours [10:35] Chipaca: cc -nyan [10:35] * zyga gets back to work [10:36] the standard lists particular code point ranges, so probably no ANSI escapes [10:37] PR snapd#7963 opened: xdgopenproxy: forward requests to the desktop portal [10:37] jamesh: hi, can you take a look ^^ ? [10:37] mborzecki: sure! [10:37] I was about to say the same [10:37] interesting [10:37] I didn't know the portal handled URLs [10:37] jamesh: thanks! [10:37] but if so let's use it :) [10:38] mborzecki: it's actually something I had on my todo list to investigate, so I'm very interested [10:38] zyga: yeah, we can move all bugs to the portals package then :P [10:38] at least the list will be consistent [10:38] mborzecki: very cool stuff [10:39] duh, forgot to add fixes: https://bugs.launchpad.net/snappy/+bug/1857128 in the commit message [10:39] Bug #1857128: Missing configuration option to allow a snap to openFile without prompting [10:50] can someone on fedora quickly check if "brave" installs/runs ? context is bug 1759219 [10:50] Bug #1759219: Brave browser fails to launch on fedora [10:55] mvo: checking [10:55] mvo: last time I tried it did not but even firefox has issues [10:56] it's brave, but not brave enough for fedora [10:56] * Chipaca hides [10:58] mvo: it actually runs [10:59] I opened it from a terminal with "snap run brave" [10:59] zyga: nice [10:59] mvo: on x86_64 fedora 31 [10:59] zyga: I guess we can close this bug then :) [10:59] mvo: I read some reports that indicate it may be different via launcher [10:59] one sec [10:59] let me try that [11:00] mvo: that also worked [11:00] I logged out to be sure [11:00] so ... yeah [11:00] close it [11:00] WFM on [11:00] snapd 2.42.2 [11:00] brb, I need a short break [11:10] 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] mvo, hi, yes I am checking that [11:11] yesterday I was tryin to make that work but I couldn't [11:11] mvo, thanks for the fix [11:12] cachio: yeah, sorry for that, it was complicated :/ the pc gadget changed and part of the snapd code needed an update [11:13] mvo, yes, I supposed that was something else that changed asn was affecting the uc20 boot [11:13] I'll continue enabling tests now [11:13] cachio: \o/ thank you [11:14] cachio: if you could review the updated 7943, that would be great [11:15] mvo, sure [11:16] 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] ^- (cc mborzecki ) [11:39] #7961 could use a second +1 (and then I'll push tests as a separate PR) [11:39] PR #7961: cmd: sign: add filename param [12:02] PR snapd#7961 closed: cmd: sign: add filename param [12:03] mvo: tks [12:03] Chipaca: thank you! [12:04] jamesh: thanks for the feedback, i'm runnig the spread test now [12:04] maybe we should thank sdhd-sascha also :-D [12:04] * mvo hugs sdhd-sascha [12:04] tests coming up (re-running them locally just to make sure) [12:04] Chipaca: and i have thank you too [12:05] 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] heh, Ping was blocked by apparmor :/ [12:17] PR snapd#7950 closed: overlord/snapstate: tracks are now sticky [12:19] mvo: sorry, missing something, is there a bug related to it? [12:20] pedronis: yep (linked from there) [12:20] pedronis: https://bugs.launchpad.net/snappy/+bug/1857128 [12:21] Bug #1857128: Missing configuration option to allow a snap to openFile without prompting [12:21] ok [12:21] still doesn't feel like something we should add late to 2.43 [12:21] 2.43 is big enough at it is [12:22] * zyga goes afk [12:22] we managed to catch the cat [12:22] going to the vet to see if it is chipped [12:22] PR snapd#7964 opened: tests/main/snap-sign: add test for non-stdin signing [12:27] PR snapd#7935 closed: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot [12:30] 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] tsk, tsk [12:30] :) [12:30] pedronis: I reviewed the delta, anyway === ricab is now known as ricab|lunch [12:47] opensuse is a mystery to me -- https://forum.snapcraft.io/t/opensuse-snap-repository-missing-primary-xml-gz-file/14951 [12:48] zyga: ^^ something you need to poke obs for? [12:48] zyga: though it'd expect the repo setup to be automatic [12:49] * Chipaca hunts for lunch [12:50] In a moment [12:59] mborzecki: mvo: I made a review pass on #7947 with some suggestions [13:00] PR #7947: boot/many: support new UC20 style kernel extraction [13:12] Back home, I’ll be in the office in a minute [13:14] snapcraft.io is down? [13:15] or rather, the forum is down [13:17] zyga: it's being worked on :) [13:17] (yes it's down) [13:17] cool, thank you Daniel :) [13:17] 👍 [13:55] mvo, hey, do you know if the snapd.snap-repair.timer should be active in uc20? [13:58] pedronis: thanks [13:58] cachio: it should, sounds like a bug if it's not [13:59] mvo, good [14:05] cachio: I think I know what the issue is, will push a fix in a wee bit === ricab|lunch is now known as ricab [14:13] niemeyer: hello [14:13] niemeyer: happy new year :) [14:13] 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] niemeyer: it doesn't have to be now, just wanted to plan something for the week [14:32] zyga: if you cat is chipped, call it 'fish' [14:32] Chipaca: I think after calling the dog Bit my wife will have some opinions on animal names :) [14:32] Chipaca: she was not happy about the name "edge" [14:32] as in "edges and nodes' [14:32] graphs and all that [14:33] forum is back up. [14:33] zyga: cat is part of coreutils [14:33] zyga: jus' sayin' [14:33] you called the dog bit ? you should really have called it byte ! [14:33] ogra: it's a really small dog [14:34] ogra: you need for of them to even nibble [14:34] yeah [14:34] *exactly* :D [14:34] brb, lunch and tea [14:35] even chihuahuas can cause bad ankles ;) [14:38] oh, the forum seems back \o/ [14:54] PR snapd#7952 closed: snap-bootstrap: trigger udev after filesystem creation [14:56] I just saw wierd glitch: firefox suddenly got downgraded to 68esr, after snap refresh it went back to 71 [14:56] fat finger at mozilla? [14:58] zyga: Heya [14:58] zyga: Tomorrow afternoon would be nice as there are plenty of meetings already [14:58] sounds great [14:59] at around 14:00 ? [14:59] I'll ping you in the afternoon to see when it will work perhaps [15:00] mvo, I see the state.json file does not contain the last-refresh-hints value [15:00] is it intentional? [15:00] PR snapcraft#2740 closed: crystal plugin: add flags to use during shards build [15:02] * zyga goes for lunch [15:10] cachio: that's a good question - in uc20? [15:10] yes [15:11] cachio: hm, that should work, maybe something network related is not quite right, I did not expect this to break, interessting! [15:11] mvo, all the refreshes are failing btw [15:13] cachio: aha, interessting - anything in the logs that might give us a hint? [15:16] mvo, the only error I see is this https://paste.ubuntu.com/p/Rk4CfZdPpk/ [15:16] Chipaca: do i see that correctly? `snap prepare-image` has no option to for local kernel and/or gadget ? [15:16] I think refresh is not done when serial cannot be set [15:17] sdhd-sascha: --snap=....? [15:18] mvo, in that case it should automatically be fixed once we have the actual model, right? [15:18] cachio: to be precise, if we cannot get a serial we will refresh but only after some tentatives [15:18] Chipaca: thank you, i will try it later [15:19] sdhd-sascha: but in general 'snap prepare-image' isn't something you yourself call directly [15:19] pedronis, ah, ok, and is there any workaround for that? [15:19] not really [15:19] it's the expected behavior if the model doesn't let us get a serial [15:19] in the future the latter will be easier [15:19] but not atm [15:20] pedronis, ok, I'll skip those tests in that case [15:20] cachio: you can set something in the state if you really want but not sure it's worth it or it [15:20] for uc20 [15:20] Chipaca: i have called it directly, like ubuntu-image it does. To see better understand [15:20] pedronis, do what? [15:21] set manually the time fot the refresh? [15:22] no, actually is internal state of snapd [15:22] at runtime [15:22] so the only way would be a debug command [15:22] a new debug command [15:23] `snap prepare-image --channel=beta rock.model /tmp/tmpzojkf7e2/unpack` [15:25] pedronis, ah, ok, it is already implemented? [15:25] no [15:25] pedronis, ok, np [15:25] cachio: mvo: if we have a problems with the model we should fix it [15:28] pedronis: yeah, irrc we have no grade: dangerous official model and there was the question if we should have that or not [15:29] mvo: for a while it sounded like we should have only a dangerous model, but then we went the other way around [15:29] mvo: we probably need one though, because even if we allow to set channels for signed models [15:29] it still not enough for our tests I suppose [15:30] I mean the spread tests [15:30] mvo: something to talk about with foundations [15:31] * mvo nods [15:35] mvo: but I'm missing something we use a self signed image also for core18 [15:35] what's the difference? [15:35] pedronis: I think we just ignore the registration errors in the spread test [15:36] * mvo is also in a meeting [15:37] ah, no [15:37] we use the real model [15:45] (we just have a copy in-tree) [16:07] * cachio lunch [16:12] How to know if a snap name is already taken without a name registration attempt ? [16:14] om26er: hmm, I don't think there's a way [16:15] 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] yeah in some cases people just "claim" the name but never upload anything [16:19] right, in that case you can only try to claim it yourself and wait for the resolution i guess [16:20] note also that most .deb package names are auto-blocked without an actual person having claimed them [16:20] (to avoid peope from just grabbing such names) [16:58] PR snapd#7964 closed: tests/main/snap-sign: add test for non-stdin signing [16:58] mvo: pstolowski: thanks for the reviews [16:58] yw [16:59] my pleasure [17:10]