March 2018 - rel-eng - Fedora Mailing-Lists

[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, 5 months

8
14
0 / 0

[releng] Issue #7196: Please consider kernel update on builders to fix brk bug on POWER

by Florian Weimer

fweimer reported a new issue against the project: `releng` that you are following: `` On POWER, brk sometimes succeeds without mapping memory, leading to crashes: * https://bugzilla.redhat.com/show_bug.cgi?id=1518707 Note that the bug is in the running (host) kernel, not the kernel headers in the buildroot. This currently prevents glibc builds from completing. We do not have any Fedora glibc work we need to complete urgently, but I'd appreciate if fixed kernels could be installed by mid-December. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7196

5 years, 5 months

4
4
0 / 0

[releng] Issue #7151: ghostscript-fonts isn't blocked in koji for F28

by Zdenek Dohnal

zdohnal reported a new issue against the project: `releng` that you are following: `` Hi, I retired ghostscript-fonts for F28 this Monday and I can't see it blocked for it. Did I do something wrong? I retired it by 'fedpkg retire' and created pull request to fedora-comps to remove package from comps. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7151

5 years, 5 months

3
4
0 / 0

[releng] Issue #7103: fedora-modular-container-base-minimal image failed because dracut warning "/dev/root does not exist"

by Tomas Mlcoch

tmlcoch reported a new issue against the project: `releng` that you are following: `` Compose: Fedora-Modular-Bikeshed-20171019.n.1 fedora-modular-container-base-minimal generation failed for ppc64le and aarch64: https://koji.fedoraproject.org/koji/taskinfo?taskID=22555870 Because of dracut warning "/dev/root does not exist" and entering interactive mode, see screenshot in the failed task: https://koji.fedoraproject.org/koji/taskinfo?taskID=22555875 CC @sgallagh @psabata `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7103

5 years, 5 months

2
3
0 / 0

[releng] Issue #7092: Update PDC f27 SL entries once the f27 GA date is confirmed

by Matt Prahl

mprahl reported a new issue against the project: `releng` that you are following: `` The SLs in PDC for the f27 branch [1] were made with the assumption that the f27 GA date would be October 24th. Once the GA date is finalized, we should update these entries to reflect that. When the time comes feel free to ping me and I can write a script to do it. 1 - https://pdc.fedoraproject.org/rest_api/v1/component-branches/?name=f27 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7092

5 years, 5 months

3
2
0 / 0

[releng] Issue #7076: armhfp docker images fail 'ApplianceError: Image status is FAILED: sh: /bin/sh: No such file or directory'

by Paul Whalen

pwhalen reported a new issue against the project: `releng` that you are following: `` The fedora-docker-base images for armhfp are failing with the error: ApplianceError: Image status is FAILED: sh: /bin/sh: No such file or directory. All other arches completed successfully. https://koji.fedoraproject.org/koji/taskinfo?taskID=22112174 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7076

5 years, 5 months

2
1
0 / 0

[releng] Issue #7075: EPEL 7 aarch64 buildroot has no emacs

by Mattias Ellert

ellert reported a new issue against the project: `releng` that you are following: `` See https://koji.fedoraproject.org/koji/taskinfo?taskID=22120278 Build for aarch64 fails with the following error in root.log: DEBUG util.py:439: Error: No Package found for emacs DEBUG util.py:577: Child return code was: 1 The x86_64 build finds emacs and starts properly. This package has built successfully on EPEL 7 aarch64 before. The emacs package used to be there. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7075

5 years, 5 months

3
7
0 / 0

[releng] Issue #7074: Compose configuration changes needed for modular fedora

by Dennis Gilmore

ausil reported a new issue against the project: `releng` that you are following: `` * enable createiso generation on all arches. * enable Minimal and Base container everywhere it makes sense * Enable disk images (raw.xz and qcow2) as appropriate, x86_64, ppc64le, aarch64 * configure 32 bit arm images using apliance-creator * configure syncing of contanet to mirrors * configure sending of compose reports to email lists * ensure all needed fedmsg's are sent * setup empty repos for updates and updates-testing for fedora 27 @rashmin and @tmlcoch I will setup a meeting to go over the steps needed and how to test and get it implemented. With this done we should be able to setup compose configurations for Beta. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7074

5 years, 5 months

6
23
0 / 0

[releng] Issue #7058: Tracking ticket for F27 Modular RC composes

by Mohan Boddu

mohanboddu reported a new issue against the project: `releng` that you are following: `` Generally QA files the tickets for RC composes, this is an extra compose(s) for releng to work on since this wont follow the normal release cycle. This ticket will help us tracking the work and issues with the modular RC composes. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7058

5 years, 5 months

3
3
0 / 0

[releng] Issue #7057: Tracking ticket for generating torrents for modular release

by Mohan Boddu

mohanboddu reported a new issue against the project: `releng` that you are following: `` For a traditional release we generate torrents for almost all the iso's in the compose. So, its safe to assume that a modular release also requires torrents generated for the iso's. There is not much work/code changes are needed here, but just an informational ticket for releng. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7057

5 years, 5 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng March 2018