[releng] Issue #7249: Changes/glibc 2.27, gcc 8.0, binutils 2.30
by Carlos O'Donell
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
5 years, 6 months
[releng] Issue #7213: Tracker for packages tagged into atomic tags
by Dusty Mabe
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
5 years, 6 months
[releng] Issue #7208: Scratch builds from forked repos?
by Jose A. Rivera
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?#b...
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
5 years, 6 months
[releng] Issue #7202: Add a machine readable product id to the installation
media buildstamp
by Martin Kolman
m4rtink reported a new issue against the project: `releng` that you are following:
``
The current situation
==================
At the moment the installation media buildstamp file has a field called "Product", which contains a human readable name of the product being installed.
The product name is used visually in multiple places in Anaconda (welcome screen, bootloader entries, etc.), but quite alarmingly, also as a kind of machine readable product identifier (base repo name, install class selection, etc.).
We have hit this issue yet again recently during an effort to merge back install classes for individual Fedora variants (Workstation, Server, etc.) to make install class maintenance easier & to make it possible to decommission the currently used per-variant product image packages.
Unfortunately we found out the "Product" field of every Fedora compose (rawhide/branched/GA) is, unlike on RHEL, always set to "Fedora", even if the compose & installation image itself is branded as Workstation/Server/etc. Also no other filed in the buildstamp has any information about about the variant at all.
Machine readable product id
========================
Rather than requesting the variant name to be appended to the Product field and possibly breaking all software that assumes it will always be just "Fedora" and nothing else, we would like to suggest a different solution, possibly fixing this issue once and for all.
Rather than misusing the old human readable field, let's add a new field designed to hold a separate machine readable product id. That way Anaconda and other tools will not have to parse a human readable filed to detect a variant, making things much more robust. Also adding and properly specifying a new field should be generally much safer than changing the content of an existing one.
Specifying the product id field name & value
=====================================
Looking at the current syntax, it looks like the field names are following a camel case convention (there is a BugURL and IsFinal field), so lets call the new field ProductId.
As for the machine readable product id value, I would suggest a few rules:
- no whitespace
- lower case ASCII letters, numbers and _ and - only
I suggest this because it's quite likely the machine readable product id might end up on the filesystem as a folder or file name, so the string should be safe for this use-case.
Example .buildstamp file with ProductId:
==================================
[Main]
Product=Fedora
ProductId=fedora_workstation
Version=Rawhide
IsFinal=False
UUID=201711300745.x86_64
[Compose]
Lorax=28.2-1
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7202
5 years, 6 months