Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1234277
Summary: | distro-wide architecture set overriden by buildsystem | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dan Horák <dan> |
Component: | 389-ds-base | Assignee: | Rich Megginson <rmeggins> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | admin_public, dan, edewata, hannsj_uhl, mreynolds, nhosoi, nkinder, rmeggins |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | ppc64le | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 389-ds-base-1.3.4.1-1.fc22 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-07-19 14:57:53 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 467765, 1071880, 1051573 |
Description
Dan Horák
2015-06-22 09:21:00 UTC
Noriko, can you port the recent fixes for 389 (that is, only build nunc-stans on x86_64, and use nunc-stans 0.1.5) to fedora? Upstream ticket: https://fedorahosted.org/389/ticket/48202 (In reply to Rich Megginson from comment #1) > Noriko, can you port the recent fixes for 389 (that is, only build > nunc-stans on x86_64, and use nunc-stans 0.1.5) to fedora? Sure, I will. Thanks for the report. Ah, I made a mistake in the description, but I guess you got what I meant. The sentence should read - The buildsystem should not touch the -march options at all. (In reply to Dan Horák from comment #4) > Ah, I made a mistake in the description, but I guess you got what I meant. > The sentence should read - The buildsystem should not touch the -march > options at all. If we build nunc-stans only for x86_64, the --march override problem disappears except on x86_64. This "-march=core2" is not allowed on x86_64, either? gcc -Wall -Wno-unknown-pragmas -std=c99 -march=core2 -c -I"src" -I"inc" -fpic -O0 -g -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -o obj/XYZ.o src/queue/XYZ.c Note: it's in the make file in the source code. liblfds/makefile.linux 30 ifeq ($(GCCARCH),x86_64) 31 GCCARCH = core2 32 endif ... 46 CBASE = -Wall -Wno-unknown-pragmas -std=c99 -march=$(GCCARCH) -c -I"$(SRCDIR)" -I"$(INCDIR)" (In reply to Noriko Hosoi from comment #5) > (In reply to Dan Horák from comment #4) > > Ah, I made a mistake in the description, but I guess you got what I meant. > > The sentence should read - The buildsystem should not touch the -march > > options at all. > > If we build nunc-stans only for x86_64, the --march override problem > disappears except on x86_64. > > This "-march=core2" is not allowed on x86_64, either? correct, as the resulting binary can crash on CPUs that are not core2 compatible > gcc -Wall -Wno-unknown-pragmas -std=c99 -march=core2 -c -I"src" -I"inc" > -fpic -O0 -g -O2 -g -pipe -Wall -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong > --param=ssp-buffer-size=4 -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -o > obj/XYZ.o src/queue/XYZ.c http://pkgs.fedoraproject.org/cgit/redhat-rpm-config.git/tree/rpmrc defines the CPU support for Fedora I do not want to touch liblfds at all. Take a look at https://git.fedorahosted.org/cgit/nunc-stans.git/tree/m4/lfds.m4#n65 The goal is to create a GNUmakefile that we can use to override whatever is in the liblfds makefile. And the 0.1.5 version of nunc-stans should have done just that: CFLAGS = $CFLAGS \$(AM_CFLAGS) -c -fpic -Wno-unknown-pragmas -std=c99 -I"\$(SRCDIR)" -I"\$(INCDIR)" $LFDS_CFLAGS Basically, override any CFLAGS set in makefile.linux. If this isn't working, then we need to revisit this. Hello Dan, could you please help me? I updated nunc-stans to 0.1.5 and ran fedpkg to build 389-ds-base-1.3.4.1, then somehow it fails to pick up the nunc-stans-0.1.5.tar.bz2. I repeated the same procedures when I built 389-ds-base-1.3.4.0. Here's the steps: $ fedpkg new-sources `pwd`/389-ds-base-1.3.4.1.tar.bz2 `pwd`/nunc-stans-0.1.5.tar.bz2 $ cat sources 4f61a797a4d9eff4d41c619b7d3d0358 nunc-stans-0.1.5.tar.bz2 ddcc0c0174faf1c5c1e063e2360a1984 389-ds-base-1.3.4.1.tar.bz2 I verified the sources and spec file were good by the scratch build. For instance, $ fedpkg srpm $ rpm -ivh 389-ds-base-1.3.4.1-1.fc22.src.rpm $ ls -l ~/rpmbuild/SOURCES -r--r--r--. 1 nhosoi nhosoi 3356649 Jun 23 15:23 389-ds-base-1.3.4.1.tar.bz2 -r--r--r--. 1 nhosoi nhosoi 402557 Jun 23 15:19 nunc-stans-0.1.5.tar.bz2 I committed/pushed the changes to dist-git. .gitignore 389-ds-base.spec sources $ fedpkg build This fails as follows: http://koji.fedoraproject.org/koji/taskinfo?taskID=10194207 x86_64: http://koji.fedoraproject.org/koji/taskinfo?taskID=10194210 build log: https://kojipkgs.fedoraproject.org//work/tasks/4210/10194210/build.log error: File /builddir/build/SOURCES/nunc-stans-0.1.5.tar.bz2: No such file or directory Thanks, --noriko hmm, the srpm from http://koji.fedoraproject.org/koji/taskinfo?taskID=10194208 really doesn't contain the nunx-stans archive, looking further ... And I see it, you should never ever use %ifarch around the Source or Patch tags (or %if %{use_nunc_stans} in your case), they must be present all the times. But later in the spec you can skip unpacking it. The source rpm must be the same, not depending on the arch of the builder. (In reply to Dan Horák from comment #12) > And I see it, you should never ever use %ifarch around the Source or Patch > tags (or %if %{use_nunc_stans} in your case), they must be present all the > times. But what if we don't want to build nunc-stans at all, don't have the source, and don't care about the source? That is, if I don't want to build with nunc-stans, why should I care about making sure the source is available? If you are referring to an official Fedora packaging guideline, can you provide the link? > But later in the spec you can skip unpacking it. The source rpm must > be the same, not depending on the arch of the builder. See above. (In reply to Rich Megginson from comment #13) > (In reply to Dan Horák from comment #12) > > And I see it, you should never ever use %ifarch around the Source or Patch > > tags (or %if %{use_nunc_stans} in your case), they must be present all the > > times. > > But what if we don't want to build nunc-stans at all, don't have the source, > and don't care about the source? That is, if I don't want to build with > nunc-stans, why should I care about making sure the source is available? If > you are referring to an official Fedora packaging guideline, can you provide > the link? https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Conditionalizing_Builds_for_Architecture For Fedora a single source rpm is sent to build for all architecture, both primary and secondaries. And as we can see in the example in comment 10 I think the "build srpm" task is treated as noarch, because even when it was run on x86_64 builder it didn't include the nunc_stans source archive. > > But later in the spec you can skip unpacking it. The source rpm must > > be the same, not depending on the arch of the builder. > > See above. If it is allowed just including the nunc-stans tarball in srpm but not compiling it, may I do this? diff --git a/389-ds-base.spec b/389-ds-base.spec index 50bdc44..83677c2 100644 --- a/389-ds-base.spec +++ b/389-ds-base.spec @@ -19,9 +19,7 @@ %global use_nunc_stans 0 %endif -%if %{use_nunc_stans} %global nunc_stans_ver 0.1.5 -%endif # fedora 15 and later uses tmpfiles.d # otherwise, comment this out @@ -124,9 +122,7 @@ Source0: http://port389.org/binaries/%{name}-%{version}%{?prerel}.tar.b # 389-ds-git.sh should be used to generate the source tarball from git Source1: %{name}-git.sh Source2: %{name}-devel.README -%if %{use_nunc_stans} Source3: https://git.fedorahosted.org/cgit/nunc-stans.git/snapshot/nunc-stans-%{nunc_stans_ver}.tar -%endif %description 389 Directory Server is an LDAPv3 compliant server. The base package includes yes, that's the correct way, include all sources, but build only the appropriate ones (In reply to Dan Horák from comment #16) > yes, that's the correct way, include all sources, but build only the > appropriate ones Thank you for your help, Dan! I'm going to run the build from now... --noriko 389-ds-base-1.3.4.1-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.1-1.fc22 Package 389-ds-base-1.3.4.1-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing 389-ds-base-1.3.4.1-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-10664/389-ds-base-1.3.4.1-1.fc22 then log in and leave karma (feedback). 389-ds-base-1.3.4.3-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.3-1.fc22 Hello. I am the author of liblfds. On the 29th December 2015, release 7.0.0 was published. Arch is now set always to 'native'. The makefile appends to CFLAGS, which I think will still mean the appended values will be used rather than any existing values, so the 7.0.0 makefile does not solve the problem in this bug. It's not apparent to me what the usual behaviour is supposed to be. Should the makefile build its own CFLAGS and then append the existing CFLAGS? Could you let me know what changes you'd like to see, and I'll get them in the next release (which will be quite soon, unlike 7.0.0, which took basically six years). As an aside, perhaps of interest, 7.0.0 supports the Linux kernel. Oh - additionally - I will backport the makefile fixes to the earlier releases of liblfds. I did not mean to imply you should use 7.0.0. (In reply to liblfds-admin from comment #21) > Hello. > > I am the author of liblfds. > > On the 29th December 2015, release 7.0.0 was published. > > Arch is now set always to 'native'. > > The makefile appends to CFLAGS, which I think will still mean the appended > values will be used rather than any existing values, so the 7.0.0 makefile > does not solve the problem in this bug. > > It's not apparent to me what the usual behaviour is supposed to be. Should > the makefile build its own CFLAGS and then append the existing CFLAGS? > > Could you let me know what changes you'd like to see, and I'll get them in > the next release (which will be quite soon, unlike 7.0.0, which took > basically six years). > > As an aside, perhaps of interest, 7.0.0 supports the Linux kernel. Thank you for your update. I've opened a new bug for liblfds upgrade. Bug 1298679 - nunc-stans -- upgrading liblfds Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |