[releng] Issue #6868: Extend tag configuration for f26-modularity
by Petr Šabata
psabata reported a new issue against the project: `releng` that you are following:
``
To make the `f26-modularity`-based repository usable for `buildinstall` pungi phase, we need two additional changes to the tag configuration:
* the `build` group needs to be defined; it should include the usual set -- `koji add-group f26-modularity build && koji add-group-pkg f26-modularity build bash bzip2 coreutils cpio diffutils fedora-release findutils gawk gcc gcc-c++ grep gzip info make patch redhat-rpm-config rpm-build sed shadow-utils tar unzip util-linux which xz`
* dnf should be used to install this group -- `koji edit-tag -x mock.package_manager=dnf f26-modularity`
This is a followup for https://pagure.io/releng/issue/6696. I've tested these changes in staging and it works as expected.
Thanks!
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6868
6 years, 1 month
[releng] Issue #6799: [koji] Add configuration for module build service
content generator
by Stanislav Ochotnicky
sochotni reported a new issue against the project: `releng` that you are following:
``
We will need changes/additions to koji configuration to enable imports of Modules through content generator.
Expect future updates once since this is a bit off the top of my head.
1. Add content generator "module-build-service"
2. Add btype "module"
3. Configure whatever user is used by modulebuild service to have permission for the content generator APIs
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6799
6 years, 1 month
[releng] Issue #6671 `Figure out how to block real builds in koji coming
from forks in pagure`
by Pierre-YvesChibon
pingou reported a new issue against the project: `releng` that you are following:
``
As far as I understood from Patrick the current mechanism for koji to allow/deny building from a source is fairly simple.
With pagure on the top of dist-git, we may need something a little more flexible as we would like to support the following use-cases:
* Builds from main repo proceed as now
* Builds from forks can only be either (or both) of:
* scratch-build
* in a certain tag used for the CI integration (redefining the dist tag to allow building the same package, once for testing and once for real)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6671
6 years, 2 months
[releng] Issue #6863: Separate Subpackage and Source Debuginfo releng review
by Mark Wielaard
mjw reported a new issue against the project: `releng` that you are following:
``
https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo is a system wide change proposal for f27. All code is in rawhide already, but the feature isn't enable by default. Packages wishing to have a separate debugsource package and sub-debuginfo packages need to explicitly define one (or both) of the following in their spec file:
%global _debugsource_packages 1
%global _debuginfo_subpackages 1
This might need some release engineering magic to make sure the created <package>-debugsource and <subpackage>-debuginfo packages end up in the [fedora-debuginfo] repository.
There is some more background information on the various debuginfo improvements in the current rawhide rpmbuild and which macros packages can use in the spec files in this fedora devel mailinglist message:
https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.or...
Depending on feedback on that we could enable one or both settings by default for the mass rebuild. Although that can also be done afterwards. Or if any issues are found we could keep it off by default and let packages explicitly opt-in.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6863
6 years, 2 months