Project

General

Profile

Building from a master/nightly branch (best practice)

ryry - about 2 years ago -

I am quite keen to build the latest Dino (xmpp client) from master, given that it now supports voice and video calls, but has not yet quite reached a release yet.
I was wondering firstly, I have check the dependencies are all already in parabola repos, but what I am unsure of is, can anybody confirm there is no reason for me to not build it now regarding any additions or changes that would make dino no longer compatible with a non-free distro. As far as I can see, there is nothing, but would like a second opinion if possible?

Secondly, when building from a master or nightly where there is no checksum, what is considered the best practice to ensure that your building with security and integrity in mind? I know that Skip is a function for this, but I always feel a bit nervous of just skipping.

Any help as always is much appreciated.

Ryry


Replies (5)

Building from a master/nighlty branch (best practice) - bill-auger - about 2 years ago -

i dont quite understand the first question - if you are compiling
something for use on a parabola system, then it is of no concern,
whether or not that same build will run on a non-free distro (or
any other distro) - if you wanted to run that program on
another distro, you should compile it again, specifically for
that distro - it is generally a bad idea, to use packages that
were intended for another distro - unless i misunderstood the
question (or unless the other distro is arch) the best
practice is: "just dont do that"

the second question is easy to answer - when pulling the source
code from VCS (eg: git+https://), you can put 'SKIP' for the
checksum - the VCS system maintains the integrity of its files

the "best practice" though, is to not build anything from VCS
sources, but use a stable versioned release, if one exists - this
is essentially asking for the best practice, regarding a
(generally) bad practice

frankly, if the developers did not give their software a versioned
release, that software should be considered "experimental"; and
only brave people should use it (eg: people wanting to help improve
it, to a state where it is release-worthy, and recommendable for
regular use) - if the developers did give their software a versioned
release, still, the un-versioned VCS sources should be considered
just as "experimental", and not intended for normal use

RE: Building from a master/nightly branch (best practice) - ryry - about 2 years ago -

Thanks for your response bill-auger

With regards the first part, I don't think I explained myself very well. What I should have said was. Given that there are some packages that start off completely libre and FSDG compliant, but then some ways down the line become non-free or their dependencies. Such as Jami/Jami-qt and others. I was just checking that Dino had not fallen to something of a similar fate, so that I would still be building from a source that was completely libre/free. I have no reason to believe that it is not, but with big changes, I thought I'd check.

Anyhow the second answer makes that moot anyhow as I will refrain from building from non stable source releases etc.

Once again many thanks

Ryry

RE: Building from a master/nightly branch (best practice) - ryry - about 2 years ago -

Further to my original post, I waited for the official Dino release and have used asp to pull the last PKGBUILD that arch used for the previous Dino package we use and changed only the version number and added all the new dependencies, which are all in parabola repos. However, I couldn't find a checksum so I manually downloaded the release tar and asc verfied using gpg --verify and sha256sum the release and put the checksum in the PKGBUILD.
I asked on the Dino chat about if the checksum would be on the website somewhere, but was suggested that the signing key in the PKGBUILD would provide both integrity and security checks, so left this unchanged in the PKGBUILD and built and this worked fine.
So before I install new said package, given that the Dino release key in the PKGBUILD is unchanged and the same used by arch in previous releases can be assured that I have built the package securely and this was the right thing to do? Sorry to ask again, but this is my second ever build and I like to be sure.

Many Thanks
Ryry

RE: Building from a master/nightly branch (best practice) - bill-auger - almost 2 years ago -

sry i did not respond sooner - i understand your questions better now

the only way to know if the source code has become non-free is by watching the files and licenses for changes - there is no simply way, but it is very unlikely to happen - in the case of non-free dependencies, that is easier to detect; because the package would not build, or the program would not start

normally, the upstream developers do not give checksums - only rarely do they give signatures - the checksums in the PKGBUILD are put there by the person who wrote the PKGBUILD, an arch team member in this case - makepkg will verify the checksums and signature automatically

generally, if you want to upgrade a package (such as dino) which is available in parabola (any version), and it is in the [core], [extra] or [community] repos (dino is in community), then you can run `makepkg -g` on the arch PKGBUILD, after changing only the pkgver (usually) - that will print the new checksums for you to replace in the PKGBUILD - then `makepkg -sri` will build and install the package

that is usually not necessary because the arch packager will upgrade it very soon anyways - to build a "nightly" or VCS version, the process is somewhat more complicated - that is usually not necessary either - it is almost always best to simply wait for a new proper release

RE: Building from a master/nightly branch (best practice) - ryry - almost 2 years ago -

Thanks for this, that give me some good long term advice, as you say mostly it isn't needed as most packages are updated soon after releases etc anyhow.

ry

    (1-5/5)