January 2019 - rel-eng - Fedora mailing-lists

[pungi-fedora] PR #598: Fedora Minimal Compose for OpenQA testing
by Mohan Boddu 09 Mar '21

09 Mar '21

mohanboddu opened a new pull-request against the project: `pungi-fedora` that you are following: `` Fedora Minimal Compose for OpenQA testing `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/598

5 20

[pungi-fedora] PR #438: Add post-compose rsync script
by Kellin 08 Mar '21

08 Mar '21

kellin opened a new pull-request against the project: `pungi-fedora` that you are following: `` Add post-compose rsync script `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/438

3 2

[pungi-fedora] PR #502: WIP: Add fedora-atomic-ws config
by Colin Walters 08 Mar '21

08 Mar '21

walters opened a new pull-request against the project: `pungi-fedora` that you are following: `` WIP: Add fedora-atomic-ws config `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/502

6 20

[pungi-fedora] Issue #501: Mark compiler-rt as multilib
by Tom Stellard 26 Jan '21

26 Jan '21

tstellar reported a new issue against the project: `pungi-fedora` that you are following: `` The i686 packages for compiler-rt are no longer available in the x86_64 repositories starting with Fedora 27. Could you mark this package as multilb. See https://bugzilla.redhat.com/show_bug.cgi?id=1513286 `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/issue/501

2 3

[pungi-fedora] Issue #426: Convert file sync from one-liner to durable shell script
by Kellin 15 May '20

15 May '20

kellin reported a new issue against the project: `pungi-fedora` that you are following: `` The way we rsync composes today is a one-liner bash script that is not very durable and requires that a release engineer babysit it through the entire four hour rsync process. I am going to make this more durable, however, it will also slightly change our process behind the scenes. Today if a process works or is DOOMED after a full run it is assigned an RC release number. (EG: 1.1, 1.2, 1.3, etc). If the compose fails quickly from something such as a failure to have signed packages then it will not be assigned a release candidate. Per @mohanboddu there is not a durable way to identify the all of the different ways the special case DOOMed composes occur so they will be assigned an RC number after the automation is deployed. The only visible change will be extra gaps in the RC composes in /pub/alt/stage that represent these extra numbers being inserted to the sequence. @mohanboddu is fine with this change; does anyone else have objections? @ausil , @kevin , @puiterwijk please let me know. The initial script PR will be coming within the next two business days. `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/issue/426

4 7

[releng] Issue #7793: Implement new Fedora Security policy for retiring packages with security bugs
by Huzaifa Sidhpurwala 13 Sep '19

13 Sep '19

huzaifas reported a new issue against the project: `releng` that you are following: `` We need to implement the new Fedora Security policy as per: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… "If a CRITICAL or IMPORTANT security issue is currently open against a package, or a security issue of lower severity has been open for at least 6 months, four weeks before the branch point a procedure similar to long-standing FTBFS will be triggered immediately, with 8 weeks of weekly notifications to maintainers and subsequent orphaning and then subsequent removal from distribution. This applies to all packages, not just leaf." So before 4 weeks before the branch point, we need to ensure that: 1. Packages which have any pending critical or important security flaws open ie: https://bugzilla.redhat.com/buglist.cgi?bug_severity=urgent&bug_severity=hi… are marked for FTBS and not built. 2. Packages which have any <important flaws open for atleast 6 months or more ie: https://bugzilla.redhat.com/buglist.cgi?bug_severity=urgent&bug_severity=hi… are marked for FTBS and not build. * When do you need this? 2019-01-01 - Much before the last branch point. * If we cannot complete your request, what is the impact? Fedora 30 will ship lot of insecure packages. Major issue for the release. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7793

5 12

[releng] Issue #7662: Build once, run everywhere seems to be pretty unsupported (modularity)
by Igor Gnatenko 10 Sep '19

10 Sep '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` * Describe the issue Today we've encountered issue that if your modulemd contains something like ```yaml - buildrequires: platform: [f29] requires: platform: [] ``` MBS doesn't tag it properly into f28-* because it checks for buildrequires and not for requires. Which is wrong: https://pagure.io/fm-orchestrator/issue/974 However, @puiterwijk mentioned that bodhi doesn't support this either because it would pick first tag instead of creating updates for multiple ones. It seems that bodhi would need to change some core parts for this. I'm submitting this ticket just to make sure that work is scoped and if can't be completed before F29 bodhi activation point, could be workarounded. * When do you need this? (YYYY/MM/DD) F29 Bodhi activation point. * When is this no longer needed or useful? (YYYY/MM/DD) When modularity dies. * If we cannot complete your request, what is the impact? One of the main use-cases for modularity doesn't work. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662

8 16

[releng] Issue #7555: permission to build livecd for minishift
by Praveen Kumar 10 Sep '19

10 Sep '19

kumarpraveen reported a new issue against the project: `releng` that you are following: `` I am part of minishift[0] development team and currently, we only have support for CentOS and RHEL live iso to provision Openshift locally, we also want to add support for Fedora iso so people can try the latest development around container world. As a starting point we only first try the scratch build of the iso with f28/f29/rawhide. ``` $ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: kumarpraveen(a)FEDORAPROJECT.ORG Valid starting Expires Service principal 06/08/2018 12:31:28 06/09/2018 12:28:38 HTTP/koji.fedoraproject.org(a)FEDORAPROJECT.ORG renew until 06/15/2018 12:28:32 06/08/2018 12:28:38 06/09/2018 12:28:38 krbtgt/FEDORAPROJECT.ORG(a)FEDORAPROJECT.ORG renew until 06/15/2018 12:28:32 $ koji spin-livecd --scratch minishift-fedora 1.0.0 rawhide x86_64 fedora.ks spin-livecd is deprecated and will be replaced with spin-livemedia [====================================] 100% 00:00:00 19.70 KiB 33.12 KiB/sec ActionNotAllowed: livecd permission required ``` [0] https://github.com/minishift/minishift `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7555

5 15

[releng] Issue #7477: Changes for release SOP before f29
by Kevin Fenzi 10 Sep '19

10 Sep '19

kevin reported a new issue against the project: `releng` that you are following: `` This ticket will collect any changes we need to make to the release SOP that were missed in f28 but we should add in f29. We should collect them here and then close this once all of them are merged into the SOP. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7477

5 9

[releng] Issue #7428: Anaconda & bodhi update improvements
by Martin Kolman 10 Sep '19

10 Sep '19

m4rtink reported a new issue against the project: `releng` that you are following: `` I would like to start by saying that the Bodhi update process works just fine for Anaconda during freeze periods - we just build a new version of Anaconda or any of it's related packages with all the blocker a FE fixes, put it to an update and basically hand it over to Fedora QA, who handle the rest (make sure it ends up in the appropriate compose, etc.). Where I think the Bodhi process does not really work are the periods when Fedora is not in freeze (so after Bodhi activation and before Beta freeze and after Beta freeze and before Final freeze). As regular users are rather unlikely to test Installer updates (with the whole "you need to reinstall your machine to test it" thing) so the Anaconda updates generally sit there for the full 7 days (+any Bodhi push overhead) and are then pushed to stable possibly without any testing. Also any changes to the update, such as adding a fixed build or adding additional packages reset karma and (IIRC) also the waiting period. Given that the no-freeze period are generally about two weeks, it's actually pretty challenging to get any regular Anaconda updated to stable at all. This can then result in users getting 6+ weeks (4 weeks freeze, 1-2 weeks in Bodhi) of changes at once, possibly right before the next freeze. Or the update might not even make it in before the next freeze has started due to all the delays, complicating maters further. I'm not sure if there is a simple solution for this (other than "go bother Adam/Fedora QA for each update") but it would be ideal if each Anaconda update would both: - get some actual testing (other than our unit tests/CI) - would reach composes much sooner, making it possible to do more smaller releases outside of the freeze period, making the discovery and fixing of release blocking issues more likely before they can wreak havoc during the freeze period Maybe some more automated CI & some notification mechanism for Fedora QA that fires when new updates for Anaconda shows up ? Ideally with some commitment to tests it & push to stable if it looks fine. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7428

3 4

[releng] Issue #7337: Emit fedmsg when candidate composes are synced to stage
by Adam Williamson 10 Sep '19

10 Sep '19

adamwill reported a new issue against the project: `releng` that you are following: `` Candidate composes (as opposed to nightly composes) for Branched are synced to https://dl.fedoraproject.org/pub/alt/stage/ after they're built. This is supposed to be the preferred download location for them (rather than kojipkgs). However, there is currently no fedmsg emitted when this happens, so automated systems have no good way to know when a candidate compose has been synced and is available from stage/. It would be good if there was a fedmsg for this (probably a `compose` one). @puiterwijk `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7337

3 4

[releng] Issue #7588: F29 system wide change: Deprecate YUM 3 - request for review
by Daniel Mach 06 Sep '19

06 Sep '19

dmach reported a new issue against the project: `releng` that you are following: `` I'd like to request review of F29 system wide change: Deprecate YUM 3 https://fedoraproject.org/wiki/Changes/Deprecate_YUM_3 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7588

9 15

[releng] Issue #8086: Fedora 30 Mass Rebuild
by Mohan Boddu 05 Sep '19

05 Sep '19

mohanboddu reported a new issue against the project: `releng` that you are following: `` * Describe the issue Changes that require mass rebuild for F30 are: https://pagure.io/releng/issue/8023 https://pagure.io/releng/issue/7907 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8086

3 4

[releng] Issue #7909: Consider enabling nosync
by Mikolaj Izdebski 05 Sep '19

05 Sep '19

