February 2015 - rel-eng - Fedora Mailing-Lists

#6035: read cloud image size from spin-kickstarts git repo instead of hardcoding in the script

by Fedora Release Engineering

#6035: read cloud image size from spin-kickstarts git repo instead of hardcoding in the script -----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 21 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Currently, the cloud image size is hardcoded at 3GB in https://git.fedorahosted.org/cgit/releng/tree/scripts/build-cloud- images#n39 This is apparently too small for current Atomic, and may actually be _bigger_ than we want for Cloud Base. We want to fix the size problem in Atomic, though, and don't want to keep hassling with tickets to rel-eng to change the scripts. Instead, please make this read from the spin-kickstarts file -- either a config file in spin-kickstarts (e.g. fedora-cloud-atomic.ks.cfg) or from the kickstart file itself (a special comment? i'm not sure that'll survive the kickstart smashing). -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6035> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

8 years, 11 months

1
5
0 / 0

#6020: If Workstation tree is being dropped, please do same with Cloud

by Fedora Release Engineering

#6020: If Workstation tree is being dropped, please do same with Cloud ----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ Based on yesterday's FESCo meeting, the plan is for Fedora Workstation composes to be refactored such that there is not a separate Workstation tree, but that top-level directory on the mirrors will just contain the live ISOs in various architectures. I still think just rm'ing the netinst images from those trees is the lowest-impact workaround, but if this is what we are doing, Cloud should match because the exact same situation applies. So, please drop everything but the Images subdirectory from the Cloud tree. Thank you! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6020> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

8 years, 11 months

1
4
0 / 0

#5984: Adding metadata to the Fedora Workstation Live CD

by Fedora Release Engineering

#5984: Adding metadata to the Fedora Workstation Live CD ----------------------------+------------------------ Reporter: rhughes | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ Hi Dennis, and other rel-eng dudes! I've hit somewhat of a roadblock with this: http://blogs.gnome.org/hughsie/2014/08/29/putting-packagekit-metadata-on- the-fedora-livecd/ Basically, I need access to the post-mash (i.e. fedora, fedora-updates) from the compose server. This allows us to put the old metadata on the Fedora LiveCD so we don't have to wait the few minutes after install to be able to search for and install new applications. I totally agree we don't want unfettered internet access, or even access to the mirror network, as I'm happy doing something like this in the fedora-live-workstation.ks file: %post --nochroot DESTDIR=$INSTALL_ROOT $INSTALL_ROOT/usr/libexec/packagekit-direct refresh --rewrite-baseurl fedora=http://some.local.ip.address/f21 --rewrite- baseurl updates=http://some.local.ip.address/f21-updates On the assumption that some.local.ip.address is available from inside the LiveCD builder and gives us access to the mash'ed *metadata* only (I don't need packages, and it can even be a few days old with no penalty). The alternative is that I ship the fedora and updates metadata in the PackageKit rpm file, which means doing a -0.01 day release of the RPM for the Live media, which makes everything so very fragile. Other ideas of course welcome. Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5984> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

8 years, 11 months

1
3
0 / 0

#5894: git branches for SCL packages

by Fedora Release Engineering

#5894: git branches for SCL packages -----------------------------+------------------------ Reporter: mmaslano | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Alpha | Component: git Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ I would prefer SCL packages in branches of the main package (eg ruby). We used the same approach in some internal projects and it worked well with koji, composes, everything... I suggest name of branches: scl-f21 scl-f22 -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5894> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

8 years, 11 months

1
68
0 / 0

#5805: add index.asc files for cloud images for virt-builder

by Fedora Release Engineering

#5805: add index.asc files for cloud images for virt-builder ----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 20 Beta | Component: other Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ Please add a GPG-signed 'index.asc' file to the Fedora 20 Images/ directory describing cloud images for virt-builder and other tools. The format is documented at http://libguestfs.org/virt-builder.1.html #creating-your-own-templates, and there's actually a Fedora example there. Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5805> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

8 years, 11 months

1
16
0 / 0

#5883: New Cloud Images Process

by Fedora Release Engineering

#5883: New Cloud Images Process -----------------------------+------------------------ Reporter: red | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: git Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ The cloud kickstart file has been moved to the spin-kickstarts Git by rel- eng. When this happened, it seems there was no discussion regarding the future process to create cloud images and the Spins Process doesn't seem appropriate. Therefore, the Cloud SIG would like to know what the intended process should look like to give new contributors access to the cloud image kickstart files and how to make sure new images (i.e. products) are created from new kickstart files if necessary. For now, mattdm (probably already has) and I need access from the Cloud SIG but more will follow soon as we get ready to work on new products. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5883> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

8 years, 11 months

1
6
0 / 0

#5880: update to pv-grub aki used in EC2

by Fedora Release Engineering

#5880: update to pv-grub aki used in EC2 -----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ * '''What:''' We are currently using old boot images with pv grub 1.02 -- newer versions at http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvidedKernels.html * '''Where:''' https://git.fedorahosted.org/cgit/releng/tree/scripts/cloud/fedora_ec2.py * '''Why:''' new version allows GPT partitions, works with both unpartioned and partitioned, would allow us to use a separate /boot if we want to change the filesystem for / in the future; also new version has bugfixes * '''When:''' F21 alpha; prereq of using whole-disk images -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5880> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

8 years, 11 months

1
3
0 / 0

#5721: Need application icons and application descriptions

by Fedora Release Engineering

#5721: Need application icons and application descriptions ----------------------------+------------------------ Reporter: rhughes | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ Hi, For the application installer preview I need the application icons and localized description data. I had the fedora-app-data package NAKd, but something needs to provide this data. Spot seemed to think it would be okay to include as metadata. The idea is to: * Generate the appstream.xml and appstream.tar files on koji * xmlmerge the .xml files and cat the .tar files when mash'ing the compose together. I've got C code to do the former, although someone familiar with python probably wants to re-write the code before putting it into koji. For F20 we can probably just ship the 15 most popular application icons and descriptions in gnome-software, although this won't scale with all the apps in Fedora. Any questions, I'm hughsie on IRC. Thanks. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5721> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

8 years, 11 months

1
19
0 / 0

#6047: handle packages that are retired only in Branched but not Rawhide

by Fedora Release Engineering

#6047: handle packages that are retired only in Branched but not Rawhide -----------------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: koji Keywords: meeting | Blocked By: Blocking: | -----------------------------+------------------------ Currently we allow to retire packages in Branched even if they are not retired in Rawhide. Today I realized that if a package is retired in Branched (i.e. it will be blocked in f21), it will also not be shipped in Rawhide, even if it is not retired there, because currently if it is blocked in f21 it is also blocked in f22. It might make sense to only retire packages in Branched to not ship packages with broken deps, like it is currently proposed. However this does not mean that the package should be retired in Rawhide, to allow it being fixed for the next release. Therefore we should decide if we: 1) Allow retirement in Branched only for packages retired in Rawhide 2) Unblock packages in f22 if they are only retired in f21 -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6047> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

8 years, 11 months

1
4
0 / 0

#5886: need method for distributing urgent fixes... urgently

by Fedora Release Engineering

#5886: need method for distributing urgent fixes... urgently -----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 21 Alpha | Component: mash Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Right now, the time it takes to do a push of F19 and F20 updates is a critical bottleneck in our ability to put out zero-day security updates. We need a solution for this. I understand that Infrastructure is working on a Netapp fix which will give a 3x speedup. I think that's probably still too slow. We need to be able to put out urgent updates on the scale of minutes, not hours. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5886> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

8 years, 11 months

1
31
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng February 2015