rel-eng March 2016

rel-eng@lists.fedoraproject.org

14 participants
83 discussions

#6369: Please create a f24-gnome side tag
by Fedora Release Engineering 17 May '16

17 May '16

#6369: Please create a f24-gnome side tag -----------------------------+------------------------ Reporter: kalev | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, Please create a new f24-gnome side tag and build target. We'll use it for building GNOME megaupdates before submitting them to Bodhi, to help ensure they don't cause issues in F24 proper while we're preparing the updates. Thanks, Kalev -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6369> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 5

#6376: Missing administrators of several KDE packages
by Fedora Release Engineering 02 May '16

02 May '16

#6376: Missing administrators of several KDE packages -----------------------------+------------------------ Reporter: dvratil | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, shortly after group maintainership was introduced in pkgdb KDE SIG started using it. At some point we submitted several new packages where we set group::kde-sig as an owner. Back then pkgdb allowed that but the result is that now we have a bunch of packages with only group::kde-sig having approved ACLs and thus we are not able to add/approve new ACLs for them or manage the packages. Could you please add me (FAS dvratil) and Rex (FAS rdieter) as package administrators to the packages below? {{{ rpms/kaccounts-integration rpms/kaccounts-providers rpms/kde-cli-tools rpms/kdecoration rpms/kdeedu-data rpms/kf5-kfilemetadata rpms/kf5-kpackage rpms/kf5-kpeople rpms/kf5-kwayland rpms/kf5-kxmlrpcclient rpms/kf5-modemmanager-qt rpms/kf5-networkmanager-qt rpms/khelpcenter rpms/khotkeys rpms/kinfocenter rpms/kio-extras rpms/kmenuedit rpms/ksysguard rpms/kwrited rpms/libkeduvocdocument rpms/libkface rpms/libkgeomap rpms/libkscreen-qt5 rpms/libksysguard rpms/plasma-nm rpms/plasma-pk-updates rpms/plasma-workspace-wallpapers rpms/signon rpms/signon-kwallet-extension rpms/signon-plugin-oauth2 rpms/signon-ui }}} Thanks a lot. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6376> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 4

#6381: Unretire perl-B-Hooks-OP-Check-EntersubForCV in Fedora >= 23
by Fedora Release Engineering 18 Apr '16

18 Apr '16

#6381: Unretire perl-B-Hooks-OP-Check-EntersubForCV in Fedora >= 23 -----------------------------+------------------------ Reporter: ppisar | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Please unretire perl-B-Hooks-OP-Check-EntersubForCV package in Fedora 23 and newer. Package review <https://bugzilla.redhat.com/show_bug.cgi?id=1318969>. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6381> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 3

Retire fedora-releng-dash?
by Ralph Bean 12 Apr '16

12 Apr '16

We have a site up at https://apps.fedoraproject.org/releng-dash that is supposed to trawl through the fedmsg history and display the latest status about our various artifacts (nightlies, live cds, bodhi repos, etc..). With the move to pungi4, we will need to do some repair work on it to get that part working again.. however it crossed my mind that PDC will display a similar set of information. https://pdc.fedoraproject.org/ Question to the list: should we retire fedora-releng-dash and replace it with a redirect to PDC, or bring it up to speed on the pungi4 changes?

6 10

#6289: Add license information to new sphinx docs
by Fedora Release Engineering 10 Apr '16

10 Apr '16

#6289: Add license information to new sphinx docs -----------------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 22 Final | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ With the conversion from the wiki to sphinx, the license information of the content got lost. The wiki contains the statement {{{Content is available under Attribution-Share Alike 3.0 Unported unless otherwise noted.}}}. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6289> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 3

#6373: Please set jdennis as default package maintainer for mod_auth_mellon
by Fedora Release Engineering 10 Apr '16

10 Apr '16

#6373: Please set jdennis as default package maintainer for mod_auth_mellon -----------------------------+------------------------ Reporter: jdennis | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ I have admin rights to mod_auth_mellon (https://admin.fedoraproject.org/pkgdb/package/rpms/mod_auth_mellon/) and I'm taking primary over as the primary package maintainer from Simo (with his approval). At a minimum I need to be set as the default asignee for bugzilla bugs for mod_auth_mellon. Not sure what else needs to be switched over, but what ever it might be please do that as well. Many thanks, John -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6373> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#6382: un-block arquillian-core
by Fedora Release Engineering 09 Apr '16

09 Apr '16

#6382: un-block arquillian-core -----------------------------+------------------------ Reporter: gil | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ arquillian-core was orphaned but has now been re-reviewed and approved for inclusion in Fedora ( https://bugzilla.redhat.com/show_bug.cgi?id=1316195 ) Please un-block it in rawhide, F24, and F23. Thanks in advance Regards -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6382> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#6359: Broken "Broken dependencies" report about noarch package with ExclusiveArch
by Fedora Release Engineering 07 Apr '16

07 Apr '16

