April 2015 - rel-eng - Fedora Mailing-Lists

PATCH - First attempt to enable Atomic ISO compose in pungi-koj

by Adam Miller

I've added a handful of parameters here to mirror the command that's currently being done run-pungi.sh[0] The options can either be strings for single elements or lists for multiples in the pungi-koji config. ====== BEGIN Example config add_template = "/srv/pungi/spin-kickstarts/atomic-installer/lorax-configure-repo.tmpl" add_template_var = [ "ostree_osname=Fedora-Cloud_Atomic", "ostree_ref=fedora-atomic/f22/x86_64/docker-host", ] add_arch_template = "/srv/pungi/spin-kickstarts/atomic-installer/lorax-embed-repo.tmpl" add_arch_template_var = [ "ostree_repo=http://compose-x86-01.phx2.fedoraproject.org/compose/atomic/", "ostree_osname=Fedora-Cloud_Atomic", "ostree_ref=fedora-atomic/f22/x86_64/docker-host", ] ===== END Example config I look forward to feedback. -AdamM [0] - https://git.fedorahosted.org/cgit/releng/tree/scripts/run-pungi#n67 diff --git a/pungi/phases/buildinstall.py b/pungi/phases/buildinstall.py index 1a60607..cf32658 100644 --- a/pungi/phases/buildinstall.py +++ b/pungi/phases/buildinstall.py @@ -86,13 +86,19 @@ class BuildinstallPhase(PhaseBase): noupgrade = not self.compose.conf.get("buildinstall_upgrade_image", False) buildinstall_method = self.compose.conf["buildinstall_method"] + # These were added for the Atomic ISO Lorax compose + add_template = self.compose.conf.get("add_template", None) + add_template_var = self.compose.conf.get("add_template_var", None) + add_arch_template = self.compose.conf.get("add_arch_template", None) + add_arch_template_var = self.compose.conf.get("add_arch_template_var", None) + for arch in self.compose.get_arches(): repo_baseurl = self.compose.paths.work.arch_repo(arch) output_dir = self.compose.paths.work.buildinstall_dir(arch) volid = get_volid(self.compose, arch) if buildinstall_method == "lorax": - cmd = lorax.get_lorax_cmd(product, version, release, repo_baseurl, output_dir, is_final=self.compose.supported, buildarch=arch, volid=volid, nomacboot=True, noupgrade=noupgrade) + cmd = lorax.get_lorax_cmd(product, version, release, repo_baseurl, output_dir, is_final=self.compose.supported, buildarch=arch, volid=volid, nomacboot=True, noupgrade=noupgrade, add_template=add_template, add_template_var=add_template_var, add_arch_template=add_arch_template, add_template_var=add_template_var) elif buildinstall_method == "buildinstall": cmd = lorax.get_buildinstall_cmd(product, version, release, repo_baseurl, output_dir, is_final=self.compose.supported, buildarch=arch, volid=volid) else: diff --git a/pungi/wrappers/lorax.py b/pungi/wrappers/lorax.py index 80d7f9f..c462f7b 100644 --- a/pungi/wrappers/lorax.py +++ b/pungi/wrappers/lorax.py @@ -21,7 +21,40 @@ from kobo.shortcuts import force_list class LoraxWrapper(object): - def get_lorax_cmd(self, product, version, release, repo_baseurl, output_dir, variant=None, bugurl=None, nomacboot=False, noupgrade=False, is_final=False, buildarch=None, volid=None): + def _handle_optional_arg_type(self, f_arg, c_arg): + """ + _handle_optional_arg_type + private function to handle arguments to LoraxWrapper get_*_cmd + functions that can optionally be different types (such as string + or list). This effectively allows to repeat args to the commands + wrapped by LoraxWrapper. + + @param uknown type : f_arg + - Function argument that is passed to the get_*_cmd function. + + @param string: c_arg + - Command line argument to append to cmd + + @return list + - returns a list of strings to join with the cmd list in the get_*_cmd + functions + """ + + cmd_args = [] + + if type(f_arg) is list: + for item in f_arg: + cmd_args.append("%s=%s" % (c_arg, item)) + if type(f_arg) is str: + cmd_args.append("%s=%s" % (c_arg, item)) + else: + raise Exception( + f_arg, + "Incorrect type passed to LoraxWrapper for " % c_arg + ) + return cmd_args + + def get_lorax_cmd(self, product, version, release, repo_baseurl, output_dir, variant=None, bugurl=None, nomacboot=False, noupgrade=False, is_final=False, buildarch=None, volid=None, add_template=None, add_template_var=None, add_arch_template=None, add_arch_template_var=None): cmd = ["lorax"] cmd.append("--product=%s" % product) cmd.append("--version=%s" % version) @@ -53,6 +86,39 @@ class LoraxWrapper(object): if volid: cmd.append("--volid=%s" % volid) + if add_template: + cmd.extend( + self._handle_optional_arg_type(add_template, "--add-template") + ) + + if add_template_var: + cmd.extend( + self._handle_optional_arg_type( + add_template_var, "--add-template-var" + ) + ) + + if add_template_var: + cmd.extend( + self._handle_optional_arg_type( + add_template_var, "--add-template-var" + ) + ) + + if add_arch_template: + cmd.extend( + self._handle_optional_arg_type( + add_arch_template, "--add-arch-template" + ) + ) + + if add_arch_template_var: + cmd.extend( + self._handle_optional_arg_type( + add_arch_template_var, "--add-arch-template-var" + ) + ) + output_dir = os.path.abspath(output_dir) cmd.append(output_dir)

