How to deprecate a subpackage
by Lukas Zapletal
Hey,
I have a subpackage which is not needed anymore in the new version of the package. Is my assumption correct that for a smooth upgrade path I should simply delete the subpackage and make the main package to obsolete it:
Obsoletes: %{name}-gtk2
Provides: %{name}-gtk2
Looks like rpmlint wants me to add version, I can do that.
4 years
Specify debug build in qtmake?
by Richard Shaw
Has something changed with Qt 5.14? I'm trying to update klog to new
version but debuginfo is not being generated.
Looking at the build log it's definitely missing "-g" during building but a
debug build is requested:
qmake-qt5 "PREFIX=%{buildroot}%{_prefix}" "CONFIG+=debug c++17" KLog.pro
Looking at KLog.pro I see:
CONFIG += release
and
#DEFINES *= QT_NO_DEBUG_OUTPUT
Which I assume is ok. I should be overriding the first line and the second
is commented out.
Tips?
Thanks,
Richard
4 years
multiple definitions build failure on armv7hl only
by Orion Poplawski
Test building the latest gdl, I get the following errors only on armv7hl:
/usr/bin/ld: CMakeFiles/gdl.dir/basic_op.cpp.o:(.rodata+0x30): multiple
definition of `typeinfo name for Data_<SpDByte>';
CMakeFiles/gdl.dir/datatypes.cpp.o:(.rodata+0x50): first defined here
/usr/bin/ld: CMakeFiles/gdl.dir/basic_op.cpp.o:(.data.rel.ro+0x0):
multiple definition of `typeinfo for Data_<SpDByte>';
CMakeFiles/gdl.dir/datatypes.cpp.o:(.data.rel.ro+0xc): first defined here
Full log:
https://kojipkgs.fedoraproject.org//work/tasks/5149/42205149/build.log
Anything immediately suspicious here? Seems odd to have two definitions
in different segments of the same object file.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
4 years
Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
by Aleksandra Fedorova
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
== Summary ==
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.
== Owner ==
* Name: [[User:Bookwar| Aleksandra Fedorova]]
* Email: alpha(a)bookwar.info
* Name: [[User:Sgallagh | Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
== Detailed Description ==
This Change supersedes the previously-approved [[Changes/Additional
buildroot to test x86-64 micro-architecture update|Change]] to enable
an additional buildroot. During development, its scope has expanded to
include the entire process of how the Fedora sources are built and
composed into shippable artifacts.
ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.
ELN (Enterprise Linux Next) is going to be that place. What we want to
do is establish a set of RPM conditionals that can be used for the set
of packages that may need to be built differently for a RHEL-like
target as compared to a Fedora one. (For example, we may want to skip
regenerating documentation during package-build and instead use
pre-built docs from the tarball or SRPM.)
This includes:
* buildroot configuration, rpm macro and compile flags,
* comps files and the compose content,
* compose itself and the pipeline which builds it.
Under this umbrella we are going to have:
* RPM variables for conditionals to allow tweaking rpm spec files
* A new Koji tag which allows control of the buildroot,
* A fork of the pungi configuration which describes the compose configuration,
* A pipeline which builds a periodic compose based on that configuration,
* Storage for such composes and additional pipelines which will verify
the quality of the compose and test additional scenarios on top of it.
The RPM variables:
* `%{dist}` will return `.eln` (no numerical suffix)
* `%{fedora}` will return `.fcXX` (where XX is the Fedora version
represented by Rawhide).
* `%{rhel}` will be set and will return a number one higher than the
most recent major release of Red Hat Enterprise Linux (at present,
that will be `9`).
* `%{eln}` will be set and will expand to `%{rhel}`
The reasoning behind this approach is so that we break as little as
possible when we implement this new build and compose. Existing
packages that are using conditionals such as `if 0%{?rhel} > 7` will
transition over to building "like RHEL" automatically. Any packages
that do not have a shared Fedora/RHEL specfile will continue to build
as normal. Some unknown number of packages that rely on `if !
0%{?fedora}` will require manual intervention.
The `%{eln}` variable will be set primarily to allow for the
possibility of needing conditionals that apply to ELN only and should
not carry over to RHEL, but we expect its use to be exceptionally
rare.
== Benefit to Fedora ==
Who benefits from the implementation of this feature:
* Fedora Infrastructure
** As we are going to try and test new, more easily maintainable
infrastructure for composes.
* Fedora Minimization
** As we are going to modify the compose content according to
minimization goals and provide feedback to Fedora maintainers on the
results
* CentOS Stream, EPEL and RHEL
** We are going to build Fedora packages into a compose similar to the
multi-repo structure of CentOS and RHEL.
* Fedora Community
** The feedback pipelines built for the project will allow downstream
developers to open up their work and bring it closer to Fedora. In
particular, it will enable projects like OpenShift to do their work in
Fedora.
** Making Fedora friendlier to its downstream will justify bringing
more resources and more contributions to Fedora Rawhide. So that
downstream not only tries to catch up with Fedora going forward, but
actively participates in Fedora development and testing.
** The tooling developed for this project will allow further
development of changes in Fedora Infrastructure without blocking the
regular Fedora packaging and release process.
== Scope ==
* Proposal owners:
** Setup build environment for a new disttag (`eln`).
** Setup automation to trigger new ELN build every time there is a new
update submitted to Fedora Rawhide.
** Post build result to Fedora Messaging, so that it appears in Bodhi
and can be used as a
[https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test].
** Setup automation to run periodic partial composes (via ODCS)
without installation media to generate repositories with these
packages.
** Update packaging documentation to mention new disttag and how it can be used.
* Other developers:
*: Anyone who wants to produce different content for the ELN compose
will need to implement the new macros in their specfile. The
overwhelming majority of packages will require no modification.
* Release engineering: [https://pagure.io/releng/issue/9154 #9154]
* Policies and guidelines:
[https://pagure.io/packaging-committee/issue/955 #955]
* Trademark approval: not needed. There is no new shippable artifact.
== Upgrade/compatibility impact ==
N/A
Though it is a System Wide change it doesn’t impact Fedora upgrades,
as it is a development environment tracking Fedora Rawhide.
== How To Test ==
There is going to be a development snapshot of the state of the ELN
repositories.
It is under discussion whether this snapshot will have its own
installation media. For now the preferred way to test ELN composes
would be to use standard Fedora Rawhide images and then include ELN as
an additional repository.
== User Experience ==
There is no user-facing part in this change. No ELN artifacts are
going to be shipped to the end-user.
== Dependencies ==
There is no dependency on other changes, though some of the
infrastructure services like ODCS composes and Fedora CI will be
involved.
== Contingency Plan ==
* Contingency mechanism: If this effort doesn’t land in Fedora 33 we
review it and decide whether it needs to be moved further to Fedora 34
or cancelled.
* Contingency deadline: N/A as it is a continuous process in Fedora
Rawhide and it is not pinned to a specific release.
* Blocks release? No
* Blocks product? No
Additional risk: Infrastructure resources taken by ELN builds can
create load on Fedora build system
Mitigation: In case of such load we cancel or reschedule ELN tasks
(package and compose builds and tests) on request from the Fedora
Infrastructure team. At least initially, we will also set ELN tasks to
low-priority, similar to how COPR does it.
== Documentation ==
https://fedoraproject.org/wiki/ELN
See also previous discussions:
* "Alternative buildroot as a development tool" @ devel
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
== Release Notes ==
N/A
Though it is a System-Wide Change it has no user-facing component. We
may announce it through other channels.
--
Aleksandra Fedorova
bookwar
4 years
Does anyone/thing care about the kernel inside the boot.iso rootfs?
by Brian C. Lane
We've noticed that there is a kernel inside the install.img of the
boot.iso -- it isn't used for booting, and as far as I can tell it's
just taking up extra space.
But I have no idea if it's safe to remove it :)
I have this PR, which works fine for me in my testing:
https://github.com/weldr/lorax/pull/926
The corresponding hmac file is being used by the dracut fips module, but
that's been solved in dracut-050.
Anyone have any objections to removing it?
--
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
4 years
Compilation Error on F32
by Nathanael D. Noblet
Hello,
I have a project that isn't part of Fedora yet - though really I
should add it at this point. Its php-cpp. It allows me to write c++
extensions for PHP. Its worked well for a couple years. I upgraded to
F32 beta and now when compiling anything that includes its headers
compilation fails and I'm not entirely sure why.
g++ -MT pdf-image.o -MMD -MP -MF .d/pdf-image.Td -Wall -g -c -O2
-std=c++11 -fPIC `pkg-config poppler-cpp fontconfig openssl --
cflags` -DVERSION=\"0.11.16\" -c -o pdf-image.o pdf-image.cpp
In file included from /usr/include/phpcpp.h:38,
from pdf-image.cpp:8:
/usr/include/phpcpp/throwable.h:29:1: error: expected class-name before
‘{’ token
I've attached the header. Any gcc experts out there able to tell me
what's wrong with the header format that used to compile but no longer
does?
In case it is relevant PHPCPP_EXPORT has the following definition:
#define PHPCPP_EXPORT __attribute__ ((visibility ("default")))
Sincerely,
--
Nathanael
4 years