#6359: Broken "Broken dependencies" report about noarch package with ExclusiveArch -----------------------------+------------------------ Reporter: ppisar | Owner: rel-eng@… Type: defect | Status: new Milestone: Fedora 24 Alpha | Component: mash Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ I have perl-Dumbbench source package that produces noarch perl- Dumbbench-!BoxPlot package. The package run-requires perl-SOOT that is not available on ARM. Therefore I added an !ExclusiveArch statement into the perl- Dumbbench-!BoxPlot package to prevent from including the package into ARM composes: {{{ ExclusiveArch: %{ix86} x86_64 noarch }}} This is in line packaging guidelines [https://fedoraproject.org/wiki/Packaging:Guidelines#Requires] and it worked for many years. But today, I received this e-mail: {{{ Date: Mon, 29 Feb 2016 22:05:02 +0000 (UTC) From: buildsys(a)fedoraproject.org To: perl-Dumbbench-owner(a)fedoraproject.org Cc: Subject: Broken dependencies: perl-Dumbbench perl-Dumbbench has broken dependencies in the rawhide tree: On armhfp: perl-Dumbbench-BoxPlot-0.10-2.fc24.noarch requires perl(SOOT) }}} I believe a flaw has been introduced into your compose process. Could you fix it? -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6359> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 3

#6383: Build a 'test' compose automatically when installer-related packages change
by Fedora Release Engineering 04 Apr '16

04 Apr '16

#6383: Build a 'test' compose automatically when installer-related packages change ----------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: other Keywords: | Blocked By: Blocking: | ----------------------+------------------------ We have a kind of 'chicken and egg' problem with anaconda updates on Branched after Bodhi activation. We can't test them until we have a compose built with them included, but as things stand, the only way we can get a compose with them included is to push the update stable blind so it goes into nightly composes, or go through the manual 'candidate' / 'production' compose request process. It would be a lot more awesome if we had a nice smooth automated flow here. What I'd like to see on releng side is that when an update containing any installer-related package appears (I'm not sure where we'd want to store the list of packages that should trigger this process, or whose job it should be to maintain it), a 'test' compose is produced entirely automatically which contains that update (the packages from the update would be tagged into some special tag and the compose built from that, most likely). That's a 'test' compose in the Pungi / productmd meaning of the word - Pungi 4 has three compose types, 'nightly', 'production' and 'test', and we haven't used 'test' for anything yet. This seems like a good fit. The rest of the chain would be to run openQA tests on the 'test' compose and then get the results into Bodhi (ideally in such a way that we could automate the stable push, or at least block stable push of completely broken updates), but that's mostly not rel-eng's problem. The only bit that might conceivably involve releng is the question of how we get the results to the right update - it's easy to trigger openQA tests for any new compose that appears, but it's a more interesting problem to know that the results from testing 'Fedora-24-20160401.t.0' or whatever should go to the Bodhi update for 'anaconda-24.14-1.fc24' or whatever. I don't know the best way to do that yet - not sure whether it would make most sense for the thing that builds the test compose to simply log what updates it contains somewhere that can be queried later by the thing that submits the results, or whether the thing that submits the results should have to figure it out somehow from the test compose metadata. Open to ideas there. If this works out, we could of course potentially extend the mechanism for testing other things it makes sense to test at the level of an entire distribution compose, like maybe new kernels and bootloaders and stuff. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6383> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 15

Re: Retiring 32-bit images
by Adam Williamson 30 Mar '16

30 Mar '16

On Wed, 2016-03-23 at 14:37 -0400, Dusty Mabe wrote: > > On 03/23/2016 01:48 PM, Adam Williamson wrote: > > > > Hi, folks! > > > > So I noticed today that F24 nightly composes are missing Cloud images. > > This is, I think, because 32-bit Cloud image generation is still > > enabled for F24, and it's failing due to the known kernel bug > > preventing 32-bit boot working at all: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=13434747 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=13434766 > > https://kojipkgs.fedoraproject.org//work/tasks/4766/13434766/screenshot.ppm > > > > I believe when the i386 image build fails the Koji task fails, and when > > the Koji task fails Pungi just doesn't pull in any of the images - even > > though the x86_64 subtask succeeded and built images. > > > > Obviously we could consider solving that in Pungi somehow, but it led > > me to wondering whether we actually want 32-bit image generation > > enabled at all any more. It seems from this ticket: > > > > https://fedorahosted.org/cloud/ticket/106 > > > > and this meeting discussion: > > > > https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2015-09-09/cloud_wg.… > > > > that the intent was to 'sunset' the i386 images in the F24 cycle. I'm > > not sure whether that means you still want them built, or not. So can > > the WG please clarify if they still want i386 Cloud images to be built > > at all? If not, releng can disable them in the Pungi config. > I don't know if it was every properly communicated to the public, but > I definitely don't want to see 32 bit images any longer. Well no-one else has replied for the last week, so that may be the best we're gonna get...Dennis, maybe we can just go ahead and turn the damn things off now? > Did we ever put a post up on fedmag about this? Can we do one now? I don't recall ever seeing one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng March 2016