9 years

2
4
0 / 0

#6162: Schedule and coordinate mass rebuild for F23

by Fedora Release Engineering

#6162: Schedule and coordinate mass rebuild for F23 -----------------------------+------------------------ Reporter: jkurik | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 23 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Coordinate the packages that need to be rebuilt for F23. We try to have no more than one mass rebuild per cycle. So we need to list the things that need a mass rebuild and then schedule it to happen. Branching is no earlier than 2015-07-14, so mass rebuild should be done by 2015-06-16 (with 4 weeks clean up grace period). The main reason for mass rebuild is GCC5 change: https://fedoraproject.org/wiki/Changes/GCC5 For full Fedora 23 schedule see https://fedoraproject.org/wiki/Releases/23/Schedule -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6162> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

9 years

1
3
0 / 0

#6144: Document the semantics of "comps"

by Fedora Release Engineering

#6144: Document the semantics of "comps" -----------------------------+------------------------ Reporter: rholy | Owner: rel-eng@… Type: defect | Status: new Milestone: Fedora 22 Final | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ We, as the developers of DNF, miss a document that describes what "comps" mean and how should package managers work with them. Until it is documented, we cannot handle DNF bugs related to "comps" properly since we don't know what is the expected behaviour. E.g. what does "mandatory" packages mean? Could a "comp" be installed without a mandatory package (since it seems that there is a common practice to do that in kickstart files; e.g. RHBZ 1131969 and RHBZ 1185408)? What should happen if a "comp" is installed and its mandatory package gets removed? What if multiple comps share the same mandatory packages? And so on... And please don't focus only on mandatory packages. If there is a piece of software that has to work with another one, the dependency has to be documented. Also another issue related to the mandatory packages comes to my mind. Since I understand "comps" as something that specifies which packages are the Fedora default (is true? can you document it?), what is the recommended approach to replace a default package (YUM) with a new default package (DNF) on all user systems? That is something that should be possible to be specified on the comps level IIUIC. Also it would be nice if there will be a way how to specify which packages are preferred over which ones since there are people that are convinced that Fedora e.g. prefers MariaDB over community-mysql so Fedora has to express it somehow. Anyway, we can discuss it once you finish the documentation. I just wanted to let you know about some use cases in case it would help you to design the semantics. It would be nice if you could fix it as soon as possible. (Actually, DNF uses "libcomps" to work with "comps" so in fact, we don't mind if it is documented on "comps.xml" level or on "libcomps" level but I assume that "libcomps" cannot be documented until "comps.xml" is documented anyway.) -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6144> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

