i686 architecture patching in 'common-functions'

andreas_baumann · 2017-08-27 07:17:14

When building autoconf (which is arch 'any') I experienced a problem: makepkg always
told me something about 'not being available on x86_64'. I'm using a forked
builder on http://github.com/andreasbaumann/builder in a standalone script
called 'test-build-package' (which is basically lumping together things from
'build-packages' without all the master/slave things of the build system).

I patched 'append_architectures' in the following way, not to add the architecture
for 'any' packages:

# append_architectures $PKGBUILD
#  mangle $arch in PKBUILDs to contain i486, i586, i686

append_architectures() {
  local PKGBUILD="$1"
  sed -i '/^arch=.*any/!{/^arch=(/s/(/(i686 /}' "${PKGBUILD}"
}

Comments? :-)

deep42thought · 2017-08-28 05:45:32

Hi,

first let me thank you for the contributions you made :-)

second: Sry, I can't reproduce your error: your regex works fine and also your script looks ok - besides the sed-hack (from an aesthetical point). Also complaint about x86_64 seems wrong - are you sure you're building in a 32-bit environment? Maybe it's from the first makepkg invocation?

third: What do you think of the idea to include your test-build-package script into the builder repository, so everyone can use it?

Cheers,
deep42thought

andreas_baumann · 2017-08-28 07:38:25

Hi,

No problem for doing a little bit of packaging.

I'm still trying to understand the builder, so the test-build-package script is pure copy-paste code.
Sure I can make a pull request after cleaning up a little bit.

I'll test again the architeture issue, I have a clue that one of the first makepkg invocations
happens on the host and not in the 32-bit chroot..

..and sed is never aesthetical, in my point of view. :-)

Greetings

Andreas

deep42thought · 2017-08-28 11:50:53

What do you think of the idea to add an option to "build-packages" to build exactly the given package and not report it to the build master?
This would reduce code duplicates.

Btw: I noticed the gpg-key issue, too (If I understand you correctly, this is the reason why you run "makepkg -S" before running staging-i686-build). But it always went away after some while, so I was unable to debug it :-/ The best choice should be to remove this issue and simply run "staging-i686-build" on a hand-crafted PKGBUILD, I think.

andreas_baumann · 2017-08-28 12:26:39

I agree, having an option to build-packages for a single-run-test-mode is the best way to go.
I can try to do that. An alternative would be to make more functions..

deep42thought · 2017-08-28 13:44:39

I implemented a '-l' option (and a -u option to enforce uploads regardless - this is something which I needed for some time to remove stale lock files on the build master).
I also took your idea to only add i686 if it's not an any-package (current builds were all $pkgname-$pkgver-$pkgrel-i686.pkg.tar.xz). Let me know if you miss something - just open an issue or a pull request.

andreas_baumann · 2017-08-29 19:01:54

Yeah. Nice. :-)

So I can build and test packages with build-packages:

./build-packages -l which.fe6d45dd22ee25e70164dd3bb84541968ba6813e.4120aefd67048ed2e5bce7caf43e83d88a8165f1.core

I still have trouble with PGP keys everywhere like:

gpg: skipped "0x15eebadc0de": Invalid user ID
gpg: signing failed: Invalid user ID

but I have to sort aout my local PGP mess..

Maybe a './build-packages which.HEAD.HEAD.core' would also be usefull using the current git versions of packages/community resp. packages32?

HEAD would do a 'git rev-parse HEAD' or 'git stash create' to get the current revision. The git stash has the benefit that you
don't have to check in the packages32 directory while still working on the package.

git_revision=$(cd ${repo_path}; git rev-parse HEAD)

mod_git_revision=$(cd ${repo_paths__archlinux32}; git stash create)
if [ -z $mod_git_revision ]; then
        mod_git_revision=$(cd ${repo_paths__archlinux32}; git rev-parse HEAD)
fi

Last edited by andreas_baumann (2017-08-29 19:04:24)

deep42thought · 2017-08-29 19:24:14

I found the source of your gpg-problem: You need to set the variable "package_key" in conf/local.conf to your gpg-key identity (have a look at conf/default.conf).

I will think a little about the HEAD-idea before actually starting to implement it.

andreas_baumann · 2017-08-29 19:28:05

A thanks.

I'll have a little hack in my fork testing the HEAD idea too in build-package..

deep42thought · 2017-08-29 20:01:52

Two thoughts about the HEAD-idea:
1st: "HEAD" is already a valid qualifier (which specifies not what you want) - I'd prefer something else, like "work-tree" (which might be a valid commit in git, too, but this is really unlikely - especially given the use case).
2nd: I'd prefer not creating a stash, because then you'd need to remove the stash later on - "git write-tree" writes the current index into a git-tree which can be accessed via its hash (have a look at bin/strict-bashism-check) - for this to work, one needs to add the files to the index first (ideally without messing it up): This seems to be exactly what we want.
And one additional hint: Check out git's "-C" option (also in heavy use in the build master scripts).

deep42thought · 2017-09-01 10:39:14

You can now use 'work-tree' as a pseudo-revision for the modification repository like so:

bin/build-packages -l pcsxr.922f9c6f11ae9cb2b42ff805fb6362c6163b4739.work-tree.multilib

Btw, I was wrong regarding "HEAD": It is a valid git qualifier, but you can't use it as a revision for the upstream package-repository, because the given qualifier is used to determine if the package is from community or packages.
Unfortunately I don't see how to determine this by other means, because some packages are in community and packages (e.g. cmucl, ddd, fbida, nedit).

Arch Linux

#1 2017-08-27 07:17:14

i686 architecture patching in 'common-functions'

#2 2017-08-28 05:45:32

Re: i686 architecture patching in 'common-functions'

#3 2017-08-28 07:38:25

Re: i686 architecture patching in 'common-functions'

#4 2017-08-28 11:50:53

Re: i686 architecture patching in 'common-functions'

#5 2017-08-28 12:26:39

Re: i686 architecture patching in 'common-functions'

#6 2017-08-28 13:44:39

Re: i686 architecture patching in 'common-functions'

#7 2017-08-29 19:01:54

Re: i686 architecture patching in 'common-functions'

#8 2017-08-29 19:24:14

Re: i686 architecture patching in 'common-functions'

#9 2017-08-29 19:28:05

Re: i686 architecture patching in 'common-functions'

#10 2017-08-29 20:01:52

Re: i686 architecture patching in 'common-functions'

#11 2017-09-01 10:39:14

Re: i686 architecture patching in 'common-functions'

Board footer