✅ PASS: Test report for kernel 5.11.12-200.fc33 (fedora-33)
Hello, We ran automated tests on the following kernel build: Kernel package: kernel-5.11.12-200.fc33 Task URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=65454832 The results of these automated tests are provided below. Overall result: PASSED Tests: OK All kernel binaries, config files, and logs are available for download here: https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse-public/2021/04/08/283316596 Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. For the full detail on our testing procedures, please scroll to the bottom of this message. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' __ Hardware testing We booted each kernel and ran the following tests: aarch64: Host 1: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ Storage: swraid mdadm raid_module test 🚧 ✅ xfstests - btrfs 🚧 ✅ Storage blktests 🚧 ✅ Storage block - filesystem fio test 🚧 ✅ Storage block - queue scheduler test 🚧 ✅ Storage nvme - tcp 🚧 ⚡⚡⚡ Storage: lvm device-mapper test 🚧 ⚡⚡⚡ stress: stress-ng Host 2: ✅ Boot test ✅ ACPI table test ✅ LTP ✅ CIFS Connectathon ✅ Loopdev Sanity ✅ Memory: fork_mem ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Ethernet drivers sanity ppc64le: Host 1: ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ Storage: swraid mdadm raid_module test 🚧 ✅ xfstests - btrfs 🚧 ✅ Storage blktests 🚧 ✅ Storage block - filesystem fio test 🚧 ✅ Storage block - queue scheduler test 🚧 ✅ Storage nvme - tcp 🚧 ✅ Storage: lvm device-mapper test Host 2: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ⚡⚡⚡ Boot test ⚡⚡⚡ LTP ⚡⚡⚡ CIFS Connectathon ⚡⚡⚡ Loopdev Sanity ⚡⚡⚡ Memory: fork_mem ⚡⚡⚡ Memory function: memfd_create ⚡⚡⚡ AMTU (Abstract Machine Test Utility) ⚡⚡⚡ Ethernet drivers sanity Host 3: ✅ Boot test ✅ LTP ✅ CIFS Connectathon ✅ Loopdev Sanity ✅ Memory: fork_mem ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Ethernet drivers sanity s390x: Host 1: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ⚡⚡⚡ Boot test ⚡⚡⚡ LTP ⚡⚡⚡ CIFS Connectathon ⚡⚡⚡ Loopdev Sanity ⚡⚡⚡ Memory: fork_mem ⚡⚡⚡ Memory function: memfd_create ⚡⚡⚡ AMTU (Abstract Machine Test Utility) ⚡⚡⚡ Ethernet drivers sanity Host 2: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ⚡⚡⚡ Boot test ⚡⚡⚡ Storage: swraid mdadm raid_module test 🚧 ⚡⚡⚡ Storage blktests 🚧 ⚡⚡⚡ Storage nvme - tcp 🚧 ⚡⚡⚡ stress: stress-ng Host 3: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ⚡⚡⚡ Boot test ⚡⚡⚡ LTP ⚡⚡⚡ CIFS Connectathon ⚡⚡⚡ Loopdev Sanity ⚡⚡⚡ Memory: fork_mem ⚡⚡⚡ Memory function: memfd_create ⚡⚡⚡ AMTU (Abstract Machine Test Utility) ⚡⚡⚡ Ethernet drivers sanity Host 4: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ⚡⚡⚡ Boot test ⚡⚡⚡ Storage: swraid mdadm raid_module test 🚧 ⚡⚡⚡ Storage blktests 🚧 ⚡⚡⚡ Storage nvme - tcp 🚧 ⚡⚡⚡ stress: stress-ng x86_64: Host 1: ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ xfstests - nfsv4.2 ✅ Storage: swraid mdadm raid_module test 🚧 ❌ xfstests - btrfs 🚧 ✅ xfstests - cifsv3.11 🚧 ✅ Storage blktests 🚧 ✅ Storage block - filesystem fio test 🚧 ✅ Storage block - queue scheduler test 🚧 ✅ Storage nvme - tcp 🚧 ✅ Storage: lvm device-mapper test
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547946553 It is an important distinction that the typical package has an upstream source repository, and dist-git. We have essentially 2 different upstream repositories and dist-git, so having the date generated the way it does gives me some information about the kernel-ark repository, while the git tag gives me some information about upstream, both are useful in day to day at a glance. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547944992 kernel-5.11.0-155 kernel-5.11.0-156 kernel-5.11.0-157 kernel-5.11.0-158 These are tags by an autogenerated by scripts and have nothing to do with dist-git because most of them were not used. Of those, only kernel-5.11.0-155 was built for rawhide, with an extra build of 156 for F34. The rest of them were never in dist-git at all. `` does distinguish the actual tag applied and is useful there. The date is useful in being able to quickly see when a build was last done, or more importantly to distinguish quickly if a script failed and ark-latest does not have a valid new build. As we build rawhide almost daily, and in the morning, I can tell you what I build in dist-git today was in Linus' tree yesterday most of the time. There is a 1 day difference in most cases. It is static, and as a maintainer it is much more useful as a representation of when the tree was built vs when linus handled a pull request. Remember, this date doesn't necessarily correlate with when I generate dist-git so much as when ark-latest is composed in practice. It has happened several times that I don't get to a build until the next day, but before the script runs. By the time that finishes koji, it looks like a fresh build, but it is probably time to start the next one because that was older. Developers are doing various things from os- build, but from a maintainer standpoint, dist-git is only generated from ark-latest. As to whether `` remains where it is, or is moved to between the 0 and rc, I just don't care all that much. The reasons for keeping it at the end are, it seems more logical with the build number being at the end, as versioning gets more granular from left to right. It also falls into the "if it ain't broke" category in that it has been there for a good 10 years now, and I don't see any particular advantage to changing it. But in the end, it doesn't really make a ton of difference to me. Perhaps some of the ELN developers and maintainers would have stronger opinions there as they have a *lot* more tooling around completed builds than Fedora does. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: David Ward on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547939066 Sorry if I am misunderstanding something. I was saying that for `kernel-5.12.0-0.rc6.20210408git454859c5.186` we should make the date (`20210408`) correspond to the upstream commit (`454859c5`). If we use the date that the Makefile is run, that is not reproducible behavior. It affects the filenames of source tarballs (which have to be generated), along with the package NVR itself. You mentioned using the date to distinguish changes in dist-git that are independent of the upstream source. My comment was that we should being use `` for that, not the snapshot date. A major reason is that the date might not even be in the NVR to begin with (which is expected). For example: - kernel-5.11.0-155 - kernel-5.11.0-156 - kernel-5.11.0-157 - kernel-5.11.0-158 can only be distinguished by ``. Similarly, I am suggesting we should be using `` to distinguish these tags (from the last cycle), where dist-git changed but the upstream sources did not: - kernel-5.11.0-0.rc5.20210130git0e9bcda5.139 - kernel-5.11.0-0.rc5.20210131git0e9bcda5.140 If I rebuild from those tags on my local system today, and make no modifications, it would generate packages named - kernel-5.11.0-0.rc5.20210408git0e9bcda5.139 - kernel-5.11.0-0.rc5.20210408git0e9bcda5.140 which does not reproduce the earlier behavior. (If I make any local changes, I should set the BUILDID or somehow tag the package differently.) Is that reasonable? Am I overlooking something? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547885204 https://www.kernel.org/ for reference. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547881033 rc releases such as kernel-5.12.0-0.rc6.184 are built as release kernels which is why they differ. It is an actual upstream release. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: David Ward on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547864291 We can't rely on that, because a date is only used for snapshotting. `kernel-5.12.0-0.rc6.184` does not have a date in it, but everything you mentioned still applies; you could rebuild the same source with a new tag after making configuration fixes. My understanding is that `` is supposed to be the field that distinguish changes in dist-git the way you described. Yes, it is redundant to have both a date and a commit hash, but [it was meant](https://docs.fedoraproject.org/en-US/packaging- guidelines/Versioning/#_snapshots) to be that way: > All snapshots MUST contain a snapshot information field (`:`) in the Release: tag. That field must at minimum consist of the date in eight-digit "MMDD" format. The packager MAY include up to 17 characters of additional information after the date. The following formats are suggested: > > `MMDD.` > > `MMDD` Again, I'm just making sure I understand how this is expected to work now, and if it should be different based on the Fedora Versioning Guidelines or any other reason. I can open a MR for changes that make sense. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547745411 Date in this case is very much important and different in that the git commit there is the upstream (Linus tree) commit, and not the kernel-ark commit id. Date gives us a bit more information as to what changes might have gone in between when Linus last pushed code, and when we created the dist-git for it. In fact, in all cases, I would assume git ID will give you the date of the upstream source commit, and date should be when the package was prepared for Fedora. Otherwise, the date is basically redundant information. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: David Ward on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547733607 My guess would be that the script would already have become confused at this point, given that `` was added. Related to ``: it contains the date that the [RPM source files are generated](https://gitlab.com/cki-project/kernel-ark/-/blob/4712146f 5f9576d52f1276c1932d66bc6767a7d4/redhat/Makefile.common#L72-73). I believe it should actually contain the date that the code was committed to upstream (as extracted using Git). Otherwise, if you run the Makefile locally to generate RPMs you can use for bisection, the date is not meaningful. I don't see that spelled out in the packaging guidelines, but I assume that is how it was meant to be used? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547725975 The decision to drop `` to 1 was made after 5.12 started as the numbers are climbing inconsistently with what we want. Realistically 100/200/300 have special meaning for Fedora stable releases, and rawhide should always be below 100. As to moving the `` to before the rc, I don't have particularly strong opinion on it, it has always been used just before the fedora release for well over a decade at this point, so that was where it was kept when we added the git tag. Though `` was typically '1'. For instance: kernel-5.6.0-0.rc2.git2.1.fc33 kernel-3.0-0.rc6.git0.1.fc16 My only concern might be that someone has a script somewhere expecting behavior that has existed for over a decade. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: David Ward on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547716096 I agree this is outside of Fedora here (although the NVR is not being changed for Rawhide, which is a different matter). I wanted to clarify: in the example above, you would have `Release: 0.186.rc6.2021...` when the Fedora versioning guidelines are used, which have a lot of detail about handling pre-releases. This NVR would be superceded by kernel-5.12.0-1. Aside: it seems `` is not being dropped to 1 after each release. For kernel-5.12.0, the first tag uses 158, continuing from kernel-5.11.0-158. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv19 0/4] [redhat] Add GIT macro to Makefile and Makefile.common:
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547598365 As a prerelease kernel, we have never relied on for ordering, nor should we. This is not a valid 5.12 release. 5.12.0-1 should supercede it. I will say that the release bump is not entirely necessary, though you can get into the case of building multiple snapshots in the same day (rarely), and it can matter. I thought the solution we agreed upon was to reset the release number for each kernel series, so when we start snapshots for 5.13, that 186 drops back to 1. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-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/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
