rel-eng April 2015

rel-eng@lists.fedoraproject.org

25 participants
113 discussions

[PATCH] srpm-excluded-arch.py enhancement
by Jakub Cajka 25 May '15

25 May '15

Hello, I have prepared enhancement of srpm-excluded-arch.py based on sharkcz's ideas(if I'm not mistaken :) ). I have moved this script from optparse to argparse, added possibility to run this script over multiple paths/directories(for example updates and release, etc.) and prepare list of excluded packages based on most recent ENVR. Also is possible to issue warning(to stderr) if package have multiple versions present and state of exclusion have changed(to warn about possible unintentional changes). Command syntax should be the same as original version, except switch -w, which adds up mentioned warnings(outputted to stderr), and --path accepts more than one path now, expansion is done up to 3 levels using python glob. I hope it brings desired improvements( and no bugs :)), looking forward for any feedback,... Patch follows. Best regards, Jakub >From b91af25ac1a89b4892cc1ffb4af60346cdb40eca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20=C4=8Cajka?= <jcajka(a)redhat.com> Date: Mon, 23 Feb 2015 15:57:48 +0100 Subject: [PATCH] srpm-excluded-arch.py can check multiple paths --- scripts/srpm-excluded-arch.py | 97 ++++++++++++++++++++++++++++++------------- 1 file changed, 68 insertions(+), 29 deletions(-) diff --git a/scripts/srpm-excluded-arch.py b/scripts/srpm-excluded-arch.py index 2125517..718f7c2 100755 --- a/scripts/srpm-excluded-arch.py +++ b/scripts/srpm-excluded-arch.py @@ -3,39 +3,54 @@ # srpm-exlcuded-arch: is a tool to give you a list of packge names that # are excluded on the given arches. access to a srpm tree is needed. # -# Copyright (C) 2008-2013 Red Hat, Inc. +# Copyright (C) 2008-2015 Red Hat, Inc. # SPDX-License-Identifier: GPL-2.0+ # # Authors: # Dennis Gilmore <dennis(a)ausil.us> +# Jakub Cajka <jcajka(a)redhat.com> import rpm import os import sys -import optparse +import argparse import glob +import types -OptionParser = optparse.OptionParser -usage = "%prog [options]" -parser = OptionParser(usage=usage) -parser.add_option("-a", "--arches", - help="space or command separated list of arches to check for") -parser.add_option("--path", default='./', - help="path to dir with srpms, default current directory") -(options, args) = parser.parse_args() -arches = options.arches -if arches == None: - print "You must pass arches to check for in." - sys.exit() -else: - if arches.find(',') == -1: - arches = arches.split(' ') - else: - arches = arches.split(',') - -srpm_path = options.path -srpms = glob.glob('%s/*.rpm' % srpm_path) -pkglist = [] +def rpmvercmp((e1, v1, r1), (e2, v2, r2)): + """find out which build is newer""" + rc = rpm.labelCompare((e1, v1, r1), (e2, v2, r2)) + if rc == 1: + #first evr wins + return 1 + elif rc == 0: + #same evr + return 0 + else: + #second evr wins + return -1 + +parser = argparse.ArgumentParser() +parser.add_argument('-a', '--arches', nargs='+', required=True) +parser.add_argument('-w', '--withcheck', action='store_true') +parser.add_argument('--path', nargs='+', default='./') +args = parser.parse_args() + +# be previous version compatible i.e. -a "arch arch ..." +if len(args.arches) == 1 and type(args.arches[0]) is types.StringType: + if args.arches[0].find(',') == -1: + args.arches = args.arches[0].split(' ') + else: + args.arches = args.arches[0].split(',') + +arches = args.arches +srpms = [] + +for srpm_path in args.path: + srpms += glob.glob('%s/*/*/*.rpm' % srpm_path) + srpms += glob.glob('%s/*/*.rpm' % srpm_path) + srpms += glob.glob('%s/*.rpm' % srpm_path) +pkglist = {} for srpm in srpms: """Return the rpm header.""" @@ -52,14 +67,38 @@ for srpm in srpms: if arch not in hdr[rpm.RPMTAG_EXCLUSIVEARCH]: if arch not in ExcludeArch: ExcludeArch.append(arch) - if ExcludeArch == arches: - pkgname = hdr[rpm.RPMTAG_NAME] - if pkgname not in pkglist: - pkglist.append(pkgname) - #print "Excluding: %s" % pkgname + + pkgname = hdr[rpm.RPMTAG_NAME] + pkgevr = ('0'if not hdr[rpm.RPMTAG_EPOCH] else str(hdr[rpm.RPMTAG_EPOCH]), + hdr[rpm.RPMTAG_VERSION], + hdr[rpm.RPMTAG_RELEASE]) + if not pkgname in pkglist: + pkglist[pkgname] = [] + excluded = set(ExcludeArch) == set(arches) + + pkglist[pkgname].append({'evr':pkgevr, 'excluded':excluded}) output = "" +warning = "" + for pkg in pkglist: - output += pkg + " " + pkglist[pkg].sort(cmp=rpmvercmp, key=lambda x: x['evr'], reverse=True) + if pkglist[pkg][0]['excluded']: + output += pkg + " " + + if args.withcheck: + last = None + change = "" + for srpm in pkglist[pkg]: + if last and last['excluded'] != srpm['excluded']: + change += str(srpm)+'->'+str(last) + last = srpm + if change: + warning += pkg + " " + change + "\n" + +if args.withcheck and warning: + warning = "WARNING: Fellowing packages have changed their exclude state:\n"+warning + sys.stderr.write(warning) print output + -- 1.9.3

