Hi @all,

As I recently started to contribute some small work into joyent-pkgsrc
repository, I would like to clarify few open cases to establish how to prepare
"perfect" (or at the very least: recommended) environment for building packages.
First of all, there's a pkgbuild image that can be easily found via imgadm

imgadm update ; imgadm avail | grep pkgbuild

The way I understand it, one should pick the version against which package
will be build. For example, should you want to target 2015Q4 (to provide some
package for 15.4.1 LTS images), one should pick 15.4.1 pkgbuild and should you
target 2016Q2 (or trunk) you should grab latest one available (at current moment
it would be 16.2.0).
There are few places that cover preparation of the environment on the pkgbuild -
some are on Joyent's images documentation, some are on GitHub, some are on
Joyent's pkgsrc documentation and some bits are available only on some Gist. The

 * https://github.com/joyent/pkgbuild/
 * https://pkgsrc.joyent.com/
 * https://gist.github.com/drscream/c45419950d8af648e2c6

The last is there as I want to sign packages I'm building and it's the only
place that explains how to add your key to be recognized by SmartOS and to allow
me to install self-built stuff. (It doesn't work BTW., but I will get back to it

I tried to combine all of these sources and still failed to get it right in my
first two attempts (even though Jonathan picked the PR I made on GitHub, he had
to introduce quite a few changes in order to push them further upstream -- thank
you BTW. also for the awesome help in the IRC channel). For one thing  -- I
always failed to properly add my public key to the pkgsrc keyring, like so:

gpg --primary-keyring /opt/local/etc/gnupg/pkgsrc.gpg --import

Command itself is not complaining, but pkg_install is still complaining when
trying to install package built and signed with my GPG key :/
Secondly, I never used to run-sandbox, which is necessary for proper chroot
build environment (or at least that's how I understand it) -- simply because I
missed it on pkgsrc.joyent.com and docs.joyent.com (noticed it later on on

OK, enough. I would now like to clarify what is step-by-step to get this whole
environment right -- with proper GPG signing, proper sandboxing etc. etc.

1. Spawn new zone based on the pkgbuild image (for example
4183fce6-49b2-11e6-a1ca-4f007e77f9d5 for 16.2.0).
   a) First question: which user should I use to build packages? There's default
   admin user with 'sudo' superpowers, there's also pbulk user described as
   Package Builder (but, by default, the dude has no home [directory]), but the
   code checkout under /data is owned by root... So, admin? pbulk? root?
2. The way I understand it, ordinary fellow like me should not push stuff
   directly to joyent-pkgsrc. Preferred way here is definitely to fork the repo
   on GH, provide keys to clone it onto your pkgbuild zone to the user that will
   be handling the builds (look it up above in point 1a) in place of the
   existing /data/pkgsrc. If you plan to maintain this repo for some time it
   might not be a terrible idea to add joyent-pkgsrc as a upstream source to
   sync it every now and then.
3. User is picked, keys are in place, code has been forked & cloned. There's no
   gcc installed by default, so I will now follow instructions for Building
   Packages from pkgsrc.joyent.com.
   a) pkgin -y in gcc49 gnupg2
   b) checkout the branch you want to build against (unless it's the default
   trunk), for example joyent/release/2016Q2.
   c) directory structure is mostly already provided under /data. Difference I
   can already see is that default /opt/local/etc/mk.conf file is now having an
   include to the /opt/local/etc/mk.conf.local where all custom changes should
   d) put GPG & GPG_SIGN_AS into /opt/local/etc/pkg_install.conf and import your
   private and public GPG keys to the user that will be building packages (1a).
   e) setup gpg-agent accordingly (.bashrc config, .gnupg/gpg.conf and
   .gnupg/gpg-agent.conf files involved).
   f) Add your public key to the pkgsrc keyring (even though the command is not
   complaining, when running bmake install it fails to recognize my signature).
4. Once that's done, from the user picked for packages building (1a), issue
   run-sandbox 2016Q2 where 2016Q2 matches the pkgbuild image version, branch
   version that you checked out and your idea against which code version you
   want to build package against.
5. Afterwards, the rest should be quite straight-forward -- pick a package and
   run bmake package to check whether all is fine. What should happen:
   a) all the dependencies for building a package should be fetched and
   b) package should be built.
   c) package should be signed with your private key.
   d) on installation attempt it shouldn't fail with not being able to find a
   signature etc.).

In theory exiting the sandbox should clean everything up (or are there any
manual steps necessary like bmake clean clean-depends for example?). Once you
make any changes to the package you want to build (like bumping up the version),
you need to run bmake mdi to regenerate distinfo and it might be necessary to
run bmake print-PLIST > PLIST (if there are new files in the new upstream
released package). This and more (like patching) is already quite nicely
explained on pkgsrc.joyent.com.

I'm really hoping to clarify couple of the things I mentioned above to have
better overview what is the preferred way of providing the packages against
joyent-pkgsrc. Is there any linting mechanism I should also use?

With best wishes
 - Filip

Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
Powered by Listbox: http://www.listbox.com

Reply via email to