mizdebsk reported a new issue against the project: `releng` that you are following: `` Please consider turning on [nosync setting in mock](https://github.com/rpm-software-management/mock/wiki/Feature-nosync) on Koji builders. This was brought up in [Removal of GCC from the buildroot](https://lists.fedoraproject.org/archives/list/devel@lists.fedora… thread on devel mailing list in July. Nosync aims to improve performance of dnf phase in mock. It achieves this by disabling fsync calls. Fsync calls are not ignored during rpmbuild phase. For more information see upstream documentation linked above. I temporarily enabled nosync in staging Koji to estimate its effect on build performance. Results will be posted below in separate comments. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7909

6 13

[releng] Issue #7575: Impact check for Fedora 29 change: .plt.got Isolation
by Florian Weimer 05 Sep '19

05 Sep '19

fweimer reported a new issue against the project: `releng` that you are following: `` https://fedoraproject.org/wiki/Changes/.plt.got_Isolation Ideally requires mass rebuild. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7575

5 7

[releng] Issue #7403: Consider no longer producing the Workstation repo tree in composes
by Neal Gompa 05 Sep '19

05 Sep '19

ngompa reported a new issue against the project: `releng` that you are following: `` Recently, we stopped producing [the Cloud repo tree](https://pagure.io/pungi-fedora/pull-request/577) as part of composes to speed things up and reduce the number of useless deliverables. I suggest we also stop producing the Workstation repo tree for composes, as we don't use it or need it. Today, for the Workstation Edition, we produce two main artifacts: the live ISO and the branded netinstall ISO. As far as I'm aware, the branded net install ISO differs from the main Fedora netinstall ISO only in branding and defaults through the anaconda productimg embedded within. It uses the `Everything` repo tree like the regular netinstall ISO, and is functionally similar to the regular netinstall ISO. Since the Workstation netinstall doesn't need it, and we don't produce a Workstation install DVD ISO, I do not see a reason to keep producing the Workstation repo tree. Not producing the tree would help reduce the compose time significantly, too. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403

12 46

[releng] Issue #7445: [RFE][PATCH] make $releasever return "rawhide" on Rawhide
by Kamil Páral 03 Sep '19

03 Sep '19

kparal reported a new issue against the project: `releng` that you are following: `` **Background** If we want to have a more reliable and stable Rawhide, we need to make it easier to test and automate. That means eliminating the differences between Rawhide and stable releases and reducing the necessary manual maintenance steps as much as possible. You can read more about related issues in https://pagure.io/releng/issue/7398 and https://pagure.io/copr/copr/issue/267. **Problem** Currently dnf variable `$releasever` returns a number (29) on Rawhide, but all the repos are stored in `rawhide/` directory, not `29/` (as with stable releases). There are good reasons for this, but it has consequences. It forces the official fedora repos to be split between `fedora-repos` and `fedora-repos-rawhide` (because you can't rely on a variable and have to hardcode "rawhide" in the repo path) and breaks copr and any other third-party repos. Basically for all repos, you need to have two separate versions - rawhide and non-rawhide - and always correctly detect and install the right one. I'd like to propose improvements in this area and discuss it with you in this ticket. **Proposed solution 1** Here's a trivial patch for `fedora-release`: ``` diff --git a/fedora-release.spec b/fedora-release.spec index ecca47f..b4b66f2 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,6 +1,7 @@ %define release_name Rawhide %define dist_version 29 %define bug_version rawhide +%define releasever rawhide # All changes need to be submitted as pull requests in pagure # The package can only be built by a very small number of people @@ -19,6 +20,7 @@ Obsoletes: redhat-release Provides: redhat-release Provides: system-release Provides: system-release(%{version}) +Provides: system-release(releasever) = %{releasever} # Kill off the fedora-release-nonproduct package Provides: fedora-release-nonproduct = %{version} ``` This adds provision `system-release(releasever) = rawhide` to the `master` branch of `fedora-release`. Therefore, this provision will only be present for Rawhide version of that package. It uses DNF's [detect_releasever()](https://github.com/rpm-software-management/dnf/blob/65… logic to populate `$releasever` with `rawhide` string (the new provides) instead of `29` (the version of the package). (Note: This is currently broken in DNF due to a [bug](https://bugzilla.redhat.com/show_bug.cgi?id=1568366), but it will be fixed in the next DNF release). The outcome is that all repos can now use `$releasever` in URLs, because it will get replaced by `rawhide` and therefore reach the correct destination. That means you can use the same repo file as in a stable release for COPR or other third-party repo and it will work fine. If the user wants to switch to Branched after branching has happened, they'd run e.g.: ``` sudo dnf distrosync fedora-release\* --releasever=28 ``` **Proposed solution 2** This is a similar approach to the first solution, but creates a `fedora-release-rawhide` subpackage: ``` diff --git a/fedora-release.spec b/fedora-release.spec index ecca47f..74637f1 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,6 +1,7 @@ %define release_name Rawhide %define dist_version 29 %define bug_version rawhide +%define releasever rawhide # All changes need to be submitted as pull requests in pagure # The package can only be built by a very small number of people @@ -33,6 +34,15 @@ BuildArch: noarch %description Fedora release files such as various /etc/ files that define the release. +%package rawhide +Summary: Fedora release files for Rawhide +Provides: system-release(releasever) = %{releasever} +Requires: fedora-release = %{version}-%{release} + +%description rawhide +This identifies the system as Rawhide for the package manager, causing Rawhide +repositories to be used. + %package atomichost Summary: Base package for Fedora Atomic-specific default configurations Provides: system-release-atomichost @@ -315,6 +325,9 @@ glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || : %{_prefix}/lib/systemd/system-preset/99-default-disable.preset +%files rawhide + + %files atomichost %{!?_licensedir:%global license %%doc} %license LICENSE ``` The difference here is that you can install/uninstall `fedora-release-rawhide` any time at will, which marks/unmarks your system to be following the Rawhide stream. The benefit is that you can switch your system from Rawhide to Branched before the branching actually happens, and your system automatically picks up the right repos after branching (which is awesome, especially for our automation needs). The downside is that both `rawhide/` and `29/` repo URLs/paths need to be present and working during the whole life cycle of Rawhide, so that you can switch any time. And this doesn't apply just to official Fedora repos, but ideally also to COPR and other third-party repos. COPR devs [wanted to avoid](https://pagure.io/copr/copr/issue/267) duplicated content or maintaining symlinks, but I guess they could be convinced. But other third-party repos might not follow this approach and the whole concept might be confusing for them (however, a good question is how many of those repos actually work on Rawhide already). So to summarize, this is how you'd switch your system to Rawhide: ``` # use dnf system-upgrade to upgrade to Rawhide sudo dnf install fedora-release-rawhide ``` And switching from Rawhide to Branched: ``` sudo dnf remove fedora-release-rawhide sudo dnf distrosync # if branching already happened ``` Fresh Rawhide installation would receive `fedora-release-rawhide` by default, of course. Overall, this adds more user control at the expense of more infra work. Not sure if this is worth it or not. **Proposed solution 3** For the sake of completeness, I'll mention another approach how to achieve the goal without using new RPM provides. `$releasever` value can be overridden by a file like this: ``` $ cat /etc/dnf/vars/releasever rawhide ``` If this file was owned by `fedora-release-rawhide`, it would be very similar to solution 2 - you can switch the Branched/Rawhide stream any time. The implementation detail here is whether to mark this file as a config file or not, so that it doesn't e.g. stay around even after you remove `fedora-release-rawhide`, or that it doesn't e.g. conflict with an already existing file at that location (if the user wanted to override `$releasever` already for any reason). Solution 2 seems a bit cleaner here because you don't need to bother with corner cases involving config file management. **Possible future steps for Fedora Releng** Once `$releasever` returns `rawhide` on Rawhide, you can (if you wish) drop `fedora-repos-rawhide` and use the same `fedora-repos` package everywhere (ideally also create empty `updates/rawhide` and `updates/testing/rawhide` repos as requested in https://pagure.io/releng/issue/7398) Some repo properties will still probably have different values (like `metadata_expire`), but that can be easily adjusted in the spec file and you can have the same source tarball for all releases, if you wish. This would make the environment even more consistent for users (the repo names would be named the same in all releases). **Known pitfalls** There's one known problem with any of the approaches suggested above, called PackageKit. PackageKit doesn't use DNF to figure out `$releasever`, nor it uses the same logic. Instead, it parses `VERSION_ID` from `/etc/os-release` ([source1](https://github.com/hughsie/PackageKit/blob/2f1c4b820b056efc989be0f…, [source2](https://github.com/hughsie/PackageKit/blob/1e7858b1b67120b377adcb3…) So any changes described here will not apply to PackageKit and it will still return a number (e.g. 29) as `$releasever`. That is something that of course needs to get resolved as well, but before investing time into fixing it, I first wanted to know whether this whole idea gets approved or not. There are several approaches how to fix this in PackageKit, either retrieving `$releasever` from libdnf (when on Fedora), or implementing the same detection logic as in DNF, or perhaps adding `VERSION_CODENAME=Rawhide` to `/etc/os-release` and then special-casing this in PackageKit (however, this would break if solution 2 or 3 is used and the user can switch between streams arbitrarily). However, I'd like to first talk about the concept itself, and only after that start hammering out the implementation details with PackageKit developers. **Discussion** Please tell me what do you think about the proposed changes. Does it make sense? Have I overlooked something important? Are there better ways to solve the aforementioned issues? Thank you. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7445

10 46

[releng] Issue #7718: The FTBFS cleanup policy is not happening
by Miro Hrončok 24 Jul '19

24 Jul '19

churchyard reported a new issue against the project: `releng` that you are following: `` The https://fedoraproject.org/wiki/Fails_to_build_from_source policy says: > If a FTBFS bug remains in NEW state, a weekly reminder will be sent. This never happened. (Opened also as https://pagure.io/fesco/issue/1973 - feel free to close the less appropriate one.) `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7718

6 45

[releng] Issue #7606: F29 system wide change: uEFI for ARMv7
by Peter Robinson 17 Jul '19

17 Jul '19

pbrobinson reported a new issue against the project: `releng` that you are following: `` https://fedoraproject.org/wiki/Changes/uEFIforARMv7 Change for uEFI on ARMv7. There will need to be a new version of oz deployed on aarch64 builder userd for building images to enable us to build ARMv7 images on those devices. I will co-ordinate with infra/rel-eng to deploy and test this on stage/prod infrastructure, and once deployed and tested will provide a PR with the pungi config changes (minor) to enable this in the nightly composes. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7606

3 5

[releng] Issue #7996: Taking over Hoard
by Emery D Berger 17 Jul '19

17 Jul '19

emeryberger reported a new issue against the project: `releng` that you are following: `` * Hoard has been orphaned; I am claiming it and taking it over. (I am the author and maintainer of Hoard.) `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7996

5 16

[releng] Issue #7490: container/waiverdb has no f28 branch?
by Ralph Bean 17 Jul '19

17 Jul '19

ralph reported a new issue against the project: `releng` that you are following: `` It has master and f27, but no f28. Did it get missed in mass-branching? As packagers, we're disallowed by dist-git to push the branch ourselves. /cc @gnaponie `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7490

4 7

[releng] Issue #8092: Change impact: Python 3.8
by Miro Hrončok 17 Jul '19

17 Jul '19

churchyard reported a new issue against the project: `releng` that you are following: `` https://fedoraproject.org/wiki/Changes/Python3.8 * we'll need a side tag `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8092

3 3

[releng] Issue #7498: Support on-the-fly tarball generation in Koji
by Florian Weimer 08 Jul '19

08 Jul '19

fweimer reported a new issue against the project: `releng` that you are following: `` I've just filed this fedpkg-minimal feature request: * https://bugzilla.redhat.com/show_bug.cgi?id=1578348 It would be great if we could get this to work on Fedora Koji, with a suitable whitelist of supported repositories. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7498

12 43

[releng] Issue #7393: perl component is missing from Fedora/Fedora Module product in Bugzilla
by Petr Pisar 08 Jul '19

08 Jul '19

ppisar reported a new issue against the project: `releng` that you are following: `` Bugzilla finally contains component for modules. But "perl" is still missing there (in contrast to "perl-bootstrap"). Please create "perl" component in Fedora/Fedora Module product with default assignee "ppisar(a)redhat.com". `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7393

4 12

[releng] Issue #7400: Rethink how we handle networking config with createImage (oz / ImageFactory)
by Adam Williamson 03 Jul '19

03 Jul '19

adamwill reported a new issue against the project: `releng` that you are following: `` I spent a bit of time digging into the issues around https://pagure.io/fedora-kickstarts/pull-request/366 this morning, and I figure we can improve this area more generally, but I don't think the optimal path is *completely* obvious, so I thought I'd file an issue for discussion before filing any PRs. As things stand, I believe, for all `createImage` tasks, we wind up with oz running the installer in a VM such that a single network interface is brought up, using a udev 'persistent' name. anaconda then writes out an ifcfg file for that 'persistent' name - e.g. `ifcfg-ens3` or `ifcfg-ens0p3` or something - to the installed system. If you poke about in fedora-kickstarts a bit, you'll find that five kickstarts then do stuff to try and 'clean this up'. We can ignore `fedora-cloud-bigdata` and `fedora-cloud-experimental`, I think, so we're left with `fedora-atomic`, which does this: bootloader --timeout=1 --append="no_timer_check console=tty1 console=ttyS0,115200n8 console=ttyAMA0 console=hvc0 net.ifnames=0" network --bootproto=dhcp --device=link --activate --onboot=on .... # Remove any persistent NIC rules generated by udev rm -vf /etc/udev/rules.d/*persistent-net*.rules # And ensure that we will do DHCP on eth0 on startup cat > /etc/sysconfig/network-scripts/ifcfg-eth0 << EOF DEVICE="eth0" BOOTPROTO="dhcp" ONBOOT="yes" TYPE="Ethernet" PERSISTENT_DHCLIENT="yes" EOF .... # For trac ticket https://pagure.io/atomic-wg/issue/128 rm -f /etc/sysconfig/network-scripts/ifcfg-ens3 `fedora-cloud-base`, which does this: bootloader --timeout=1 --append="no_timer_check net.ifnames=0 console=tty1 console=ttyS0,115200n8" network --bootproto=dhcp --device=link --activate --onboot=on .... # When we build the image with oz, dracut is used # and sets up a ifcfg-en<whatever> for the device. We don't # want to use this, we use eth0 so it is always the same. # So we remove all these ifcfg-en<whatever> devices so # The 'network' service can come up cleanly. rm -f /etc/sysconfig/network-scripts/ifcfg-en* And `fedora-disk-base`, which does this: network --bootproto=dhcp --device=link --activate bootloader --timeout=1 # The enp1s0 interface is a left over from the imagefactory install, clean this up rm -f /etc/sysconfig/network-scripts/ifcfg-enp1s0 Note they all do something different for trying to remove the 'predictably'-named interface configuration produced by the installer. We touched the `cloud-base` version most recently, and it's most probably the best approach. `disk-base` doesn't try to disable 'persistent' naming for the installed system, which I believe is intentional and correct, as that kickstart is for the ARM disk images which will be booted on real hardware with potentially varying network adapters and should probably respect the distro default to use 'persistent' naming on real hardware. I don't know how this results in the network coming up on first boot of these images, if it even does, but hey, that seems a bit out of scope. `atomic` and `cloud-base` both try to disable 'persistent' naming for the installed system. `cloud-base` used to try and do it just by removing udev rules, which was dumb, so @nirik recently changed that to add `net.ifnames=0` to the kickstart `bootloader` line, which basically disables udev 'predictable' naming (the udev rules will see the param and not rename the device). `atomic` seems to do a belt-and-braces approach ATM: it *both* sets `net.ifnames=0` in the `bootloader` line *and* tries to remove udev rules, badly (they don't live in `/etc/udev/rules.d` any more). One obvious cleanup would be to make all three use the `rm -f /etc/sysconfig/network-scripts/ifcfg-en*` strategy for removing the 'predictably'-named interface config file. Another obvious cleanup would be to take the udev rule deletion bits out of `fedora-atomic`, since they're not doing anyone any good there. There is another thing we can do, though. oz actually permits (since https://github.com/clalancette/oz/commit/14ad1922aa8c0922aaa2a3f9e52daa2692… , I think that's version 0.13.0) the passing of arbitrary extra kernel parameters to the installer, at least for the RHEL/Fedora 'url' install type, which is what `createImage` uses. You just have to add a `kernelparam` entry to the template. We could send a PR for Koji to use this to disable 'predictable' interface naming during the image creation; either to just *always* include a `kernelparam` value of `biosdevname=0 net.ifnames=0` for `createImage` tasks, or to make this configurable via the command line somehow and then have pungi / pungi-fedora pass it in for the images we want to use it for (handwave handwave). This should mean anaconda would write an `ifcfg-eth0` into the installed system, and for Atomic and Cloud images, in theory we wouldn't have to mung *anything* in the kickstart. @kevin points out that the file might in fact specify a MAC address, which we would have to filter out, but we might be able to tweak the kickstart to avoid that, I'll look into it. For ARM images, we'd just want to tweak the kickstart to remove that `ifcfg-eth0` file instead of the name it currently tries to remove - but this is slightly *better* than the current situation, where we've had at least one case where the 'predictable' interface name suddenly became unpredictable. At least in this particular workflow, the name `eth0` for the sole interface used during the image build should be *truly* predictable. Anyway, that's where I'm up to. Thoughts / comments / ideas on this? @kevin @mohanboddu @dustymabe @walters @mikem @lsedlar `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7400

4 6

[releng] Issue #7288: Request permissions to untag packages
by Jason ティビツ 26 Jun '19

26 Jun '19

tibbs reported a new issue against the project: `releng` that you are following: `` So I know I used to be able to untag a package but now that fails due to me not having autosign permissions (and probably other things). Today I merged a PR against redhat-rpm-config but wasn't able to test it sufficiently locally due to my local rawhide box not having received gcc 8 yet. I foolishly built it anyway and immediately broke all of rawhide. 100% my fault. It's a one line fix, but I can't untag it and nobody is online with permissions to do so. Since as of late I have been doing a number of changes to that and other related packages which can potentially break all of rawhide/fedora/epel, it would be useful for me to be able to untag in case something goes wrong. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7288

5 9

[releng] Issue #7753: Permission to change package owner (to reassign packages from nonrepsonsive packager procedure)
by Miro Hrončok 25 Jun '19

25 Jun '19

churchyard reported a new issue against the project: `releng` that you are following: `` * Describe the issue Recently, i deal with a lot of nonrepsonsive packagers and people ask to be assigned to those. I open releng tickets. It's a bit tedious. I cannot imagine how tedious this is for releng. Can I please be granted permission to reassign packages to different users? This might be the cvsadmin group. I'm already a provenpackager and I would only use this once the nonrepsonsive packager process is approved by FESCo. * When do you need this? The sooner the better. * When is this no longer needed or useful? This is always useful. * If we cannot complete your request, what is the impact? A lot of releng tickets from me. Thank you. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7753

5 23

[releng] Issue #7265: blender git repo contains large files causing git checkout to timeout during builds
by Richard Shaw 24 Jun '19

24 Jun '19

hobbes1069 reported a new issue against the project: `releng` that you are following: `` ``` From checkout.log: $ git clone -n https://src.fedoraproject.org/rpms/blender.git /var/lib/mock/f28-build-11036148-838686/root/tmp/scmroot/blender Cloning into '/var/lib/mock/f28-build-11036148-838686/root/tmp/scmroot/blender'... error: RPC failed; curl 18 transfer closed with outstanding read data remaining fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header ``` ``` $ git rev-list --objects --all | grep "\.rpm\|\.gz" 6115a22040643818e89404f301faa1d4a4ce4a56 results_blender/2.77a/1.fc23/blender-2.77a-1.fc24.src.rpm 2340a78e377e89c3a3b751a997ce0a563a9714ff results_blender/2.77a/1.fc23/blender-2.77a-1.fc24.x86_64.rpm 7966c177500299784bcaa963381f14b74eddc108 results_blender/2.77a/1.fc23/blender-debuginfo-2.77a-1.fc24.x86_64.rpm 014423f48c5697e0c256cc93c789823800883d85 results_blender/2.77a/1.fc23/blender-rpm-macros-2.77a-1.fc24.noarch.rpm e2e943ce223ac62904fde4717ceac8e4f3387018 results_blender/2.77a/1.fc23/blenderplayer-2.77a-1.fc24.x86_64.rpm e3c53ce853edd37b76bc5b4d422f85b14a1a10c5 results_blender/2.77a/1.fc23/fonts-blender-2.77a-1.fc24.noarch.rpm 5b6716c806f9ef18beaeed55beb07b2c162179b6 results_blender/2.77a/1.fc26/blender-2.77a-1.fc26.src.rpm 12a5eee6eb79f3ec8c257cc4b02a16e1c0774966 results_blender/2.77a/1.fc26/blender-2.77a-1.fc26.x86_64.rpm 8a7e6d7dc970f5b1fdd66e9a9e57e814db4de9a2 results_blender/2.77a/1.fc26/blender-debuginfo-2.77a-1.fc26.x86_64.rpm ac7b7d731e06bf30deb8cfcbbf2a7002b3cef7c4 results_blender/2.77a/1.fc26/blender-rpm-macros-2.77a-1.fc26.noarch.rpm 9b783965dbe33cdc8a670a70d5212e62442094ec results_blender/2.77a/1.fc26/blenderplayer-2.77a-1.fc26.x86_64.rpm dee39b967a93774562690fc7a898013bbdd831e5 results_blender/2.77a/1.fc26/fonts-blender-2.77a-1.fc26.noarch.rpm 7bffb5068eb55df30d688d8608cd9264a77c8cf3 results_blender/2.78/1.fc26/blender-2.78-1.fc26.src.rpm c89795526e03033ff0255495f94ced42cea86271 results_blender/2.78/1.fc26/blender-2.78-1.fc26.x86_64.rpm 12907ae1397483d284498820e3fac62ad7e17c07 results_blender/2.78/1.fc26/blender-debuginfo-2.78-1.fc26.x86_64.rpm b518a731b7f38961433cbf8f6b2b9c4716fce785 results_blender/2.78/1.fc26/blender-rpm-macros-2.78-1.fc26.noarch.rpm 4cd2e44e3562eb77ddf4c3193e80f69389469090 results_blender/2.78/1.fc26/blenderplayer-2.78-1.fc26.x86_64.rpm 6459a4e4cf1ac226117b091ddd7a59bec6cfc6b5 results_blender/2.78/1.fc26/fonts-blender-2.78-1.fc26.noarch.rpm 30bb773c1b4242fdb48b33788e53374a4a900e14 blender-2.77a-1.el7.src.rpm a6c477b254d54ebe07ed11df6b2ec41e132ddded blender-2.77a-1.fc23.src.rpm a34c5c49de2fcd378e3d7f74cecfc1dcf77082af blender-2.77a-1.fc26.src.rpm e17f27a4415c31a747f76e10a68e592bf5d25b47 blender-2.78-1.el7.src.rpm 0e7cb8ad4bf7571ac1123c853e5636854e622124 blender-2.78-1.fc26.src.rpm a4a9f0f6a24e622799cfefccf1804cae48cdfcae blender-2.78.tar.gz ``` Can these files be removed? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7265

7 12

[releng] Issue #8080: rsync temporaries under /alt/risc-v
by Jason ティビツ 20 Jun '19

20 Jun '19

tibbs reported a new issue against the project: `releng` that you are following: `` I've talked about this in IRC, but I figured I would open an issue for it. Whatever process is responsible for copying content into /alt/risc-v does so by calling rsync without --delay-updates. This means that rsync temporaries can appear anywhere in that directory structure. These temporaries are world-readable, and so the file list generator will include them in the file listings of the mirror. So quick-fedora-mirror will try to copy them, and this causes a failure: ``` Looks like the file list is outdated. rsync: link_stat "/alt/risc-v/repo/fedora/29/24607/src/Packages/i/.initial-setup-0.3.62-2.fc29.src.rpm.UQ5u2x" (in fedora-buffet0) failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1659) [generator=3.1.3] rsync failed; aborting run. Will not check in or delete anything. ``` This seems to happen a couple of times a week, though of course it's quite random. The simplest solution seems to me to be to call rsync with --delay-updates. This will make rsync store the temporaries in a directory named `.~tmp~` which the file list generator and other rsync process should conveniently skip. It's much easier to skip one file with a weird name than it is to try and figure out what might be an rsync temporary. (Starts with a dot and ends with a dot followed by maybe six alphanumerics is the best we could do, which doesn't seem particularly safe.) `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8080

6 9

[releng] Issue #7995: Automate Unretirement and Unorphan procedures
by Mohan Boddu 19 Jun '19

19 Jun '19

mohanboddu reported a new issue against the project: `releng` that you are following: `` * Describe the issue Currently its a manual process to unretire a package and it is described in https://docs.pagure.org/releng/sop_unretire.html (unorphan is nothing but assigning the package to the requestor which is also part of that sop - https://docs.pagure.org/releng/sop_unretire.html#verify-package-is-not-orph…) It would be great if the process is automated. It cannot be fully automated, but a script that runs the unretirement rather than running each step manually. * When do you need this? (YYYY/MM/DD) Sooner the better * When is this no longer needed or useful? (YYYY/MM/DD) There will be always unretirement requests * If we cannot complete your request, what is the impact? Someone has to run the steps manually every time there is a unretirement request. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7995

7 12

[releng] Issue #7469: some packages were not properly rebuilt for F29 mass rebuild
by Till Maas 18 Jun '19

18 Jun '19

till reported a new issue against the project: `releng` that you are following: `` Example: https://src.fedoraproject.org/rpms/sepolicy_analysis/commits/master -> commit for mass rebuild https://koji.fedoraproject.org/koji/packageinfo?packageID=23907 -> no build by releng I will rebuild all packages that might not have been rebuilt, but it would be great to investigate what went wrong and make sure that this does not happen next time. I am currently looking at packages that did not get any successful rebuild and did not get a bug report that they fail to be built for F29, so this list does probably contain other packages that were affected: ``` 0install 0xFFFF Fedora-Live-Astronomy_KDE Fedora-Live-Cinnamon Fedora-Live-Design_suite Fedora-Live-Games Fedora-Live-KDE Fedora-Live-LXDE Fedora-Live-Robotics Fedora-Live-Scientific_KDE Fedora-Live-Security Fedora-Live-SoaS Fedora-Live-Workstation Fedora-Live-Xfce NearTree R-xtable adevs ascii-design auriferous brewtarget calamaris centerim clojure compat-gcc-32 dia-gnomeDIAicons dnssec-tools elasticsearch elixir fbdesk fbreader fetchlog freehdl gauche-gtk gcc-python-plugin gimmix git-cola git-ftp git-octopus gitstats gnome-pie gnomint golang-github-xiang90-probing hawtbuf hawtdispatch hoard holland homerun howl-logger html401-dtds htmlparser http-builder httpcomponents-asyncclient httpdtap jam-control kanyremote kguitar libvirt-java libyahoo2 lightcouch linode-cli littleproxy localizer log4j-jboss-logmanager logisim londonlaw lorem-ipsum-generator lovelock-kde-theme lpf lshell lua-alt-getopt lua-argparse lua-copas lua-coxpcall lua-fun lua-moonscript lua-term lure lxqt-build-tools lxqt-common lxqt-l10n lzma-java m4ri m4rie maatkit mahout-collection-codegen-plugin maildirproc mailgraph man-pages-cs man-pages-de man-pages-es man-pages-it man-pages-ko man-pages-zh-CN mantis manuale mapdb marave marked mathjax maven-ant-plugin maven-archetype maven-changelog-plugin maven-deploy-plugin maven-docck-plugin maven-downloader maven-ear-plugin maven-ejb-plugin maven-gpg-plugin maven-help-plugin maven-hpi-plugin maven-idea-plugin maven-injection-plugin maven-jarsigner-plugin maven-jsf-plugin maven-jxr maven-license-plugin maven-mapping maven-native maven-osgi maven-patch-plugin maven-processor-plugin maven-project-info-reports-plugin maven-rar-plugin maven-repository-builder maven-repository-plugin maven-shared-jar maven-shared-jarsigner maven-shared-resources maven-site-plugin maven-stage-plugin maven-stapler-plugin maven-toolchains-plugin maven-verifier-plugin maven-war-plugin mavibot maxmind-db-java mbassador mckoi mcollective mcollective-qpid-plugin mcu8051ide mediawiki-HTTP302Found mediawiki-intersection mediawiki-semantic mediawiki-validator mediawiki-wikicalendar megaglest megaglest-data memoryfilesystem mencal metadata-extractor2 metainf-services mgarepo mhwaveedit microba midisport-firmware midori miglayout migrationtools mimepull mingw-GConf2 mingw-SDL mingw-SDL2 mingw-SDL2_image mingw-SDL2_mixer mingw-SDL_image mingw-SDL_mixer mingw-admesh mingw-antlr mingw-atkmm mingw-bzip2 mingw-cairo mingw-cairomm mingw-celt051 mingw-clucene mingw-cmocka mingw-colord mingw-colord-gtk mingw-colorhug-client mingw-cppunit mingw-crossreport mingw-crt mingw-cximage mingw-cxxtest mingw-dbus mingw-dirac mingw-dlfcn mingw-fftw mingw-freeglut mingw-ftplib mingw-gdb mingw-gdbm mingw-gettext mingw-giflib mingw-gmp mingw-gnutls mingw-goocanvas2 mingw-gsl mingw-gstreamer mingw-gstreamer-plugins-base mingw-gtk2 mingw-gtkglext mingw-gtkmm24 mingw-gtksourceview3 mingw-gtkspell3 mingw-gtkspellmm30 mingw-headers mingw-icu mingw-id3lib mingw-jasper mingw-jxrlib mingw-lcms mingw-libIDL mingw-libarchive mingw-libcroco mingw-libffi mingw-libgcrypt mingw-libgeotiff mingw-libglade2 mingw-libglademm24 mingw-libgnurx mingw-libgovirt mingw-libgpg-error mingw-libidn mingw-libjpeg-turbo mingw-libltdl mingw-libmicrohttpd mingw-libmng mingw-libogg mingw-liboil mingw-libosinfo mingw-libpng mingw-libsigc++20 mingw-libsigsegv mingw-libsqlite3x mingw-libssh2 mingw-libtiff mingw-libusbx mingw-libvirt-glib mingw-libvorbis mingw-libxml++ mingw-libxml2 mingw-libxslt mingw-llvm mingw-mpfr mingw-nettle mingw-nsiswrapper mingw-opusfile mingw-pangomm mingw-pcre mingw-pdcurses mingw-physfs mingw-pixman mingw-plotmm mingw-portablexdr mingw-proj mingw-qpid-cpp mingw-qt mingw-qt5-qtsystems mingw-qwt mingw-readline mingw-rest mingw-sane-backends mingw-sigar mingw-speex mingw-spice-protocol mingw-srvany mingw-termcap mingw-tesseract mingw-usbredir mingw-webkitgtk mingw-webkitgtk3 mingw-win-iconv mingw-wine-gecko mingw-winpthreads mingw-winstorecompat mingw-wpcap mingw-wxWidgets mingw-xerces-c mingw-xz mingw-zfstream mingw-zlib minidns minimal-json minlog minutor mirmon mkproject mnemonicsetter moconti mod_auth_cas mod_perl mod_ruid2 mod_security_crs module-macros moin mojarra mojo-keytool mongo-java-driver2 monitor-edid monkeystudio mono-cecil-flowanalysis mono-tools monochrome-icon-theme monodevelop morfologik-stemming morphia mozilla-googlesharing mozjs24 mozldap mozvoikko mqtt-client multibit-commons multibit-hardware multiverse munin mussh mustache-java mybashburn mybatis mybatis-generator mybatis-parent mycila-licenses mylvmbackup myrepos mysema-apt-maven-plugin mysema-commons-lang mysql-connector-java mysqlreport mysqltuner mythes-bg mythes-ca mythes-da mythes-el mythes-fr mythes-ga mythes-hu mythes-it mythes-mi mythes-ne mythes-nl mythes-pt mythes-ro mythes-ru mythes-sv mythes-uk mytop nacl-arm-gcc naev-data naga nagios-plugins-check-updates nar-maven-plugin narayana native2ascii-maven-plugin ncbi-blast+ neko-htmlunit nekohtml neon-backgrounds netbeans-javaparser netbeans-svnclientadapter netcdf-cxx4 netstat-monitor netty-xnio-transport netty3 neurord newtonsoft-json nexcontrol nextcloud nickle nik4 nikto ninja-ide nipy-data nmbscan node-gyp nodejs-abbrev nodejs-after nodejs-ain2 nodejs-alter nodejs-amdefine nodejs-ansi-cyan nodejs-ansi-green nodejs-ansi-magenta nodejs-ansi-regex nodejs-ansi-styles nodejs-ansi-wrap nodejs-ansi-yellow nodejs-ansicolors nodejs-ansidiff nodejs-ansistyles nodejs-any-promise nodejs-append-transform nodejs-aproba nodejs-archiver-utils nodejs-archy nodejs-are-we-there-yet nodejs-argsparser nodejs-arr-exclude nodejs-arr-union nodejs-array-filter nodejs-array-flatten nodejs-array-foreach nodejs-array-index nodejs-array-map nodejs-array-reduce nodejs-array-union nodejs-array-uniq nodejs-array-unique nodejs-arrify nodejs-ascli nodejs-asn1 nodejs-assert-plus nodejs-ast-traverse nodejs-ast-types nodejs-astral nodejs-astral-angular-annotate nodejs-astral-pass nodejs-async-array-reduce nodejs-async-some nodejs-aws-sign nodejs-aws-sign2 nodejs-babel-runtime nodejs-backbone nodejs-base64-url nodejs-basic-auth nodejs-basic-auth-connect nodejs-basic-auth-parser nodejs-batch nodejs-beeper nodejs-benchmark nodejs-better-assert nodejs-bignumber-js nodejs-block-stream nodejs-boolbase nodejs-boom nodejs-breakable nodejs-buf-compare nodejs-buffer-crc32 nodejs-buffer-equal nodejs-builtin-modules nodejs-builtins nodejs-bundle-dependencies nodejs-bunker nodejs-burrito nodejs-caching-transform nodejs-call-signature nodejs-camel-case nodejs-caniuse-db nodejs-carrier nodejs-caseless nodejs-change-case nodejs-char-spinner nodejs-character-parser nodejs-charm nodejs-child-process-close nodejs-chmodr nodejs-chownr nodejs-cjson nodejs-clean-yaml-object nodejs-cli nodejs-cli-color nodejs-cli-spinner nodejs-cliui nodejs-clone nodejs-clone-stats nodejs-cls nodejs-co nodejs-co-mocha nodejs-code-point-at nodejs-codemirror nodejs-collections nodejs-columnify nodejs-combined-stream nodejs-commander nodejs-commondir nodejs-commoner nodejs-commonmark nodejs-component-emitter nodejs-component-indexof nodejs-compress-commons nodejs-compressible nodejs-concat-map nodejs-connect-livereload nodejs-connect-timeout nodejs-console-browserify nodejs-console-dot-log nodejs-constant-case nodejs-constantinople nodejs-cookie-jar nodejs-cookie-parser nodejs-cookiejar nodejs-couch-login nodejs-coveralls nodejs-cross-spawn-async nodejs-cryptiles nodejs-css nodejs-css-parse nodejs-csslint nodejs-cssom nodejs-csurf nodejs-csv-generate nodejs-csv-spectrum nodejs-ctype nodejs-currently-unhandled nodejs-cycle nodejs-dashdash nodejs-date-now nodejs-decamelize nodejs-deep-is nodejs-deeper nodejs-default-require-extensions nodejs-defaults nodejs-defence-cli nodejs-deferred nodejs-defs nodejs-del nodejs-delayed-stream nodejs-delegates nodejs-dep-graph nodejs-deprecated nodejs-detect-file nodejs-diff nodejs-difflib nodejs-docopt nodejs-doctrine nodejs-dom-serializer nodejs-domelementtype nodejs-domhandler nodejs-domutils nodejs-dot-case nodejs-dotfile-regex nodejs-dreamopt nodejs-dryice nodejs-duplexer2 nodejs-duration nodejs-each nodejs-each-async nodejs-ebnf-parser nodejs-ee-first nodejs-ejs nodejs-emojione nodejs-encodeurl nodejs-entities nodejs-errorhandler nodejs-es5-ext nodejs-es5-shim nodejs-es6-iterator nodejs-es6-map nodejs-es6-set nodejs-es6-shim nodejs-es6-symbol nodejs-es6-weak-map nodejs-escape-html nodejs-escape-regexp-component nodejs-escape-string-regexp nodejs-esprima-harmony-jscs nodejs-esrecurse nodejs-estraverse-fb nodejs-event-emitter nodejs-eventemitter2 nodejs-events nodejs-events-to-array nodejs-exit nodejs-expect nodejs-expect-dot-js nodejs-extend nodejs-extend-shallow nodejs-extsprintf nodejs-eyes nodejs-fancy-log nodejs-far nodejs-fast-levenshtein nodejs-faye-websocket nodejs-fd-slicer nodejs-file-entry-cache nodejs-file-sync-cmp nodejs-filename-regex nodejs-fileset nodejs-find-cache-dir nodejs-first-chunk-stream nodejs-flagged-respawn nodejs-flot nodejs-fn-dot-name nodejs-fn-name nodejs-forever-agent nodejs-formatio nodejs-formidable nodejs-fs-exists-sync nodejs-fs2 nodejs-ftp nodejs-gauge nodejs-gaze nodejs-generate-function nodejs-generate-object-property nodejs-generic-pool nodejs-get-port nodejs-get-stdin nodejs-getobject nodejs-github-url-from-git nodejs-github-url-from-username-repo nodejs-globals nodejs-globby nodejs-glogg nodejs-gonzales-pe nodejs-graceful-readlink nodejs-grip nodejs-growl nodejs-grunt-angular-templates nodejs-grunt-banner nodejs-grunt-compare-size nodejs-grunt-contrib-requirejs nodejs-grunt-git-authors nodejs-grunt-known-options nodejs-grunt-sed nodejs-grunt-simple-mocha nodejs-grunt-util-args nodejs-grunt-util-options nodejs-grunt-util-process nodejs-grunt-util-property nodejs-gulplog nodejs-has-ansi nodejs-has-color nodejs-has-gulplog nodejs-has-yarn nodejs-hash_file nodejs-hashish nodejs-heap nodejs-highlight-js nodejs-hock nodejs-hoek nodejs-hooker nodejs-hosted-git-info nodejs-html-minifier nodejs-http-signature nodejs-i nodejs-iferr nodejs-ignore nodejs-imurmurhash nodejs-indent-string nodejs-inflight nodejs-inherits nodejs-inherits1 nodejs-inline-source-map nodejs-install nodejs-interpret nodejs-invert-kv nodejs-irregular-plurals nodejs-is-absolute nodejs-is-arrow-function nodejs-is-boolean-object nodejs-is-builtin-module nodejs-is-dir nodejs-is-dotfile nodejs-is-equal-shallow nodejs-is-extendable nodejs-is-finite nodejs-is-fullwidth-code-point nodejs-is-generator nodejs-is-generator-fn nodejs-is-lower-case nodejs-is-my-json-valid nodejs-is-number nodejs-is-number-object nodejs-is-obj nodejs-is-observable nodejs-is-path-cwd nodejs-is-path-in-cwd nodejs-is-path-inside nodejs-is-primitive nodejs-is-property nodejs-is-regexp nodejs-is-relative nodejs-is-string nodejs-is-text-path nodejs-is-typedarray nodejs-is-unc-path nodejs-is-upper-case nodejs-is-url nodejs-is-utf8 nodejs-isarray nodejs-isexe nodejs-iso8601 nodejs-isodate nodejs-isstream nodejs-jasmine-growl-reporter nodejs-jasmine-reporters nodejs-jison-lex nodejs-jju nodejs-joose nodejs-joosex-namespace-depended nodejs-joosex-simplerequest nodejs-js-base64 nodejs-jschardet nodejs-jscoverage nodejs-json-parse-helpfulerror nodejs-json-stable-stringify nodejs-jsonfile nodejs-jsonify nodejs-jsonm nodejs-jsonparse nodejs-jsonpointer nodejs-jsonselect nodejs-jsonstream nodejs-jwt-simple nodejs-keypress nodejs-latest-version nodejs-lcid nodejs-lcov-parse nodejs-leaflet-hash nodejs-leche nodejs-levn nodejs-lex-parser nodejs-linkify-it nodejs-locate-path nodejs-log-driver nodejs-lolex nodejs-loud-rejection nodejs-lower-case nodejs-lower-case-first nodejs-lru-queue nodejs-ltx nodejs-markdown-it-testgen nodejs-max-timeout nodejs-md5-hex nodejs-md5-o-matic nodejs-mdurl nodejs-media-typer nodejs-memoizee nodejs-merge-stream nodejs-metascript nodejs-method-override nodejs-methods nodejs-mimeparse nodejs-minimist nodejs-mongodb nodejs-mongodb-core nodejs-multiline nodejs-multiparty nodejs-mustache nodejs-mute-stream nodejs-mv nodejs-ncp nodejs-needle nodejs-negotiator nodejs-net-browserify-alt nodejs-next nodejs-next-tick nodejs-node-int64 nodejs-nopt-usage nodejs-noptify nodejs-normalize-git-url nodejs-normalize-package-data nodejs-normalize-path nodejs-npm-license nodejs-npm-run-path nodejs-nth-check nodejs-number-is-nan nodejs-on-finished nodejs-on-headers nodejs-once nodejs-onetime nodejs-only-shallow nodejs-oop nodejs-open nodejs-opn nodejs-optimist nodejs-optionator nodejs-options nodejs-optjs nodejs-opts nodejs-orchestrator nodejs-ordered-read-streams nodejs-os-homedir nodejs-os-locale nodejs-output-file-sync nodejs-p-finally nodejs-p-limit nodejs-p-locate nodejs-package nodejs-package-json nodejs-package-license nodejs-pad nodejs-pad-left nodejs-paperboy nodejs-param-case nodejs-parse-ms nodejs-parserlib nodejs-pascal-case nodejs-path-array nodejs-path-case nodejs-path-exists nodejs-path-is-absolute nodejs-path-is-inside nodejs-path-key nodejs-path-to-regexp nodejs-path-type nodejs-path2 nodejs-pathval nodejs-pause nodejs-pend nodejs-pify nodejs-pkg-dir nodejs-pkg-up nodejs-pkginfo nodejs-platform nodejs-plur nodejs-prelude-ls nodejs-preserve nodejs-pretty-hrtime nodejs-pretty-ms nodejs-private nodejs-promises-aplus-tests nodejs-propagate nodejs-proxy-agent nodejs-pruddy-error nodejs-pseudomap nodejs-pubcontrol nodejs-qunit-extras nodejs-rainbowsocks nodejs-randomatic nodejs-raw-body nodejs-re-emitter nodejs-read-dir-files nodejs-read-file nodejs-read-package-tree nodejs-read-pkg nodejs-read-pkg-up nodejs-realize-package-specifier nodejs-rechoir nodejs-redent nodejs-reduce-component nodejs-regenerator nodejs-regex-cache nodejs-relateurl nodejs-repeat-element nodejs-repeat-string nodejs-repeating nodejs-repl nodejs-replace nodejs-replace-ext nodejs-replace-require-self nodejs-requestretry nodejs-require-all nodejs-require-directory nodejs-require-inject nodejs-require-yaml nodejs-requirejs nodejs-resolve-pkg nodejs-response-time nodejs-revalidator nodejs-rndm nodejs-ronn nodejs-run-parallel-limit nodejs-runforcover nodejs-safe-json-stringify nodejs-safecb nodejs-samsam nodejs-saucelabs nodejs-sax nodejs-scmp nodejs-sentence-case nodejs-sequencify nodejs-serialize-error nodejs-serve-index nodejs-serve-static nodejs-set-getter nodejs-setimmediate nodejs-shelljs nodejs-shelljs-nodecli nodejs-should-equal nodejs-should-type nodejs-showdown nodejs-sigmund nodejs-signal-exit nodejs-simple-fmt nodejs-simple-is nodejs-sinon nodejs-sinon-restore nodejs-smart-buffer nodejs-snake-case nodejs-socks-client nodejs-socks-proxy-agent nodejs-sort-keys nodejs-sorted-object nodejs-source-map-fixtures nodejs-sparkles nodejs-spdx-correct nodejs-spdx-exceptions nodejs-spdx-expression-parse nodejs-spdx-license-ids nodejs-sprintf nodejs-sprintf-js nodejs-stable nodejs-stack-trace nodejs-stack-utils nodejs-static-favicon nodejs-stream-consume nodejs-stream-counter nodejs-stream-replace nodejs-stream-to-array nodejs-streamsink nodejs-streamtest nodejs-string nodejs-string-dot-prototype-dot-repeat nodejs-string_decoder nodejs-stringmap nodejs-stringscanner nodejs-stringset nodejs-stringstream nodejs-strip-bom nodejs-strip-bom-stream nodejs-strip-indent nodejs-strip-json-comments nodejs-strip-path nodejs-success-symbol nodejs-superagent-proxy nodejs-supertest nodejs-swap-case nodejs-symbol-observable nodejs-tad nodejs-tap-mocha-reporter nodejs-tap-parser nodejs-tar-stream nodejs-temporary nodejs-tern nodejs-tern-cordovajs nodejs-tern-liferay nodejs-terst nodejs-test nodejs-testjs nodejs-testswarm nodejs-thenify-all nodejs-through2-filter nodejs-thunkify nodejs-tildify nodejs-time-stamp nodejs-timers-ext nodejs-tinycolor nodejs-title-case nodejs-tmatch nodejs-tmp nodejs-to-absolute-glob nodejs-to-object-path nodejs-tracejs nodejs-treeify nodejs-trim-newlines nodejs-try-open nodejs-tryor nodejs-tsscmp nodejs-type-check nodejs-typeahead.js nodejs-typescript nodejs-uc-dot-micro nodejs-uglify-to-browserify nodejs-uid-number nodejs-umask nodejs-unc-path-regex nodejs-underscore nodejs-underscore-dot-logger nodejs-underscore-dot-string nodejs-unique-filename nodejs-unique-slug nodejs-unique-stream nodejs-unpipe nodejs-upper-case nodejs-upper-case-first nodejs-url2 nodejs-utfx nodejs-util nodejs-util-extend nodejs-vali-date nodejs-validate-npm-package-license nodejs-validate-npm-package-name nodejs-vasync nodejs-vhost nodejs-vinyl nodejs-vow nodejs-vow-queue nodejs-w3cjs nodejs-walkdir nodejs-wcwidth nodejs-weak-map nodejs-websocket-driver nodejs-when nodejs-win-spawn nodejs-window-size nodejs-with nodejs-woothee nodejs-wordwrap nodejs-wrap-ansi nodejs-wrap-fn nodejs-wrappy nodejs-write-json-file nodejs-write-pkg nodejs-xmlbuilder nodejs-xregexp nodejs-y18n nodejs-yamlish nodejs-yargs nodejs-yauzl nodejs-zlib-browserify nodejs-zlibjs nodoka-theme-gnome noggit nogravity-data nom-tam-fits not-yet-commons-ssl novprog numix-gtk-theme numix-icon-theme numix-icon-theme-circle nvmetcli objectweb-anttask ocaml-autoconf octave-audio octave-communications octave-general octave-metch octave-miscellaneous octave-ncarray octave-nnet octave-quaternion octave-signal octave-specfun octave-struct odfpy officeparser ohc olfs olpc-netutils ooo2txt oorexx opal open-sendmail openarena openbox-theme-mistral-thin openbox-theme-mistral-thin-dark opencl-filesystem opencsv opengl-games-utils openhft-chronicle-queue openhft-java-compiler openhft-java-lang openid-selector openid4java openid4java-team openjdk-orb openjfx openjpa opennlp openoffice-lv pam_radius pdfresurrect publican-fedora quantum-espresso retext rubygem-connection_pool rubygem-cucumber-rails rubygem-gettext_i18n_rails rubygem-kgio sassc sepolicy_analysis springframework-data-redis vmmlib wadofstuff-django-serializers ``` `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7469

5 11

[releng] Issue #7549: unretire ghc-fgl
by Jens Petersen 18 Jun '19

18 Jun '19

petersen reported a new issue against the project: `releng` that you are following: `` Hi RelEng, can you please unretire `ghc-fgl`, which I would like to restore to Fedora for F28+. https://bugzilla.redhat.com/show_bug.cgi?id=1585448 (https://pagure.io/releng/fedora-scm-requests/issue/6879) Please unblock `ghc-fgl` for the master and f28 branches. Thanks! `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7549

4 8

[releng] Issue #8084: Opt-out from branching for rust packages
by Igor Gnatenko 18 Jun '19

18 Jun '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` Hello release engineering folks, The Rust SIG never updates any crates in released Fedora's. Is it possible to opt-out from branching so that users won't get outdated crates? I can provide list of packages, but roughly that would be whatever matches `rust-*` with a few exceptions. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8084

4 5

[releng] Issue #7320: please create f28-kde koji side target
by Rex Dieter 11 Jun '19

11 Jun '19

rdieter reported a new issue against the project: `releng` that you are following: `` Please create a f28-kde koji side target. It will be invaluable to work on batched builds (Qt5, in particular) to avoid and minimize breaking rawhide depenedencies in the meantime. Thanks. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7320

5 18

[releng] Issue #7552: enable epel7-kde koji target
by Rex Dieter 11 Jun '19

11 Jun '19

rdieter reported a new issue against the project: `releng` that you are following: `` Will begin work on a large batch of interdependant builds, please (re)enable epel7-kde koji target, koji add-target epel7-kde epel7-kde thanks. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7552

4 10

[releng] Issue #7931: spam-o-matic (depcheck) is wildly, uselessly wrong
by Adam Williamson 10 Jun '19

10 Jun '19

adamwill reported a new issue against the project: `releng` that you are following: `` * Describe the issue The output of spam-o-matic (`depcheck` in the compose logs) is just utterly wrong for recent Rawhide composes. e.g. this, from the most recent Rawhide compose: [calamares] calamares-3.1.8-10.fc29.i686 requires hicolor-icon-theme calamares-3.1.8-10.fc29.i686 requires dnf calamares-3.1.8-10.fc29.i686 requires console-setup calamares-3.1.8-10.fc29.i686 requires system-release [calibre] calibre-3.29.0-2.fc30.i686 requires python2-cssutils calibre-3.29.0-2.fc30.i686 requires python2-dateutil calibre-3.29.0-2.fc30.i686 requires python2-dns calibre-3.29.0-2.fc30.i686 requires python2-enum34 calibre-3.29.0-2.fc30.i686 requires python2-feedparser calibre-3.29.0-2.fc30.i686 requires python2-beautifulsoup calibre-3.29.0-2.fc30.i686 requires python2-mechanize calibre-3.29.0-2.fc30.i686 requires python2-pygments calibre-3.29.0-2.fc30.i686 requires python2-odfpy All those deps actually *are* in the tree, they should not be shown as broken. We've known the output has been kinda unreliable for a while, but IIRC this related only to soft deps and/or modules. Aside from that it was still more or less correct for x86_64, so it was usable for spotting real broken deps. But it's now just stuffed with completely incorrect info and unusable. * When do you need this? (YYYY/MM/DD) It's not utterly critical, but I was hoping to find broken deps introduced by the Python 2 subpackage removal. Without any kind of usable dep check this is hard to do. * When is this no longer needed or useful? (YYYY/MM/DD) * If we cannot complete your request, what is the impact? It'll be harder to find and fix broken deps in Rawhide. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7931

3 6

[releng] Issue #8074: perl:5.26:20181205105946 module is in both updates and testing repositories
by Petr Pisar 10 Jun '19

10 Jun '19

ppisar reported a new issue against the project: `releng` that you are following: `` ~~~~ # dnf module info perl:5.26 | grep -E '^(Version|Repo)' Version : 20180417112647 Repo : fedora-modular Version : 20181205105946 Repo : updates-modular Version : 20181205105946 Repo : updates-testing-modular ~~~~ I would expect that the module build will be moved from testing to updates. Not copied. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8074

1 2

[releng] Issue #7671: Builders does not respect ExclusiveArch
by Vít Ondruch 09 Jun '19

09 Jun '19

vondruch reported a new issue against the project: `releng` that you are following: `` A while ago, there was a change in packaging guidelines: https://pagure.io/packaging-committee/issue/751 And the ticket started with a claim: > A while back, Koji was fixed to actually pay attention to ExcludeArch: and ExclusiveArch: when choosing the host to build a noarch package. I don't think that it works, testing with either this: ~~~ diff --git a/rubygem-mongo.spec b/rubygem-mongo.spec index 1d436d7..82a9e00 100644 --- a/rubygem-mongo.spec +++ b/rubygem-mongo.spec @@ -26,6 +26,9 @@ BuildRequires: %{_bindir}/mongod BuildRequires: rubygem(bson) >= 4.3.0 BuildRequires: rubygem(rspec) BuildArch: noarch +# MongoDB serverved does not support all architectures. Use x86_64 for build +# to be sure Koji build is always successful. +ExclusiveArch: x86_64 noarch %description A Ruby driver for MongoDB. ~~~ https://koji.fedoraproject.org/koji/taskinfo?taskID=28734500 or ~~~ diff --git a/rubygem-mongo.spec b/rubygem-mongo.spec index 1d436d7..82a9e00 100644 --- a/rubygem-mongo.spec +++ b/rubygem-mongo.spec @@ -26,6 +26,9 @@ BuildRequires: %{_bindir}/mongod BuildRequires: rubygem(bson) >= 4.3.0 BuildRequires: rubygem(rspec) BuildArch: noarch +# MongoDB serverved does not support all architectures. Use x86_64 for build +# to be sure Koji build is always successful. +ExclusiveArch: x86_64 %description A Ruby driver for MongoDB. ~~~ https://koji.fedoraproject.org/koji/taskinfo?taskID=28734626 Both builds were done on i686 builders while only x86_64 builders should be used. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7671

5 13

[releng] Issue #7523: rubygem-connection_pool mess
by Vít Ondruch 04 Jun '19

04 Jun '19

vondruch reported a new issue against the project: `releng` that you are following: `` There is package rubygem-connection_pool, where although the review was finished \[[1]\], the package was never imported neither built. Later, somebody wanted to use rubygem-connection_pool, so there was other review \[[2]\]. This was approved (while unnoticed, there is rubygem-connection_pool already in Fedora) and repository rubygem-connection-pool was requested (please note the dash instead of underscore in the repository name). From there, there are coming builds of rubygem-connection_pool here \[[3]\]. Somebody later noticed and retired the rubygem-connection-pool package \[[4]\], but really, I am not sure this was the best possible action. There are several concerns: 1. It is not obvious what happened and where the package is coming from. It is surprising, that the repo request was approved, although it did not match the review. 2. The package is escaping mass rebuilds. Actually I am surprised this kind of repositories is not detected/reported after rebuild. 3. It is not obvious who is maintaining the package. For (1) and (2), I hope you can check your tooling and avoid these situations in the future. For (3) neither one of the current maintainers is really active. I haven't hear about @anujmore for past 4 years. I've heard about @axilleas, but I believe he is busy with other stuff. @ilgrad might still be interested in this package. I can also take the package over, since it is dependency of Ruby on Rails. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=967334 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1267328 [3]: https://koji.fedoraproject.org/koji/packageinfo?packageID=16736 [4]: https://src.fedoraproject.org/rpms/rubygem-connection-pool/commits/master `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7523

3 8

[releng] PR #7881: Add a script to send reminders to FTBFs bugzillas
by Miro Hrončok 02 Jun '19

02 Jun '19

churchyard opened a new pull-request against the project: `releng` that you are following: `` Add a script to send reminders to FTBFs bugzillas `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7881

5 24

[releng] Issue #7763: define and implement retention policy for nightly composes
by Dan Horák 29 May '19

29 May '19

sharkcz reported a new issue against the project: `releng` that you are following: `` * Describe the issue Right now we have only last 14 days of the nightly composes. Which makes it impossible to compare current compose with an old one to see what changed (mainly functionally). The polocy could be time based (like keep 1 compose per week for 4 weeks preceding the 14 days, then keep 1 per month, until previous GA). Or it can be based on the openqa testing and keep composes "nominated for further testing". Or something else. One of the reason for this request is https://bugzilla.redhat.com/show_bug.cgi?id=1623547 where I'm almost sure I had a F-29 nightly compose behaving sanely on s390x in the past, but have nothing I could compare with the current state. * When do you need this? (YYYY/MM/DD) soon * When is this no longer needed or useful? (YYYY/MM/DD) never * If we cannot complete your request, what is the impact? Difficult to find out what changed (functionally) in the composes as the previous compose is the GA compose of the last release. AFAIK it's almost impossible to recreate an old compose from a given date on demand. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7763

4 7

[releng] Issue #7802: Several EPEL7 package conflicts with RHEL/CentOS 7.5
by Eli Young 29 May '19

29 May '19

elyscape reported a new issue against the project: `releng` that you are following: `` #### Describe the issue The releases of RHEL and CentOS 7.5 (and likely earlier versions) brought with them new packages that were previously provided by EPEL7. Some of these are still present in EPEL, potentially causing conflicts. Particularly problematic are various packages that are provided in EPEL as python2-* and provided in upstream as python-*. While fully-overlapping names are suboptimal, these partially-overlapping names that provide the same actual package leads to issues like [certbot #6314][certbot] and [RHBZ #1578071][bugzilla]. I have attached 4 files containing lists of problematic packages: filename|description|impact if unresolved -|-|- base-and-updates-full.txt|EPEL7 packages also in upstream base or updates|moderate base-and-updates-partial.txt|EPEL7 packages also in upstream base or updates as python-*|significant extras-full.txt|EPEL7 packages also in upstream extras|moderate extras-partial.txt|EPEL78 packages also in upstream extras as python-*|significant #### When do you need this? (YYYY/MM/DD) No specific date, but sooner is better. #### When is this no longer needed or useful? (YYYY/MM/DD) N/A #### If we cannot complete your request, what is the impact? EPEL-provided packages with full name overlap may potentially override upstream packages. EPEL-provided packages with partial name overlap may cause issues like [certbot #6314][certbot] and [RHBZ #1578071][bugzilla]. <!!image> <!!image> <!!image> <!!image> [certbot]: https://github.com/certbot/certbot/issues/6314 [bugzilla]: https://bugzilla.redhat.com/show_bug.cgi?id=1578071 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7802

5 7

[releng] Issue #7738: fedpkg build - Connection aborted.
by Vít Ondruch 21 May '19

21 May '19

vondruch reported a new issue against the project: `releng` that you are following: `` * Describe the issue The fedpkg connection with server fails during build almost every time: ~~~ $ fedpkg scratch-build --srpm /usr/lib/python3.7/site-packages/fedora/client/bodhi.py:48: DeprecationWarning: fedora.client.bodhi has been deprecated. Please use bodhi.client.bindings instead. DeprecationWarning) /usr/lib/python3.7/site-packages/fedpkg/__init__.py:235: DeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5 runtime_os, runtime_version, _ = platform.linux_distribution() Zapsáno: /home/vondruch/fedora-scm/own/ruby/ruby-2.5.1-99.fc30.src.rpm /usr/lib/python3.7/site-packages/koji/__init__.py:1704: DeprecationWarning: This method will be removed in future versions. Use 'parser.read_file()' instead. config.readfp(f) [====================================] 100% 00:00:03 10.90 MiB 3.16 MiB/sec Building ruby-2.5.1-99.fc30.src.rpm for rawhide Created task: 29377062 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=29377062 Watching tasks (this may be safely interrupted)... Could not execute scratch_build: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')) ~~~ This happens already for some time and it is quite annoying. ~~~ $ rpm -q fedpkg fedpkg-1.35-1.fc30.noarch ~~~ `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7738

10 16

[releng] Issue #8046: Rebase the rawhide binutils to version 2.32
by Nicholas Clifton 21 May '19

21 May '19

nickc reported a new issue against the project: `releng` that you are following: `` * Describe the issue I would like to rebase the version of binutils used in rawhide from GNU binutils 2.31.1 to version 2.32. * When do you need this? 2019/01/28 Version 2.32 is due to be released on January 27 2019, so I would like to rebase once this has happened. * When is this no longer needed or useful? (2019/08/31) The release after 2.32 will most likely happen in August 2019. * If we cannot complete your request, what is the impact? Bug fixes present in 2.32 but not in 2.31 will be absent from Fedora. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8046

3 6

[releng] Issue #8025: Fedora 30 system-wide change: Golang 1.12
by Jakub Čajka 21 May '19

21 May '19

jcajka reported a new issue against the project: `releng` that you are following: `` * Describe the issue This is tracking issue for the [Golang 1.12](https://fedoraproject.org/wiki/Changes/golang1.12) change proposal, that would require rebuild of all Go based package(either as side tag rebuild or during mass rebuild). New golang version is not yet available in rawhide. I will update this issue when the new golang version will be available and so rebuild possible. All the dependent/affected packages are [listed](https://fedoraproject.org/wiki/Changes/golang1.12#Dependencies) in the change proposal. * When do you need this? By the Fedora 30 freeze * If we cannot complete your request, what is the impact? Block the completion of the change `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8025

3 5

[releng] Issue #8073: Re-write scripts/branching/modulepkg.py with help of libmodulemd
by Andrei Stepanov 21 May '19

21 May '19

astepano reported a new issue against the project: `releng` that you are following: `` `scripts/branching/modulepkg.py` I try to run it in Fedora29. But it says: ./modulepkg.py Traceback (most recent call last): File "./modulepkg.py", line 17, in <module> import modulemd ModuleNotFoundError: No module named 'modulemd' I have a lot of different packages installed: # rpm -qa | grep mod python3-module-build-service-copr-0.4-4.fc29.noarch fedmod-0.4.3-1.fc29.noarch python2-module-build-service-copr-0.4-4.fc29.noarch module-build-service-2.11.1-1.fc29.noarch libmodulemd-2.0.0-3.fc29.x86_64 libmodulemd1-1.8.0-3.fc29.x86_64 python3-libmodulemd-2.0.0-3.fc29.noarch Could you please update the script to use modern python modules? Thank you! `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8073

3 4

[releng] Issue #8023: [System-wide change] Fully remove deprecated and unsafe functions from libcrypt
by Björn Esser 21 May '19

21 May '19

besser82 reported a new issue against the project: `releng` that you are following: `` * Describe the issue System-wide change to remove the encrypt, encrypt_r, setkey, setkey_r, and fcrypt functions from the system-default libcrypt library. This includes a so-name bump from `libcrypt.so.1` to `libcrypt.so.2`. A compatibility library for the `libcrypt.so.1` library will still be provided, so there is no fallout or negative impact on the build-roots for Fedora 30. The packages requiring `libcrypt.so.1` can either be rebuild during a planned mass-rebuild or by the requestee. See: TBA * When do you need this? Before the mass-rebuild for Fedora 30 starts. * When is this no longer needed or useful? After the completion deadline of system-wide changes for Fedora 30. * If we cannot complete your request, what is the impact? The change cannot be done nor completed. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8023

4 6

[releng] Issue #8026: Packages are not retired entirely
by Vít Ondruch 21 May '19

21 May '19

vondruch reported a new issue against the project: `releng` that you are following: `` * Describe the issue There was recently mass retirement of orphaned packages. However, the retirement does not work as expected IMO and not everything is removed. Now I'll continue to speak specifically about rubygem-acts-as-taggable-on \[[1]\], but I suspect that this is a general issue. I have no Idea why there is still "ruby-packagers-sig" listed among committers. Every committer should be removed upon retirement IMO and groups especially. Also, the package is somehow watched by me. I don't know it that is because I am member of ruby-packagers-sig, but I definitely don't want to watch such package. * When do you need this? (YYYY/MM/DD) The sooner the better. * When is this no longer needed or useful? (YYYY/MM/DD) When Pagure is fixed or replaced by something else. * If we cannot complete your request, what is the impact? I am annoyed ;) [1] https://src.fedoraproject.org/rpms/rubygem-acts-as-taggable-on `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8026

4 7

[releng] Issue #8012: Self-contained change proposal: krb5 crypto modernization
by Robbie Harwood 21 May '19

21 May '19

rharwood reported a new issue against the project: `releng` that you are following: `` * Describe the issue Mandatory check with rel-eng is required for Fedora 30 change proposal [krb5 crypto modernization](https://fedoraproject.org/wiki/Changes/krb5_crypto_moderniza…. I don't expect any impact, but that's why we do these checks. * When do you need this? (YYYY/MM/DD) Change submission deadline is 2019-01-29 for self-contained changes * When is this no longer needed or useful? (YYYY/MM/DD) Beta freeze is 2019-03-05, but I think it really should be done before the submission deadline of 2019-01-29. * If we cannot complete your request, what is the impact? I'm not actually sure and policy doesn't really say. I think it goes forward anyway without your input? Maybe it doesn't get accepted? Hopefully this isn't an issue. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8012

5 7

[releng] Issue #7994: Inform module maintainers when their module/stream is going to EOL
by Mohan Boddu 21 May '19

21 May '19

mohanboddu reported a new issue against the project: `releng` that you are following: `` * Describe the issue Currently there is no way right now to intimate the module maintainers when their module/stream is going EOL. It would good if we can send some notifications about it prior to their EOL. This requires parsing through all modules/streams in PDC to get their EOL dates and if its getting EOL'd in a week (or something more, we have to decide on this duration) , then find the maintainer of that module in dist-git and send them an email. * When do you need this? (YYYY/MM/DD) ASAP * When is this no longer needed or useful? (YYYY/MM/DD) Its always useful * If we cannot complete your request, what is the impact? Every time maintainers will have issues pushing to dist-git if their module/stream is EOL'd. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7994

3 2

[releng] Issue #7215: older drpms not synced
by Kevin Fenzi 21 May '19

21 May '19

kevin reported a new issue against the project: `releng` that you are following: `` As noted in this post: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… it seems we are only syncing out the drpms made in that specific compose. We should keep a (ideally configurable) amount of older ones around. I think for rawhide we were keeping 2 weeks, we could start with that. as it is now unless someone updates on the day an update is pushed they won't get the advantage of the drpm. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7215

3 3

[releng] Issue #7548: Fedora 29 Change: NSS load p11-kit modules by default
by Daiki Ueno 21 May '19

21 May '19

ueno reported a new issue against the project: `releng` that you are following: `` Hello, Could you review your impact with https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules ? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7548

4 3

[releng] Issue #7907: Fedora 30 Toolchain Rebase: glibc 2.29, gcc 9.0
by Carlos O'Donell 09 May '19

09 May '19

codonell reported a new issue against the project: `releng` that you are following: `` * Describe the issue All Fedora releases must be released using a released and supported version of the core toolchain involving glibc, gcc, and binutils. The Fedora toolchain team is responsible for ensuring that Fedora Rawhide stabilizes static linking, code generation, and library ABI, before a Fedora release, or that after the branch that the Fedora release is rebased (a very small rebase) to the final released version. This is a requirement for Fedora to inherit the ABI and API guarantees provided by upstream. If a mass rebuild is required by binutils, gcc, glibc or other components, the Fedora toolcahin team will ensure coordination with release engineering such that a mass rebuild uses the released version of all components and fix any last minute ABI or code-generation changes. * When do you need this? (2019/01/30) We need a mass rebuild. Change page for review: https://fedoraproject.org/wiki/Changes/GLIBC229 Owner: Carlos O'Donell carlos(a)redhat.com glibc mass rebuild request: This request. Change page for review: https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition Owner: Carlos O'Donell carlos(a)redhat.com glibc mass rebuild request: ppc64le transition to 128-bit IEEE long double. GCC will file a system-wide change request for GCC 9 transition also in December. Binutils will remain as 2.31.1 and will not change (Nick Clifton's notes). * If we cannot complete your request, what is the impact? I we cannot do a mass rebuild then we should not transition to glibc 2.29 or gcc 9, but we might still be able to transition via targeted mass rebuilds. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7907

3 4

[releng] Issue #7979: Updates for rawhide containers
by Randy Barlow 09 May '19

09 May '19

bowlofeggs reported a new issue against the project: `releng` that you are following: `` @mskalick originally [filed this request in the Bodhi tracker](https://github.com/fedora-infra/bodhi/issues/2830): > could it be possible to enable update for rawhide containers? Or for Fedora release N+1, currently F30... > Currently there is no way for developers how to release them. Result images are pushed into candidate-registry.fedoraproject.org by koji. > Different possible solution would be to push images directly into registry.fedoraproject.org by koji for rawhide. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7979

4 6

[releng] Issue #7961: Incomplete repo creation
by Igor Gnatenko 09 May '19

09 May '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` Something bad happened when processing following ticket: https://pagure.io/releng/fedora-scm-requests/issue/9143 ``` - Checking for PDC global-component golang-github-tv42-httpunix - Creating PDC global-component golang-github-tv42-httpunix - Checking for existing PDC branch (rpm)golang-github-tv42-httpunix#master - Creating PDC branch (rpm)golang-github-tv42-httpunix#master - Mapping SL rawhide:2222-01-01 to (rpm)golang-github-tv42-httpunix#master Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/requests/adapters.py", line 449, in send timeout=timeout File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 731, in urlopen body_pos=body_pos, **response_kw) File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 731, in urlopen body_pos=body_pos, **response_kw) File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 731, in urlopen body_pos=body_pos, **response_kw) [Previous line repeated 2 more times] File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 711, in urlopen retries = retries.increment(method, url, response=response, _pool=self) File "/usr/lib/python3.7/site-packages/urllib3/util/retry.py", line 398, in increment raise MaxRetryError(_pool, url, error or ResponseError(cause)) urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='pdc.fedoraproject.org', port=443): Max retries exceeded with url: /rest_api/v1/component-branch-slas/ (Caused by ResponseError('too many 400 error responses')) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/fedscm-admin", line 11, in <module> load_entry_point('fedscm-admin==1.0.2', 'console_scripts', 'fedscm-admin')() File "/usr/lib/python3.7/site-packages/click/core.py", line 763, in __call__ return self.main(*args, **kwargs) File "/usr/lib/python3.7/site-packages/click/core.py", line 716, in main rv = self.invoke(ctx) File "/usr/lib/python3.7/site-packages/click/core.py", line 955, in invoke return ctx.invoke(self.callback, **ctx.params) File "/usr/lib/python3.7/site-packages/click/core.py", line 554, in invoke return callback(*args, **kwargs) File "/usr/lib/python3.7/site-packages/fedscm_admin/fedscm_admin.py", line 72, in cli process_all_tickets(auto_approve=auto_approve) File "/usr/lib/python3.7/site-packages/fedscm_admin/utils.py", line 204, in process_all_tickets process_ticket(issue, auto_approve=auto_approve) File "/usr/lib/python3.7/site-packages/fedscm_admin/utils.py", line 268, in process_ticket 'initial_commit', True)) File "/usr/lib/python3.7/site-packages/fedscm_admin/utils.py", line 439, in prompt_for_new_repo sla, eol, repo, branch_name, branch_type) File "/usr/lib/python3.7/site-packages/fedscm_admin/pdc.py", line 193, in new_sla_to_branch timeout=60, http_verb='post', service_name='PDC') File "/usr/lib/python3.7/site-packages/fedscm_admin/request_utils.py", line 86, in requests_wrapper return requests_function(*args, **kwargs) File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 572, in post return self.request('POST', url, data=data, json=json, **kwargs) File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 524, in request resp = self.send(prep, **send_kwargs) File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 637, in send r = adapter.send(request, **kwargs) File "/usr/lib/python3.7/site-packages/requests/adapters.py", line 507, in send raise RetryError(e, request=request) requests.exceptions.RetryError: HTTPSConnectionPool(host='pdc.fedoraproject.org', port=443): Max retries exceeded with url: /rest_api/v1/component-branch-slas/ (Caused by ResponseError('too many 400 error responses')) ``` `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7961

4 7

[releng] Issue #7921: setgid bit on Fedora 29 directories
by Ian Wienand 09 May '19

09 May '19

iwienand reported a new issue against the project: `releng` that you are following: `` Hello, We rsync a Fedora mirror to a local AFS volume. When I added the F29 directories we started getting ``` receiving incremental file list rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/.": Permission denied (13) rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Everything": Permission denied (13) rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Everything/x86_64": Permission denied (13) rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Modular": Permission denied (13) rsync: failed to set permissions on "/afs/.openstack.org/mirror/fedora/updates/29/Modular ``` Quite bizarre and unhelpful; turns out on stracing the failing call is ``` 3213 chmod(".", 02755 <unfinished ...> ``` On AFS, you need administrator permissions to setgid (02) which the mirror user doesn't have. I tried on several different rsync mirrors and they all do the same, so I'm assuming this comes from the master sync. I can avoid this problem by dropping "-p" from our rsync command; however we haven't (and don't) need this for any of the other fedora directories. Could someone check if this has inadvertently been applied to the F29 directories somehow? Thanks `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7921

5 18

[releng] Issue #7275: provide casync index and object storage files for images on getfedora.org
by Basti Endres 09 May '19

09 May '19

sedrubal reported a new issue against the project: `releng` that you are following: `` [casync](https://github.com/systemd/casync) is like a new and better rsync for directory trees, binary files and system images. It can speed up downloads if the user already has a similar image on his local machine. For example if a user already has fedora 26 and he wants to download fedora 27 he can use fedora 26 as local seed and download only differences using casync. The same applies if he has fedora workstation and he wants to download fedora server. It was great if you provide a `.caibx` index file for each image and a (global) `.castr` object storage on the fedora ftp mirrors. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7275

5 9

[releng] Issue #7300: Deny push / Implement git hook for unescaped macro in %changelog
by Igor Gnatenko 09 May '19

09 May '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` ```python #!/usr/bin/python3 import re import sys replace = False out = [] with open(sys.argv[1], "r"): for l in open(sys.argv[1], "r"): out.append(l) if l.startswith("%changelog"): replace = True continue if not replace: continue if l.startswith("%"): replace = False continue if l.startswith("*"): # XXX: HACK continue out[-1] = re.sub(r"([^%])%([^% \n\d])", r"\1%%\2", l) with open(sys.argv[1], "w") as f: f.writelines(out) ``` This is something I've been using for automatic fix myself. I think we should either prohibit pushing this or have git-hook which would fix it automatically. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7300

5 9

[releng] Issue #7878: Please make pm_request available (and working) in koji
by Nicolas Mailhot 09 May '19

09 May '19

nim reported a new issue against the project: `releng` that you are following: `` So the Go (golang) ecosystem is a morass of fast-changing software, with massive code reuse, and components that get created/forked/renamed/deprecated at a fast pace. This is similar to other "modern" language ecosystems such as javascript. This has led to mass-generation of Go spec files in Fedora from code analysis tools (and has prevented any form of official Fedora Go packaging guidelines). However, generating specs outside rpm leads to specs that rot at a fast pace. No one really understands or audits the generated code, and as soon as you need to adapt it due to some upstream quirk you lose the ability to regenerate it cleanly. And you can not ignore golang or javascript, the first is used by pretty much any container-oriented software, the other by pretty much anything that needs to present a web ui. Therefore I've been trying for a year to put back the generation logic within rpm macros, so it's centralized, audited and and controlled by Fedora, and the generation logic is cleanly separated from human adaptations in the corresponding spec files. For build requires, that means computing the code needs in %prep and getting mock to install the corresponding packages. The approach agreed on with FPC members and upstream mock was to use the pm_request mock plug-in and the corresponding logic written by the Java sig in javapackages. https://github.com/rpm-software-management/mock/issues/160 Unfortunately the Java SIG code was too imbricated with Java specific things to be reusable so I ended up writing a separate mock pm request client https://github.com/nim-nim/mock-install https://copr.fedorainfracloud.org/coprs/nim/mock-install/ https://bugzilla.redhat.com/show_bug.cgi?id=1629371 And now I find out pm_request is not available in koji and copr (don't know it it was before and has been removed since, or if it was never enabled because the java sig built its stuff elsewhere) Anyway: 1. please enable pm_request in koji 2. please make sure that it works https://github.com/rpm-software-management/mock/issues/218 How to test: 1. take a mock install binary from https://copr.fedorainfracloud.org/coprs/nim/mock-install/ 2. use any spec you like that calls mock-install <package-name> from %prep See also https://pagure.io/koji/issue/1133 https://bugzilla.redhat.com/show_bug.cgi?id=1641187 https://bugzilla.redhat.com/show_bug.cgi?id=1641191 https://bugzilla.redhat.com/show_bug.cgi?id=1629371 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7878

6 13

[releng] Issue #7873: Review of ’GIMP as a Module’ Change
by Nils Philippsen 09 May '19

09 May '19

nphilipp reported a new issue against the project: `releng` that you are following: `` Please see the [`GIMP as a Module`](https://fedoraproject.org/w/index.php?title=Changes/GIMP_as_a_Modu… Change for Fedora 30. I don't expect releng work beyond integrating the [’Set default stream and profile for gimp’](https://pagure.io/releng/fedora-module-defaults/pull-request/34) pull request. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7873

5 5

[releng] Issue #7848: fedpkg retire on modules doesn't remove them from anywhere
by Igor Gnatenko 09 May '19

09 May '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` ## Describe the issue I've ran `fedpkg retire` on `stratis/master`, but module didn't disappear neither from f29 nor from rawhide. It would be nice if it would be removed since it is unsupported ;) ## When do you need this? (YYYY/MM/DD) Ideally before F29 final freeze because then it would be shipped to users. ## When is this no longer needed or useful? (YYYY/MM/DD) I think it will be useful always. ## If we cannot complete your request, what is the impact? Unsupported RPMs will be shipped to users. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7848

3 2

[releng] Issue #7807: please create f29-kde koji side target
by Rex Dieter 09 May '19

09 May '19

rdieter reported a new issue against the project: `releng` that you are following: `` * Name of the side tag? f2-kde * Number of builds that are expected in the side tag? 50-100 * How long do you need the side tag? at least until f29 final freeze * Any extra information? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7807

4 6

[releng] Issue #7641: Create a Fedora Container release in bodhi stg
by Clement Verna 05 May '19

05 May '19

cverna reported a new issue against the project: `releng` that you are following: `` * Describe the issue In order to test container updates in bodhi stg. We need to have a bodhi release available for f28 containers. This will also requires koji tags to be created. * When do you need this? (YYYY/MM/DD) when possible * When is this no longer needed or useful? (YYYY/MM/DD) * If we cannot complete your request, what is the impact? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7641

4 13

[releng] Issue #7524: Koji builder changes its time suddenly
by Pavel Valena 02 May '19

02 May '19

pvalena reported a new issue against the project: `releng` that you are following: `` In build log, there occurs: ``` make: Warning: File 'abrt_prelude.rb' has modification time 69 s in the future ``` Then executing part of the test suite (in %check) results in (re)compiling a part of code we did not intend to (or at all), and failure occurs: https://kojipkgs.fedoraproject.org//work/tasks/8343/27188343/build.log https://kojipkgs.fedoraproject.org//work/tasks/8339/27188339/build.log https://kojipkgs.fedoraproject.org//work/tasks/8030/27168030/build.log https://kojipkgs.fedoraproject.org//work/tasks/8026/27168026/build.log `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7524

6 17

[releng] Issue #7827: Split modules-for-flatpaks into separate compose/repos
by Colin Walters 01 May '19

01 May '19

walters reported a new issue against the project: `releng` that you are following: `` This should probably block Fedora 29 releases (at least classic systems), otherwise it's going to bite people: ``` # podman run --rm -ti registry.fedoraproject.org/fedora:29 bash [root@2fc48260492d /]# yum module enable eog:master ... Enabling module streams: eog master ... [root@2fc48260492d /]# yum -y install bubblewrap ... Installed: bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 .... [root@2fc48260492d /]# rpm -ql bubblewrap |grep /app /app/bin/bwrap ... ``` This is just totally broken - this RPM should only be used to generate flatpaks *server side*. Anyone who ends up installing flatpak-targeted app RPMs on the client side is highly likely to end up with a broken system. https://github.com/projectatomic/rpm-ostree/issues/1542 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7827

8 14

[releng] Issue #7922: Build Fedora 29 Python Classroom Lab
by Miro Hrončok 30 Apr '19

30 Apr '19

churchyard reported a new issue against the project: `releng` that you are following: `` * Describe the issue The Fedora 29 Python Classroom Lab was not built (it FTBFS and I failed to notice that). The FTBFS fix was pushed to rawhide and F29, rawhide builds, so should F29. Please rebuild it, so we can "release" it. The list should be: https://fedoraproject.org/wiki/Changes/PythonClassroomLab#Scope * When do you need this? (YYYY/MM/DD) No real deadline, sooner the better. * When is this no longer needed or useful? (YYYY/MM/DD) Fedora 29 EOL. * If we cannot complete your request, what is the impact? No Fedora 29 Python Classroom Lab :( `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7922

5 21

[releng] PR #7646: FTBFS fixes
by Mohan Boddu 18 Apr '19

18 Apr '19

mohanboddu opened a new pull-request against the project: `releng` that you are following: `` FTBFS fixes `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7646

3 6

[releng] PR #7652: Fixing need rebuild
by Mohan Boddu 18 Apr '19

18 Apr '19

mohanboddu opened a new pull-request against the project: `releng` that you are following: `` Fixing need rebuild `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7652

3 4

[releng] PR #7366: add script for pruning atomic ostree repos
by Dusty Mabe 15 Apr '19

15 Apr '19

dustymabe opened a new pull-request against the project: `releng` that you are following: `` add script for pruning atomic ostree repos `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7366

7 46

[releng] PR #7929: Add script to populate fpdc releases
by Clement Verna 13 Apr '19

13 Apr '19

cverna opened a new pull-request against the project: `releng` that you are following: `` Add script to populate fpdc releases `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7929

2 1

[releng] PR #7849: Adjust EOL of modules and branches to a given date
by Mohan Boddu 13 Apr '19

13 Apr '19

mohanboddu opened a new pull-request against the project: `releng` that you are following: `` Adjust EOL of modules and branches to a given date `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7849

2 1

[releng] PR #7704: Two enhancements for mass-rebuild-close-bugs.py
by Zbigniew Jędrzejewski-Szmek 13 Apr '19

13 Apr '19

zbyszek opened a new pull-request against the project: `releng` that you are following: `` Two enhancements for mass-rebuild-close-bugs.py `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7704

3 2

[pungi-fedora] PR #540: Let pungi make all comps files during compose
by Kellin 13 Apr '19

13 Apr '19

kellin opened a new pull-request against the project: `pungi-fedora` that you are following: `` Let pungi make all comps files during compose `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/540

3 5

[pungi-fedora] PR #433: Make release-candidate.sh script more durable
by Kellin 13 Apr '19

13 Apr '19

kellin opened a new pull-request against the project: `pungi-fedora` that you are following: `` Make release-candidate.sh script more durable `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/433

3 2

[releng] PR #7119: A SOP for adjusting EOLs on arbitrary branches.
by Ralph Bean 13 Apr '19

13 Apr '19

ralph opened a new pull-request against the project: `releng` that you are following: `` A SOP for adjusting EOLs on arbitrary branches. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7119

4 3

[pungi-fedora] PR #381: AH: Stop generating raw-xz images
by Colin Walters 13 Apr '19

13 Apr '19

walters opened a new pull-request against the project: `pungi-fedora` that you are following: `` AH: Stop generating raw-xz images `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/381

7 10

[releng] Issue #7584: Change Review request for minishift iso
by Praveen Kumar 13 Apr '19

13 Apr '19

kumarpraveen reported a new issue against the project: `releng` that you are following: `` * Describe the issue We have created the wiki for https://fedoraproject.org/w/index.php?title=Changes/Minishift_Spin to have fedora ISO for minishift for that we need your team review. * When do you need this? (YYYY/MM/DD) Sooner would be better. * When is this no longer needed or useful? (YYYY/MM/DD) N/A * If we cannot complete your request, what is the impact? We will not be going to have fedora iso from our official channel :( `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7584

4 4

[releng] Issue #7551: Self contained change review request
by Lukáš Tyrychtr 13 Apr '19

13 Apr '19

tyrylu reported a new issue against the project: `releng` that you are following: `` Hello. I'd like someone from release engineering to review this proposal: https://fedoraproject.org/wiki/Changes/Update_festival_to_2.5 Thanks. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7551

5 12

[releng] Issue #8091: rpm-software-management-sig ownership (currently owned by releng)
by Daniel Mach 12 Apr '19

12 Apr '19

dmach reported a new issue against the project: `releng` that you are following: `` The rpm-software-management-sig group[1] is currently owned by releng. I don't know what was the original purpose of the group, but the members are existing and former members of the Red Hat's Software Management team I lead. If you think it's a right thing to do, could you transfer the group ownership to me so I can manage membership any time a new team member joins the Software Management team? Another option would be to drop this group and replace it with a new one (possibly rpm-software-management without the -sig suffix). [1] https://src.fedoraproject.org/group/rpm-software-management-sig `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8091

3 3

[releng] Issue #7962: reconfigure koji builders to use LANG=C.UTF-8
by Zbigniew Jędrzejewski-Szmek 12 Apr '19

12 Apr '19

zbyszek reported a new issue against the project: `releng` that you are following: `` * Describe the issue As a follow-up for https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buil… and #7610, koji needs to run with LANG=en_US.UTF-8 replaced by LANG=C.UTF-8. * When do you need this? ASAP * When is this no longer needed or useful? never * If we cannot complete your request, what is the impact? Perl builds emit warnigs, cmake builds fail. Every Perl package build spits a warning like this: ``` perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "en_US.UTF-8" are supported and installed on your system. ``` Example <https://kojipkgs.fedoraproject.org//packages/perl-Task-Kensho-Async/0.40/1.…>. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7962

5 9

[releng] Issue #7903: rust-timerfd is not in grok-mirror
by Igor Gnatenko 12 Apr '19

12 Apr '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` https://src.fedoraproject.org/rpms/rust-timerfd exists for 2 months, but I can't see in my brand new mirror of git repos... \cc @kevin `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7903

2 3

[releng] Issue #7739: rubygem-rails occasionally fails to build
by Vít Ondruch 12 Apr '19

12 Apr '19

vondruch reported a new issue against the project: `releng` that you are following: `` * Describe the issue Koschei builds of rubygem-rails started to fail randomly \[[1]\] with errors such as: ~~~ DEBUG util.py:522: Executing command: ['/usr/bin/dnf', 'builddep', '--installroot', '/var/lib/mock/f30-build-13572340-985213/root/', '/var/lib/mock/f30-build-13572340-985213/root//builddir/build/SRPMS/rubygem-railties-5.2.1-2.fc30.src.rpm', '--setopt=tsflags=nocontexts'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'en_US.UTF-8', 'LC_MESSAGES': 'C'} and shell False DEBUG util.py:439: Last metadata expiration check: 0:00:01 ago on Thu 30 Aug 2018 04:01:54 PM UTC. DEBUG util.py:439: No matching package to install: 'rubygem(bootsnap)' DEBUG util.py:439: Not all dependencies satisfied DEBUG util.py:439: Error: Some packages could not be found. DEBUG util.py:577: Child return code was: 1 ~~~ This is weird because it sometimes works and it does not work the other time. It seems to be some issues on the builder side. [1]: https://apps.fedoraproject.org/koschei/package/rubygem-railties?collection=… `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7739

4 10

[releng] Issue #7712: Reassign lzma maintenance
by Antonio Trande 12 Apr '19

12 Apr '19

sagitter reported a new issue against the project: `releng` that you are following: `` * Name of the package? lzma * Maintainer's FAS username? sagitter * Any extra information? Although [LZMA Utils are no longer developed and replaced by XZ](https://tukaani.org/lzma/), they're still required by other packages on Fedora. lzma package is still correctly compiled on fedora 28+, it can endure for a little while yet as long as all dependent software migrate to XZ. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7712

6 9

[releng] Issue #7645: module metadata in releases/28/Modular/$basearch/os/repodata/ has no context or arch
by Daniel Mach 12 Apr '19

12 Apr '19

dmach reported a new issue against the project: `releng` that you are following: `` * Describe the issue Module metadata in released F28 repos has no context or arch. This impacts new libnf module dependency resolution code that needs both for proper functionality. More details in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1603109 * When do you need this? (2018/07/20) * When is this no longer needed or useful? (2019/05/07) * If we cannot complete your request, what is the impact? New libdnf with dependency resolution that supports stream expansion and architectures won't work on Fedora 28. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7645

3 4

[releng] Issue #7522: koji authentication is unreliable
by Till Maas 12 Apr '19

12 Apr '19

till reported a new issue against the project: `releng` that you are following: `` When trying to build, koji errors too often (IMHO) with AuthError: unable to obtain a session For example for 51 builds it happened 7 times and every time some builds before and afterwards cold be submitted without a problem, so it was not a outage but happenes every few builds. IMHO this is an indication that something is somehow broken, not sure what. The requests that failed were to build snownews qdevelop python-oslo-vmware ptlib opal nuvola-app-tunein nodejs-utf8 Here is some info about the tasks that were created before and afterwards to help identifying the exact times to be able to look into the logs: ``` Created task: 27243633 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=27243633 Rebuilding nuvola-app-tunein AuthError: unable to obtain a session Command '['koji', 'build', '--nowait', '--background', 'rawhide', 'git+https://src.fedoraproject.org/rpms/nuvola-app-tunein.git?#7608d8e356d71…']' returned non-zero exit status 1. Created task: 27243642 Created task: 27244803 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=27244803 Rebuilding opal AuthError: unable to obtain a session Command '['koji', 'build', '--nowait', '--background', 'rawhide', 'git+https://src.fedoraproject.org/rpms/opal.git?#ae968fe460fe56a1dad0c0a2aa…']' returned non-zero exit status 1. Created task: 27244810 Created task: 27245354 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=27245354 Rebuilding ptlib AuthError: unable to obtain a session Command '['koji', 'build', '--nowait', '--background', 'rawhide', 'git+https://src.fedoraproject.org/rpms/ptlib.git?#58737509e4992ef8812e9eecb…']' returned non-zero exit status 1. Created task: 27245366 Created task: 27245763 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=27245763 Rebuilding qdevelop AuthError: unable to obtain a session Command '['koji', 'build', '--nowait', '--background', 'rawhide', 'git+https://src.fedoraproject.org/rpms/qdevelop.git?#e4caa9d3e7ac737a960143…']' returned non-zero exit status 1. Created task: 27245767 ``` `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7522

3 3

[releng] Issue #7325: Cinnamon spin rawhide compose missing critical packages
by Dan Book 12 Apr '19

12 Apr '19

grinnz reported a new issue against the project: `releng` that you are following: `` The Cinnamon livemedia compose is missing several packages that are dependencies of the 'cinnamon' metapackage, despite including that package and others from the @cinnamon-desktop group as the kickstart has been unchanged. The issue seems to have started occurring after 2018-01-06, the earliest compose log that's still there is: https://kojipkgs.fedoraproject.org//packages/Fedora-Cinnamon-Live/Rawhide/2… and here is one from today: https://kojipkgs.fedoraproject.org//packages/Fedora-Cinnamon-Live/Rawhide/2… These logs say "Downloading 1426 RPMs" or so, I don't have the logs from 2018-01-05 and earlier but the number is supposed to be around 1470. As the kickstart isn't doing anything except including the @cinnamon-desktop group itself, I'm not sure how to debug this further. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7325

6 11

[releng] Issue #7311: Cleanup repositories with "dead.package"
by Igor Gnatenko 12 Apr '19

12 Apr '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` It would be very nice if you could set up automatic removal of all files except `dead.package` for repositories. Since `rpm-specs-latest.tar.xz` is not updated very often, I try to run grep on all git repositories, but unfortunately there are packages which are dead but still have spec file in there. I know that I could filter all such packages, but I think it would be better to clean them up anyway. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7311

7 13

[releng] Issue #7268: Wrongly-formed `Fedora-Modular--updates-testing-20171031.0` compose still present in updates dir
by Adam Williamson 12 Apr '19

12 Apr '19

adamwill reported a new issue against the project: `releng` that you are following: `` Going by fedmsg logs, there have been some very wrongly-formed attempts at update composes (my personal favourite is `Fedora-Modular-f27-updates-updates-Fedora-Modular-27-20171013.0`...), but most of them seem to have been cleaned up. There is still one that's clearly wrong, though, this one: https://kojipkgs.fedoraproject.org/compose/updates/Fedora-Modular--updates-… It was obviously meant to be `Fedora-Modular-27-updates-testing-20171031.0`, but somehow lost the release number. It'd make things cleaner if it got killed, I think. (There's probably very little value in keeping *any* of those `Fedora-Modular-27-updates-testing` composes around, but I'll leave that to you to figure out). @mohanboddu `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7268

3 3

[releng] Issue #7212: rubygem-factory_girl is not properly tagged in F27+
by Vít Ondruch 12 Apr '19

12 Apr '19

vondruch reported a new issue against the project: `releng` that you are following: `` I was wondering why rubygem-factory_girl is not build by Koschei \[[1]\] and I was told by @msimacek that the package is not properly tagged for F28: ~~~ $ koji list-tagged --inherit f28-build --latest | grep rubygem-factory_girl ~~~ Please note that the package was incorrectly unbolcked in #6904 and the unblocking was later fixed by #6982, so this still might be some outfall of this. Not sure ... [1]: https://apps.fedoraproject.org/koschei/package/rubygem-factory_girl `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7212

3 4

[releng] Issue #7206: Tag cockpit-ws container for f27
by Peter Volpe 12 Apr '19

12 Apr '19

pvolpe reported a new issue against the project: `releng` that you are following: `` We need a cockpit container for f27. The lastest build is here. https://koji.fedoraproject.org/koji/buildinfo?buildID=1000116 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7206

4 3

[releng] Issue #7201: Initial discussion for rpm-ostree jigdo ♲📦
by Colin Walters 12 Apr '19

12 Apr '19

walters reported a new issue against the project: `releng` that you are following: `` See https://github.com/projectatomic/rpm-ostree/issues/1081 and https://lists.fedoraproject.org/archives/list/rel-eng@lists.fedoraproject.o… Goal here is to determine initial design of integration; the whole idea is to decrease the burden on releng so hopefully we succeed at that! `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7201

5 6

[releng] Issue #7195: ODCS: create Koji channels which will be used by odcs main/children pungi runroot tasks
by Jan Kaluža 12 Apr '19

12 Apr '19

jkaluza reported a new issue against the project: `releng` that you are following: `` This is follow-up of meeting we have with @Kellin, @puiteriwjk, @mboddu, @ralph and others about using ODCS for alpha/beta composes. More info about motivation can be found here: https://docs.google.com/document/d/1VLOgxmdHL6eXMK1dZAsimJ1U3gtppntdeQkM-x8… In order to make ODCS scalable and keep using read-only access for /mnt/fedora_koji, we decided to run ODCS tasks in Koji runroot. We need to prevent deadlock scenario, when main runroot task with main pungi "process" submits to Koji another children runroot tasks (for example for buildinstall phase), but Koji would not have enough buiders for these runroot tasks ready. It has been advised that we could fix that by using different Koji channels for main pungi runroot task (this is submitted by ODCS backend) and children pungi runroot tasks (these are submitted by Pungi main runroot task). This request is official ticket asking for two new Koji channel. First one (for example "odcs"), to be used by ODCS backend process to spawn the main Pungi runroot. Second one (for example "odcs-pung") to be used by main Pungi runroot to spawn children runroot tasks. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7195

3 3

[releng] Issue #7194: ODCS: Create secret private volume to share secrets between Koji runroot tasks.
by Jan Kaluža 12 Apr '19

12 Apr '19

jkaluza reported a new issue against the project: `releng` that you are following: `` This is follow-up of meeting we have with @Kellin, @puiteriwjk, @mboddu, @ralph and others about using ODCS for alpha/beta composes. More info about motivation can be found here: https://docs.google.com/document/d/1VLOgxmdHL6eXMK1dZAsimJ1U3gtppntdeQkM-x8… In order to make ODCS scalable and keep using read-only access for /mnt/fedora_koji, we decided to run ODCS tasks in Koji runroot. That means that even the pungi running in Koji runroot task needs to be able to spawn another runroot task and therefore it needs some secret files like keytab. The advised solution for that was creating new secret volume which could be mounted in ODCS pungi runroot task and pungi in that runroot task can read kerberos keytab from that storage. ODCS backend/frontend would not have access to that directory. This ticket is official request for such storage. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7194

3 3

[releng] Issue #7174: Proposal: Give Bodhi a REST API for mashing
by Randy Barlow 12 Apr '19

12 Apr '19

bowlofeggs reported a new issue against the project: `releng` that you are following: `` Greetings releng! @puiterwijk and I came up with a glorious plan for Bodhi to give it a REST API to control mashing. This is needed in order to automate mass container rebuilds because Bodhi will need to be able to mash the lower layers into the registry before the higher layers that depend on them can be built. A REST API will allow automated services to ask Bodhi to do that when needed. Giving Bodhi a REST API into the masher opens the possibility for a lot of other Nice Things™ for releng, such as a much better way to see the status of the masher than we have today. Aren't you tired of tailing the logs to see what the masher is doing, or looking for lock files in the mash directory? Wouldn't it be nice if a CLI or possibly even web interface could tell you what's up? This will even make it possible to give bodhi a web interface to control the masher. Anyways, I'd like to solicit releng's feedback on the proposal. I have created a project for this that has all of the individual tickets that express the proposal in more detail than I've written here: https://github.com/fedora-infra/bodhi/projects/2 The tickets are arranged from top to bottom in priority order. The tickets that are marked "high priority" mean that I am going to attempt to get them done by Feb 20 (no guarantees though!), and they are required for Bodhi to support containers. The remaining tickets I will pursue after that. Please peruse the various tickets, and please provide feedback in the tickets if you have any. I filed this ticket so we could discuss it during one of your weekly meetings, if you like. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7174

3 3

[releng] Issue #7150: Retiring ghostscript-fonts for F27 without noticing it is already Final Freeze
by Zdenek Dohnal 12 Apr '19

12 Apr '19

zdohnal reported a new issue against the project: `releng` that you are following: `` Hi, this Monday I finally got to issue which I already discussed on devel-list - removing ghostscript-fonts from Fedora, because they are deprecated long ago and they are replaced by urw-base35-fonts. Two remaining components ghostscript and hylafax+, which had dependency on ghostscript-fonts, removed this dependency, so I retired it for F27 and F28. But problem is, I didn't check Fedora 27 schedule, and F27 is already in Final Freeze, in which retiring packages mustn't happen (I check emails regulary on devel, devel-announce, fedora-announce and test-announce, but all I saw was postponing Fedora 27, so I thought it isn't Final Freeze already), I'm really sorry about it. What can I do now for F27? Should I request unretirement for only one release? Or will package be retired for F27? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7150

3 6

[releng] Issue #7104: Koji tries to build i686-only packages on i386 (error: Architecture is not included: i386)
by Igor Gnatenko 12 Apr '19

12 Apr '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` In rust-packaging we have ``` BuildArch: noarch ExclusiveArch: %{rust_arches} noarch ``` Where ``` [brain@ignatenko-w541 rust-packaging]$ rpm --eval %rust_arches x86_64 i686 armv7hl aarch64 ppc64 ppc64le s390x ``` Somehow koji schedules build on machine which has i386 architecture: https://koji.fedoraproject.org/koji/taskinfo?taskID=22585560 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7104

4 11

[releng] Issue #7097: Automate the process of reviewing and merging PRs on releng/fedora-scm-requests
by Pierre-YvesChibon 12 Apr '19

12 Apr '19

pingou reported a new issue against the project: `releng` that you are following: `` The https://pagure.io/releng/fedora-scm-requests/ project is used for few things: - Ask for a new package to be added to the distro - Ask for a new branch on an existing package - Tune the anitya integration flag - Set bugzilla overrides (so EPEL bugs go to a different person than the Fedora ones) The first two tasks are requested by tickets at: https://pagure.io/releng/fedora-scm-requests/issues and processed by releng using [fedrepo-req](). The last two tasks are requested by PRs and could be automatically reviewed and merged. I would like to propose that we do this automation, all it requires is checking that the person opening the ticket has ACLs on the project (up to us if we want to limit this to ``admins`` for example). If these people have ACL on the project, then it's just like on pkgdb before, we let the users configure things the way they want. I do not think there is a good reason to be blocking any changes the maintainers want to do on their package. Thoughts? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7097

3 6

[releng] Issue #7083: orphan-all-packages.py should remove bugzilla_contact entries from fedora-scm-requests as well
by Till Maas 12 Apr '19

12 Apr '19

till reported a new issue against the project: `releng` that you are following: `` orphan-all-packages.py only updates pagure, but fedora-scm-requests also contains owners for other branches such as EPEL. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7083

3 4

[releng] Issue #7079: reset 27 atomic host ostree repo
by Dusty Mabe 12 Apr '19

12 Apr '19

dustymabe reported a new issue against the project: `releng` that you are following: `` We are currently using smart versioning for our ostree repo in Fedora 27 (i.e. using `"version": '!OSTREE_VERSION_FROM_LABEL_DATE_TYPE_RESPIN'` feature of pungi). Since we have not yet completed the work to move bodhi to pungi from mash we need to go back to not smart versioning like we were doing in previous releases for now. I'll open a PR against pungi-fedora for this. In order to do this we need the repo to be reset. This can be as simple as removing just the refs `fedora/27/${basearch}/atomic-host`. Extra credit would be to also prune the repo so that we drop content we no longer care about. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7079

5 12

[releng] Issue #7071: libcrypt-nss-2.26-8.fc27.i686 missing from Fedora 27 x86_64 compose
by Florian Weimer 12 Apr '19

12 Apr '19

fweimer reported a new issue against the project: `releng` that you are following: `` The multlib RPM went missing: $ rsync rsync://ftp-stud.hs-esslingen.de/fedora/linux/updates/testing/27/x86_64/l/ | grep libcrypt -rw-r--r-- 74,352 2017/09/15 12:51:44 libcrypt-2.26-8.fc27.i686.rpm -rw-r--r-- 73,492 2017/09/15 12:53:17 libcrypt-2.26-8.fc27.x86_64.rpm -rw-r--r-- 66,192 2017/09/15 12:50:54 libcrypt-nss-2.26-8.fc27.x86_64.rpm This currently breaks updates, see [#1495431](https://bugzilla.redhat.com/show_bug.cgi?id=1495431). `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7071

6 26

[releng] Issue #7067: Fix package ownership in koji
by Dennis Gilmore 12 Apr '19

12 Apr '19

ausil reported a new issue against the project: `releng` that you are following: `` in talking to @ralph about why everything in koji is owner by releng, when it should be owned by someone responsible for the package. It was switched to releng due to fetching the information from pagure taking too long. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7067

4 5

[releng] Issue #7637: updates debuginfo repos not available for ppc64le
by Dan Horák 09 Apr '19

09 Apr '19

sharkcz reported a new issue against the project: `releng` that you are following: `` * Describe the issue Mirrormanager doesn't return any repo for updates (and updates-testing) debuginfos for the F-28 ppc64le. After checking with "curl", debuginfo repos exists for all arches, except ppc64le. ```` curl 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f28&…' ... # repo=updates-released-debug-f28&arch=aarch64 # repo=updates-released-debug-f28&arch=armhfp # repo=updates-released-debug-f28&arch=i386 # repo=updates-released-debug-f28&arch=ppc64 # repo=updates-released-debug-f28&arch=s390x # repo=updates-released-debug-f28&arch=x86_64 ... ```` * When do you need this? (YYYY/MM/DD) ASAP * When is this no longer needed or useful? (YYYY/MM/DD) N/A * If we cannot complete your request, what is the impact? Bad user experience on F-28 ppc64le. CC: @adrian `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7637

5 17

[releng] Issue #7823: Add special "provides" or new stream for platform module ("latest" and/or "rawhide")
by Igor Gnatenko 09 Apr '19

09 Apr '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` Right now, all rust packages are kept up to date only in rawhide but there is no way to say `buildrequires: platform: [rawhide]`, I always have to update it manually after branching. \cc @psabata `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7823

3 3

[releng] Issue #7792: glibc-headers-2.28-9.fc29.i686 seems to be missing from mirrors
by Zbigniew Jędrzejewski-Szmek 09 Apr '19

09 Apr '19

zbyszek reported a new issue against the project: `releng` that you are following: `` * Describe the issue ```console $ dnf list glibc-headers Last metadata expiration check: 0:03:05 ago on Mon 10 Sep 2018 09:41:45 AM CEST. Installed Packages glibc-headers.x86_64 2.28-9.fc29 @updates-testing Available Packages glibc-headers.i686 2.28-6.fc29 fedora ``` As you can see, the .i686 version has a lower version, so glibc-headers.i686 conflicts with glibc-headers.x86_64, causing problems on upgrades (dnf wants to remove half of the world along with glibc-headers.i686). In koji build, all the subpackages are present: https://koji.fedoraproject.org/koji/buildinfo?buildID=1140359. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7792

2 2

[releng] Issue #7732: staging: f29-flatpak-build, create f29 branch for minimal-runtime
by Owen Taylor 09 Apr '19

09 Apr '19

otaylor reported a new issue against the project: `releng` that you are following: `` Looking at staging koji, it looks like a sync from production was done before the f29 flatpak tags/targets were added to production, so the f28 flatpak tags/targets we were using previously removed, but the f29 ones weren't sync'ed in. It's probably simplest to create the f29 tags so that future sync's won't mess things up, and I'll retarget my test content. koji -p staging add-tag f29-flatpak koji -p staging add-target f29-flatpak-candidate f29-build f29-flatpak koji -p staging add-pkg --owner=otaylor f29-flatpak minimal-runtime banner Also, I'll need a f29 branch of modules/minimal-runtime in git. Thanks! `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7732

3 3

[releng] Issue #7705: nvidia-query-resource-opengl-lib multilib whitelist
by Nicolas Chauvet 09 Apr '19

09 Apr '19

kwizart reported a new issue against the project: `releng` that you are following: `` * Describe the issue There is a need to add nvidia-query-resource-opengl-lib.i686 into the x86_64 repository. This library is used supposed to be pre-loaded before debuging a particular OpenGL process for resources usage. It is built out of the nvidia-query-resource-opengl package which doesn't provide any -devel files. As such the -lib sub-package isn't automatically copied into the x86_64 where it would be useful. * When do you need this? (YYYY/MM/DD) any time when possible. * When is this no longer needed or useful? (YYYY/MM/DD) * If we cannot complete your request, what is the impact? It will not be possible to debug i686 libraries and 3rd part binaries using the OpenGL query resource extension. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7705

3 3

[releng] Issue #7573: Rebase binutils to 2.31 release
by Nicholas Clifton 09 Apr '19

09 Apr '19

nickc reported a new issue against the project: `releng` that you are following: `` Rebase the binutils package from the 2.30 release to the 2.31 release of the FSF binutils project. The change request is here: https://fedoraproject.org/w/index.php?title=Changes/BINUTILS231 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7573

4 4

[releng] Issue #7499: New variant subpackages for fedora-release
by Matthew Miller 09 Apr '19

09 Apr '19

mattdm reported a new issue against the project: `releng` that you are following: `` Proposed change: https://fedoraproject.org/wiki/Changes/Label_Our_Variants Right now, we have `-atomichost`, `-cloud`, `-server`, and `-workstation`. This change would add: -container -kdeplasma -xfce -mate-compiz -cinnamon -lxde -soas -silverblue and possibly also -astronomy -designsuite -games -jam -pythonclassroom -roboticssuite -scientific -securitylab `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7499

5 19

[releng] Issue #7578: Impact check for Fedora 29 self-contained change: glibc32 Build Adjustments
by Florian Weimer 09 Apr '19

09 Apr '19

fweimer reported a new issue against the project: `releng` that you are following: `` https://fedoraproject.org/wiki/Changes/glibc32_Build_Adjustments Only affects gcc and glibc. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7578

3 4

[releng] Issue #7846: Please unblock epel7 branch of rpms/libssh (and Koji)
by Robert Scheck 01 Apr '19

01 Apr '19

robert reported a new issue against the project: `releng` that you are following: `` * Describe the issue The package `libssh` got part of the `rhel-7-{server,workstation}-extras-rpms` repo, however only for the x86_64 architecture, but not for aarch64, ppc64 and ppc64le. Thus it is currently not possible to build e.g. `tmate` for EPEL 7 on all architectures. As per https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages, I would like to import the current RHEL source RPM into EPEL 7 with lower ENVRA, but the `epel7` branch of `libssh` is blocked in Git (and likely also in Koji). ``` ! [remote rejected] epel7 -> epel7 (hook declined) ``` * When do you need this? (YYYY/MM/DD) As soon as possible, but not urgent. * When is this no longer needed or useful? (YYYY/MM/DD) n/a * If we cannot complete your request, what is the impact? n/a `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7846

3 11

[releng] Issue #7840: Consider ursa-major
by Ralph Bean 27 Mar '19

27 Mar '19

ralph reported a new issue against the project: `releng` that you are following: `` See this older thread on the infra list for some context: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr… We created a tool that will automatically tag *some* module builds into the inheritance hierarchy for the base buildroot. Adopting it in Fedora will provide a way for some rpms to move 100% into modules while still being available at buildtime to other core packages which need them. @sgallagh and @mizdebsk, can you elaborate? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7840

8 24

[releng] Issue #8049: Claim orphaned python-resumable-urlretrieve
by Luis Enrique Bazán De León 26 Mar '19

26 Mar '19

lbazan reported a new issue against the project: `releng` that you are following: `` Please unorphan python-resumable-urlretrieve - rawhide Review request https://bugzilla.redhat.com/show_bug.cgi?id=1665541 FAS Account: lbazan Cheers! `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8049

3 7

[releng] Issue #7635: RFE: Include all maintainers in the mass-rebuild failure pages
by Jason ティビツ 26 Mar '19

26 Mar '19

tibbs reported a new issue against the project: `releng` that you are following: `` * Describe the issue The mass-rebuild failure script at https://pagure.io/releng/blob/master/f/scripts/find_failures.py which generates https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html makes use of only the first maintainer in the data returned by pagure. So the list misses many maintainers, and this has generated a couple of complaints about it not being easy for some people to find packages they need to look at. There's a script we use when mailing out notices about package problems and mass package changes which lives at https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-…. That script generates two lists: one lists packages with a list of maintainers, the other lists maintainers with a list of packages. We find this to be a pretty useful format. One other thing from our script which would be useful is that it makes use of the cached owner data provided by pagure (at https://src.fedoraproject.org/extras/pagure_owner_alias.json) instead of making an API call per package. This speeds it up, well, a whole lot. That file is updated hourly. * When do you need this? Would be nice to have it before the next mass rebuild, though I guess if we can change it before this one is complete then why not. * When is this no longer needed or useful? I guess it would always be nice to have this. * If we cannot complete your request, what is the impact? Probably just more complaints about packagers not seeing their names in the list when packages they maintain fail to build. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7635

4 6

[releng] Issue #7569: Fedora 29 system-wide change: Golang 1.11
by Jakub Čajka 26 Mar '19

26 Mar '19

jcajka reported a new issue against the project: `releng` that you are following: `` Hello, this is tracking issue for the Golang 1.11 change proposal, that would require rebuild of all Go based package(either as side tag rebuild or during mass rebuild). New golang version is not yet available in rawhide. I will update this issue when the new golang version will be available and so rebuild possible. List of package to rebuild follows(from up mentioned change proposal): ``` atomic buildah caddy cadvisor consul containerd containernetworking-cni cri-o cri-tools deepin-daemon deepin-gir-generator dep direnv docker docker-distribution docker-latest douceur etcd exercism fzf git-lfs glide glusterd2 go-bindata go-i18n gocomplete godep godotenv gofed golang-apache-thrift golang-bazil-fuse golang-bitbucket-kardianos-osext golang-bitbucket-ww-goautoneg golang-deepin-dbus-factory golang-deepin-go-lib golang-dmitri-shuralyov-html-belt golang-dmitri-shuralyov-route-github golang-dmitri-shuralyov-state golang-github-10gen-escaper golang-github-10gen-openssl golang-github-3rf-mongo-lint golang-github-AdRoll-goamz golang-github-AudriusButkevicius-cli golang-github-AudriusButkevicius-go-nat-pmp golang-github-AudriusButkevicius-kcp-go golang-github-AudriusButkevicius-pfilter golang-github-Azure-azure-sdk-for-go golang-github-BurntSushi-freetype-go golang-github-BurntSushi-graphics-go golang-github-BurntSushi-toml golang-github-BurntSushi-xgb golang-github-BurntSushi-xgbutil golang-github-DATA-DOG-go-sqlmock golang-github-DataDog-datadog-go golang-github-Jeffail-gabs golang-github-MakeNowJust-heredoc golang-github-Masterminds-semver golang-github-Masterminds-vcs golang-github-PuerkitoBio-goquery golang-github-PuerkitoBio-purell golang-github-PuerkitoBio-urlesc golang-github-RangelReale-osin golang-github-RangelReale-osincli golang-github-SAP-go-hdb golang-github-SermoDigital-jose golang-github-Shopify-sarama golang-github-Shopify-toxiproxy golang-github-Sirupsen-logrus golang-github-a8m-tree golang-github-abbot-go-http-auth golang-github-aclements-gg golang-github-aclements-moremath golang-github-aead-chacha20 golang-github-aead-poly1305 golang-github-agl-ed25519 golang-github-ajstarks-svgo golang-github-akrennmair-gopcap golang-github-alcortesm-tgz golang-github-alecthomas-assert golang-github-alecthomas-chroma golang-github-alecthomas-colour golang-github-alecthomas-kingpin golang-github-alecthomas-repr golang-github-alecthomas-template golang-github-alecthomas-units golang-github-andybalholm-cascadia golang-github-anmitsu-shlex golang-github-appc-spec golang-github-armon-circbuf golang-github-armon-go-metrics golang-github-armon-go-proxyproto golang-github-armon-go-radix golang-github-armon-gomdb golang-github-asaskevich-govalidator golang-github-auth0-go-jwt-middleware golang-github-aws-aws-sdk-go golang-github-axgle-mahonia golang-github-azure-autorest golang-github-beevik-ntp golang-github-beorn7-perks golang-github-bep-gitmap golang-github-bep-inflect golang-github-bgentry-go-netrc golang-github-bgentry-speakeasy golang-github-billziss-gh-cgofuse golang-github-bitly-simplejson golang-github-bkaradzic-go-lz4 golang-github-blang-semver golang-github-bmizerany-assert golang-github-bmizerany-pat golang-github-bmizerany-perks golang-github-boltdb-bolt golang-github-boombuler-barcode golang-github-bradfitz-gomemcache golang-github-bradfitz-http2 golang-github-bradfitz-smtpd golang-github-buger-jsonparser golang-github-bugsnag-bugsnag-go golang-github-bugsnag-panicwrap golang-github-calmh-du golang-github-calmh-luhn golang-github-calmh-xdr golang-github-ccding-go-stun golang-github-cenkalti-backoff golang-github-cespare-xxhash golang-github-chaseadamsio-goorgeous golang-github-cheekybits-is golang-github-cheggaaa-pb golang-github-chmduquesne-rollinghash golang-github-chrismalek-oktasdk-go golang-github-chzyer-logex golang-github-chzyer-test golang-github-circonus-labs-circonus-gometrics golang-github-circonus-labs-circonusllhist golang-github-client9-gospell golang-github-cloudfoundry-incubator-candiedyaml golang-github-cockroachdb-cmux golang-github-cockroachdb-cockroach-go golang-github-codahale-aesnicheck golang-github-codegangsta-cli golang-github-codegangsta-negroni golang-github-collectd-go-collectd golang-github-coreos-bbolt golang-github-coreos-gexpect golang-github-coreos-go-etcd golang-github-coreos-go-iptables golang-github-coreos-go-log golang-github-coreos-go-oidc golang-github-coreos-go-semver golang-github-coreos-go-systemd golang-github-coreos-pkg golang-github-cpuguy83-go-md2man golang-github-cryptix-wav golang-github-cznic-b golang-github-cznic-fileutil golang-github-cznic-golex golang-github-cznic-internal golang-github-cznic-lex golang-github-cznic-lexer golang-github-cznic-lldb golang-github-cznic-mathutil golang-github-cznic-ql golang-github-cznic-sortutil golang-github-cznic-strutil golang-github-cznic-zappy golang-github-d2g-dhcp4 golang-github-d2g-dhcp4client golang-github-d4l3k-messagediff golang-github-danwakefield-fnmatch golang-github-data-dog-godog golang-github-data-dog-txdb golang-github-davecgh-go-spew golang-github-daviddengcn-go-colortext golang-github-dchest-cssmin golang-github-dchest-safefile golang-github-dchest-siphash golang-github-denisenkom-go-mssqldb golang-github-denverdino-aliyungo golang-github-dgnorton-goback golang-github-dgrijalva-jwt-go golang-github-digitalocean-godo golang-github-dimchansky-utfbom golang-github-disintegration-imaging golang-github-djherbis-times golang-github-dlclark-regexp2 golang-github-dnaeon-vcr golang-github-docker-go golang-github-docker-go-connections golang-github-docker-go-units golang-github-docker-libcontainer golang-github-docker-libkv golang-github-docker-libtrust golang-github-docker-spdystream golang-github-dropbox-sdk-unofficial golang-github-dsnet-compress golang-github-dsnet-golib golang-github-duosecurity-duo_api_golang golang-github-dustin-go-humanize golang-github-dvsekhvalnov-jose2go golang-github-eapache-go-resiliency golang-github-eapache-queue golang-github-edsrzf-mmap-go golang-github-eknkc-amber golang-github-elazarl-go-bindata-assetfs golang-github-ema-qdisc golang-github-emicklei-go-restful golang-github-emirpasic-gods golang-github-endophage-gotuf golang-github-evanphx-json-patch golang-github-facebookgo-atomicfile golang-github-facebookgo-pidfile golang-github-fatih-color golang-github-fatih-pool golang-github-fatih-structs golang-github-flynn-go-shlex golang-github-flynn-json5 golang-github-fortytw2-leaktest golang-github-fsnotify-fsnotify golang-github-fsouza-go-dockerclient golang-github-fullsailor-pkcs7 golang-github-garyburd-redigo golang-github-gdamore-encoding golang-github-gdamore-tcell golang-github-gengo-grpc-gateway golang-github-getsentry-raven-go golang-github-ghodss-yaml golang-github-git-lfs-wildmatch golang-github-glacjay-goini golang-github-gliderlabs-ssh golang-github-globalsign-mgo golang-github-go-asn1-ber-asn1-ber golang-github-go-errors-errors golang-github-go-fsnotify-fsnotify golang-github-go-ini-ini golang-github-go-ldap-ldap golang-github-go-macaron-inject golang-github-go-mgo-mgo golang-github-go-sql-driver-mysql golang-github-go-tomb-tomb golang-github-gobuffalo-envy golang-github-gobwas-glob golang-github-gocql-gocql golang-github-godbus-dbus golang-github-golang-appengine golang-github-golang-glog golang-github-golang-groupcache golang-github-golang-image golang-github-golang-sys golang-github-golang-time golang-github-gonum-blas golang-github-gonum-floats golang-github-gonum-graph golang-github-gonum-internal golang-github-gonum-lapack golang-github-gonum-matrix golang-github-google-btree golang-github-google-cmp golang-github-google-go-cmp golang-github-google-go-genproto golang-github-google-go-github golang-github-google-go-querystring golang-github-google-gofuzz golang-github-google-pprof golang-github-googleapis-gax golang-github-googlecloudplatform-cloudsql-proxy golang-github-gopherjs golang-github-goraft-raft golang-github-gorilla-context golang-github-gorilla-css golang-github-gorilla-handlers golang-github-gorilla-mux golang-github-gorilla-securecookie golang-github-gorilla-sessions golang-github-gorilla-websocket golang-github-gosexy-gettext golang-github-gregjones-httpcache golang-github-grpc-ecosystem-go-grpc-prometheus golang-github-grpc-ecosystem-grpc-gateway golang-github-grpc-grpc-go golang-github-hailocab-go-hostpool golang-github-hashicorp-consul-migrate golang-github-hashicorp-errwrap golang-github-hashicorp-go-checkpoint golang-github-hashicorp-go-cleanhttp golang-github-hashicorp-go-hclog golang-github-hashicorp-go-immutable-radix golang-github-hashicorp-go-memdb golang-github-hashicorp-go-msgpack golang-github-hashicorp-go-multierror golang-github-hashicorp-go-plugin golang-github-hashicorp-go-retryablehttp golang-github-hashicorp-go-rootcerts golang-github-hashicorp-go-sockaddr golang-github-hashicorp-go-syslog golang-github-hashicorp-go-uuid golang-github-hashicorp-golang-lru golang-github-hashicorp-hcl golang-github-hashicorp-hil golang-github-hashicorp-logutils golang-github-hashicorp-mdns golang-github-hashicorp-memberlist golang-github-hashicorp-net-rpc-msgpackrpc golang-github-hashicorp-raft golang-github-hashicorp-raft-boltdb golang-github-hashicorp-raft-mdb golang-github-hashicorp-scada-client golang-github-hashicorp-serf golang-github-hashicorp-yamux golang-github-hawkular-hawkular-client-go golang-github-howeyc-fsnotify golang-github-howeyc-gopass golang-github-ianlancetaylor-demangle golang-github-imdario-mergo golang-github-inconshreveable-go-vhost golang-github-inconshreveable-mousetrap golang-github-inconshreveable-muxado golang-github-influxdb-gomdb golang-github-influxdb-hyperleveldb-go golang-github-influxdb-influxdb golang-github-influxdb-rocksdb golang-github-jackpal-gateway golang-github-jacobsa-oglematchers golang-github-jbenet-context golang-github-jdkato-prose golang-github-jdkato-syllables golang-github-jedisct1-clocksmith golang-github-jedisct1-dlog golang-github-jedisct1-dnsstamps golang-github-jedisct1-minisign golang-github-jedisct1-xsecretbox golang-github-jefferai-jsonx golang-github-jellevandenhooff-dkim golang-github-jessevdk-go-flags golang-github-jfrazelle-go golang-github-jfrogdev-gofrog golang-github-jinzhu-gorm golang-github-jlaffaye-ftp golang-github-jmank88-nuts golang-github-jmespath-go-jmespath golang-github-jmhodges-levigo golang-github-jonboulle-clockwork golang-github-jtolds-gls golang-github-juju-ratelimit golang-github-julienschmidt-httprouter golang-github-justinas-alice golang-github-k-sone-critbitgo golang-github-kardianos-service golang-github-karlseguin-ccache golang-github-karlseguin-expect golang-github-kballard-go-shellquote golang-github-kdar-factorlog golang-github-kevinburke-ssh-config golang-github-keybase-go-crypto golang-github-kimor79-gollectd golang-github-kisielk-gotool golang-github-klauspost-compress golang-github-klauspost-cpuid golang-github-klauspost-crc32 golang-github-klauspost-reedsolomon golang-github-knieriem-markdown golang-github-kolo-xmlrpc golang-github-kr-fs golang-github-kr-pretty golang-github-kr-pty golang-github-kr-text golang-github-kylelemons-godebug golang-github-kyokomi-emoji golang-github-lib-pq golang-github-linuxdeepin-go-x11-client golang-github-lpabon-godbc golang-github-lsegal-gucumber golang-github-lucasb-eyer-colorful golang-github-lucasb-eyer-go-colorful golang-github-magiconair-properties golang-github-markbates-inflect golang-github-marstr-collection golang-github-marstr-goalias golang-github-marstr-guid golang-github-marstr-randname golang-github-mattn-go-colorable golang-github-mattn-go-isatty golang-github-mattn-go-runewidth golang-github-mattn-go-sqlite3 golang-github-mattn-shellwords golang-github-matttproud-golang_protobuf_extensions golang-github-mdlayher-genetlink golang-github-mdlayher-netlink golang-github-mdlayher-wifi golang-github-mesos-mesos-go golang-github-mgutz-ansi golang-github-mgutz-logxi golang-github-mholt-archiver golang-github-michaelklishin-rabbit-hole golang-github-microcosm-cc-bluemonday golang-github-miekg-dns golang-github-miekg-mmark golang-github-miekg-pkcs11 golang-github-milochristiansen-axis2 golang-github-milochristiansen-lua golang-github-minio-sha256-simd golang-github-mistifyio-go-zfs golang-github-mitchellh-cli golang-github-mitchellh-copystructure golang-github-mitchellh-go-homedir golang-github-mitchellh-go-testing-interface golang-github-mitchellh-go-wordwrap golang-github-mitchellh-goamz golang-github-mitchellh-mapstructure golang-github-mitchellh-reflectwalk golang-github-montanaflynn-stats golang-github-msteinert-pam golang-github-muesli-smartcrop golang-github-mvo5-goconfigparser golang-github-mvo5-uboot-go golang-github-mxk-go-flowrate golang-github-ncw-acd golang-github-ncw-dropbox-sdk-unofficial golang-github-ncw-swift golang-github-neelance-astrewrite golang-github-neelance-sourcemap golang-github-neurosnap-sentences golang-github-nfnt-resize golang-github-nightlyone-lockfile golang-github-noahdesu-go-ceph golang-github-nsf-termbox golang-github-nwaples-rardecode golang-github-nwidger-jsoncolor golang-github-ojii-gettext.go golang-github-okzk-sdnotify golang-github-olekukonko-tablewriter golang-github-olekukonko-ts golang-github-olivere-elastic golang-github-onsi-ginkgo golang-github-onsi-gomega golang-github-opencontainers-runtime-spec golang-github-opencontainers-specs golang-github-openzipkin-zipkin golang-github-oschwald-geoip2-golang golang-github-oschwald-maxminddb-golang golang-github-patrickmn-go-cache golang-github-paulrosania-go-charset golang-github-pebbe-zmq4 golang-github-pelletier-go-buffruneio golang-github-pelletier-go-toml golang-github-pengsrc-shared golang-github-petar-GoLLRB golang-github-peterbourgon-diskv golang-github-peterh-liner golang-github-petermattis-goid golang-github-pkg-errors golang-github-pkg-profile golang-github-pkg-sftp golang-github-pmezard-go-difflib golang-github-pquerna-cachecontrol golang-github-pquerna-otp golang-github-prometheus-client_golang golang-github-prometheus-client_model golang-github-prometheus-common golang-github-prometheus-procfs golang-github-prometheus-prometheus golang-github-rackspace-gophercloud golang-github-rakyll-pb golang-github-rasky-go-xdr golang-github-remeh-sizedwaitgroup golang-github-remyoudompheng-bigfft golang-github-rfjakob-eme golang-github-robertkrimen-otto golang-github-russross-blackfriday golang-github-ryanuber-go-glob golang-github-samalba-dockerclient golang-github-sasha-s-go-deadlock golang-github-satori-uuid golang-github-sdboyer-constext golang-github-seccomp-libseccomp-golang golang-github-sergi-go-diff golang-github-sethgrid-pester golang-github-sevlyar-daemon golang-github-shiena-ansicolor golang-github-shirou-gopsutil golang-github-shogo82148-go-shuffle golang-github-shopspring-decimal golang-github-shurcooL-sanitized_anchor_name golang-github-shurcool golang-github-shurcool-component golang-github-shurcool-events golang-github-shurcool-flavored-markdown golang-github-shurcool-frontend golang-github-shurcool-githubql golang-github-shurcool-gofontwoff golang-github-shurcool-goon golang-github-shurcool-graphql golang-github-shurcool-highlight golang-github-shurcool-highlight-diff golang-github-shurcool-home golang-github-shurcool-htmlg golang-github-shurcool-httperror golang-github-shurcool-httpfs golang-github-shurcool-httpgzip golang-github-shurcool-issues golang-github-shurcool-issuesapp golang-github-shurcool-markdownfmt golang-github-shurcool-notifications golang-github-shurcool-notificationsapp golang-github-shurcool-octiconssvg golang-github-shurcool-reactions golang-github-shurcool-users golang-github-shurcool-webdavfs golang-github-smartystreets-assertions golang-github-smartystreets-goconvey golang-github-soundcloud-runit golang-github-sourcegraph-annotate golang-github-sourcegraph-syntaxhighlight golang-github-spacejam-loghisto golang-github-spacemonkeygo-flagfile golang-github-spacemonkeygo-openssl golang-github-spacemonkeygo-spacelog golang-github-spaolacci-murmur3 golang-github-spf13-afero golang-github-spf13-cast golang-github-spf13-cobra golang-github-spf13-fsync golang-github-spf13-jWalterWeatherman golang-github-spf13-nitro golang-github-spf13-pflag golang-github-spf13-viper golang-github-src-d-gcfg golang-github-sstarcher-go-okta golang-github-stevvooe-resumable golang-github-streadway-amqp golang-github-stretchr-objx golang-github-stretchr-testify golang-github-syncthing-notify golang-github-syndtr-gosnappy golang-github-t3rm1n4l-go-mega golang-github-tambet-asana golang-github-tarm-serial golang-github-tchap-go-patricia golang-github-templexxx-cpufeat golang-github-templexxx-reedsolomon golang-github-templexxx-xor golang-github-thejerf-suture golang-github-thomsonreuterseikon-ntlm golang-github-tjfoc-gmsm golang-github-ugorji-go golang-github-ulikunitz-xz golang-github-unknwon-goconfig golang-github-urfave-cli golang-github-vbatts-tar-split golang-github-vishvananda-netlink golang-github-vishvananda-netns golang-github-vitrun-qart golang-github-vividcortex-ewma golang-github-vividcortex-godaemon golang-github-vjeantet-asn1-ber golang-github-wsxiaoys-terminal golang-github-xanzy-ssh-agent golang-github-xeipuuv-gojsonpointer golang-github-xeipuuv-gojsonreference golang-github-xeipuuv-gojsonschema golang-github-xiang90-probing golang-github-xrash-smetrics golang-github-xtaci-kcp-go golang-github-xtaci-smux golang-github-yosssi-ace golang-github-yosssi-gohtml golang-github-yuin-gopher-lua golang-github-yunify-qingstor-sdk golang-github-yvasiyarov-go-metrics golang-github-yvasiyarov-gorelic golang-github-yvasiyarov-newrelic_platform_go golang-github-zillode-notify golang-github-zyedidia-clipboard golang-github-zyedidia-glob golang-github-zyedidia-poller golang-github-zyedidia-pty golang-github-zyedidia-tcell golang-github-zyedidia-terminal golang-go4 golang-google-golangorg-cloud golang-googlecode-go-crypto golang-googlecode-go-decimal-inf golang-googlecode-go-exp golang-googlecode-goauth2 golang-googlecode-gogoprotobuf golang-googlecode-gomock golang-googlecode-google-api-client golang-googlecode-goprotobuf golang-googlecode-net golang-googlecode-text golang-googlecode-tools golang-googlecode-uuid golang-gopkg-check golang-gopkg-data-dog-sqlmock-1 golang-gopkg-go-check-check golang-gopkg-go-macaroon-macaroon golang-gopkg-natefinch-lumberjack-2 golang-gopkg-pipe-2 golang-gopkg-readline-1 golang-gopkg-retry-v1 golang-gopkg-sourcemap golang-gopkg-sourcemap-1 golang-gopkg-src-d-billy golang-gopkg-src-d-git golang-gopkg-src-d-git-fixtures golang-gopkg-warnings golang-gopkg-yaml golang-grpc-go4 golang-honnef-js-dom golang-honnef-tools golang-layeh-gopher-luar golang-opencensus golang-torproject-pluggable-transports-goptlib golang-x-build golang-x-debug golang-x-perf golang-x-sync golint gomtree gotun heketi hub hugo jid kompose manifest-tool micro mongo-tools obfs4 oci-kvm-hook oci-register-machine ocitools podman popub powerline-go rclone runc skopeo snapd source-to-image syncthing arduino-builder audit caddy containerd deepin-api deepin-dbus-generator flannel go-compilers golang golang-github-BurntSushi-toml-test golang-github-SeanDolphin-bqschema golang-github-docopt-docopt-go golang-github-influxdb-go-cache golang-github-mreiferson-go-httpclient golang-github-openshift-go-json-rest golang-github-openshift-go-systemd golang-github-racker-perigee golang-github-rakyll-globalconf golang-github-rakyll-statik golang-github-rcrowley-go-metrics golang-github-ryanuber-columnize golang-github-samalba-dockerclient golang-github-samuel-go-zookeeper golang-github-skarademir-naturalsort golang-github-skratchdot-open-golang golang-github-skynetservices-skydns golang-github-smartystreets-go-aws-auth golang-github-stathat-go golang-github-syndtr-gocapability golang-github-syndtr-goleveldb golang-github-tent-http-link-go golang-github-tonnerre-golang-pretty golang-github-vaughan0-go-ini golang-github-vmware-govcloudair golang-googlecode-gcfg golang-googlecode-log4go golang-googlecode-sqlite gotags kubernetes openvswitch-ovn-kubernetes origin reg rkt startdde swig tmux-top ``` `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7569

5 10

[releng] Issue #7537: Requesting rel-eng review of Node.js 10.x Change Proposal
by Stephen Gallagher 26 Mar '19

26 Mar '19

sgallagh reported a new issue against the project: `releng` that you are following: `` I'm going to be updating Node.js to 10.x in Fedora 29 which may (unclear yet) require a side-tag to rebuild the native packages. We need a review by rel-eng as part of the Change Process. CC @jkurik `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7537

3 3

[releng] Issue #7543: Impact check for Fedora 29 change: i686 Is For x86-64
by Florian Weimer 26 Mar '19

26 Mar '19

fweimer reported a new issue against the project: `releng` that you are following: `` https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64 The only releng concern is that we should have a mass rebuild for this (if only as the last opportunity to back it out again). `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7543

3 4

[releng] Issue #7553: Arch-Specific Runtime Dependencies in sub-packages
by Miro Hrončok 26 Mar '19

26 Mar '19

churchyard reported a new issue against the project: `releng` that you are following: `` Please first read trough https://pagure.io/packaging-committee/issue/691 We have been approached by this question: 1. I have an noarch package `foo` 2. it has (implicitly noarch) subpackage `foo-extra`, it has a runtime dependency on `extra` package (that is not available on `xyz` arch) How do I proceed to exclude the `foo-extra` subpackage from being build/available on the `xyz` arch? Do I need to switch both the main package and the subpackage to be arched? In FPC, we have some _ideas_ about how it _should_ work, however, we don't know how it actually is implemented. Thanks `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7553

4 4

[releng] Issue #7520: Provide stable names for images
by Till Maas 26 Mar '19

26 Mar '19

till reported a new issue against the project: `releng` that you are following: `` The images at https://kojipkgs.fedoraproject.org/pub/fedora/linux/development/rawhide/Clo… contain dynamic information in their name that might change daily, e.g.: Fedora-Cloud-Base-Rawhide-20180525.n.0.x86_64.qcow2 It would be great if there was also a symlink with a stable name, e.g. Fedora-Cloud-Base-Rawhide-x86_64.qcow2 to make it easier to automatically download the latest image. CentOS does this for example as well: https://cloud.centos.org/centos/6/images/ `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7520

5 7

[releng] Issue #7525: unreasonable large build.log files for mingw-qt
by Till Maas 26 Mar '19

26 Mar '19

till reported a new issue against the project: `releng` that you are following: `` ``` du -hcs /mnt/koji/packages/mingw-qt/*/*/data/logs/*/build.log [...] 253M /mnt/koji/packages/mingw-qt/4.8.7/1.fc25/data/logs/armv7hl/build.log 253M /mnt/koji/packages/mingw-qt/4.8.7/1.fc25/data/logs/i686/build.log 253M /mnt/koji/packages/mingw-qt/4.8.7/1.fc25/data/logs/x86_64/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/2.fc26/data/logs/aarch64/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/2.fc26/data/logs/armv7hl/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/2.fc26/data/logs/i686/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/2.fc26/data/logs/ppc64/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/2.fc26/data/logs/ppc64le/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/2.fc26/data/logs/x86_64/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc26/data/logs/aarch64/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc26/data/logs/armv7hl/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc26/data/logs/i686/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc26/data/logs/ppc64/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc26/data/logs/ppc64le/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc26/data/logs/x86_64/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc27/data/logs/aarch64/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc27/data/logs/armv7hl/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc27/data/logs/i686/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc27/data/logs/ppc64/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc27/data/logs/ppc64le/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc27/data/logs/s390x/build.log 2,7G /mnt/koji/packages/mingw-qt/4.8.7/3.fc27/data/logs/x86_64/build.log 69G ``` `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7525

3 3

[releng] Issue #7326: ppc image build tasks are failing for f28/rawhide
by Dusty Mabe 21 Mar '19

21 Mar '19

dustymabe reported a new issue against the project: `releng` that you are following: `` I'm not sure if it's because of an issue with a builder of because of the software content in rawhide itself but we need to investigate this so we can get ppc64le media building again. #####here are koji tasks from Rawhide-20180217.n.2: - https://koji.fedoraproject.org/koji/taskinfo?taskID=25123798 - https://koji.fedoraproject.org/koji/taskinfo?taskID=25123819 - https://koji.fedoraproject.org/koji/taskinfo?taskID=25123781 ##### Rawhide-20180216.n.0 - https://koji.fedoraproject.org/koji/taskinfo?taskID=25095465 - https://koji.fedoraproject.org/koji/taskinfo?taskID=25095487 - https://koji.fedoraproject.org/koji/taskinfo?taskID=25095448 etc... `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7326

8 24

[releng] Issue #8050: Claim orphaned python-rangehttpserver
by Luis Enrique Bazán De León 15 Mar '19

15 Mar '19

lbazan reported a new issue against the project: `releng` that you are following: `` Please unorphan python-rangehttpserver - rawhide FAS Account: lbazan Cheers! `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8050

2 8

[releng] Issue #7389: docker registry does not respond correctly to v1 requests
by Langdon White 12 Mar '19

12 Mar '19

langdon reported a new issue against the project: `releng` that you are following: `` If you run something like: wget -q https://registry.fedoraproject.org/v1/repositories/fedora-minimal/tags -O - | sed -e 's/[][]//g' -e 's/"//g' -e 's/ //g' | tr '}' '\n' | awk -F: '{print $3}' you get no results even though fedora-minimal has a number of tags. However, skopeo inspect docker://registry.fedoraproject.org/fedora-minimal seems to work. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7389

3 4

[releng] Issue #7344: Please generate static deltas for FAW27
by Colin Walters 12 Mar '19

12 Mar '19

walters reported a new issue against the project: `releng` that you are following: `` ostree has had static deltas for years now; it makes us look less than stellar if people aren't getting them. We do this as part of the FAH release process, but at the moment there is no such thing for FAW which just drops out of pungi. Simplest thing is probably to add it to Ansible for now, literally just `ostree --repo=/path/to/repo static-delta generate --if-not-exists fedora/27/x86_64/workstation`. (However, the benefits of deltas will be greatly maximized if we batch updates) `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7344

5 8

[releng] Issue #7500: update pixman for F-28 AtomicHost 2-weeks releases
by Dan Horák 12 Mar '19

12 Mar '19

sharkcz reported a new issue against the project: `releng` that you are following: `` F-28 GA has a nasty bug on ppc64le (https://bugzilla.redhat.com/show_bug.cgi?id=1546693) that has been fixed post-GA with updated pixman rpms. We would like to include the updated pixman (pixman-0.34.0-7.fc28 or pixman-0.34.0-8.fc28) in the anaconda runtime environment, if that's possible. @dustymabe @sinnykumari `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7500

3 3

[releng] Issue #7408: intermittent `libvirtError: File exists` errors for imagebuild tasks
by Dusty Mabe 12 Mar '19

12 Mar '19

dustymabe reported a new issue against the project: `releng` that you are following: `` It seems like it mostly happens on aarch64 machines, but has also been seen on [ppc64le]([https://koji.fedoraproject.org/koji/taskinfo?taskID=25873773). ``` ApplianceError: Image status is FAILED: could not create appliance through libvirt. Try running qemu directly without libvirt using this environment variable: export LIBGUESTFS_BACKEND=direct Original error from libvirt: File exists [code=89 int1=0] ``` Examples where we have seen this: - [tracker](https://pagure.io/dusty/failed-composes/issue/106) [task](https://koji.fedoraproject.org/koji/taskinfo?taskID=25959092) - [tracker](https://pagure.io/dusty/failed-composes/issue/96) [task](https://koji.fedoraproject.org/koji/taskinfo?taskID=25873773) - [tracker](https://pagure.io/dusty/failed-composes/issue/103) [task](https://koji.fedoraproject.org/koji/taskinfo?taskID=25907748) - [tracker](https://pagure.io/dusty/failed-composes/issue/93) [task](https://koji.fedoraproject.org/koji/taskinfo?taskID=25858017) - [tracker](https://pagure.io/dusty/failed-composes/issue/87#comment-499900) [task](https://koji.fedoraproject.org/koji/taskinfo?taskID=25750250) `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7408

4 11

[releng] Issue #7455: Missing f28 dist-git branches
by Petr Pisar 12 Mar '19

12 Mar '19

ppisar reported a new issue against the project: `releng` that you are following: `` Till now I found 4 packages that were missing f28 dist-git branches that should have been created at f28 branching time: rpms/perl-Alien-Base-ModuleBuild rpms/perl-Exporter-Easy rpms/perl-Math-Utils rpms/perl-Test-Exit I worry there is some bug in the mass branching script and more packages are missing the f28 branch. Please recheck the repositories and create the branches where missing. (These four have already been fixed.) `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7455

3 5

[releng] Issue #7439: Bodhi can now manage containers
by Randy Barlow 12 Mar '19

12 Mar '19

bowlofeggs reported a new issue against the project: `releng` that you are following: `` Greetings! Today I deployed Bodhi 3.6.0 to production, which adds support for containers (except for buildroot overrides). To make use of it, we just need to add container releases to Bodhi with all the appropriate Koji tags and we're off to the races. Doing so may or may not require Freeze Break Requests, not sure, but wanted to let you know that the feature is ready for your use as you see fit. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7439

3 5

[releng] Issue #7405: [s390x] Latest cloud-base and (or) container images are failing for F28 and rawhide composes
by Sinny Kumari 12 Mar '19

12 Mar '19

sinnykumari reported a new issue against the project: `releng` that you are following: `` By looking into last few nightly composes for container and cloud on s390x, I observed that we never had all of the artifacts built successfully in a single compose. For example: * From Fedora-28-20180317.n.0 - cloud-base and container-minimal-base image built successfully. container-base image failed * From Fedora-28-20180317.n.0 - cloud-base and container-base image built successfully. conatiner-minimal-base image failed. Similar results from rest of the latest compose. I did some local run of these images using imagefactory and each time following behavior has been seen: * kernel.img and initrd files get downloaded, vm gets launched to start install process. * vm boots and it reaches at [ OK ] Reached target System Initialization. [ OK ] Reached target Basic System. [ 35.891858] dracut-initqueue[817]: RTNETLINK answers: File exists [ 76.688981] random: crng init done [ 427.634076] dracut-initqueue[817]: Warning: dracut-initqueue timeout - starting timeout scripts --- [ 625.922797] dracut-initqueue[817]: Warning: dracut-initqueue timeout - starting timeout scripts [ 625.923855] dracut-initqueue[817]: Warning: Could not boot. Starting Dracut Emergency Shell... Warning: /dev/root does not exist dracut:/# and vm install stops here. Not sure what is the reason of this behavior. Can it be something related to network between s390x machine and koji ? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7405

3 4

[releng] Issue #7388: predicting dependency failures in image builds
by Dusty Mabe 12 Mar '19

12 Mar '19

dustymabe reported a new issue against the project: `releng` that you are following: `` It would be nice if we could predict when dependency failures in image builds will happen. I have been using a rough set of commands to do this in the past few weeks but this could be polished up and put in place to forecast failures. What I;ve been doing is: ` dnf --releasever 29 --installroot /srv/installroot/ --disablerepo=* --enablerepo=today --enablerepo=koji install $(cat packages.txt | sed 's/^-/--exclude /' | tr '\n' ' ') ` - where repo `today` is today's rawhide run - where repo `koji` is the f29-build repo - where packages.txt is the %packages list from a kickstart file This is a pretty good indicator of failures. This could be refined and put into a testing framework to run often. Steps: For each kickstart do: - `ksflatten` kickstart file and get `%packages` list - For groups use libcomps and fedora-comps repo to determine packages - use koji `f29-build` repo and list of packages to determine if there are missing dependencies `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7388

3 3

[releng] Issue #7379: Cannot install the python2-markdown RPM on Rawhide because the module gets pulled in for some reason
by Randy Barlow 12 Mar '19

12 Mar '19

bowlofeggs reported a new issue against the project: `releng` that you are following: `` Bodhi CI is failing to run on Rawhide because it cannot install python2-markdown. Instead of the RPM being present in the repository, the module for it is present instead and is signed with the wrong key: ``` $ sudo docker run --rm -it registry.fedoraproject.org/fedora:rawhide dnf install -y python2-markdown Fedora - Rawhide - Developmental packages for the next Fedora release 3.0 MB/s | 60 MB 00:19 Last metadata expiration check: 0:00:21 ago on Wed Mar 7 17:12:37 2018. Dependencies resolved. =================================================================================================================================================================================================================== Package Arch Version Repository Size =================================================================================================================================================================================================================== Installing: python2-markdown noarch 2.4.1-11.module_0b083f9b rawhide 189 k Installing dependencies: python2 x86_64 2.7.14-13.fc29 rawhide 101 k python2-libs x86_64 2.7.14-13.fc29 rawhide 6.3 M python2-pip noarch 9.0.1-16.fc29 rawhide 1.8 M python2-setuptools noarch 38.4.0-3.fc28 rawhide 622 k Transaction Summary =================================================================================================================================================================================================================== Install 5 Packages Total download size: 9.0 M Installed size: 36 M Downloading Packages: (1/5): python2-markdown-2.4.1-11.module_0b083f9b.noarch.rpm 513 kB/s | 189 kB 00:00 (2/5): python2-2.7.14-13.fc29.x86_64.rpm 274 kB/s | 101 kB 00:00 (3/5): python2-setuptools-38.4.0-3.fc28.noarch.rpm 743 kB/s | 622 kB 00:00 (4/5): python2-pip-9.0.1-16.fc29.noarch.rpm 942 kB/s | 1.8 MB 00:01 (5/5): python2-libs-2.7.14-13.fc29.x86_64.rpm 1.1 MB/s | 6.3 MB 00:05 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 1.4 MB/s | 9.0 MB 00:06 warning: /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/python2-markdown-2.4.1-11.module_0b083f9b.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID a3cc4e62: NOKEY Importing GPG key 0x429476B4: Userid : "Fedora 29 (29) <fedora-29(a)fedoraproject.org>" Fingerprint: 5A03 B4DD 8254 ECA0 2FDA 1637 A20A A56B 4294 76B4 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64 Key imported successfully Import of key(s) didn't help, wrong key(s)? Public key for python2-markdown-2.4.1-11.module_0b083f9b.noarch.rpm is not installed. Failing package is: python2-markdown-2.4.1-11.module_0b083f9b.noarch GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64 The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: GPG check FAILED ``` `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7379

3 3

[releng] Issue #7354: apitrace-libs.i686 version mismatches apitrace-libs.x86_64 on F27
by Sandro Mani 12 Mar '19

12 Mar '19

smani reported a new issue against the project: `releng` that you are following: `` On F27 the current version of apitrace is apitrace-7.1-7.fc27. On F27 x86_64 however, # dnf install --refresh apitrace-libs.i686 currently gives you apitrace-libs-7.1-7.fc27.i686 (note: -7 instead of -9). On the other hand, # dnf install --refresh apitrace-libs gives you apitrace-libs-7.1-9.fc27.x86_64 as expected. apitrace-libs is multilib whitelisted, but appears to be out of sync. See also #1541099. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7354

2 2

[releng] Issue #7316: variants-modular.xml & fedora-release*
by Langdon White 12 Mar '19

12 Mar '19

langdon reported a new issue against the project: `releng` that you are following: `` Once [#7227](https://pagure.io/releng/issue/7227) is complete, I wanted to confirm that: * We should continue to make PRs against [variants-modular.xml](https://pagure.io/pungi-fedora/blob/master/f/variants-modular.xml) and file tickets here to get new modules added to the compose. * Should we file tickets here or use some other method to get changes to fedora-release* rpms? Specifically, we will need to include a system profile ([for example](https://github.com/sgallagher/semimodular_poc/blob/master/semimodu…) and modify it as modules are added. /cc @sgallagh @psabata `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7316

2 2

[releng] Issue #8014: request for f30-ghc
by Jens Petersen 11 Mar '19

11 Mar '19

petersen reported a new issue against the project: `releng` that you are following: `` * For which release? F30 * Name of the side tag? (Generally fxx-pkg) f30-ghc * Number of builds that are expected in the side tag? 500 * How long do you need the side tag? 2 weeks * Any extra information? Corresponding Fedora Change for updating to ghc-8.4 to follow soon `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8014

3 17

[releng] Issue #7966: f30-kde koji target
by Rex Dieter 05 Mar '19

05 Mar '19

rdieter reported a new issue against the project: `releng` that you are following: `` * For which release? fedora 30 * Name of the side tag? (Generally fxx-pkg) f30-kde * Number of builds that are expected in the side tag? 30-40 initially * How long do you need the side tag? Likely on/off for the duration of fedora 30 lifetime. * Any extra information? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7966

3 15

[releng] Issue #7997: unretire epel7 branch for libmspack
by Dan Horák 04 Mar '19

04 Mar '19

sharkcz reported a new issue against the project: `releng` that you are following: `` * Name of the package? libmspack * FAS username of the new maintainer? orion * Branches that you need it to be unretired for? epel7 * Package re-review BZ URL? N/A, it's still an active package in Fedora * Any extra information? The epel7 branch got retired because libmspack appeared in RHEL 7.6, but it's not provided for all arches. Thus will be reintroduced as arch-limited package. CCing @orion `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7997

3 6

[releng] Issue #7900: New side tag for rawhide llvm 7.0 ABI change.
by Tom Stellard 26 Feb '19

26 Feb '19

tstellar reported a new issue against the project: `releng` that you are following: `` * Describe the issue I need to break the ABI of libLLVM.so without a soname bump in order to fix an llvm bug[1]. I need a side-tag in order to rebuild all dependent packages without creating a disruption. [1] https://bugs.llvm.org/show_bug.cgi?id=39427 * When do you need this? (YYYY/MM/DD) 2018/11/01 * When is this no longer needed or useful? (YYYY/MM/DD) 2019/08/01 * If we cannot complete your request, what is the impact? Users will not be able to link programs compiled with clang against Fedora's llvm-libs package. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7900

6 23

[releng] Issue #7984: unorphan netatalk
by Andrew Bauer 21 Feb '19

21 Feb '19

kni reported a new issue against the project: `releng` that you are following: `` Please unorphan the following branches for the netatalk package: - rawhide - f29 - f28 - epel7 FAS Account: kni Thank you. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7984

2 9

[releng] PR #7871: Edit the targets of newly branched release
by Mohan Boddu 19 Feb '19

19 Feb '19

mohanboddu opened a new pull-request against the project: `releng` that you are following: `` Edit the targets of newly branched release `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7871

1 1

[releng] Issue #8058: Give OSBS permission to create images in koji
by Clement Verna 18 Feb '19

18 Feb '19

cverna reported a new issue against the project: `releng` that you are following: `` * Describe the issue I am trying to build the fedora container base image in OSBS, but I am getting the following error " Image build failed. Error in plugin add_filesystem: ActionNotAllowed('image permission required') " I believe this is something that needs to be allowed in Koji * When do you need this? (YYYY/MM/DD) * When is this no longer needed or useful? (YYYY/MM/DD) * If we cannot complete your request, what is the impact? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8058

2 4

[releng] Issue #7031: Should f27 and f27-build have different architectures?
by Kellin 14 Feb '19

14 Feb '19

kellin reported a new issue against the project: `releng` that you are following: `` $ koji taginfo f27 Tag: f27 [417] Arches: armv7hl i686 x86_64 ppc64 ppc64le aarch64 ^PGroups: appliance-build, build, livecd-build, livemedia-build, srpm-build Required permission: 'admin' Tag options: mock.package_manager : 'dnf' Inheritance: $ koji taginfo f27-build Tag: f27-build [425] Arches: aarch64 armv7hl i686 ppc64 ppc64le s390x x86_64 Groups: appliance-build, build, livecd-build, livemedia-build, srpm-build Required permission: 'admin' Tag options: This tag is a buildroot for one or more targets Current repo: repo#785431: 2017-09-14 21:09:29.969602 Targets that build from this tag: f27-candidate f27-rebuild f27-binutils-rebuild f27 Inheritance: 0 .... f27-override [424] `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7031

4 6

[releng] Issue #8057: Unblock/reactivate the 9.6 stream branch of the postgresql module
by Nils Philippsen 14 Feb '19

14 Feb '19

nphilipp reported a new issue against the project: `releng` that you are following: `` * Describe the issue The `9.6` stream branch of the `postgresql` module is inactive, probably because it's past its EOL date which was set to 2018-12-01 when it was created. The maintainer of the module @praiskup reported this to the [Modularity Tracker](https://pagure.io/modularity/issue/123). Two possible remedies come to mind: - Manually set the `bug_fixes` (and `security_fixes`?) EOL date for the `modules/postgresql:9.6` branch to 2021-12-01, corresponding with the upstream EOL date of 2021-11-11. - Or, ignore the SL metadata when determining which branch is active ([background](https://pagure.io/modularity/issue/124#comment-549423), [#2](https://pagure.io/modularity/issue/112)). This probably involves changes in code/scripts. * When do you need this? (YYYY/MM/DD) I assume the sooner the better. @praiskup? * When is this no longer needed or useful? (YYYY/MM/DD) End of 2021 when 9.6 maintenance ceases upstream. * If we cannot complete your request, what is the impact? The `9.6` stream can't be updated. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8057

4 5

[releng] PR #8075: Use Fedora 29 for Vagrant
by Filip Valder 13 Feb '19

13 Feb '19

fivaldi opened a new pull-request against the project: `releng` that you are following: `` Use Fedora 29 for Vagrant `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/8075

3 4

[releng] PR #8082: Mass rebuild modules
by Mohan Boddu 12 Feb '19

12 Feb '19

mohanboddu opened a new pull-request against the project: `releng` that you are following: `` Mass rebuild modules `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/8082

3 41

[releng] Issue #8035: Unretire js-jquery2
by Vít Ondruch 12 Feb '19

12 Feb '19

vondruch reported a new issue against the project: `releng` that you are following: `` * Name of the package? js=jquery2 * FAS username of the new maintainer? vondruch * Branches that you need it to be unretired for? f30 * Package re-review BZ URL? Non. I hope I made it in two weeks. * Any extra information? If somebody is going to dispute this unretirement, I will bundle js-jquery2 in rubygem-jquery-rails: https://src.fedoraproject.org/rpms/rubygem-jquery-rails/blob/master/f/rubyg… `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8035

3 12

[releng] Issue #8059: increase rootfs size for ppc64le composes
by Dan Horák 12 Feb '19

12 Feb '19

sharkcz reported a new issue against the project: `releng` that you are following: `` * Describe the issue The installer runtime image (install.img) created by lorax is 2GB in size, the content written there by lorax fits into the 2GB space, but there isn't enough free space for anaconda in runtime. As a result the installation on ppc64le crashes. See https://bugzilla.redhat.com/show_bug.cgi?id=1666298 One possible solution is to explicitly set a bigger rootfs size for ppc64le compose similarly to what is done for cloud images in the Fedora pungi config. * When do you need this? (YYYY/MM/DD) ASAP * When is this no longer needed or useful? (YYYY/MM/DD) N/A * If we cannot complete your request, what is the impact? non-installable ppc64le compose `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8059

2 3

[releng] Issue #8055: Delete accidentally created branches on the rpms/module-build-service repo
by Matt Prahl 12 Feb '19

12 Feb '19

mprahl reported a new issue against the project: `releng` that you are following: `` * Describe the issue Instead of creating a fork, I created the branches `pungi-dep` and `pungi-dep2` on the rpms/module-build-service dist-git repo in preparation for a PR. Could you please remove them? * When do you need this? (YYYY/MM/DD) Whenever there is time. This is not urgent at all. * When is this no longer needed or useful? (YYYY/MM/DD) N/A * If we cannot complete your request, what is the impact? No real impact. This is just a cosmetic fix. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8055

2 2

[releng] Issue #7664: Delete rawhide-repo-holder build target
by Mikolaj Izdebski 11 Feb '19

11 Feb '19

mizdebsk reported a new issue against the project: `releng` that you are following: `` * Describe the issue Presence of [rawhide-repo-holder](https://koji.fedoraproject.org/koji/buildtargetinfo?ta… build target in Koji makes kojira generate repos for [rawhide](https://koji.fedoraproject.org/koji/taginfo?tagID=197) tag, which according to @puiterwijk is not used any longer. * When do you need this? (YYYY/MM/DD) earliest convenience * When is this no longer needed or useful? (YYYY/MM/DD) * If we cannot complete your request, what is the impact? Koji resources are wasted generating unneeded repos. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7664

3 5

[pungi-fedora] PR #684: set installer image size to 3GB on ppc64le
by Dan Horák 01 Feb '19

01 Feb '19

sharkcz opened a new pull-request against the project: `pungi-fedora` that you are following: `` set installer image size to 3GB on ppc64le `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/684

3 7

[releng] Issue #8090: python-openshift branches exist in PDC but not dist-git
by Jason Montleon 31 Jan '19

31 Jan '19

jmontleon reported a new issue against the project: `releng` that you are following: `` * Describe the issue These requests for epel7 and f29 were closed invalid with, "The branch in PDC already exists" https://pagure.io/releng/fedora-scm-requests/issue/9556 https://pagure.io/releng/fedora-scm-requests/issue/9557 The branches don't exist in dist-git and can't be pushed: https://src.fedoraproject.org/rpms/python-openshift/branches * When do you need this? (YYYY/MM/DD) Next several days * When is this no longer needed or useful? (YYYY/MM/DD) N/A * If we cannot complete your request, what is the impact? I think someday it will delay RDO, but I'm not aware of any pressing date. They asked for us to release the package in Fedora/EPEL. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8090

2 2

[releng] Issue #8061: ChangeF30/Boost-1.69
by Denis Arnaud 31 Jan '19

31 Jan '19

denisarnaud reported a new issue against the project: `releng` that you are following: `` * As per the [accepted change of having Boost 1.69 on Rawhide/F30](https://fedoraproject.org/wiki/Changes/F30Boost169), I would need a [side build tag](https://docs.pagure.org/releng/sop_adding_side_build_targets.html), for instance `f30-boost` * Needed as soon as possible (2019/01/19) * When is this no longer needed or useful? (2019/02/28) * If we cannot complete your request, what is the impact? I will have a hard time rebuilding the dependencies on Boost on Rawhide `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8061

5 24

[releng] PR #8089: Fix for need-rebuild
by Mohan Boddu 31 Jan '19

31 Jan '19

mohanboddu opened a new pull-request against the project: `releng` that you are following: `` Fix for need-rebuild `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/8089

2 1

[releng] PR #8088: Changes for F30 Mass Rebuild
by Mohan Boddu 31 Jan '19

31 Jan '19

mohanboddu opened a new pull-request against the project: `releng` that you are following: `` Changes for F30 Mass Rebuild `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/8088

2 1

Release Engineering Automation effort
by Clement Verna 31 Jan '19

31 Jan '19

Hi all, I have started a document [0] to gather the releng tasks that would benefit automation. At this point I am not looking for the HOW, but more for the WHAT. So if you have any ideas please add an entry to this bullet list [1], Once we have a few items there we can start looking at HOW, this is something I started for automating the unorphan requests.[2] As always feedbacks are more than welcome. Thanks Clément [0] - https://fedoraproject.org/wiki/Infrastructure_2020/RelengAutomation [1] - https://fedoraproject.org/wiki/Infrastructure_2020/RelengAutomation#Release… [2] - https://fedoraproject.org/wiki/Infrastructure_2020/RelengAutomation#Adoptin…

2 2

[Fedocal] Reminder meeting : Fedora Release Engineering
by mohanboddu＠fedoraproject.org 31 Jan '19

31 Jan '19

Dear all, You are kindly invited to the meeting: Fedora Release Engineering on 2019-01-31 from 17:00:00 to 18:00:00 UTC At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Fedora Release Engineering weekly meeting Source: https://apps.fedoraproject.org/calendar/meeting/9274/

1 0

[releng] Issue #8087: python-openshift exists in PDC but no dist-git
by Jason Montleon 30 Jan '19

30 Jan '19

jmontleon reported a new issue against the project: `releng` that you are following: `` * Describe the issue Issue 9555 was closed stating the PDC branch exists for python-openshift. But the dist-git repo does not exist. $ fedpkg clone python-openshift Cloning into 'python-openshift'... No such repository Asking in fedora-admin I was told, "<mizdebsk> i see, the branch exists in pdc, but not in distgit <mizdebsk> jmontleon, you can open a releng ticket to have them fix that" * When do you need this? (YYYY/MM/DD) No super pressing date. Within the next few/several days would be good. * When is this no longer needed or useful? (YYYY/MM/DD) N/A * If we cannot complete your request, what is the impact? Members of the Openstack team requested we get the package added to EPEL/Fedora for RDO use if I understood correctly. I believe eventually we hold up RDO from a release, but again I am not aware of any immediate date where that would be the case. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8087

1 1

[pungi-fedora] PR #683: produce cloud image in vmdk format
by Dusty Mabe 30 Jan '19

30 Jan '19

dustymabe opened a new pull-request against the project: `pungi-fedora` that you are following: `` produce cloud image in vmdk format `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/683

2 1

[pungi-fedora] PR #682: Use substitution for createrepo_extra_args
by Jonathan Dieter 30 Jan '19

30 Jan '19

jdieter opened a new pull-request against the project: `pungi-fedora` that you are following: `` Use substitution for createrepo_extra_args `` To reply, visit the link below or just reply to this email https://pagure.io/pungi-fedora/pull-request/682

2 1

[releng] Issue #8056: Claim orphaned python-txsocksx
by Gwyn Ciesla 30 Jan '19

30 Jan '19

limb reported a new issue against the project: `releng` that you are following: `` FAS: limb `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8056

2 2

[releng] Issue #8064: claim orphaned package python-txsocksx
by Luis Enrique Bazán De León 30 Jan '19

30 Jan '19

lbazan reported a new issue against the project: `releng` that you are following: `` please unorphan python-txsocksx package - rawhide FAS Account: lbazan `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8064

2 3

[releng] Issue #8053: Claim orphaned python-pytimeparse
by Pradeep Kilambi 30 Jan '19

30 Jan '19

pkilambi reported a new issue against the project: `releng` that you are following: `` please unorphan python-pytimeparse package - rawhide FAS Account: pkilambi `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8053

2 2

[releng] Issue #8052: Claim orphaned python-aodhclient
by Pradeep Kilambi 30 Jan '19

30 Jan '19

pkilambi reported a new issue against the project: `releng` that you are following: `` Please unorphan python-aodhclient - rawhide FAS Account: pkilambi `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8052

2 2

[releng] Issue #8051: Claim orphaned python-gnocchiclient
by Pradeep Kilambi 30 Jan '19

30 Jan '19

pkilambi reported a new issue against the project: `releng` that you are following: `` Please unorphan python-gnocchiclient - rawhide FAS Account: pkilambi Cheers! `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8051

2 2

[releng] Issue #8063: Claim orphaned python-parsley
by Luis Enrique Bazán De León 30 Jan '19

30 Jan '19

lbazan reported a new issue against the project: `releng` that you are following: `` please unorphan python-parsley - rawhide FAS Account: lbazan `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8063

2 2

[releng] Issue #8076: Change: LXQt 0.14.0
by Ziqian SUN (Zamir) 30 Jan '19

30 Jan '19

zsun reported a new issue against the project: `releng` that you are following: `` * Describe the issue We are planning to update LXQt to 0.14.0 in Fedora. This is a ticket for tracking the change. https://fedoraproject.org/wiki/Changes/LXQt_0.14.0 Only some of the Deepin related packages will be affected. While in reality I am one of the change owner for the DeepinDE change, so there is no risk at all. All related packages are already built locally. We will need to retire one package from Fedora 30 if this change got approved.Out of that, no actions from Release Engineering needed. * When do you need this? (YYYY/MM/DD) N/A This is a ticket for tracking the change. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8076

2 4

[releng] Issue #8085: Self-contained change proposal: Vagrant 2.2 upgrade with QEMU Session enabled by default
by Pavel Valena 30 Jan '19

30 Jan '19

pvalena reported a new issue against the project: `releng` that you are following: `` * Describe the issue Mandatory check with rel-eng is required for Fedora 30 change proposal. I don't expect any impact: Upgrade to Vagrant 2.2 with QEMU Session enabled by default. * When do you need this? (YYYY/MM/DD) 2019-02-04 - or sooner, ideally. Sorry for late submission. * When is this no longer needed or useful? (YYYY/MM/DD) 2019-02-14 - In time to make changes before change Completion deadline. * If we cannot complete your request, what is the impact? Vagrant will probably not get upgraded to 2.2 in F30. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8085

2 4

[releng] PR #8083: Replace fedorahosted.org links with pagure.io
by Eldar Yusupov 30 Jan '19

30 Jan '19

eyusupov opened a new pull-request against the project: `releng` that you are following: `` Replace fedorahosted.org links with pagure.io `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/8083

2 4

[releng] Issue #7936: Changes/Ruby_2.6
by Vít Ondruch 30 Jan '19

30 Jan '19

vondruch reported a new issue against the project: `releng` that you are following: `` FYI, we are planning to introduce Ruby 2.6 into Fedora: https://fedoraproject.org/wiki/Changes/Ruby_2.6 We will be asking for side-tag after Christmas and should be done with the rebuild prior mass rebuild, but I assume we will open a separate ticket. Please let me know if you have any concerns. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7936

2 4

[releng] Issue #8030: Changes/GNOME3.32
by Kalev Lember 30 Jan '19

30 Jan '19

kalev reported a new issue against the project: `releng` that you are following: `` Please review https://fedoraproject.org/wiki/Changes/GNOME3.32 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8030

2 5

[releng] Issue #7604: F29 System-Wide Change: Remove Excessive Linking
by Igor Gnatenko 30 Jan '19

30 Jan '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` Please review https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking change. P.S. I don't think that any actions from rel-eng are needed. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7604

5 10

[releng] Issue #7687: Change impact: Mass Python 2 Package Removal
by Miro Hrončok 30 Jan '19

30 Jan '19

churchyard reported a new issue against the project: `releng` that you are following: `` a check of an impact with Release Engineering is needed https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7687

3 3

[releng] Issue #7110: libtomcrypt missing from Koji f27 buildroot?
by Randy Barlow 29 Jan '19

29 Jan '19

bowlofeggs reported a new issue against the project: `releng` that you are following: `` Greetings! I've discovered that [Bodhi doesn't build in F27](https://koji.fedoraproject.org/koji/taskinfo?taskID=22659036) as of recently, as libtomcrypt doesn't seem to be available in the buildroot: ``` - nothing provides libtomcrypt.so.0()(64bit) needed by python2-crypto-2.6.1-17.fc27.s390x ``` I [reported this](https://bugzilla.redhat.com/show_bug.cgi?id=1505641) to the libtomcrypt maintainer, who pointed out that it seems to be tagged correctly. I then realized that I was able to install it in an f27 container as well: ``` $ sudo docker run --rm registry.fedoraproject.org/fedora:27 dnf install python2-crypto -y ``` Is there maybe something wrong with the f27 buildroot that causes this issue? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7110

3 5

[releng] Issue #6877: Refine cleaning up packages with broken deps
by Suzanne Yeghiayan 29 Jan '19

29 Jan '19

syeghiay added a new comment to an issue you are following: `` @humaton will talk to @mohanboddu about this ticket. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6877

1 0

[releng] Issue #6876: Please review the Graphical Applications as Flatpaks change proposal
by Suzanne Yeghiayan 29 Jan '19

29 Jan '19

syeghiay added a new comment to an issue you are following: `` @mohanboddu, is this fixed? @otaylor, are you happy? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6876

1 0

[releng] Issue #6822: using include statements in pungi-fedora
by Suzanne Yeghiayan 29 Jan '19

29 Jan '19

syeghiay added a new comment to an issue you are following: `` @humaton will talk to @mohanboddu about this. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6822

1 0

[releng] Issue #6676: f26 mass branching followups
by Suzanne Yeghiayan 29 Jan '19

29 Jan '19

syeghiay added a new comment to an issue you are following: `` @mohanboddu, what is the status of this work? `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6676

1 0

[releng] Issue #6365: "Broken dependencies" report does not understand rich dependencies
by Suzanne Yeghiayan 29 Jan '19

29 Jan '19

syeghiay added a new comment to an issue you are following: `` @humaton will talk to @mohanboddu about how to resolve this ticket. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6365

1 0

[releng] Issue #6230: sign our docker images
by Suzanne Yeghiayan 29 Jan '19

29 Jan '19

syeghiay added a new comment to an issue you are following: `` @humaton is happy to help with some guidance from @puiterwijk `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6230

1 0

Re: RelEng schedule tasks
by Ben Cotton 29 Jan '19

29 Jan '19

Mohan and team, I've created a draft F31 schedule with your feedback incorporated: https://fedorapeople.org/groups/schedule/f-31/f-31-releng-tasks.html Please review it and let me know if anything is amiss. You can reply here or add a comment to the Pagure issue: https://pagure.io/fedora-project-schedule/issue/91 -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

[releng] Issue #8071: Please add file-roller to the f29-flatpak tag.
by Carlos Soriano 29 Jan '19

29 Jan '19

csoriano reported a new issue against the project: `releng` that you are following: `` Please add file-roller to the f29-flatpak tag. $ koji add-pkg --owner=releng f29-flatpak file-roller `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8071

2 1

[releng] Issue #8070: Please add glade to the f29-flatpak tag.
by Carlos Soriano 29 Jan '19

29 Jan '19

csoriano reported a new issue against the project: `releng` that you are following: `` Please add glad to the f29-flatpak tag. $ koji add-pkg --owner=releng f29-flatpak glade `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8070

2 1

[releng] Issue #8069: Please add mediawriter to the f29-flatpak tag.
by Jan Grulich 29 Jan '19

29 Jan '19

jgrulich reported a new issue against the project: `releng` that you are following: `` $ koji add-pkg --owner=releng f29-flatpak mediawriter `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8069

2 1

[releng] Issue #8078: please untag copr-frontend-1.139-2.fc28 from trashcan
by clime 29 Jan '19

29 Jan '19

clime reported a new issue against the project: `releng` that you are following: `` * Describe the issue copr-frontend-1.139-2.fc28 is tagged with trashcan. I would like the tag to be removed because that version is supposed to be used in production. * When do you need this? (YYYY/MM/DD) 29/1/2019 * When is this no longer needed or useful? (YYYY/MM/DD) always useful * If we cannot complete your request, what is the impact? - `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8078

2 2

[releng] Issue #8077: Changes/Fish 3.0
by Igor Gnatenko 29 Jan '19

29 Jan '19

ignatenkobrain reported a new issue against the project: `releng` that you are following: `` Please review https://fedoraproject.org/wiki/Changes/Fish_3.0. I'm 100% sure that it doesn't affect releng, but that's the procedure. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8077

2 2

[releng] Issue #8079: Claim orphaned wifi-radar
by Luis Manuel Segundo 29 Jan '19

29 Jan '19

blackfile reported a new issue against the project: `releng` that you are following: `` please unorphan wifi-radar package - rawhide FAS Account: blackfile `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8079

2 2

[releng] Issue #8081: Claim orphaned python-pep8
by Miro Hrončok 29 Jan '19

29 Jan '19

churchyard reported a new issue against the project: `releng` that you are following: `` * Name of the package? python-pep8 * FAS username of the new maintainer? churchyard * Any extra information? I'd like to get it retired and obsoleted by pycodestyle, but too many things still use it. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8081

2 2

[releng] PR #8020: Port find_unblocked_orphans from yum to dnf
by Miro Hrončok 29 Jan '19

29 Jan '19

churchyard opened a new pull-request against the project: `releng` that you are following: `` Port find_unblocked_orphans from yum to dnf `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/8020

2 1

[releng] PR #7930: Orphans: Use pagination to query pagure
by Till Maas 29 Jan '19

29 Jan '19

till opened a new pull-request against the project: `releng` that you are following: `` Orphans: Use pagination to query pagure `` To reply, visit the link below or just reply to this email https://pagure.io/releng/pull-request/7930

3 6

[releng] Issue #8060: Unorphan winetricks
by Ernestas Kulik 29 Jan '19

29 Jan '19

ekulik reported a new issue against the project: `releng` that you are following: `` FAS username: ekulik `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8060

1 2

[releng] Issue #8034: Koji tag for Ruby 2.6
by Vít Ondruch 29 Jan '19

29 Jan '19

vondruch reported a new issue against the project: `releng` that you are following: `` * For which release? F30 * Name of the side tag? (Generally fxx-pkg) f30-ruby * Number of builds that are expected in the side tag? ~200 * How long do you need the side tag? Until Ruby packages are rebuilt. The worst case scenario is mass rebuild, i.e. 2019-01-30, but hopefully it will be done sooner. * Any extra information? This is related to #7936 `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8034

4 13

[releng] Issue #8054: Block retired packages from Koji
by Miro Hrončok 28 Jan '19

28 Jan '19

churchyard reported a new issue against the project: `releng` that you are following: `` Those packages were retired ~ 3 months ago (or 8 in one case), but are not blocked in Koji: gossip maven-downloader maven-jsf-plugin maven-jxr nuvola-app-8tracks nuvola-app-deezer nuvola-app-google-play-music nuvola-app-jango nuvola-app-mixcloud openid4java-team port-allocator-maven-plugin takari-local-repository Please block them from f30+. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8054

2 5

[releng] Issue #6746: Produce a slimmed-down compose whenever certain packages appear in an update
by Adam Williamson 26 Jan '19

26 Jan '19

adamwill added a new comment to an issue you are following: `` @mohanboddu said we can reopen this ticket now (the taiga is not the thing any more apparently), so I'm re-opening it... Current state: I have *less* of an urgent need for this now because I sorta gave up waiting and [did it myself](https://www.happyassassin.net/2019/01/23/new-openqa-tests-update-in…. openQA has a test now which creates an installer image containing the package from the update and then tests it - which is the thing I was trying to get done. This would still probably be nice to have for others to use and perhaps to get more images for testing, though. @mohanboddu says the thing that's missing now is a list of the packages which should act as 'triggers' for this process; we don't really have such a thing, so we'd have to either write one or somehow try and synthesize one out of comps and kickstart and fedora-pungi data or something. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/6746

1 0

[releng] Issue #6746: Produce a slimmed-down compose whenever certain packages appear in an update
by Adam Williamson 26 Jan '19

26 Jan '19

The status of the issue: `Produce a slimmed-down compose whenever certain packages appear in an update` of project: `releng` has been updated to: Open by adamwill. https://pagure.io/releng/issue/6746

1 0

Ben Cotton Invoice # EP329947-932
by Ben Cotton 25 Jan '19

25 Jan '19

Sorry for the delay…. Please submit the new documents as soon as possible. Missing Documents: Invoice EP329947-932 (previous version is attached) Thank you for your business! Ben Cotton bcotton(a)redhat.com -

1 0

[releng] Issue #8065: please unlock and push this update to testing
by Mukundan Ragavan 24 Jan '19

24 Jan '19

nonamedotc reported a new issue against the project: `releng` that you are following: `` * Describe the issue I submitted an update of htop for Fedora 28. I ended up unpushing the update by mistake. Here is the update - https://bodhi.fedoraproject.org/updates/FEDORA-2019-a122c96bcf Please push this update to testing again. I am unable to edit the update since it is locked. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8065

2 3

[releng] Issue #8072: Please retire (and orphan) openmolar
by Ankur Sinha 24 Jan '19

24 Jan '19

ankursinha reported a new issue against the project: `releng` that you are following: `` * Describe the issue The openmolar src repository does not contain any files, and there are no builds for the package either. Could this package be retired please? I only have commit access so I cannot orphan the package, and the two maintainers seem to be inactive. * When do you need this? (YYYY/MM/DD) NA * When is this no longer needed or useful? (YYYY/MM/DD) NA * If we cannot complete your request, what is the impact? The empty package stays in SCM. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8072

1 1

[Fedocal] Reminder meeting : Fedora Release Engineering
by mohanboddu＠fedoraproject.org 24 Jan '19

24 Jan '19

Dear all, You are kindly invited to the meeting: Fedora Release Engineering on 2019-01-24 from 17:00:00 to 18:00:00 UTC At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Fedora Release Engineering weekly meeting Source: https://apps.fedoraproject.org/calendar/meeting/9274/

1 0

[releng] Issue #8068: Fedora 27 is still active in PDC
by Elliott Sales de Andrade 23 Jan '19

23 Jan '19

qulogic reported a new issue against the project: `releng` that you are following: `` * Describe the issue In PDC, Fedora 27 is still marked active: https://pdc.fedoraproject.org/release/?search=27 This causes `fedpkg request-branch --all-releases` to open requests for Fedora 27 which get closed as invalid, e.g., https://pagure.io/releng/fedora-scm-requests/issue/9492 * When do you need this? (YYYY/MM/DD) Two-ish months ago? * When is this no longer needed or useful? (YYYY/MM/DD) N/A * If we cannot complete your request, what is the impact? Extra branch request tickets for people using `fedpkg request-branch --all-releases` `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8068

2 2

Fedora Atomic Host Two Week Release Announcement: 29.20190121.0
by noreply＠fedoraproject.org 22 Jan '19

22 Jan '19

2 1

[releng] Issue #8067: 20190121: Release Fedora 29 Atomic Host
by Michael Nguyen 22 Jan '19

22 Jan '19

mnguyen reported a new issue against the project: `releng` that you are following: `` You should be able to do it with this command: `python push-two-week-atomic.py -k fedora-29 -r 29 --pungi-compose-id Fedora-29-updates-Fedora-29-updates-20190121.0` Note: We won't need to use options --compose-basedir and --first-release from this release onward. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8067

3 4

[releng] Issue #8066: Delete branch symlink-script in rpms/jmc
by Salman Siddiqui 22 Jan '19

22 Jan '19

sasiddiq reported a new issue against the project: `releng` that you are following: `` * Describe the issue I accidentally created a bugfix branch in dist-git * When do you need this? (YYYY/MM/DD) 2019/01/30 * When is this no longer needed or useful? (YYYY/MM/DD) 2019/01/21 * If we cannot complete your request, what is the impact? No real impact. This is just a cosmetic fix. `` To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8066

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng January 2019