Self Introduction: Jonathan Lebon
Hello everyone, I've been a Fedora user and developer for a few years now. I used to work on the awesome SystemTap tool[1] and now work on (the equally awesome) Project Atomic[2]. My current endeavor is to make it easier for folks of all skill levels to try out the Fedora Atomic image without having to know how to set up cloud-init. To that end, I wrote an atomic-devmode package which has also been submitted for review[3]. For more info (and if you'd like to try it out!), you can check out the post on the cloud mailing list[4]. Cheers! Jonathan PS: My GPG key (ID 0x519CE313) is available on the MIT server if you required it. [1] http://systemtap.org/ [2] http://www.projectatomic.io/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=1297552 [4] https://lists.fedoraproject.org/archives/list/cloud%40lists.fedoraproject.org/thread/M75UQFVNUPNC6ES3RZMT5PXRHIH3FMP5/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Pidora
> I'm surprised to hear about Fedora working on the Pi Zero, since > that's an ARMv6 computer. Are we bringing ARMv6 into the fold along > with our ARMv7 and AArch64 support? It'd be pretty cool if we did, > since that would enable support for a very wide range of ARM > computers... During his DevConf presentation, Ian mentioned that he had to recompile a lot of the base packages to get it working, so I'm guessing not. His presentation should be on YouTube by now if you're interested. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HEADS UP] util-linux based on new mount API coming to rawhide/f39
On Tue, Apr 11, 2023 at 1:05 PM Colin Walters wrote: > Looks like this broke our mounting of zram: > > https://github.com/coreos/fedora-coreos-tracker/issues/1462 To follow up on this, I filed https://github.com/util-linux/util-linux/issues/2161 upstream with the requested logs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora CoreOS Meeting Minutes 2023-01-18
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2023-01-18/fedora_coreos_meeting.2023-01-18-16.30.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2023-01-18/fedora_coreos_meeting.2023-01-18-16.30.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2023-01-18/fedora_coreos_meeting.2023-01-18-16.30.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by jlebon at 16:30:02 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2023-01-18/fedora_coreos_meeting.2023-01-18-16.30.log.html . Meeting summary --- * roll call (jlebon, 16:30:09) * Action items from last meeting (jlebon, 16:33:45) * "Kernel Errors w/latest next/testing likely CIFS related." (jlebon, 16:35:28) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1381 (jlebon, 16:35:31) * AGREED: It appears this issue may affect older machines that are upgraded but we are still investigating to get more details. Since currently this issue only has one reported affected user/environment and they have pinned on a known working version we will release the next `testing` as usual. (dustymabe, 16:58:41) * [CfP] Container Plumbing Days 2023 (jlebon, 17:00:16) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1378 (jlebon, 17:00:20) * Podman begins CNI plugins deprecation (jlebon, 17:03:49) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1374 (jlebon, 17:03:52) * Create container repo tags for each FCOS release (jlebon, 17:12:08) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1367 (jlebon, 17:12:10) * Open Floor (jlebon, 17:25:54) Meeting ended at 17:30:13 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * jlebon (72) * dustymabe (46) * fifofonix (27) * zodbot (17) * bgilbert (12) * walters (10) * jmarrero (2) * jbrooks (1) * aaradhak[m] (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora CoreOS Meeting Minutes 2023-03-01
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2023-03-01/fedora_coreos_meeting.2023-03-01-16.30.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2023-03-01/fedora_coreos_meeting.2023-03-01-16.30.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2023-03-01/fedora_coreos_meeting.2023-03-01-16.30.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by jlebon at 16:30:08 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2023-03-01/fedora_coreos_meeting.2023-03-01-16.30.log.html . Meeting summary --- * roll call (jlebon, 16:30:12) * Action items from last meeting (jlebon, 16:36:20) * tracker: Fedora 38 changes considerations (jlebon, 16:36:58) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1357 (jlebon, 16:37:03) * we don't ship cups, shouldn't affect us (dustymabe, 16:39:20) * this is specific to Fedora IoT (dustymabe, 16:39:42) * we don't ship python (dustymabe, 16:39:57) * rawhide: upgrades fail with new openssh-9.0p1-10.fc38.1 (jlebon, 16:42:39) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1394 (jlebon, 16:42:43) * AGREED: we will go with option 2, where we will rely on an updated migration service shipped by sshd that works on OSTree-based systems and give a heads up on coreos-status (jlebon, 16:58:26) * F38 Change: Shorter Shutdown Timer (jlebon, 17:00:02) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1404 (jlebon, 17:00:05) * AGREED: we will get the fedora-release MR merged which currently only affects FCOS for now so that we can include it and verify it (jlebon, 17:08:41) * evaluate inclusion of GPU firmware (jlebon, 17:11:02) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1350 (jlebon, 17:11:05) * AGREED: we will keep the firmwares for now as users currently rely on them. we may in the future remove them as part of a larger space-savings initiative. (jlebon, 17:21:49) * Open Floor (jlebon, 17:22:06) * LINK: https://hackmd.io/T3F32w5aSiywOd_ekB8HKw?view (dustymabe, 17:26:00) Meeting ended at 17:32:44 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * dustymabe (92) * jlebon (70) * zodbot (16) * bgilbert (10) * pboy (4) * walters (2) * ravanelli (1) * c4rt0 (1) * gursewak (1) * spresti[m] (1) * spresti (0) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora CoreOS next stream rebased to Fedora Linux 39
Fedora Linux 39 Beta was released today [1]. Our Fedora CoreOS `next` stream has been migrated to Fedora Linux 39 content. Existing nodes on the `next` stream will update as normal over the following days. The Fedora Project accepted changes for Fedora 39 are at [2] and the Fedora CoreOS analysis of each change is documented in the tracker issue ticket #1491 [3]. The following changes require special attention: - The modularity effort in Fedora has been retired. As such, there are no more modular repos available. If you are currently using modules (e.g. `cri-o`), manual steps are required in order to avoid rebasing issues. See [4] for details. - To enhance security, the AWS AMI now has IMDSv1 disabled by default in favour of IMDSv2. If you have applications which still require access via IMDSv1, you may turn it back on when launching new instances. No change should occur to upgrading systems. For more information, see [5]. - The AWS AMI now uses the `gp3` volume type by default rather than `gp2` which provide more flexibility. Note that the minimum IOPS may be lower than `gp2` for smaller disk sizes. See [6] for a full comparison. - The AWS AMI now uses UEFI by default on x86_64 instance types that support it. This shouldn't have any noticeable effect on the host. - The `moby-engine` package has been updated from v20.10 to v24.0. This is an update that skips several major versions. Please test and report regressions in the Fedora bug tracker [7] and if possible link back to the Fedora CoreOS tracker issue [8]. Please test out the `next` stream over the coming month and report any issues in our issue tracker [9]. Thank you to everyone helping find issues by running the `next` stream! The Fedora CoreOS Team [1] https://fedoramagazine.org/announcing-fedora-39-beta/ [2] https://fedoraproject.org/wiki/Releases/39/ChangeSet [3] https://github.com/coreos/fedora-coreos-tracker/issues/1491 [4] https://github.com/coreos/fedora-coreos-tracker/issues/1513#issuecomment-1724299918 [5] https://github.com/coreos/fedora-coreos-tracker/issues/1502#issuecomment-1724336977 [6] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html [7] https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=moby-engine&version=39 [8] https://github.com/coreos/fedora-coreos-tracker/issues/1476 [9] https://github.com/coreos/fedora-coreos-tracker/issues ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora CoreOS Community Meeting Minutes 2024-01-17
Text Log: https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-01-17/fedora-coreos-meeting.2024-01-17-16.29.log.txt HTML Log: https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-01-17/fedora-coreos-meeting.2024-01-17-16.29.log.html Text Minutes: https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-01-17/fedora-coreos-meeting.2024-01-17-16.29.txt HTML Minutes: https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-01-17/fedora-coreos-meeting.2024-01-17-16.29.html = # #meeting-1:fedoraproject.org: fedora_coreos_meeting = Meeting started by @dustymabe:matrix.org at 2024-01-17 16:29:18 Meeting summary --- * TOPIC: roll call (@dustymabe:matrix.org, 16:29:23) * TOPIC: Action items from last meeting (@dustymabe:matrix.org, 16:35:27) * TOPIC: there are no action items from the last meeting. (@dustymabe:matrix.org, 16:35:44) * TOPIC: Platform Request: Proxmox (@dustymabe:matrix.org, 16:35:58) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/736 (@dustymabe:matrix.org, 16:36:05) * INFO: there is work going on that should make proxmox easier to add FCOS support for if a motivated individual came along: https://github.com/coreos/fedora-coreos-tracker/issues/736#issuecomment-1892669133 (@dustymabe:matrix.org, 16:51:29) * AGREED: We will reserve the `proxmoxve` platform ID for the proxmox platform. (@dustymabe:matrix.org, 16:54:42) * TOPIC: Podman v5 breaking changes (@dustymabe:matrix.org, 16:56:45) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1629 (@dustymabe:matrix.org, 16:56:53) * INFO: we are looking for a volunteer to drive the process to help users migrate older systems to newer settings that will allow them to adopt podman v5 without issue (@dustymabe:matrix.org, 17:04:56) * TOPIC: Open Floor (@dustymabe:matrix.org, 17:07:43) Meeting ended at 2024-01-17 17:13:47 Action items People Present (lines said) --- * @dustymabe:matrix.org (43) * @jlebon:fedora.im (18) * @zodbot:fedora.im (9) * @apiaseck:matrix.org (3) * @mnguyen:fedora.im (3) * @jbtrystram:matrix.org (3) * @meetbot:fedora.im (2) * @gurssing:matrix.org (2) * @buckaroogeek:fedora.im (2) * @marmijo:fedora.im (2) -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Current status of OSTree and its handling RPM scriptlets?
Hi Zdenek, On Mon, Feb 12, 2024 at 4:58 AM Zdenek Dohnal wrote: > > Hi all, > > there was an issue (either due a bug or due design) in the past about > RPM OSTree treating %post scriptlets in SPEC file differently than on > Fedora Linux - IIUC the explanation was %post scriptlets were applied on > the server side of the system with RPM OSTree, thus any configuration > changes like switching symlinks with alternatives were not > applied/usable for normal user. > > Has it got fixed during the time? Or is there a new technology which > would do the trick for Silverblue and Fedora Linux alike? Just a note: I would say "for Silverblue and traditional systems alike" instead. Silverblue is part of Fedora Linux. :) > Because there is a user which was used to setting NOEXEC on /usr/bin/vi > to prevent running shell from vi as a root when using 'sudo vi' - since > the /usr/bin/vi is shell script now and uses exec to spawn the correct > binary, NOEXEC flags breaks 'sudo vi' completely. > > The only possible solution here I see is to use alternatives in %post > scriptlet, but if the situation is the same, the functionality brought > by alternatives (automatic switch from vi -> vim and back if > vim-enhanced is installed without shell restart) won't work in OSTree. So the high-level situation of scriptlets wanting to modify /var content is still problematic. And in fact, we'd like to propose a package change at some point to discourage this (see https://github.com/coreos/fedora-coreos-tracker/issues/1067). The common way to make "image-mode friendly" system state changes is to e.g. use a systemd service or a tmpfiles.d dropin or to bake the migration into the application itself (all these would of course work across OSTree and non-OSTree based variants). Specifically for alternatives, see also https://github.com/fedora-sysv/chkconfig/issues/9 which calls for changing how it's implemented to be more compatible with image-based updates. Specifically for your issue though, it's not clear to me how much it's worth supporting this. Do they also have a way to prevent `sudo vi` from e.g. creating/modifying a systemd unit that can run arbitrary code? > Thank you in advance! Hope that helps! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
On Tue, Oct 25, 2022 at 12:43 PM Colin Walters wrote: > - This proposal is explicitly trying to tie everything together. I think > without the "bigger picture", it's actually *more* confusing. For example, > just pushing the container images does little unless we invest in them as a > derivation source and build tooling and docs around them. I agree it's helpful to discuss this at a higher level than the individual pieces to make sense of it. But the proposal as is seems to imply it will all be done in one cycle which I agree with Dusty is very optimistic. > But you're certainly not wrong, it *is* a big proposal. Happy to make > changes, I'm mainly just saying there already are dedicated sub-proposal > trackers to discuss the details of those. WDYT about introducing phases into the proposal? E.g. something like: - phase 1 (f38): start pushing OSTree-based variants as container images in Quay.io; users can opt into rebasing onto them - phase 2 (f39): automatically transition existing users to shipping from Quay.io; users can opt out. - phase 3 (f40): stop pushing OSTree repo updates entirely This is just an example, we can break it down some other way. Also, it'd make sense to have the transition for each variant be driven by that variant's working group (obviously with collaboration between them). On that topic, it doesn't seem like we got any feedback from Fedora IoT at least. Also not sure where we stand for Fedora Silverblue and Kinoite. On Thu, Oct 13, 2022 at 3:09 PM Ben Cotton wrote: > * `rpm-ostree` is reworked to gain strong CLI compatibility with > `yum/dnf` commands (cliwrap) > * The new container native functionality is exposed via `dnf image` > * (TBD: Rebranding of rpm-ostree itself to `dnf-image` or something else) Some concerns about this have been raised upstream already around whether hijacking the `dnf` command in that way could cause more confusion than it's worth. ISTM like a cleaner approach would be to build this out into `dnf` directly instead and have it drive rpm-ostree. Then the relationship becomes much clearer, and there's an obvious path towards gaining parity. Conveniently with dnf5 ditching Python, this becomes more achievable for systems that don't want Python. Things like `install` and `update` can more or less be passthrough as is (some debate there about whether to provide "advice" on whether what you're trying to install should be in a container instead; more of that below). Things like `status` would be valid in "image-mode" only to start, but then we could build out a traditional version of it. It would be great to get feedback from the DNF maintainers about this proposal and some of the ideas here. On Tue, Nov 1, 2022 at 9:34 AM Colin Walters wrote: > I personally think "we'll actually just do what you asked for when you type > dnf -y install cowsay" is a notable leap here. I think this probably makes sense generally, but I'll note that for Fedora CoreOS at least, the whole point is to have users' workloads run in containers and decoupled from the host. E.g. we've gone to great lengths to keep Python out for that reason (also, `cowsay` pulls in Perl BTW :) ). Having non-finger compatibility with `dnf install -y cowsay` was kind of a feature in that sense; it made users think twice before falling into the same patterns as other systems. Now with this and especially container layering, it gives more power to users but weakens that messaging. I'm not sure if it's worth adding some artificial technological constraints to try to steer them back or just keeping it as a documentation thing would suffice. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora CoreOS rebasing to Fedora Linux 40
Fedora Linux 40 was released today[1]. The Fedora CoreOS `testing` stream has been rebased and is currently rolling out. In two weeks, it will be promoted to the `stable` stream. For more information about Fedora 40, see the Fedora Project’s list of official Changes[2] and the Fedora CoreOS analysis of each Change[3]. The following changes require special attention: - Podman v5.0[4]: This release contains breaking changes. See the Podman website[5] and the tracker issue[6] for details. - Assign individual, stable MAC addresses for Wi-Fi connections[7]: If you are using Wi-Fi, then your system's MAC address will likely change after the update. Please test out the `testing` stream and report any issues in our issue tracker[8]. Thank you to everyone helping find issues by running the `next` and `testing` streams! The Fedora CoreOS Team [1]: https://fedoramagazine.org/announcing-fedora-linux-40/ [2]: https://fedoraproject.org/wiki/Releases/40/ChangeSet [3]: https://github.com/coreos/fedora-coreos-tracker/issues/1626 [4]: https://fedoraproject.org/wiki/Changes/Podman5 [5]: https://blog.podman.io/2024/03/podman-5-0-breaking-changes-in-detail/ [6]: https://github.com/coreos/fedora-coreos-tracker/issues/1629 [7]: https://fedoraproject.org/wiki/Changes/StableSSIDMACAddress [8]: https://github.com/coreos/fedora-coreos-tracker -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changelog between OS states (ie: VMs)
- Original Message - > On Mon, Jan 8, 2018 at 1:19 PM, Nico Kadel-Garcia wrote: > I fully agree wrt configuration changes. I am scoping my interest > exclusively to rpms. > > A bit like saying "I run yum/dnf update on an OS, what bugfixes are > landing/have landed?" Interestingly, these are both things that Atomic Host make easier to query. E.g. if both VMs are on AH but sitting on different commits, you can pull the commit on one of the two and do: $ rpm-ostree db diff COMMIT1 COMMIT2 to get a diff of the rpmdb between the two, and with the `--changelogs` flag, it will also output new changelog entries. Re. configuration changes, not exactly what you were looking for, though `ostree admin config-diff` allows you to see which `/etc` files were changed/added/removed from the base shipped configuration. Anyway, I realize this doesn't help if your VMs are not currently on AH, though just thought I'd bring it up for general interest! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Changelog between OS states (ie: VMs)
- Original Message - > On Mon, Jan 8, 2018 at 2:52 PM, Jonathan Lebon wrote: > > Interestingly, these are both things that Atomic Host make > > easier to query. > > > > E.g. if both VMs are on AH but sitting on different commits, > > you can pull the commit on one of the two and do: > > > > $ rpm-ostree db diff COMMIT1 COMMIT2 > > oh, that's so very nice. Can it be extracted, split out to a script? > (ie: point it to two rpmdb dirs...) It's not pretty, though here's a Gist that does this: https://gist.github.com/jlebon/790fcd04646e10bb09ae7993b20ca307 You'll need `ostree` and `rpm-ostree` (which can be installed equally well in yum/dnf-managed systems). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)
On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa wrote: > This is a fair point. I've personally been very annoyed about how > little Fedora CoreOS integrates with the rest of the Fedora Project. > One very broken consequence of Fedora CoreOS working this way is that > they basically *don't* participate in Changes discussions and just do > things differently without warning or documentation. This has led to > problems when Fedora CoreOS differs from the rest of Fedora in core, > fundamental ways. This has even happened unintentionally, where Fedora > CoreOS accidentally deviated from Fedora (and RHEL CoreOS!) by using > the wrong variant of iptables: > https://github.com/coreos/fedora-coreos-tracker/issues/676 We do look over every Fedora Changes that come through and evaluate how we need to adapt FCOS for them. I agree we could do a better job at providing more timely feedback to change owners and the community (thinking about the recent rpmdb backend change for example). Part of it I think is that we do not yet have a rawhide stream which would expose us to all these changes earlier (it's on the radar though!). But to be clear, the intent is always to match Fedora whenever possible. Due to our update model, we have to be extremely careful about these changes, and sometimes that means that FCOS lags behind a bit in getting them. The iptables example was an unfortunate slip up; ordinarily this would've been part of the f32 rebase just like the rest of Fedora. > Additionally, to the point about their tooling: there's been a bunch > of effort to plug OSBuild based image builds into our normal > infrastructure, and given that even Fedora IoT Edition can > successfully be produced through that pipeline, I would think that we > should have Fedora CoreOS transition to it. There's a lot more effort > going around OSBuild within the project as a whole, and it's much more > likely that we'll be able to incorporate that into the general > infrastructure in a way that makes it traceable and actionable within > and outside the project. I agree build tooling is an important part of the picture. Both teams of coreos-assembler and osbuild are aware of the overlap that exists and we do plan to discuss this further. Though this is not something we are likely to tackle in any serious way anytime soon. So for the purposes of this discussion, I hope we can put this aside. We do run our builds in CentOS CI, but we're open to integrating with Fedora processes in any way necessary. For example, we recently added informational fedmsgs when builds and releases happen as Clement linked to above. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora CoreOS rawhide stream
We've recently started a rawhide "mechanical" stream of Fedora CoreOS (mechanical streams are streams that are meant for developers and that don't use RPM lockfiles). You can see the first build here: https://builds.coreos.fedoraproject.org/browser?stream=rawhide This will allow us to more easily track breaking changes in rawhide and work with maintainers and upstreams to resolve them earlier in the process. (Yes, this is long overdue -- better late than never!) Cheers! Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
On Wed, Jan 5, 2022 at 9:46 AM Neal Gompa wrote: > That is not Ignition configuring the network, that is *you* knowing > what an NM file looks like and dropping it in. With cloud-init, it > knows how to access cloud provider data sources to get configuration > information and translate it into machine network configuration > automatically. For cloud-specific network configuration, we've been steering towards nm-cloud-setup. We do ship it in FCOS, but it's currently disabled by default pending more CI coverage and investigation: https://github.com/coreos/fedora-coreos-tracker/issues/320#issuecomment-791492732 So in theory, we could drop support for ifcfg as this Change is proposing and add nm-cloud-setup. (And that'd take us closer to being able to move from cloud-init to Ignition, which would have lots of benefits too.) I'm not sure how wide the gap between nm-cloud-setup and cloud-init is today though. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora CoreOS branched stream
Hi all, This was mentioned in an email on the coreos list[1], but wanted to raise visibility on this. In addition to the rawhide FCOS stream previously discussed[2], we now have a branched stream which tracks "Fedora CoreOS 34" (in quotes because this doesn't mean the same thing as "Fedora 34"). If you'd like to take it for a spin, you can download it from the builds browser[3] (and take notice of the "Caution" message there :)). Cheers! [1] https://lists.fedoraproject.org/archives/list/cor...@lists.fedoraproject.org/thread/A6QLMB2SYMNCROUIZDCJ7UGLCSYN3EUW/ [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XPYEN7VTK26E5NHEI7YUXMJRK5LNGRXY/ [3] https://builds.coreos.fedoraproject.org/browser?stream=branched ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora CoreOS branched stream
On Thu, Mar 11, 2021 at 10:54 AM Fabio Valentini wrote: > > On Thu, Mar 11, 2021 at 4:45 PM Jonathan Lebon wrote: > > > > Hi all, > > > > This was mentioned in an email on the coreos list[1], but wanted to > > raise visibility on this. > > > > In addition to the rawhide FCOS stream previously discussed[2], we now > > have a branched stream which tracks "Fedora CoreOS 34" (in quotes > > because this doesn't mean the same thing as "Fedora 34"). > > Well ... what *does* it track, if it doesn't track Fedora 34? Heh right, that comment was clearly begging to be elaborated on. It does track f34, but as Fedora CoreOS streams are rolling, there aren't set Fedora 34 Beta/GA deliverables like there are for other editions. The purpose of the `branched` stream is to make sure we're in good shape before moving the production streams to f34 content (starting with `next`, then after GA, `testing` and finally `stable`). Maybe I should've simply said: > we now have a branched stream which tracks Fedora CoreOS on f34. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora CoreOS moving to podman v4
In the coming months, the Podman container runtime will be upgraded from v3 to v4. This is a major release [1] that introduces backward incompatible changes to configuration files and APIs. The full release notes for Podman v4 are available at [2]. Here is a brief summary of how this will impact Fedora CoreOS nodes: - Existing containers will be preserved without any change required. - Compatibility for the Docker API is fully preserved. - Users of the Podman remote API will need matching server/client versions. - Rollbacks to a version with Podman v3.x will require manual action. - Only new installations will use the new network stack by default. For more details, see the Major Changes page in the Fedora CoreOS documentation [3]. This change will be rolled out together with the rebase to Fedora 36: - the `next` rebase is targeted for 2022-03-15 - the `testing` rebase is targeted for 2022-04-19 - the `stable` stream will follow `testing` as usual Thanks, Jonathan Lebon, for the Fedora CoreOS team [1] https://podman.io/releases/2022/02/22/podman-release-v4.0.0.html [2] https://github.com/containers/podman/releases/tag/v4.0.0 [3] https://docs.fedoraproject.org/en-US/fedora-coreos/major-changes/#_podman_v4_0 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora CoreOS Meeting Minutes 2022-04-13
Minutes: https://meetbot-raw.fedoraproject.org/teams/fedora_coreos_meeting/fedora_coreos_meeting.2022-04-13-16.31.html Minutes (text): https://meetbot-raw.fedoraproject.org/teams/fedora_coreos_meeting/fedora_coreos_meeting.2022-04-13-16.31.txt Log: https://meetbot-raw.fedoraproject.org/teams/fedora_coreos_meeting/fedora_coreos_meeting.2022-04-13-16.31.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by jlebon at 16:31:11 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2022-04-13/fedora_coreos_meeting.2022-04-13-16.31.log.html . Meeting summary --- * roll call (jlebon, 16:31:17) * Action items from last meeting (jlebon, 16:35:21) * F36: Fedora CoreOS Test Week (jlebon, 16:35:57) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1123 (jlebon, 16:35:59) * F36: No network on rpi4 (dustymabe, 16:37:07) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1145 (dustymabe, 16:37:13) * rebasing to another stream fails when deployment is staged (dustymabe, 16:37:19) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1150 (dustymabe, 16:37:23) * F36: 36.20220325.1.0 NetworkManager not allowed to access NM dispatcher scripts (dustymabe, 16:37:29) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1156 (dustymabe, 16:37:34) * F36 VM fails to display the network device information on console (dustymabe, 16:37:40) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1153 (dustymabe, 16:37:44) * exoscale: disk images fail to provision (dustymabe, 16:37:49) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1160 (dustymabe, 16:37:55) * Fedora36 Next Auto-Upgrade Fails & Yields Grub Prompt (dustymabe, 16:38:12) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1149 (dustymabe, 16:38:17) * LINK: https://github.com/coreos/fedora-coreos-docs/pulls?q=is%3Apr+ (dustymabe, 16:40:10) * rebasing to another stream fails when deployment is staged (jlebon, 16:45:15) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1150 (jlebon, 16:45:21) * LINK: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9c21ee528d (jlebon, 16:48:37) * this UX issue should be fixed by ostree 2022.2 (https://github.com/ostreedev/ostree/pull/2524) (jlebon, 16:53:05) * Fedora CoreOS talks for devconf.us 2022 (jlebon, 16:53:28) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1154 (jlebon, 16:53:30) * tracker: Fedora 36 changes considerations (jlebon, 16:55:39) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/918 (jlebon, 16:55:45) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1098 (dustymabe, 16:59:19) * LINK: https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html (dustymabe, 17:02:53) * we are now in final freeze. we will be doing next releases weekly. (jlebon, 17:04:23) * Open Floor (jlebon, 17:05:08) * LINK: https://github.com/coreos/vagrant-ignition/ (bgilbert, 17:08:16) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/144 (bgilbert, 17:13:23) Meeting ended at 17:16:18 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * dustymabe (67) * jlebon (56) * zodbot (20) * bgilbert (16) * travier (5) * davdunc (5) * mnguyen_ (3) * saqali (1) * aaradhak (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
