sinnykumari reported a new issue against the project: `releng` that you are following:
``
Releng ticket for F28 self contained change - https://fedoraproject.org/wiki/Changes/Atomic_Cloud_and_Docker_images_for_s…
As per my current understanding, required releng work will include making changes in pungi configuration to enable these additional s390x composes. Pull Request is already opened at https://pagure.io/pungi-fedora/pull-request/496 containing some useful discussion.
There might be some work during Fedora 28 release like putting images at required places to get picked up by mirror manager.
I am ready to work with releng for any additional changes required!
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7286
adrian reported a new issue against the project: `releng` that you are following:
``
I just changed mirrormanager to point to releases/27 also for the category "Fedora Secondary Arches". The following directories could now be deleted on the master mirror:
* fedora/linux/development/27/
* fedora-secondary/development/26/
* fedora-secondary/development/27/
The last one (fedora-secondary/development/27/) needs probably another hour before it can be deleted. But once all mirrorlist servers have the latest information the directories above are no longer necessary from mirrormanager's point of view.
Also see email thread on mirror-admin: https://lists.fedoraproject.org/archives/list/mirror-admin@lists.fedoraproj…
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7277
adamwill reported a new issue against the project: `releng` that you are following:
``
There appears to be no garbage collection in place for the Cloud and Docker post-release nightly composes. AFAICT, every single one of these that has ever been built still exists in https://kojipkgs.fedoraproject.org/compose .
Other nightly composes - the Rawhide and Branched nightlies, and the two-week Atomic nightlies - *are* garbage collected. Two-week Atomic nightly composes still exist back to October 2017, but there certainly were older ones that are now gone. Rawhide and Branched seem to be cleaned about every two weeks.
@mohanboddu
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7266
codonell reported a new issue against the project: `releng` that you are following:
``
All Fedora releases must be released using a released and supported version of the core toolchain involving glibc, gcc, and binutils.
The Fedora toolchain team is responsible for ensuring that Fedora Rawhide stabilizes static linking, code generation, and library ABI, before a Fedora release, or that after the branch that the Fedora release is rebased (a very small rebase) to the final released version. This is a requirement for Fedora to inherit the ABI and API guarantees provided by upstream. If a mass rebuild is required by binutils, gcc, glibc or other components, the Fedora toolcahin team will ensure coordination with release engineering such that a mass rebuild uses the released version of all components and fix any last minute ABI or code-generation changes.
As of 2018-01-08 the Fedora toolchain team is requesting a mass rebuild for the Fedora 28 release.
Reasons given:
* Enable Intel CET for current and all future revisions of Fedora (compile with CET turned on).
* Test coverage of flags injection for Annobin, getting as much of the distribution built with annotated binaries for security hardening checking.
Change page for review: https://fedoraproject.org/wiki/Changes/Annobin
Owner: Nick Clifton <nickc(a)redhat.com>
Change page for review: https://fedoraproject.org/wiki/Changes/GLIBC227
Owner: Carlos O'Donell <carlos(a)redhat.com>
Change page for review: https://fedoraproject.org/wiki/Changes/GCC8
Owner: Jakub Jelínek <jakub(a)redhat.com>
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7249
pbrobinson reported a new issue against the project: `releng` that you are following:
``
This is the rel-eng ticket for this change:
https://fedoraproject.org/w/index.php?title=Changes/AArch64_Server_Promotion
The primary requirements of rel-eng is to adjust the output locations and the blocking status in the compose of the aarch64 Server (Server installers/cloud/docker) to be the same status/mirror locations of x86_64. The delivereables have already been produced for a number of cycles, previously as part of "secondary" releases, and since the koji merge in F-26+ as part of the alternate architectures releases.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7243
sgallagh reported a new issue against the project: `releng` that you are following:
``
The revamped Fedora Modularity project is working on a new approach (outlined at a high level at the [CommBlog](https://communityblog.fedoraproject.org/modularity-dead-long-live…) As part of this new approach, we will need to have the ability to compose and ship packages in a second set of Fedora repositories.
This set of add-on repositories will need to be module-aware (in that it must ship repodata created by a `createrepo` tool that understands modulemd). We will need to arrange mirroring and storage for this new content. We anticipate the storage requirements to be fairly small for the immediate future, but to grow over time.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7227
dustymabe reported a new issue against the project: `releng` that you are following:
``
For background see: [new koji tags for atomic host](https://pagure.io/releng/issue/7100) ticket
This is a tracker for packages tagged into the`f27-atomic-host-installer` and `f27-atomic-host-overrides` tags.
Currently tagged packages:
[f27-atomic-host-installer]
-
[f27-atomic-host-overrides]
-
The description will get updated over time and the comments will serve as a changelog.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7213
jarrpa reported a new issue against the project: `releng` that you are following:
``
Hello!
I'm trying to do scratch builds from the following branch:
`https://src.fedoraproject.org/fork/jarrpa/container/glusterfs/branch/private-jarrpa`
With some help I managed to figure out the following command:
`koji-containerbuild --profile koji build --scratch f27-container-candidate git+https://src.fedoraproject.org/forks/jarrpa/container/glusterfs.git?#bc6…
But then I get the following error:
```
Created task: 23656542
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=23656542
Watching tasks (this may be safely interrupted)...
23656542 build (f27-container-candidate, /forks/jarrpa/container/glusterfs.git:bc698113adb8013df859a8c446b8547a5042fbdd): free
23656542 build (f27-container-candidate, /forks/jarrpa/container/glusterfs.git:bc698113adb8013df859a8c446b8547a5042fbdd): free -> FAILED: BuildError: src.fedoraproject.org:/forks/jarrpa/container/glusterfs.git is not in the list of allowed SCMs
0 free 0 open 0 done 1 failed
23656543 buildSRPMFromSCM (/forks/jarrpa/container/glusterfs.git:bc698113adb8013df859a8c446b8547a5042fbdd): FAILED: BuildError: src.fedoraproject.org:/forks/jarrpa/container/glusterfs.git is not in the list of allowed SCMs
23656542 build (f27-container-candidate, /forks/jarrpa/container/glusterfs.git:bc698113adb8013df859a8c446b8547a5042fbdd) failed
```
Is there any way to do scratch builds from forked repos? Otherwise, is there any way to create private/wip branched on the main repo that I can freely delete or do non-ff pushes to? I just want a repo I can use to do scratch builds using koji for development testing.
Thanks!
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7208