3 3

[PATCH] run-pungi: atomic: Change the `ostree_osname` to be fedora-atomic
by Colin Walters 19 May '15

19 May '15

We should be consistent with the cloud image kickstart, which uses `fedora-atomic`. Note this string actually appears in the user interface and may be typed by the admins, so the shift key gymnastics required by the previous value are more painful than just having it in a URL or the like. --- scripts/run-pungi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

5 19

#6151: Make a Fedora 22 Desktop MultiSpin DVD
by Fedora Release Engineering 15 May '15

15 May '15

#6151: Make a Fedora 22 Desktop MultiSpin DVD -----------------------------+------------------------ Reporter: robyduck | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 22 Final | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ As decided by FAmSCo and requested by KDE-SIG we want to produce a MultiSpin DVD for F22. EMEA already decided to produce them but AFAICS we have no official request for it. The image should be for '''64bit only''' and include at least KDE, Xfce and LXDE. If possible it would be nice to include also MATE-Compiz, but we shouldn't exceed a single layer DVD. This DVD will be used by ambasssadors to promote Fedora on events, additionally to Workstation. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6151> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 9

#6166: Create Fedora 22 Final test compose (TC) and release candidate (RC)
by Fedora Release Engineering 15 May '15

15 May '15

#6166: Create Fedora 22 Final test compose (TC) and release candidate (RC) -----------------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 22 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Time for Final composes: https://fedorapeople.org/groups/schedule/f-22/f-22-releng-tasks.html Create First 'Final' Test Compose (TC1) Tue 2015-04-28 So, for TC1, please include: * [https://admin.fedoraproject.org/updates/FEDORA-2015-6866 libblockdev-0.11-1.fc22,python- blivet-1.0.8-1.fc22,anaconda-22.20.10-1.fc22] for [https://bugzilla.redhat.com/show_bug.cgi?id=1209563 #1209563] and others * [https://admin.fedoraproject.org/updates/FEDORA-2015-7011 libblockdev-0.12-1.fc22,anaconda-22.20.11-1.fc22] for [https://bugzilla.redhat.com/show_bug.cgi?id=1166598 #1166598] and multiple other blockers (those last two overlap, but pulling in both should work fine) * [https://admin.fedoraproject.org/updates/grub2-2.02-0.16.fc22 grub2-2.02-0.16.fc22] for [https://bugzilla.redhat.com/show_bug.cgi?id=1215839 #1215839] Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6166> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 8