9 years

1
5
0 / 0

[PATCH] Handle os-release upgrades from existing productized installations

by Stephen Gallagher

When we created the os-release patches for Fedora 22, we missed backporting one change from Rawhide (aec40b478cd0486ec1312551961d1af3606a6685). Because of this, packages upgraded from F21 are not getting the VARIANT assigned in /etc/os- release. Fortunately, the fix for this can be applied in an update. See attached patch. We should get this fixed for Final. See also BZ #1214783

9 years

3
4
0 / 0

#6167: revamp the secondary arch process to get bits on the master mirror

by Fedora Release Engineering

#6167: revamp the secondary arch process to get bits on the master mirror -----------------------------+------------------------ Reporter: ausil | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 23 Alpha | Component: koji Keywords: planning | Blocked By: Blocking: | -----------------------------+------------------------ right now the process we have to get secondary arch content onto the master mirrors is a bit of a hammer and was designed with the secondary arches not being in phx2. it is not the most resource friendly thing. we should design a new way that ties in using fedmsg for content landing and allows the secondary arches to push thier content when they need to. it should then allow for /mnt/koji/tree to go away on the secondary arch kojis which should additionally free up some disk on them. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6167> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

9 years

1
0
0 / 0

#6017: please give kushal permissions to do scratch cloud image builds in koji

by Fedora Release Engineering

#6017: please give kushal permissions to do scratch cloud image builds in koji ----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ If I remember right (and I admit I remember only vaguely) there are special permissions required to build images in koji. Please give these to kushal so he can create scratch images to test things out. Thank you! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6017> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

9 years

2
11
0 / 0

#6040: system to run regular orphaned packages status reports from

by Fedora Release Engineering

#6040: system to run regular orphaned packages status reports from -----------------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: koji Keywords: meeting | Blocked By: Blocking: | -----------------------------+------------------------ Currently I am creating status reports for orphaned packages from autosign01, but this should move to its own system. Requirements: - run cron jobs - send e-mails - fast access to koji and pkgdb - access to mash repos - possible in the future: access to a directory served by a web server for HTML based status reports -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6040> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

9 years

1
7
0 / 0

#5665: Providing a master CHECKSUMS file for boot.fpo

by Fedora Release Engineering

#5665: Providing a master CHECKSUMS file for boot.fpo -----------------------------+------------------------ Reporter: shaiton | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, as requested to webmasters[1], could we get a CHECKSUMS file (as provided for other Fedora releases) including all checksums? It also needs to be signed of course. You might decide that it is not needed, just forwarded the query. [1] https://lists.fedoraproject.org/pipermail/websites/2013-July/011535.html -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5665> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

9 years

1
3
0 / 0

#5939: f21-kde koji tag/target

by Fedora Release Engineering

#5939: f21-kde koji tag/target ---------------------+------------------------ Reporter: rdieter | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: koji Keywords: | Blocked By: Blocking: | ---------------------+------------------------ Please create a f21-kde koji tag/target. kde-sig will continue to have monthly kde4 and kde frameworks 5 updates to work on, so having this till be greatly beneficial. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5939> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

9 years

1
3
0 / 0

#1107: auto-cleanup rawhide trees

by Fedora Release Engineering

#1107: auto-cleanup rawhide trees -------------------------+-------------------------------------------------- Reporter: notting | Owner: rel-eng(a)lists.fedoraproject.org Type: enhancement | Status: new Milestone: | Component: koji Keywords: | -------------------------+-------------------------------------------------- Rawhide tree expiry is manual at the moment, unless I missed something. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/1107> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

9 years

1
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng April 2015