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
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
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
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
dustymabe opened a new pull-request against the project: `pungi-fedora` that you are following:
``
cloud: remove s390x from image builds
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/731
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
tstellar reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
We need a side tag (f31-llvm) for the upcoming llvm rebase in Fedora
* When do you need this? (YYYY/MM/DD)
07/29/2019
* When is this no longer needed or useful? (YYYY/MM/DD)
08/29/2019
* If we cannot complete your request, what is the impact?
Temporary breakage in rawhide when the LLVM rebase occurs.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8569
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
churchyard reported a new issue against the project: `releng` that you are following:
``
1. I've create a new repository request, where something was wrong
2. @limb processed the request, closed as invalid
3. I fixed the thing and reopened the issue
4. @limb processed the request, closed as invalid again (already exists)
5. as a result, the repo was created, but owned by @limb
This is probably broken in some script that @limb runs, it probably creates the repo, checks some constraints and assigns the repo to me. When the constraints fail, the repo exists, but is not assigned to me. I cannot provide more details, because I have no idea what happens "on the other side".
This already happened twice to me:
https://pagure.io/releng/fedora-scm-requests/issue/10716https://pagure.io/releng/fedora-scm-requests/issue/13178
In both cases, the branch was set to epel7 and initial_commit to false, if that makes any difference.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8468
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
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
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
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
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
kevin reported a new issue against the project: `releng` that you are following:
``
We have a script in releng/scripts/clean-amis.py
It runs every 10 days and is intended to delete any ami images we have on amazon that are older than 10 days.
Sadly, it's not working correctly and we have a bunch of old images.
From the cron output:
```
Traceback (most recent call last):
File "./clean-amis.py", line 188, in <module>
amis = _get_nightly_amis_nd(delta=864000, end=int(end))
File "./clean-amis.py", line 84, in _get_nightly_amis_nd
compose_id = msg['compose']['compose_id']
TypeError: string indices must be integers
```
We should try and get this fixed asap.
CC: @sayanchowdhury and @pfrields
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8126
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
Hello,
You probably saw that we were planning work on MBI, but so far we didn't got any resources. Meanwhile I would like to move rust crates out of rawhide repo to its own (but it will be still built from src.fp.o, everything will be still conforming to guidelines and so on).
Would it be feasible to create some kind of `rust` tag in koji where we would build all our crates?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8265
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
As stated in https://lists.fedoraproject.org/archives/list/rel-eng@lists.fedoraproject.o…, I would like to help with unorphan, unretire and side tags (at least for now)..
I probably already have everything except koji (because I'm already helping out with fedora-scm-requests for creation of packages). And if you could add me to @releng group, would be nice as well ;)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8142
churchyard opened a new pull-request against the project: `releng` that you are following:
``
Update the tracker bug for F31FTBFS
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8574
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
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
dustymabe reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Today we had an issue where the distrepo yum repos for our coreos tags went away. @mohanboddu regenerated them for us. We're not sure why they went away (this should probably also be investigated), but we'd like the ability to regen them on our own in case this happens again in the future (i.e. we'd like to be able to unblock ourselves in case it happens in a scenario where we need a build and time is critical)
the commands were:
- `koji dist-repo f29-coreos-continuous 429476B4 --allow-missing-signatures`
- `koji dist-repo f30-coreos-continuous CFC659B9 --allow-missing-signatures`
- `koji dist-repo coreos-pool 429476B4 CFC659B9`
* When do you need this? (YYYY/MM/DD)
would be nice to have it in the nxt week
* When is this no longer needed or useful? (YYYY/MM/DD)
never
* If we cannot complete your request, what is the impact?
we wait until releng can complete our request
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8421
merlinm reported a new issue against the project: `releng` that you are following:
``
* Name of the module?
`avocado`
* Stream name(s) and the new EOL date?
`stable` - EOL of Fedora 30
`52lts` - EOL of Fedora 30
* Any extra information?
Please drop these module streams from the Fedora 31 repos. They are Python 2-only, and will no longer build, install, or run on Fedora 31. The modulemd definitions for the streams have already been updated to stop builds beyond Fedora 30.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8401
qulogic reported a new issue against the project: `releng` that you are following:
``
I'm seeking feedback on https://fedoraproject.org/wiki/Changes/Automatic_R_runtime_dependencies and its impact to releng.
As the intent is to add a namespaced Provides and corresponding Requires, this will require rebuilding all R packages _in order_. If the mass rebuild is able to handle this, then there would be nothing else to be done. If the mass rebuild _cannot_ handle it, then I would need a side tag to effect the correct build order.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8501
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
dustymabe reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
The ostree composes seem to be failing with an error:
```
2019-03-12 16:00:50 [ERROR ] [FAIL] Ostree (variant Everything, arch x86_64) failed, but going on anyway.
2019-03-12 16:00:50 [ERROR ] 'ascii' codec can't decode byte 0xc2 in position 6271: ordinal not in range(128)
```
An example failed composes issue for this: https://pagure.io/dusty/failed-composes/issue/1642
* When do you need this? (YYYY/MM/DD)
ASAP so people on Fedora SB 30 can get updates
* When is this no longer needed or useful? (YYYY/MM/DD)
F30 EOL
* If we cannot complete your request, what is the impact?
Users of Fedora SB move to something else (possibly not Fedora).
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8330
churchyard reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I'd kindly like to request a **Fedora 32** side tag in koji for Python 3.8 rebuilds. See https://pagure.io/releng/issue/8092
Preferred tag/target name: f32-python
Parent: f32-build
```
$ koji add-tag f32-python --parent=f32-build --arches='armv7hl i686 x86_64 aarch64 ppc64 ppc64le s390x'
$ koji add-target f32-python f32-python
```
* When do you need this? (2019/08/14) - right after branching
* When is this no longer needed or useful? (2020/01/29)
* If we cannot complete your request, what is the impact?
We would not be able to rebuild Python 3.8 for Fedora 32.
Thanks.
Se also https://pagure.io/releng/issue/8320
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8506
kalev reported a new issue against the project: `releng` that you are following:
``
Hi,
I just finished a new round of openh264 builds. Please sign and send the following to Cisco:
openh264-2.0.0-1.fc30
openh264-2.0.0-1.fc31
Thanks,
Kalev
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8439
mohanboddu reported a new issue against the project: `releng` that you are following:
``
The fedora 31 schedule[1] has a mass rebuild scheduled for Jul 24 2019, We need to plan and coordinate all tasks in preparation for it.
[1] https://fedoraproject.org/wiki/Releases/31/Schedule
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8555
kwizart reported a new issue against the project: `releng` that you are following:
``
Package name: python2-django-1.11
FAS username: kwizart
Thx
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8543
sinnykumari reported a new issue against the project: `releng` that you are following:
``
** Describe the issue**
Fedora CoreOS will have [various streams](https://github.com/coreos/fedora-coreos-tracker/blob/master/stream…. All streams will use packages which are built in Fedora koji. Mechanical streams will use packages available in Fedora repos from tags f$(release), f$(release)-updates, f$(release)-updates-testing. Development and production streams will get built from packages available under koji tag `coreos-pool`. Packages which make it to production will also get tagged to `coreos-release` tag.
These tags will ensure that (1) packages are not automatically garbage collected (2) stream builds are reproducible (up to the GC retention policy we agree upon), and (3) packages are added to the pool (and thus into the production streams) in a controlled manner.
To build FCOS for different streams we need:
- coreos-pool and coreos-release koji tags created (include arches aarch64, ppc64le, x86_64)
- Permission to add packages to requested tags (ACLs for bgilbert, dustymabe, jlebon and sinnykumari, until we have bot setup done)
- Tag builds needs to be signed
- Generate dist repo for requested tags with option `--non-latest` to koji dist-repo (to perform build with desired NVRA)
**Question**
As we have streams like next-devel and testing-devel, packages will be from multiple Fedora releases in coreos-pool and coreos-release tags. Since we will be using signed packages, does koji dist-repo allows to specify multiple keys for generating dist repos? This question is because, in [infra ansible tag2distrepo](https://infrastructure.fedoraproject.org/cgit/ansible.git/tre…, so far single key has been used.
** When do you need this? (YYYY/MM/DD) **
ASAP
** When is this no longer needed or useful? (YYYY/MM/DD) **
Always needed
** If we cannot complete your request, what is the impact? **
we won't be able to build FCOS for different streams
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8294
petersen reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
The Haskell SIG is planning to update ghc and associated packages for F31.
For this we will need f31-ghc sidetag in Koji to do the builds without disrupting Rawhide.
https://fedoraproject.org/wiki/Changes/GHC_8.6
* When do you need this?
2019/07/26
* When is this no longer needed or useful?
2019/08/13
* If we cannot complete your request, what is the impact?
We won't be able to complete the F31 Change
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8549
eclipseo reported a new issue against the project: `releng` that you are following:
``
I'd kindly like to request a Fedora 31 side tag in koji for Golang rebuilds. See https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
* For which release?
F31
* Name of the side tag? (Generally fxx-pkg)
Preferred tag/target name: f31-go or f31-golang
Parent: f31-build
$ koji add-tag f31-go --parent=f31-go --arches='armv7hl i686 x86_64 aarch64 ppc64 ppc64le s390x'
$ koji add-target f31-go f31-go
* Number of builds that are expected in the side tag?
Around 1120. Exhaustive list: https://copr.fedorainfracloud.org/coprs/eclipseo/golang-ng/
* When do you need this?
This week would be good.
* How long do you need the side tag?
Until 2019-07-24
* If we cannot complete your request, what is the impact?
We would not be able to rebuild the Golang stack with the new macros.
* Any extra information?
I never used a side tag before so I'd also like some pointer or howto to properly make use of it.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8435
jwakely reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I need a sidetag, f31-boost, to do rebuilds of packages affected by https://fedoraproject.org/wiki/Changes/F31Boost170
* When do you need this?
2019/07/08
* When is this no longer needed or useful?
2019/08/24
* If we cannot complete your request, what is the impact?
No boost update in F31
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8500
churchyard reported a new issue against the project: `releng` that you are following:
``
## Describe the issue
According to [the FTBFS/FTI policy](https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_sour…:
> A week before the mass branching, any packages which still have open FTBFS bugs from the previous release will be retired. This can be requested via a releng issue.
A week before the mass branching, according to [the schedule](https://fedoraproject.org/wiki/Releases/31/Schedule), is at **2019-08-06**.
There are currently [~800 open F30FTBFS bugzillas](https://bugzilla.redhat.com/showdependencytree.cgi?id=F30FTBFS&h…, 20-30 of them are ON_QA.
Prior to the retiring, I suggest we close bugs for packages that built after the mass rebuild. (I've tried to run [mass-rebuild-close-bugs.py](https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-close-bugs.py) but ti apparently sees no build, as it did nothing but skip all. Either I using it wrong or it is broken.)
## When do you need this?
On 2019-08-06.
## When is this no longer needed or useful?
Final F30 Freeze (2019-10-08) makes this not useful for F30, but stil useful for rawhide/F31.
## If we cannot complete your request, what is the impact?
8 hundred FTBFS packages that nobody fixes.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8522
churchyard reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
python-epel-rpm-macros and python3-rpm are epel only packages, please block them for f31 in Koji.
* When do you need this? any time
* When is this no longer needed or useful? N/A
* If we cannot complete your request, what is the impact? unknown, possibly dangerous
Actual result:
```
$ koji list-pkgs --show-blocked --tag f31 --package python3-rpm
Package Tag Extra Arches Owner
----------------------- ----------------------- ---------------- ---------------
python3-rpm f31 releng
$ koji list-pkgs --show-blocked --tag f31 --package python-epel-rpm-macros
Package Tag Extra Arches Owner
----------------------- ----------------------- ---------------- ---------------
python-epel-rpm-macros f31 releng
```
Expected result:
```
$ koji list-pkgs --show-blocked --tag f31 --package python3-rpm
(no matching packages)
$ koji list-pkgs --show-blocked --tag f31 --package python-epel-rpm-macros
(no matching packages)
```
Or:
```
$ koji list-pkgs --show-blocked --tag f31 --package python3-rpm
Package Tag Extra Arches Owner
----------------------- ----------------------- ---------------- ---------------
python3-rpm f31 releng [BLOCKED]
$ koji list-pkgs --show-blocked --tag f31 --package python-epel-rpm-macros
Package Tag Extra Arches Owner
----------------------- ----------------------- ---------------- ---------------
python-epel-rpm-macros f31 releng [BLOCKED]
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8469
churchyard reported a new issue against the project: `releng` that you are following:
``
According to the [new policy about FTBFS and FTI (Fails to install) packages](https://pagure.io/fesco/issue/2109), please create the following new tracker bugzillas:
* Fedora 31 Fails to build from source - F31FTBFS
* Fedora 31 Fails to install - F31FailsToInstall
* Fedora 30 Fails to install - F30FailsToInstall
* Fedora 29 Fails to install - F29FailsToInstall
* Fedora 28 Fails to install - F28FailsToInstall
About the aliases: I suggested F31FTI, but @till [had a good point](https://pagure.io/fesco/issue/2109#comment-561765) that F30_fails_to_install (or similar) might be easier for others. I ultimately leave that decision to releng, but I guess we usually stick to CamelCase, so I went with F30FailsToInstall
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8275
dustymabe reported a new issue against the project: `releng` that you are following:
``
We are seeing network issues when pulling the ostree content during the image builds for f29AH (run during bodhi updates composes). This seems to be getting more consistent lately. I'm opening this bug to track the issue.
Here are current cases where it has happened:
- [Fedora-29-updates-testing-20190602.0](https://pagure.io/dusty/failed-composes/issue/1948)
- [Fedora-29-updates-20190531.0](https://pagure.io/dusty/failed-composes/issue/1937#comment-573321)
- [ Fedora-29-updates-20190601.0](https://pagure.io/dusty/failed-composes/issue/1941)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8407
======================================
#fedora-meeting-2: RELENG (2019-08-01)
======================================
Meeting started by mboddu at 15:59:02 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-2/2019-07-31/releng.2019…
.
Meeting summary
---------------
* init process (mboddu, 15:59:02)
* EPEL-8 (mboddu, 16:00:18)
* We did a test compose of epel8-playground and it was successful in
the first try (mboddu, 16:00:52)
* ACTION: mboddu will update the comps file with only epel8 comps
groups (mboddu, 16:21:36)
* EPEL8 Bodhi Enablement (mboddu, 16:22:22)
* ACTION: mboddu will try to enable bodhi for epel8 release today
(mboddu, 16:24:46)
* Mass Rebuild Status (mboddu, 16:37:43)
* mass rebuild for rpms are done and all the builds are merged into
main tag (mboddu, 16:42:50)
* mboddu started filing ftbfs today (mboddu, 16:43:00)
* Open Floor (mboddu, 16:46:55)
* There wont be a meeting next week as most of the people might be
traveling and I will be on PTO (mboddu, 16:47:42)
* nirik will be moving/cleaning some storage stuff around, mboddu will
be helping him in anyway possible (mboddu, 16:54:11)
Meeting ended at 16:59:53 UTC.
Action Items
------------
* mboddu will update the comps file with only epel8 comps groups
* mboddu will try to enable bodhi for epel8 release today
Action Items, by person
-----------------------
* mboddu
* mboddu will update the comps file with only epel8 comps groups
* mboddu will try to enable bodhi for epel8 release today
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mboddu (81)
* nirik (62)
* smooge (11)
* zodbot (10)
* ksinny (9)
* jednorozec (0)
* pbrobinson (0)
* pingou (0)
* sharkcz (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
limb reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Currently used only for EPEL, we need this for f31+ now.
https://bugzilla.redhat.com/show_bug.cgi?id=1734445
* When do you need this? (YYYY/MM/DD)
Soon-ish would be great. :)
* When is this no longer needed or useful? (YYYY/MM/DD)
* If we cannot complete your request, what is the impact?
Unable to split python2-numpy and python3-numpy, preventing python3-numpy from upgrading to the current release.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8572
mohanboddu opened a new pull-request against the project: `releng` that you are following:
``
F31 ftbfs changes and changing shebangs to py3
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8573
mbooth reported a new issue against the project: `releng` that you are following:
``
Please assign this package to me (mbooth).
I am maintainer of jgit, so I am probably best-placed to maintain this dep.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8570
mreynolds reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Accidentally retired 389-console from epel7 branch. I was trying to retire it from master, but didn't realize I was on the wrong branch
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8563
Dear all,
You are kindly invited to the meeting:
Fedora Release Engineering on 2019-07-31 from 16:00:00 to 17: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/
zbyszek reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
https://kojipkgs.fedoraproject.org/mass-rebuild/f30-failures.html says
> 16 failed builds:
Unless a minor miracle happened, this can't be real ;)
* When do you need this? (YYYY/MM/DD)
Soon.
* When is this no longer needed or useful? (YYYY/MM/DD)
After all rebuild failures are fixed.
* If we cannot complete your request, what is the impact?
We can expect people no to fix build failures.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8180
jwrdegoede reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
gcompris has been orphaned by its original owner and as co-maintainer and de-factor maintainer for the last xxx years I would like to become owner of gcompris before it gets removed from the distro because it has been orphaned.
* When do you need this? (YYYY/MM/DD)
Before orphaned packages are pruned.
* When is this no longer needed or useful? (YYYY/MM/DD)
After orphaned packages are pruned.
* If we cannot complete your request, what is the impact?
gcompris will be removed and children using this educational suite will have to do without it.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8567
jlebon reported a new issue against the project: `releng` that you are following:
``
Please sign FCOS release 30.20190725.0 artifacts and import the OSTree commit into the Fedora unified repo. S3 build dir path is `s3://fcos-builds/prod/streams/testing/builds/30.20190725.0`.
```
+ sha256sum CHECKSUMS
569719342dc5c9f4ec0bf46535d5cd47f8660f3f0a1f1cf9bfe1c9e90f4df148 CHECKSUMS
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8566
======================================
#fedora-meeting-2: RELENG (2019-07-25)
======================================
Meeting started by mboddu at 16:04:11 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-2/2019-07-24/releng.2019…
.
Meeting summary
---------------
* init process (mboddu, 16:04:12)
* #8555 Fedora 31 Mass Rebuild (mboddu, 16:08:40)
* LINK: https://pagure.io/releng/issue/8555 (mboddu, 16:08:46)
* Mass rebuild for rpms has started and the mass rebuild for modules
will start after the current mass rebuild is done, so that the koji
is not overloaded (mboddu, 16:10:35)
* Faster composes (mboddu, 16:13:04)
* 10 of s390x buildvm's are moved to KVM and 15 are still on Z/VM.
Couple of them are added to compose channel and couple for image
channel. This improved the compose/build times on s390x (mboddu,
16:24:30)
* nirik moved all the ppc64le vm's to use libvirt's 'unsafe' cache
mode, this improved the runroot tasks time from couple of hours to
few min which inturn improved the compose time. (mboddu, 16:26:43)
* #8513 F32 system-wide change: x86-64 micro-architecture update
(mboddu, 16:30:42)
* LINK: https://pagure.io/releng/issue/8513 (mboddu, 16:30:48)
* #7445 [RFE][PATCH] make $releasever return "rawhide" on Rawhide
(mboddu, 16:37:54)
* LINK: https://pagure.io/releng/issue/7445 (mboddu, 16:38:00)
* Open Floor (mboddu, 16:46:44)
* nirik enabled srpm repo in f31-build and there is one bug with it.
He is expecting the koji patch to land to fix it soon. (mboddu,
16:49:35)
* EPEL8 (mboddu, 16:49:49)
* EPEL8 is shaping up good and we are expecting a compose sometime
next week (mboddu, 16:52:40)
* Rawhide Gating (mboddu, 16:55:09)
* We are expecting to deploy single build rawhide gating tomorrow.
(mboddu, 16:55:46)
Meeting ended at 17:03:52 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mboddu (74)
* nirik (54)
* zodbot (8)
* sharkcz (5)
* bcotton (3)
* jednorozec (1)
* smooge (1)
* tyll (0)
* puiterwijk (0)
* masta (0)
* pbrobinson (0)
* dustymabe (0)
* pingou (0)
* ksinny (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
sgallagh opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Server: match the contents of the DVD
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/739
mohanboddu opened a new pull-request against the project: `releng` that you are following:
``
mass-rebuild.py py3 changes
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8564
churchyard reported a new issue against the project: `releng` that you are following:
``
* Name of the package? PyDrive
* FAS username of the new maintainer? nb
* Branches that you need it to be unretired for? master
* Package re-review BZ URL? Not needed.
* Any extra information?
I've accidentally retired a wrong package. I've reverted the commit immediately, but it will essentially get blocked in Koji. Please unblock (or prevent it from being blocked).
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8558
pwhalen reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
The ARM SIG would like to add an AArch64 Xfce desktop image to the Fedora 31 deliverables.
Any changes required to the Fedora kickstarts or pungi configs will be sent as pull requests by the ARM SIG.
https://fedoraproject.org/wiki/Changes/AArch64_Xfce_Desktop_image
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8556
eclipseo reported a new issue against the project: `releng` that you are following:
``
* Name of the package?
golang-github-miekg-mmark
* FAS username of the new maintainer?
eclipseo
* Branches that you need it to be unretired for?
master
* Package re-review BZ URL?
Should not be necessary as the package was retired very recently, and will be rewritten.
* Any extra information?
Still needed by hugo.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8554
cverna reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I have pushed an update of the Fedora base image container on Docker Hub we should be doing the same for registry.fp.o
The following version can be release f30 and f31.
* 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/8542
mohanboddu opened a new pull-request against the project: `releng` that you are following:
``
Changes for F31 Mass Rebuild
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8562
churchyard opened a new pull-request against the project: `releng` that you are following:
``
FTBFS weekly reminder: If ALREADY_FILED is too old, drop it
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8561
churchyard opened a new pull-request against the project: `releng` that you are following:
``
Hotfix a undefined variable in the FTBFS weekly reminder script
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8560
decathorpe reported a new issue against the project: `releng` that you are following:
``
* Name of the package?
apache-common-vfs
lz4-java
mina-ftpserver
spock
testng
* FAS username of the new maintainer?
decathorpe
* Any extra information?
These packages are required by some packages the Stewardship SIG already maintains, so we'll take them for now :frowning:
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8553
Dear all,
You are kindly invited to the meeting:
Fedora Release Engineering on 2019-07-24 from 16:00:00 to 17: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/
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-20190722.0
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8550
pingou opened a new pull-request against the project: `releng` that you are following:
``
Rawhide SOP: adjust robosignatory accesses and config
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8541
zsun reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
We are planning a self-contained change to update Deepin Desktop in Fedora to 15.11
https://fedoraproject.org/wiki/Changes/DeepinDE_15.11
We don't expect any affect to non-deepin packages.
* When do you need this? (YYYY/MM/DD)
N/A, this is a general ticket for the change.
* Affects to releng
We don't have plan for spin yet so no action from Release Engineering expected.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8551
lruzicka reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I have opened a bug (#1729151) because that module did not have the defaults correctly set for Fedora 31. In the bug, @ignatenkobrain told me that the module should not be shipped and advised me to open the ticket here to stop shipping it.
* When do you need this? (YYYY/MM/DD)
Ideally, until the Beta freeze of Fedora 31.
* When is this no longer needed or useful? (YYYY/MM/DD)
It is always needed, until solved.
* If we cannot complete your request, what is the impact?
The module will be shipped even if it was not intended to.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1729151
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8552
churchyard reported a new issue against the project: `releng` that you are following:
``
* Name of the package? python2-pytest
* FAS username of the new maintainer? @churchyard
* Branches that you need it to be unretired for? master
* Package re-review BZ URL? https://bugzilla.redhat.com/show_bug.cgi?id=1731858
Note that this package exists in EPEL and @tibbs is the maintainer. I'll check if this kicks him out and will re-add him if needed.
* Any extra information?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8548
kevin opened a new pull-request against the project: `pungi-fedora` that you are following:
``
fedora.conf: Disable i386 buildinstall creation.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/737
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
```
⋊> ~ podman run -it --rm registry.fedoraproject.org/fedora:rawhide bash
[root@e0f7ef39e0fd /]# dnf -C remove python3-unbound
Failed to set locale, defaulting to C.UTF-8
Dependencies resolved.
===============================================================================
Package Architecture Version Repository Size
===============================================================================
Removing:
python3-unbound x86_64 1.8.3-4.fc30 @anaconda 532 k
Removing unused dependencies:
libevent x86_64 2.1.8-5.fc30 @anaconda 976 k
unbound-libs x86_64 1.8.3-4.fc30 @anaconda 1.5 M
Transaction Summary
===============================================================================
Remove 3 Packages
Freed space: 3.0 M
Is this ok [y/N]:
```
Is there any specific reason why container image builds do not set `install_weak_deps=False`?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8530
churchyard opened a new pull-request against the project: `releng` that you are following:
``
Find unblocked orphans on x86_64, not i386
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8547
ankursinha reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
During the SCM creation, the f30 branch for python-matplotlib-scalebar wasn't created.
https://pagure.io/releng/fedora-scm-requests/issue/13732
Could someone please create it?
* When do you need this? (YYYY/MM/DD)
Whenever convenient please
* When is this no longer needed or useful? (YYYY/MM/DD)
NA
* If we cannot complete your request, what is the impact?
No F30 branch for this package :(
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8546
jjames reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I recently orphaned the meataxe package, believing that all consumers of it in Fedora were gone. It turns out that sagemath wants it. I would like to adopt it back.
* When do you need this? (YYYY/MM/DD)
Any time.
* When is this no longer needed or useful? (YYYY/MM/DD)
Never.
* If we cannot complete your request, what is the impact?
Sagemath cannot have a dependency on meataxe.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8545
huzaifas reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Please review: https://fedoraproject.org/wiki/Changes/HardenedCompiler
* When do you need this? (YYYY/MM/DD)
As soon as you can please
* When is this no longer needed or useful? (YYYY/MM/DD)
F31 System-Wide changes deadline :/
* If we cannot complete your request, what is the impact?
Not sure, but maybe we cant include this change unless you review it?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8204
Hi all,
I'm Aymen, a comp-sci student studying in the UK. I'm looking to
contribute to fedora, and I'm interested in the releng team -- is there
a good way to get started? Thanks.
Kind regards,
Aymen
ryanlerch reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Just wondering if it is possible to update the PDC stage instance so the active fedora releases match more closely to current reality? At the moment, the most recent active fedora release on pdc.stg is f28.
This will help make the entire stg pipeline of koji, src, and bodhi more useful when testing pushing packages through the stg pipeline for development testing.
* 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/8537
ryanlerch reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Just wondering if it is possible to update the branches on the src.stg instance to make the branches match more closely to current reality? At the moment, there is a f29 branch on src.stg, but no f30 branches.
This will help make the entire stg pipeline of koji, src, and bodhi more useful when testing pushing packages through the stg pipeline for development testing.
* 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/8538
======================================
#fedora-meeting-2: RELENG (2019-07-18)
======================================
Meeting started by mboddu at 16:00:44 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-2/2019-07-17/releng.2019…
.
Meeting summary
---------------
* init process (mboddu, 16:00:45)
* EPEL8 (mboddu, 16:02:03)
* Alternate Architecture Updates (mboddu, 16:22:15)
* LINK: https://koji.fedoraproject.org/koji/taskinfo?taskID=36293914
(nirik, 16:30:28)
* sharkcz will be doing some experiments to gather some facts on
ppc64le slowness and nirik will 4 builders on each p9 box and see if
it helps with any storage competition issue. (mboddu, 16:43:52)
* nirik will remove buildvm-ppc64le-01/02.ppc.fedoraproject.org
ppc64le builders from image channel and add 04,10,11 ppc64le
builders to image channel which makes 4 in image channel including
03 (mboddu, 16:47:09)
Meeting ended at 17:03:11 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mboddu (65)
* nirik (55)
* sharkcz (29)
* smooge (7)
* zodbot (7)
* tyll (0)
* puiterwijk (0)
* masta (0)
* jednorozec (0)
* pbrobinson (0)
* dustymabe (0)
* ksinny (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
jlebon reported a new issue against the project: `releng` that you are following:
``
Please sign FCOS release 30.20190716.1 artifacts and import the OSTree commit into the Fedora unified repo. S3 build dir path is `s3://fcos-builds/prod/streams/testing/builds/30.20190716.1`
You will find a `CHECKSUMS` file and a detached signature `CHECKSUMS.sig` at the root of the build dir. We will sign with a better key for this soon (or it will be implicitly signed once we move to fedora-messaging), but for now, I've signed it with [my personal key](https://keys.fedoraproject.org/pks/lookup?op=get&search=0x936F29E9519C….
Thanks!
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8539
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
kevin reported a new issue against the project: `releng` that you are following:
``
https://docs.pagure.org/koji/plugins/#save-failed-tree-plugin
We would need to make sure we set filters right and that this correctly errors after a buildroot has been cleaned up by kojid.
Perhaps we could try it in staging for a bit.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8243
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
kevin reported a new issue against the project: `releng` that you are following:
``
These packages do not have git repos on pkgs02, but are active in pdc:
```
ERROR: /srv/git/repositories/rpms/R-gnomeGUI.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/actdiag.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/compat-ImageMagick6.9.3.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/gnome-cpufreq-applet.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/kf5-textwidgets.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/nwdiag.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/python-elementtree.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/repsurgeon.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/seqdiag.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/tetex-beamer.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/tetex-pgf.git does not appear to be a directory
ERROR: /srv/git/repositories/rpms/tetex-xcolor.git does not appear to be a directory
```
so, likely they should be marked eol in pdc and blocked in koji?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8143
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
sgallagh reported a new issue against the project: `releng` that you are following:
``
* Name of the module?
hub
* Stream name(s) and the new EOL date?
prerelease
New EOL date is EOL of Fedora 29.
* Any extra information?
This stream is not useful as it was originally addressing the lack of upstream releases for two years. However, upstream is now doing monthly releases and so it should go away.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8166
pingou reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
We would like to implement a system allowing to gate on test results rawhide packages before they land into the buildroot and affect other packages. This is aimed to be deployed in two phase, the first phase will concern the single package updates and the second phase will concern the multi-package updates.
This ticket is to inform you about this change proposal, available in full at:
https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates
Please let us know what you think of it :)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8183
kalev reported a new issue against the project: `releng` that you are following:
``
I'm getting the following when trying to build a flatpak for thunderbird:
```
$ fedpkg flatpak-build
Created task: 32963187
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=32963187
Watching tasks (this may be safely interrupted)...
32963187 buildContainer (noarch): free
32963187 buildContainer (noarch): free -> open (buildvm-12.phx2.fedoraproject.org)
32963187 buildContainer (noarch): open (buildvm-12.phx2.fedoraproject.org) -> FAILED: Fault: <Fault 2001: 'Image build failed. Error in plugin orchestrate_build: \'{"aarch64": {"general": "\\\\"AllClustersFailedException(\\\'Could not find appropriate cluster for worker build.\\\')\\\\""}}\'. OSBS build id: thunderbird-master-79998-3'>
0 free 0 open 0 done 1 failed
32963187 buildContainer (noarch) failed
```
I assume this is fallout from https://pagure.io/releng/issue/8133 that added the aarch64 architecture to container build tags in koji.
@cverna @otaylor Any ideas?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8158
kalev reported a new issue against the project: `releng` that you are following:
``
Hi,
I just finished a new round of openh264 builds. Please sign and send the following to Cisco:
openh264-1.8.0-3.fc29
openh264-1.8.0-3.fc30
openh264-1.8.0-3.fc31
Thanks,
Kalev
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8157
zsun reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
This is a general question.
Given I am the LXQt spin maintainer, when I want to test my changes to kickstart files of generating livemedia, I need a way to try like the production.
I saw there is a page about [Building Images in Koji](https://docs.pagure.org/koji/image_build/). So I tried like that
```
koji spin-livemedia fedora-lxqt 30 f30 x86_64 ./flat-live-lxqt.ks --scratch
```
But I got
```
2019-02-20 11:20:15,915 [ERROR] koji: ActionNotAllowed: livemedia permission required
```
So my questions are
* Is the livemedia permission granted only to Release Engineering people, or also spin maintainers
* If this also grants to spin maintainers, can you grant me this permission?
* If this only grants to Release Engineering, can you provide some guide for building a livemedia like it does in Koji? I saw [this wiki](https://fedoraproject.org/wiki/Livemedia-creator-_How_to_create_and_u… already but I always need to set `selinux --permissive` to make a working Fedora Rawhide(f30) livemedia.
Thanks!
* When do you need this? (YYYY/MM/DD)
No ETA but as soon as possible
* When is this no longer needed or useful? (YYYY/MM/DD)
As long as I am still contributing to Fedora, this is still useful ;-)
* If we cannot complete your request, what is the impact?
Minimal. It just makes my work a little complex
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8145
pingou reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
In order to test the Rawhide package gating workflow in staging, we need to have a ``f31-updates-stable-pending`` koji tag created since we push builds to this tag once their gate is lifted.
* When do you need this? (YYYY/MM/DD)
ASAP
* When is this no longer needed or useful? (YYYY/MM/DD)
When f31 is EOL in staging
* If we cannot complete your request, what is the impact?
We can't test gating properly in staging
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8540
pkubat reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Seems like some builds (incl. libpq needed by me) are stuck in f31-pending:
$ koji --quiet list-tagged --latest f31-pending
cinnamon-session-4.2.1-1.fc31 f31-pending leigh123linux
clamav-0.101.2-2.fc31 f31-pending sergiomb
cross-gcc-9.1.1-2.fc31 f31-pending spot
dbus-broker-21-5.fc31 f31-pending ngompa
eureka-1.24-1.fc31 f31-pending limb
highlight-3.52-2.fc31 f31-pending filiperosset
ktimer-19.04.3-1.fc31 f31-pending rdieter
ktoblzcheck-1.49-1.fc31 f31-pending notting
libffi-3.1-22.fc31 f31-pending fweimer
libpq-11.4-1.fc31 f31-pending pkubat
php-netresearch-jsonmapper-1.5.0-1.fc31 f31-pending remi
pidgin-2.13.0-14.fc31 f31-pending jskarvad
* If we cannot complete your request, what is the impact?
libpq-11.4-1.fc31 has been stuck for a week and is needed to rebuild postgresql in Rawhide + version 11 module.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8536
Dear all,
You are kindly invited to the meeting:
Fedora Release Engineering on 2019-07-17 from 16:00:00 to 17: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/
kevin opened a new pull-request against the project: `pungi-fedora` that you are following:
``
remove old pdc entries in fedora.conf. They are no longer used
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/736
jbwillia reported a new issue against the project: `releng` that you are following:
``
* https://dl.fedoraproject.org/pub/alt/live-respins/ is giving a 403
* asap
* the next time we upload updated lives
* anyone installing with the F30 GOLD isos will have 1.2GB of updates
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8517
zlopez reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I'm now part of the bodhi team and I tried to release a new beta version, but found out I don't have permission to build f29-infra build in koji.
FAS nickname: zlopez
* When do you need this? (YYYY/MM/DD)
asap
* When is this no longer needed or useful? (YYYY/MM/DD)
When I'm no longer part of the CPE team
* If we cannot complete your request, what is the impact?
I'm not able to release beta versions of Bodhi
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8532
ueno reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
nettle 3.5 bumped the ABI:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
To rebuild the dependent packages we need a side-tag (e.g., f31-nettle).
* When do you need this? (YYYY/MM/DD)
2019/07/15
* 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/8534
cverna opened a new pull-request against the project: `releng` that you are following:
``
Add SOP for managing rawhide in bodhi.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8535
churchyard reported a new issue against the project: `releng` that you are following:
``
https://src.fedoraproject.org/rpms/cachedir/c/544ba50e44ab84340c6bdc87f9d9b… is ~1 month old, yet cachedir is not blocked:
```
$ koji list-pkgs --show-blocked --tag f31 --package cachedir
Package Tag Extra Arches Owner
----------------------- ----------------------- ---------------- ---------------
cachedir f31 releng
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8523
ngompa reported a new issue against the project: `releng` that you are following:
``
* Name of the package? `comps-extras`
* FAS username of the new maintainer? `ngompa`
* Any extra information?
This is required by dnfdragora, though I didn't know about it until now... :flushed:
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8526
churchyard reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
See https://bugzilla.redhat.com/show_bug.cgi?id=1729946
Please unatg nettle-3.5.1-1.fc31.
I've done this:
$ koji tag-build f31-pending nettle-3.4.1rc1-3.fc31
But not sure if that is enough.
* When do you need this? Right now.
* When is this no longer needed or useful? If it gets untagged by my action (tagging the previous build)
* If we cannot complete your request, what is the impact? Nobody can rebuild anything in rawhide.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8533
defolos reported a new issue against the project: `releng` that you are following:
``
* Name of the package?
python-breathe
* FAS username of the new maintainer?
defolos
* Any extra information?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8531
churchyard reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
The [python3-3.7.4-1.fc31](https://koji.fedoraproject.org/koji/buildinfo?buildID… built is stuck in f31-pending. Please unstuck it.
* When do you need this? Any time soon.
* When is this no longer needed or useful? Once we update python3.
* If we cannot complete your request, what is the impact? Rawhide builds being done over an rc2 Python version.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8528
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
### Name of the package?
`farstream02`
### FAS username of the new maintainer?
@stefanb
### Any extra information?
https://pagure.io/fesco/issue/2155
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8527
jforbes reported a new issue against the project: `releng` that you are following:
``
The change is to stop building the i686 kernels, and produce kernel-headers packages only. This will not impact the build of any other package as i686, but will mean no more bootable images. This will require changes to the releng deliverables, in that i686 bootable images should no longer be deliverables.
Change page for review: https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
Owner: @jforbes
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8461
kevin opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Drop i386 images and things that need a kernel, leave modular and Everything trees.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/735
olem reported a new issue against the project: `releng` that you are following:
``
I'd like to adopt orphaned package "moby-engine".
Package name: moby-engine
FAS username: olem
Thanks!
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8525
dmoluguw reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I'd like to take over the following orphaned packages:
- jboss-logging
- jboss-annotations-1.2-api
**NOTE:** As I'm already part of Fedora SIG, I'll be adding @stewardship-sig group to this package and will be maintaining it as part of the SIG efforts.
* When do you need this? (YYYY/MM/DD)
As soon as possible (before they are retired).
* If we cannot complete your request, what is the impact?
`pki-core` and `dogtag-pki` packages will be rendered unusable.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8431
limb reported a new issue against the project: `releng` that you are following:
``
Orphaned 2019-07-09 by jjames. My FAS id is limb. Thank you!
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8519
decathorpe reported a new issue against the project: `releng` that you are following:
``
* Name of the package?
apache-mime4j
* FAS username of the new maintainer?
decathorpe
* Branches that you need it to be unretired for?
master (rawhide)
* Package re-review BZ URL?
https://bugzilla.redhat.com/show_bug.cgi?id=1728746
* Any extra information?
This package is still required by resteasy, which is in turn a dependency of the PKI stack.
I will add this package to the set of packages maintained by the Stewardship SIG.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8521
cverna opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Set the container environment variable to oci.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/734
cverna opened a new pull-request against the project: `pungi-fedora` that you are following:
``
Set the container environment variable to oci.
``
To reply, visit the link below or just reply to this email
https://pagure.io/pungi-fedora/pull-request/733
Hi,
We are cancelling today's RelEng meeting as everyone is busy with EPEL
work.
FYI, we are getting closer to releasing epel8. We will inform you when its
ready.
Thanks.
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 Bundler 2.0
* When do you need this? (YYYY/MM/DD)
2019-07-22 or sooner, ideally.
* When is this no longer needed or useful? (YYYY/MM/DD)
2019-09-01 - In time to make changes before change Completion deadline.
* If we cannot complete your request, what is the impact?
Bundler 2.0 will probably not be in Fedora 31.
_ _ _ _
Change proposal:
https://fedoraproject.org/wiki/Changes/Bundler_2.0
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8518
churchyard reported a new issue against the project: `releng` that you are following:
``
I've seen recently packagers retiring packages from already released Fedora versions. Such as:
https://src.fedoraproject.org/rpms/yum-axelget/commits/f29
Can we please reject such commits, as it makes no sense and the package remains in the repo forever?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8324
Dear all,
You are kindly invited to the meeting:
Fedora Release Engineering on 2019-07-10 from 16:00:00 to 17: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/
sinnykumari 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-20190708.0
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8514
eclipseo reported a new issue against the project: `releng` that you are following:
``
There are a few package remaining but i will do them in f31-build, so we can work on Go 1.13 from now on.
Please merge f31-go as soon as possible.
CC: @jcajka
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8516
decathorpe reported a new issue against the project: `releng` that you are following:
``
* Name of the package?
bean-validation-api
derby
jboss-el-3.0-api
jboss-modules
jboss-servlet-3.1-api
jboss-transaction-1.2-api
* FAS username of the new maintainer?
decathorpe
* Any extra information?
These recently orphaned packages are still needed in fedora, and hence will be maintained by the Stewardship SIG for now ...
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8515
taingram reported a new issue against the project: `releng` that you are following:
``
Please assign this package to me, I have contributed patches to brightnessctl and would like to take over packaging it. Thanks!
https://src.fedoraproject.org/rpms/brightnessctl
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8508
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
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
fale reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
Hi, I would like to pick-up the brightnessctl package that I've orphaned a while ago.
* When do you need this? (YYYY/MM/DD)
When possible
* When is this no longer needed or useful? (YYYY/MM/DD)
I think it would still be useful
* If we cannot complete your request, what is the impact?
brightnessctl stays orphaned and unmaintained.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8364
atim reported a new issue against the project: `releng` that you are following:
``
* Name of the package?
faience-icon-theme
* FAS username of the new maintainer?
atim
* Branches that you need it to be unretired for?
master
f30
f29
epel7
* Package re-review BZ URL?
Retired for less than six weeks so no re-review required.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8499
ankursinha reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I'm no longer a maintainer for gitg, but new bugs on bugzilla still include my e-mail address. Would someone please know what I must do to stop new bugs for gitg including it too?
https://src.fedoraproject.org/rpms/gitg
Example new bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1727558
* When do you need this? (YYYY/MM/DD)
NA
* When is this no longer needed or useful? (YYYY/MM/DD)
Not urgent at all.
* If we cannot complete your request, what is the impact?
I keep getting these bug e-mails and remove myself manually.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8512
decathorpe reported a new issue against the project: `releng` that you are following:
``
* Name of the package?
emma
felix-osgi-obr-resolver
hibernate-jpa-2.0-api
jboss-connector-1.7-api
jboss-el-2.2-api
jboss-jsf-2.1-api
jboss-jsp-2.3-api
jboss-jstl-1.2-api
jboss-marshalling
jboss-servlet-3.0-api
jboss-websocket-1.0-api
jline1
weld-parent
* FAS username of the new maintainer?
decathorpe
* Any extra information?
These recently orphaned packages are still needed in fedora, and hence will be maintained by the Stewardship SIG for now ...
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8510
eclipseo reported a new issue against the project: `releng` that you are following:
``
* Name of the package?
golang-google-appengine
* FAS username of the new maintainer?
eclipseo
* Branches that you need it to be unretired for?
master
* Any extra information?
I've accidentally retired this package, could you please reinstate it?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8511
cverna reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I have pushed an update of the Fedora base image container on Docker Hub we should be doing the same for registry.fp.o
The following version can be release f30 and f31.
* 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/8505
filiperosset reported a new issue against the project: `releng` that you are following:
``
I'm trying to fix some broken packages, but I'm stuck with python-ttystatus, I cannot commit my changes to fix FTBFS:
[filiperosset@raw python-ttystatus]$ git push
Enter passphrase for key '/home/filiperosset/.ssh/id_rsa':
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 502 bytes | 502.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Branch refs/heads/master is unsupported
remote: Denied push for ref 'refs/heads/master' for user 'filiperosset'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/python-ttystatus
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://filiperosset@pkgs.fedoraproject.org/rpms/python-ttystatus'
[filiperosset@raw python-ttystatus]$
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8504
fujiwara reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I'd like to request review of IBus 1.5.21 for Fedora 31 from I18N team:
https://fedoraproject.org/wiki/Changes/IBus_1.5.21
* When do you need this? Fedora 31 Mass Rebuild
* When is this no longer needed or useful? Fedora 31 GA
* If we cannot complete your request, what is the impact?
Fedora Changes asks to get the impact from release-engineers.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8503
======================================
#fedora-meeting-2: RELENG (2019-07-04)
======================================
Meeting started by mboddu at 16:04:26 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-2/2019-07-03/releng.2019…
.
Meeting summary
---------------
* init process (mboddu, 16:04:26)
* EPEL8 (mboddu, 16:07:32)
* fedpkg and fedscm-admin changes are tested in stage and are working.
People can request epel8 branches just like they do for fedora
release branches. (mboddu, 16:07:34)
* ACTION: mboddu need to create pungi configs and scripts to run epel8
nightly composes (mboddu, 16:08:05)
* #7400 Rethink how we handle networking config with createImage (oz /
ImageFactory) (mboddu, 16:36:16)
* LINK: https://pagure.io/releng/issue/7400 (mboddu, 16:36:21)
* Alternate Architecture Updates (mboddu, 16:42:46)
* Now we have a s390x buildvmhost now, and nirik have configured it
but it has networking issues, once its sorted out, nirik will try to
setup a guest builder on the buildvmhost and once tested, all the
existing builders will moved (mboddu, 16:47:05)
* Open Floor (mboddu, 16:47:17)
Meeting ended at 16:50:44 UTC.
Action Items
------------
* mboddu need to create pungi configs and scripts to run epel8 nightly
composes
Action Items, by person
-----------------------
* mboddu
* mboddu need to create pungi configs and scripts to run epel8 nightly
composes
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mboddu (47)
* nirik (39)
* zodbot (8)
* puiterwijk (0)
* jednorozec (0)
* pbrobinson (0)
* dustymabe (0)
* ksinny (0)
* sharkcz (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
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
churchyard reported a new issue against the project: `releng` that you are following:
``
* Describe the issue
I'd kindly like to request a Fedora 29 side tag in koji for Python 3.7 rebuilds. See https://pagure.io/releng/issue/8092
Preferred tag/target name: f31-python
Parent: f31-build
```
$ koji add-tag f31-python --parent=f31-build --arches='armv7hl i686 x86_64 aarch64 ppc64 ppc64le s390x'
$ koji add-target f31-python f31-python
```
* When do you need this? (2019/05/26)
* When is this no longer needed or useful? (2019-07-24)
* If we cannot complete your request, what is the impact?
We would not be able to rebuild Python 3.8.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8320
Dear all,
You are kindly invited to the meeting:
Fedora Release Engineering on 2019-07-03 from 16:00:00 to 17: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/
churchyard opened a new pull-request against the project: `releng` that you are following:
``
Fix the FTBFS weekly reminder hotfix
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8502
Hello everyone,
a new version of Pungi is available! The 4.1.38 build is ready to be
used. There are updates waiting in Bodhi to go to updates-testing.
Here are the highlights of the release:
* Configuration options were deprecated: runroot, release_is_layered.
These options can be dropped from the config files, as the same
information was already deducible from other options.
* Temporary repositories created in pkgset phase now include modular
metadata. This is required for upcoming DNF failsafe mechanism - it
will reject repositories with modular packages without metadata.
* Pkgset phase creates repositories in parallel. Hopefully this should
make things slightly faster.
And a couple other small fixes.
Refer to the documentation [0] for details on what configuration
options are available.
[0] https://docs.pagure.org/pungi/index.html
If you encounter problems or need general help, stop by #fedora-releng
IRC channel or file issues in Pagure.
Happy composing!
Lubomír
churchyard opened a new pull-request against the project: `releng` that you are following:
``
Add a note about retirement to the FTBFS weekly reminder
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/pull-request/8480
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
If you get primary.xml from https://kojipkgs.fedoraproject.org/repos/f31-build/latest/x86_64/repodata/ and check what information contains `gcr` package, you will see that only `/usr/bin/gcr-viewer` is there. However, it does provide `/usr/libexec/gcr-ssh-askpass` files, but for some reason it is not in primary.xml. And you can see other `/usr/libexec/*` files in primary.xml...
I am not sure what caused this, but please take a look on it. I'm trying to make sure that you can resolve all file dependencies within primary.xml without fallback to filelists.xml.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/8496