#6120: F22 stable push requests
by Fedora Release Engineering 14 May '15

14 May '15

#6120: F22 stable push requests -----------------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ This ticket will be used for requesting pushes of tested blocker / freeze exception fixes during F21 release freezes. See https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process . Similar to TC/RC request tickets, this ticket can be closed by releng after each push and re-opened by QA each time a new push is needed. First request, current Alpha blocker / FE fixes with sufficient karma to be pushed: * [https://admin.fedoraproject.org/updates/FEDORA-2015-2552 sssd-1.12.4-2.fc22] for [https://bugzilla.redhat.com/show_bug.cgi?id=1014594 #1014594] * [https://admin.fedoraproject.org/updates/FEDORA-2015-2659 fedora- productimg-server-22-7.fc22, fedora-productimg-workstation-22-7.fc22] for [https://bugzilla.redhat.com/show_bug.cgi?id=1196504 #1196504] * [https://admin.fedoraproject.org/updates/FEDORA-2015-2655 systemd-219-5.fc22] for [https://bugzilla.redhat.com/show_bug.cgi?id=1196417 #1196417] and [https://bugzilla.redhat.com/show_bug.cgi?id=1195761 #1195761] * [https://admin.fedoraproject.org/updates/FEDORA-2015-2657 xorg-x11-drv- libinput-0.7.0-4.fc22] for [https://bugzilla.redhat.com/show_bug.cgi?id=1195905 #1195905] * [https://admin.fedoraproject.org/updates/FEDORA-2015-2553 gtk3-3.15.9-1.fc22] for [https://bugzilla.redhat.com/show_bug.cgi?id=1185585 #1185585] * [https://admin.fedoraproject.org/updates/FEDORA-2015-2882 gdm-3.15.91-1.fc22] for [https://bugzilla.redhat.com/show_bug.cgi?id=1197224 #1197224] and [https://bugzilla.redhat.com/show_bug.cgi?id=1194948 #1194948] * [https://admin.fedoraproject.org/updates/FEDORA-2015-2774 desktop- backgrounds-22.0.0-0.fc22, f22-backgrounds-21.91.0-1.fc22] for [https://bugzilla.redhat.com/show_bug.cgi?id=1196347 #1196347] Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6120> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 21

FAD proposal
by Paul W. Frields 14 May '15

14 May '15

One of Matthew Miller's goals for Fedora is to diversify our release deliverables. This is one reason the Fedora Engineering team is bringing on a full-time person soon to work on release tools. We want to contribute to the Fedora release engineering effort too (as opposed to simply asking existing folks to do more). :-) I would expect over the first month or two in that role, our release tools person will likely be: * looking at the field of deliverables needed, across not just the products but also at containers and Project Atomic needs * getting familiar with any current release processes as needed * discussion with stakeholders in the project, including rel-eng, mattdm, infrastructure, and others, on this list and elsewhere about requirements During this time, I'd expect there will be some decisions on process, architecture, etc. To kickstart development, I'd like to set up a FAD where key community members, including developers and release engineers, can start (or continue) working on actual code and supporting infrastructure. I started a wiki page here for interested people to sign up: https://fedoraproject.org/wiki/FAD_Release_Tools_and_Infrastructure_2015 There are some proposed dates listed on the wiki page. None have been fully decided yet. I have preliminary approval from the FPL, and I'm awaiting OSAS input on budget availability, and any time restrictions from their POV. There is a good chance we will do this at the Red Hat Tower (HQ) in Raleigh, NC USA. The event will not be restricted to USA people, although we'll have to select a roster of people to meet goals. There's a specific section in the page for you to write your name and any restrictions on dates. This will help us make the best date/location plan. https://fedoraproject.org/wiki/FAD_Release_Tools_and_Infrastructure_2015#Po… -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com

1 4

#6156: Specifying groups in scm changes
by Fedora Release Engineering 13 May '15

13 May '15

