16:31:05 <dustymabe> #startmeeting fedora_coreos_meeting
16:31:05 <zodbot> Meeting started Wed Feb  1 16:31:05 2023 UTC.
16:31:05 <zodbot> This meeting is logged and archived in a public location.
16:31:05 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:31:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:31:05 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:31:10 <dustymabe> #topic roll call
16:31:12 <dustymabe> .hi
16:31:13 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:22 <dustymabe> aaradhak anthr76 davdunc dustymabe gursewak jaimelm jbrooks jcajka jdoss jlebon jmarrero lorbus miabbott nasirhm ravanelli saqali skunkerk walters
16:31:25 <dustymabe> FCOS community meeting in #fedora-meeting-1
16:31:27 <dustymabe> If you don't want to be pinged remove your name from this file: https://github.com/coreos/fedora-coreos-tracker/blob/main/meeting-people.txt
16:31:37 <aaradhak[m]> .hi
16:31:38 <zodbot> aaradhak[m]: Sorry, but user 'aaradhak [m]' does not exist
16:32:20 <aaradhak> .hi
16:32:21 <zodbot> aaradhak: aaradhak 'Aashish Radhakrishnan' <aaradhak@redhat.com>
16:33:02 <jlebon> .hello2
16:33:03 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:33:18 <jmarrero> .hi
16:33:20 <zodbot> jmarrero: jmarrero 'Joseph Marrero' <jmarrero@redhat.com>
16:33:31 <marmijo[m]> .hi marmijo@redhat.com
16:33:32 <zodbot> marmijo[m]: Sorry, but user 'marmijo [m]' does not exist
16:33:42 <dustymabe> #chair aaradhak jlebon jmarrero marmijo[m]
16:33:42 <zodbot> Current chairs: aaradhak dustymabe jlebon jmarrero marmijo[m]
16:34:14 <spresti[m]> .hello spresti
16:34:15 <zodbot> spresti[m]: spresti 'Steven Presti' <spresti@redhat.com>
16:34:29 <dustymabe> #chair spresti[m]
16:34:29 <zodbot> Current chairs: aaradhak dustymabe jlebon jmarrero marmijo[m] spresti[m]
16:34:58 <dustymabe> will wait a few more minutes and then get started
16:36:06 <dustymabe> #topic Action items from last meeting
16:36:20 <dustymabe> We had two action items from last meeting: https://meetbot-raw.fedoraproject.org/teams/fedora_coreos_meeting/fedora_coreos_meeting.2023-01-25-16.31.txt
16:36:31 <dustymabe> * jmarrero to discuss option 2. (oportunistically pruning older deployments if low on space) with his team and get back to us
16:36:33 <dustymabe> * dustymabe to verify that booting a compressed kernel on ppc64le works
16:37:29 <dustymabe> I'm going to re-action mine - i had good intentions but the data loss in the ostree repo over the weekend took up some of my cycles
16:37:37 <dustymabe> #action dustymabe to verify that booting a compressed kernel on ppc64le works
16:37:41 <jmarrero> For my action item, I had a quick chat with Colin about it. Added comment: https://github.com/coreos/fedora-coreos-tracker/issues/1247#issuecomment-1412327065
16:38:43 <jbrooks> .hello jasonbrooks
16:38:44 <dustymabe> thanks jmarrero
16:38:45 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:38:49 <dustymabe> #chair jbrooks
16:38:49 <zodbot> Current chairs: aaradhak dustymabe jbrooks jlebon jmarrero marmijo[m] spresti[m]
16:39:40 <dustymabe> ok moving on
16:40:09 <dustymabe> we have the audit ticket (https://github.com/coreos/fedora-coreos-tracker/issues/1362) but I think travier wants to be here for that so we can push it to next week
16:40:37 <dustymabe> let's go over some recent change proposals for Fedora 38
16:40:55 <dustymabe> #topic tracker: Fedora 38 changes considerations
16:41:00 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1357
16:41:28 <dustymabe> there are new items for us to consider
16:41:41 <dustymabe> and also a few comments from timothee so we'll go over those too
16:41:57 <dustymabe> subtopic 116. Golang 1.20
16:42:55 <jlebon> i think for go bumps, we just need to make sure we have CI added in upstream go projects
16:43:40 <dustymabe> jlebon: like before we switch them to the next major Fedora version?
16:43:57 <dustymabe> our rebase tracker has steps for making sure the subprojects get updated
16:44:37 <dustymabe> but you mean like CI that can test against multiple go versions at once?
16:44:48 <jlebon> dustymabe: yeah, the latter
16:45:25 <jlebon> just so there are no surprises when the bump happens in the buildroot
16:45:34 <dustymabe> got ya - how do we make sure that happens? or will it happen naturally for each project?
16:46:15 <dustymabe> there are a few that should happen naturally for
16:46:29 <dustymabe> i.e. coreos-installer gets built in `rawhide` today and 1.20 will land there first?
16:46:31 <jlebon> dustymabe: maybe let's chat with bgilbert and see if he wants an issue to track it for some of the projects
16:46:47 <dustymabe> and we test rawhide, so should be covered
16:46:58 <dustymabe> jlebon: SGTM
16:47:24 <dustymabe> #action jlebon/dustymabe to ask bgilbert if we should create some process for testing newer versions of golang early for our various projects that use it
16:48:07 <dustymabe> #info for golang 1.20 we don't foresee any problems, but we should pro-actively test before hand to make sure there are no surprises
16:48:20 <dustymabe> look good ^^?
16:48:54 <dustymabe> subtopic 117. GNU Make version 4.4
16:49:36 <jlebon> LGTM
16:50:02 <jmarrero> lgtm too
16:50:04 <jlebon> safe to skip, i think
16:50:28 <dustymabe> there are some backwards incompatible changes: https://fedoraproject.org/wiki/Changes/MAKE44#Upgrade/compatibility_impact
16:51:02 <jlebon> wow, surprising for a minor bump
16:51:02 <dustymabe> #info we think this should be a transparent update for us
16:51:43 <dustymabe> subtopic 119. Add _FORTIFY_SOURCE=3 to distribution build flags
16:52:21 <dustymabe> #info this should be transparent to us. If any problems arise it should happen at rpm build time.
16:52:29 <dustymabe> ^^ check me on accuracy there
16:52:36 <jlebon> agreed
16:52:42 <jmarrero> +1
16:52:54 <dustymabe> subtopic 120. Perl: Replace versioned MODULE_COMPAT_ requires by RPM dependency generator
16:53:10 <dustymabe> #info we don't ship perl
16:53:20 <dustymabe> subtopic 121. Add -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer to default compilation flags
16:54:19 <jlebon> should be transparent
16:54:36 <dustymabe> #info should be transparent to us, no changes for us to make
16:54:42 <dustymabe> subtopic 122. Noto Fonts For More Languages
16:55:29 <dustymabe> do we even ship multi-language support?
16:55:49 <dustymabe> i guess that depends on the rpm and like for example what error messages it generates?
16:56:08 <dustymabe> (in a CLI context)
16:56:36 <jlebon> we don't even ship fonts, so i think we can skip that
16:56:48 <dustymabe> #info we don't ship fonts, this won't apply to us
16:56:53 <dustymabe> subtopic 123. Shorter Shutdown Timer
16:57:50 <jlebon> i think this may impact us if we're not setting a more generous timeout today than needed
16:57:55 <jlebon> for any service we ship
16:58:24 <jlebon> ideally if that happens, it's a CI failure and we fix it by either fixing code or adding a longer timeout
16:58:57 <jlebon> the only thing that comes to mind right now is the ostree-finalize-staged.service, but that one already has an explicit timeout
16:59:08 <dustymabe> hmm. I definitely think this is more geared towards people with laptops
16:59:45 <dustymabe> travier: added a comment in https://github.com/coreos/fedora-coreos-tracker/issues/1357#issuecomment-1406409322
17:01:24 <dustymabe> so I guess we get to decide how we want to handle things now
17:01:43 <dustymabe> maybe we agree here to open a new issue to later discuss what our path forward here is
17:01:48 <jlebon> ahh nice. the proposal doesn't make it clear the variant-specific aspect
17:02:08 <jlebon> so yeah, we have to decide if to override the new default to keep the old behaviour or not
17:02:11 <jlebon> SGTM
17:02:55 <spresti[m]> SGTM
17:03:06 <dustymabe> #action dustymabe create a new ticket for us to decide how we want to handle the shutdown timeout change
17:03:30 <dustymabe> #info we will need to consider the shutdown timeout change and if we want to accept it or add our own configuration override.
17:03:37 <dustymabe> subtopic 124. GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1)
17:04:51 <dustymabe> any thoughts on this one?
17:05:47 <dustymabe> "The compiler, the static linker and the the library are backwards compatible with the previous version of Fedora."
17:06:13 <jlebon> should be transparent
17:06:27 <spresti[m]> Non from my side; how has this tool chain upgrade gone in the past?
17:06:41 <dustymabe> #info this change should be picked up by us transparently; no active changes for us to make
17:07:05 <dustymabe> spresti[m]: usually rpms get built with the new buildchain and then we pick those up
17:07:20 <dustymabe> the only question is if there are changes we think we need to make to the rpms that we own for these changes
17:07:31 <dustymabe> usually it manifests itself as a build failure that we then have to look into
17:07:37 <dustymabe> subtopic 125. Rpmautospec by Default
17:07:52 <spresti[m]> +1 ty
17:08:26 <dustymabe> "This change is targeted at Fedora 38, but it will actually apply to all releases. The goal is to update the Packaging Guidelines and other prominent documentation and tools now, and other docs and tools possibly at a later time. Changing packages is out of scope. "
17:08:42 <dustymabe> so basically update the guidance/docs, but not existing packages for now
17:08:59 <jlebon> nice
17:09:30 <dustymabe> if you actively develop a package maybe consider trying out one or both of `%autorelease`/`%autochangelog`]
17:09:41 <dustymabe> I tried out `%autochangelog` recently and it was nice
17:10:14 <dustymabe> #info nothing for FCOS to do specifically but the maintainers of the packages we own may choose to update
17:10:21 <jlebon> i should look at that for rpm-ostree. we store the spec file upstream and then do a "merge" with the changelogs in dist-git, so i think this would be a good fit
17:10:51 <dustymabe> subtopic 126. Unfiltered Flathub
17:11:02 <dustymabe> #info we don't ship flatpak; no change for us
17:11:29 <dustymabe> subtopic 220. libpinyin 2.8
17:12:35 <dustymabe> #info we don't ship libpinyin
17:12:41 <dustymabe> subtopic 221. Fedora Sway Spin
17:12:57 <dustymabe> #info this is another variant of Fedora
17:13:02 <dustymabe> subtopic 222. Upgrade ImageMagick to version 7
17:13:07 <dustymabe> #info we don't ship imagemagick
17:13:10 <dustymabe> subtopic 223. Fedora Budgie Spin
17:13:13 <dustymabe> #info this is another variant of Fedora
17:13:22 <dustymabe> subtopic 224. Use mdadm for BIOS RAID Support in Anaconda
17:13:53 <dustymabe> "
17:13:56 <dustymabe> Use mdadm instead of dmraid to support BIOS RAID (Firmware RAID or Fake RAID) during the Fedora installation process.
17:13:58 <dustymabe> "
17:14:35 <dustymabe> interesting.. I feel like I need to learn about BIOS/Firmware/Fake RAID
17:14:58 <dustymabe> anybody familiar?
17:15:35 <jlebon> i think our grub config is "raid" aware already
17:16:07 <jlebon> https://github.com/coreos/coreos-assembler/blob/9fa3aaf93e44a53a4f5b27f15316a73e632b1abf/src/grub.cfg#L3
17:16:28 <dustymabe> reading more into it - looks like a hardware feature (i.e. not software RAID)?
17:17:09 <jlebon> probably worth having bgilbert look at it and see if there's something our RAID setup should learn from too
17:17:20 <dustymabe> #info This change is specific to anaconda.
17:17:25 <dustymabe> still ^^
17:17:31 <dustymabe> assuming we don't use dmraid anywhere
17:18:09 <dustymabe> subtopic 225. Pyramid 2.0
17:18:32 <dustymabe> #info we don't ship python-pyramid
17:18:48 <dustymabe> subtopic 226. Xfce-4.18
17:18:55 <dustymabe> #info this is another variant of Fedora
17:18:55 <jlebon> i think all of the remaining ones can be "#info we don't ship this package"
17:19:02 <dustymabe> cool
17:19:31 <jlebon> i noticed you skipped over 118, was that on purpose?
17:20:11 <dustymabe> subtopic 227. FPC repackaging
17:20:14 <dustymabe> #info we don't ship this package
17:20:16 <dustymabe> subtopic 228. TeXLive2022
17:20:18 <dustymabe> #info we don't ship this package
17:20:20 <dustymabe> subtopic 229. Noto CJK Variable Fonts
17:20:22 <dustymabe> #info we don't ship this package
17:20:24 <dustymabe> subtopic 230. IPP-USB as a weak dependency of CUPS and sane-airscan
17:20:26 <dustymabe> #info we don't ship this package
17:20:28 <dustymabe> jlebon: nope :) - I just missed it
17:20:37 <dustymabe> subtopic 118. Restore stricter SSH hostkeys permissions
17:21:13 <dustymabe> we've already dealt with some fallout from this in rawhide
17:21:35 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/1391
17:21:45 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/1394
17:22:24 <dustymabe> #info we need to make some changes to allow suid ssh-keygen and also migrate existing permissions on host keys for upgrading systems
17:22:36 <dustymabe> anything else?
17:23:26 <jlebon> i commented https://src.fedoraproject.org/rpms/openssh/pull-request/39#comment-129094 which i think would alleviate some of the pressure
17:24:30 <dustymabe> jlebon: yeah, probably a conversation worth having
17:24:47 <dustymabe> but how would we notify people to update?
17:25:35 <dustymabe> we (FCOS) could use CLHM
17:25:57 <dustymabe> or ssh themselves could put in a sleep on startup (sleep 5m and then let people in)
17:26:00 <jlebon> we still need the service to migrate, but at least if something goes wrong, users will still be able to ssh into the system
17:26:06 <dustymabe> they would possibly notice and then rectify the issue
17:26:21 <dustymabe> right, but the problem is, when do you hard cutoff?
17:26:38 <dustymabe> i.e. what's the difference between doing a hard cutoff now or later
17:26:50 <dustymabe> there must be some extra step to take to notify the user they need to make a change
17:27:24 <dustymabe> of course this migration script only handles ssh keys of a known name in a known location
17:27:26 <jlebon> yeah, we can discuss that in the issue with the maintainers maybe. need to make sure my understanding of the situation is right first
17:27:40 <dustymabe> i wonder if the name/location is configurable (in sshd config)
17:28:12 <jlebon> maybe instead of carrying the patch as is, SSH still warns but doesn't hard error
17:28:18 <dustymabe> I like the idea of a long sleep if the system is found to be in the state where the known host keys are non-compliant
17:28:55 <dustymabe> jlebon: do you mind carrying some of our feedback upstream?
17:29:16 <jlebon> dustymabe: ack
17:29:29 <dustymabe> #topic open floor
17:29:42 <dustymabe> ok - sorry that wasn't a very fun meeting
17:29:52 <dustymabe> but productive!
17:30:00 <dustymabe> anyone with any topics for open floor ?
17:30:40 <dustymabe> #info the splash page revamp has had some further edits/suggestions: https://discussion.fedoraproject.org/t/44632/18
17:30:44 <dustymabe> WDYT?
17:32:46 <jlebon> looks neat. i'm still getting used to the 3d look personally :)
17:32:49 <dustymabe> forgot to action this before
17:33:25 <dustymabe> #action jlebon to take our concerns about host key permission migration script failure to sshd package maintainer
17:33:35 <dustymabe> I like the latest iteration
17:34:00 * dustymabe will close out the meeting soon unless new discussion commences
17:34:23 <darknao> hi there :) FYI there is an update the download page that you can see here: https://fedora.gitlab.io/websites-apps/fedora-websites/fedora-websites-3.0/coreos/download/
17:34:32 <darknao> on*
17:35:14 <darknao> not everything from last feedbacks has been implemented yet
17:35:19 <jlebon> darknao: thanks!
17:35:21 <darknao> but we're working on it
17:35:29 <dustymabe> darknao: thanks
17:35:42 <darknao> also make sure to try both light/dark theme if you can
17:35:56 <dustymabe> darknao: one thing that is important to us that isn't necessarily conveyed well enough
17:36:12 <dustymabe> was this bit of feedback: `- Stream metadata querying at page load time`
17:36:27 <darknao> this is already implemented
17:36:28 <jlebon> darknao: the white on gray of the fedora logo is a bit hard to read
17:36:29 <spresti[m]> Sorry for delay. dustymabe:  yeah I like it a lot more then in the past. jlebon  yeah meee to on the 3d. Though I think it looks good.
17:36:33 <dustymabe> darknao: oh, nice
17:36:36 <darknao> the metadata are currently loaded client side
17:36:41 <jlebon> darknao: awesome
17:36:57 <jlebon> that change has real releng consequences :)
17:37:06 <darknao> the white logo is a known issue, we need to change that :)
17:37:11 <jlebon> +1
17:37:24 <darknao> I have one question regarding the GCP thing
17:37:31 <dustymabe> darknao: go for it
17:37:56 <darknao> you were talking about the gcp family right, like "fedora-coreos-stable"?
17:38:20 <darknao> does that need to be shown upfront, or can it be inside a tooltip for instance?
17:38:35 <dustymabe> yes, the gcp image family
17:38:53 <dustymabe> what is a tooltip? is it hover text?
17:39:27 <darknao> I'm trying to make that part as generic as possible in case you decide to add more cloud provider here in the future, we don't really want to rework the website everytime :)
17:40:16 <dustymabe> darknao: I understand.
17:40:18 <darknao> yes a hover text, or maybe just write it the same way as the image type on the other download
17:40:51 <dustymabe> hover text might not be the best because the user may want to copy/paste the text
17:41:02 <dustymabe> could we just expand that one bar if someone clicks on it
17:41:06 <darknao> so at the same place as the 'vmdk.xz' for instance, but with the image familly
17:42:02 <darknao> ok so add something like 'show details' that expand and show all the required info on a second line?
17:42:06 <dustymabe> in the same place as the vmdk.xz - might not be enough room there
17:42:20 <dustymabe> right now the details say: "The current latest image in the fedora-coreos-stable image family is fedora-coreos-37-20230110-3-1-gcp-x86-64"
17:42:37 <dustymabe> we could probably cut that down a bit
17:43:04 <dustymabe> but I think it gets crowded if you try to put it in the same place as the `vmdk.xz`
17:43:28 <dustymabe> how about an expandable text box and a tooltip?
17:43:53 <dustymabe> darknao: grab me in #fedora-coreos later and we can hash it out some more?
17:44:05 * dustymabe needs to close out this meeting and go pick kid up from school
17:44:07 <darknao> we can add a second button next to the launch one, that expand the box with 1 or 2 additionals lines
17:44:12 <darknao> sure :)
17:44:18 <dustymabe> darknao++
17:44:18 <zodbot> dustymabe: Karma for darknao changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:44:23 <dustymabe> #endmeeting