Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)
@nim-nim OTOH, note that builds on a public branch (i.e. no authorization), downloaded through https/ssh (so small chance of maliciously modified), on a tagged/documented check-in located in an upstream VCS repository, are entirely maintainable, as well as being consistent with RPM's goals of "reproducible builds". Overloading %setup/%patch convolutes a reproducible build with obscure rpm macro configuration. In fact, many slow-releasing upstream projects are already released through snapshot tar balls as above. The only difference with existing practice in packaging is through conventions in NVR naming to indicate a pre-release, and the tyranny of manually moving, say, a specific checkin forward by editing a maven-like SourceN: URL (as opposed to preparing a pre-release tarball, which can certainly be done already to simplify rpm packaging using %setup without overloading). But perhaps I misunderstand the goals described here: [https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation](url) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/368#issuecomment-350579988___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)
Thank you for the additional info! I will look at it. I'm not overly interested in building directly from VCS since that's security hell (both from the auth POW and the protocol filtering POW). Supporting building from github/gitlab/whatever https auto-tarballs is good enough for me. In fact it's already way too powerful, as the downside of working at commit granularity is no one properly checks each commit and code explodes right and left as stuff it depends on moves in uncontrolled way. I'll take a release, or even a tag, any day over a commit, let alone a commit not from the main branch. VCS have not make release engineering obsolete, they've just helped devs run away from consequences faster. But someone still needs to deploy in the end and that someone takes all the accumulated technical debt in the figure at once. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/368#issuecomment-350579032___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)
Finally -- overloading %setup like above is a hackers pathway away from reproducible builds into insanity. JMNSHO ... (aside) The real problem -- never well supported, but entirely achievable -- is How to build from a VCS checkout (not a tarball) with minimal hassle? This requires additional paraders like URL, authentication, repository name, branch, and checkout identifier (to name just a few of the additional parameters required). All of the above additional parameters can be mapped into a SourceN: URL ... see what Maven does. Parsing the URL and writing the script that does, say git clone or git pull would be _FAR_ more useful than overloading %setup. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/368#issuecomment-350567149___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)
The example is
%define setup() %%setup %{?_setup_args}
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/368#issuecomment-350566269___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)
Read about parametrized macros in rpm installed docs (used to be /usr/share/doc/rpm-X.Y/macros, perhaps still is). Basically a parameterized macro will parse all options/arguments to EOL into she'll-like transient macro names. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/368#issuecomment-350565696___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)
That works, thanks, I didn't know about this syntax before !
`rpm.define("setup %%setup %{?setupargs}")`
I don't understand 'use a parameterized macro if necessary to eat existing
arguments/options' however. Can you provide a simple example?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/368#issuecomment-350557027___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Allow automating %setup arguments (#368)
@nim-nim: you can likely already do this, provided you have some means to
overload %setup before the invocation in the spec file.
Macros are expanded before %setup is processed. So a definition like
%define setup %%setup -c -n whatever
will append (actually interpose, but you can use a parameterized macro if
necessary to eat existing arguments/options).
You can also load the definition from macro configuration, and add
%{?_setup_args} if that floats your boat.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/368#issuecomment-350554474___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] Building rpm-4.14.0
If this is the wrong list point me to the correct list. I am having trouble building rpm-4.14.0. when configuring for the build configure does not create db.h so when running make if fails any one have a solution? ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Missing build id, Generating build-id links failed (#367)
On Sun, Dec 10, 2017 at 09:34:25AM +0100, Tzafrir Cohen wrote: > On Fri, Dec 08, 2017 at 12:35:44AM +0100, Mark Wielaard wrote: > > At least the Fedora go toolchain should be able to generate proper > > build-ids these days. > > If not, see these (old) notes: > > https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID > > So is the official answer to use gccgo? I don't know if that is an official answer, but gccgo certainly produces more conforming ELF objects. > I recently ran into this issue and found no good answer. I ended up > using the following Makefile snippet: > > BUILD_ID=$(shell head -c20 /dev/urandom|od -An -tx1|tr -d ' \n') > BUILD_ID_OPT=-B 0x$(BUILD_ID) > BUILD_ARGS=-ldflags "-X main.version=$(VERSION) -X main.commit=$(COMMIT) -X > main.buildtime=$(BUILD_TIME) $(BUILD_ID_OPT)" > > (Yes, not a reproducible build if I use buildtime, but useful so far) I believe that is what Fedora also uses. Or a variant that is reproducible. You can also of course undefine the _missing_build_ids_terminate_build macro in your spec file to work around such toolchain issues. Cheers, Mark ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Missing build id, Generating build-id links failed (#367)
On Fri, Dec 08, 2017 at 12:35:44AM +0100, Mark Wielaard wrote: > Hi Eli, > > On Thu, Dec 07, 2017 at 03:20:01PM -0800, Eli Uriegas wrote: > > ``` > > error: Missing build-id in > > /root/rpmbuild/BUILDROOT/docker-ce-17.12.0.ce-0.1.rc1.fc27.x86_64/usr/bin/docker-containerd-shim > > error: Generating build-id links failed > > Missing build-id in > > /root/rpmbuild/BUILDROOT/docker-ce-17.12.0.ce-0.1.rc1.fc27.x86_64/usr/bin/docker-containerd-shim > > Generating build-id links failed > > ``` > > That probably means the compiler/linker of that binary didn't generate a > proper > build-id for that binary. The golang toolchain didn't in the past. > > > I believe it may have something to do with this commit: > > https://github.com/rpm-software-management/rpm/commit/5e82c7e8a8fc05195cdf622d0a120b9e70a9371b > > Why do you believe that? That commit should only fix issues for noarch > packages. > Real binaries must have build-ids. > > At least the Fedora go toolchain should be able to generate proper build-ids > these days. > If not, see these (old) notes: > https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID So is the official answer to use gccgo? I recently ran into this issue and found no good answer. I ended up using the following Makefile snippet: BUILD_ID=$(shell head -c20 /dev/urandom|od -An -tx1|tr -d ' \n') BUILD_ID_OPT=-B 0x$(BUILD_ID) BUILD_ARGS=-ldflags "-X main.version=$(VERSION) -X main.commit=$(COMMIT) -X main.buildtime=$(BUILD_TIME) $(BUILD_ID_OPT)" (Yes, not a reproducible build if I use buildtime, but useful so far) -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