#6156: Specifying groups in scm changes -----------------------------+------------------------ Reporter: orion | Owner: rel-eng@… Type: defect | Status: new Milestone: Fedora 22 Final | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ https://fedoraproject.org/wiki/Package_SCM_admin_requests#Pseudo- users_and_Groups_for_SIGs indicates you can use group:: in owners. According to Jon Ciesla pkgdb complains about this. Does the wiki page need to be changed to have it in the initialcc field instead? -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6156> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#6154: Send out notices and eventually block packages with broken deps before the F22 release
by Fedora Release Engineering 11 May '15

11 May '15

#6154: Send out notices and eventually block packages with broken deps before the F22 release -----------------------------+------------------------ Reporter: kalev | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 22 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ As per https://fedorahosted.org/fesco/ticket/1368#comment:8 , packages with broken dependencies should get blocked in both F22 and rawhide tags before the F22 final freeze. Can releng send out notices to package maintainers and do the blocking, please? Thanks, Kalev -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6154> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

RFC: rel-eng tooling development workflow
by Adam Miller 05 May '15

05 May '15

Hello all, It's recently become somewhat of a recurring theme in the #fedora-releng channel to discuss the Fedora rel-eng tooling development workflow, changes that would like to be seen, and decisions on tools/infra to deliver them. I thought I'd shoot out an email to the list to kick off the conversation in a more formal manner with an initial proposal for feedback. I'm personally a fan of what I'll simply refer to as "the GitHub workflow" by virtue of it's rise in popularity but it boils down to effectively this: 1) Upstream project has a 'master' or 'devel' branch were dev happens 2) Developers fork the repository 3) Developers create "topic branches" (a branch for a specific dev feature/fix) 4) Developer then send a pull request to 'master' or 'devel' for code review 5) Once reviewed and signed off on it is approved and merged Now a couple things to note: First and foremost is that this is by no means the only workflow but just one that has become increasingly popular that I'm a fan of. However, I'm certainly open to other suggestions and opinions but for the sake of my initial proposal and the rest of this email I'll be continuing on with this workflow in mind. Secondly, it has been brought up that the Fedora Rel-Eng team at large does not want to use GitHub because it is non-free software and I'm on board with that. With that second note in mind, there are a decent handful of open source solutions for this and of those there are two "front runners" in my mind for our use since they are written in python and the Fedora team at large has plenty of experience developing and hosting/deploying/administering software written in python. They are: - pagure (http://pagure.dev.fedoraproject.org/) This has been written by Fedora's very own pingou and it satisfies all immediate requirements that I know of (including FAS account integration) and would offer the ability for us to fine-tune it for our needs since it's effectively been developed "in house" but we could also work to make it more popular in the broader community so see if others would like to join and help add even more features to it. - kallithea (https://kallithea-scm.org/) This project has been growing interest and to the best of my knowledge is that it's slated towards being used officially by upstream CPython developers at python.org, however some have mentioned in #fedora-releng that there are missing features that we'd need/want so this might require a bit of initial heavy lifting to add upstream. (also no current support for FAS integration) Alright, with all that said. I'd like to kind of round this back to a set of requirements for the group in terms of the new workflow and tooling: I think everyone agrees that we need: 1) Code Review 2) Easy viewing/reference of code review history 3) Accountability for 1 & 2 If there are others, or things I have left out please let me know. OK, that's it! If you made it this far, I owe you a cookie or something. Please provide feedback, questions, and general snide remarks. Thank you, -AdamM

8 13

#6161: soname version bump of gnutls,nettle in rawhide
by Fedora Release Engineering 05 May '15

05 May '15

#6161: soname version bump of gnutls,nettle in rawhide ------------------+------------------------ Reporter: nmav | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: koji Keywords: | Blocked By: Blocking: | ------------------+------------------------ Hello, I open this ticket due to Updates_Policy. I'd like to update nettle and gnutls to their latest versions in rawhide. This would require a mass rebuild of the packages shown by: repoquery --whatrequires gnutls repoquery --whatrequires nettle Please advise on the process. I plan to update the packages next week. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6161> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 18

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng April 2015