Synth: Introducing new custom package repository builder for FreeBSD and DragonFly

xtaz there's only one place where host /etc/make.conf is read, and that is where the jail's makeconf is being created. Some variables are cached so the tree scans faster, and by defining MAKE_JOBS_NUMBER it caused _SMP_CPUS variable to remain undefined, which eventually defined the make jobs. Obscure, but something I need to handle.
 
Last edited by a moderator:
Thanks for your help there marino@ much appreciated! I've been using FreeBSD for about 15 years, always with ports and world/kernel from source code. Packages and binary updates are new to me. It's clear that this is the way the project is going which is why I'm taking a good look at this nice looking software you've written as it looks like it could be good for transitioning. As a result I'm now looking into cleaning up my /etc/make.conf and switching to a GENERIC kernel with loaded kernel modules etc. so that I can try to embrace this new world. Starting with removing those lines from that file!
 
The MAKE_JOBS_NUMBER line is legitimate (and thus causing me to change synth) but in your case you don't need it because you are defining it to the default value of 4.
But this case revealed an issue so thanks for helping me discover and diagnose it.
 
marino@ said:
Crivens@ so you don't believe that over the course of 40 straight hours, I didn't try everything? :)
Click to expand...
When you work 40 hours in two days, I would belive that you tried everything coming to your mind - which will politely avoid to speak about the state of mind one is in after such a ride ;). Been there, done that, got the eyesore and when coming back after some days, wondered how in hades I had missed that obvious thing to do. No offense, I just stumbled over that.
 
I've just had a failure when building one of the packages. I can see from previous posts in this forum that you've been gradually fixing various ports which fail so I guess you are probably interested in this.

lang/python27 seems to do this:

Code: 
========================< phase : package  >========================
===>  Building package for python27-2.7.11_1
pkg-static: Unable to access file /construction/xports/lang/python27/work/stage/usr/local/lib/python2.7/lib-dynload/_ssl.so: No such file or directory
*** Error code 1

Stop.
make: stopped in /xports/lang/python27
===========================================================================

The /xports looks weird as that directory doesn't exist. My build directory is /usr/obj/synth-live
 
xtaz said:
I've just had a failure when building one of the packages. I can see from previous posts in this forum that you've been gradually fixing various ports which fail so I guess you are probably interested in this.
Click to expand...

I can't reproduce, not even with synth test command. Obviously lang/python27 is a popular port so if it didn't build we would have heard about it by now. Do you have a LiveSystem-make.conf defined? If so, what's in it?
 
It's definitely going to be something I've overridden again isn't it!

Code: 
$ cat LiveSystem-make.conf
DEFAULT_VERSIONS=apache=2.4 gcc=5 perl5=5.22 pgsql=9.5 php=5.6 python=2.7 python2=2.7 python3=3.5
OPTIONS_UNSET+=X11
WITH_BDB6_PERMITTED=yes
WITH_OPENSSL_PORT=yes
 
I'll let it finish the remaining package build and then I'll experiment with that file to see if I can get it to work. That option looks like a valid thing to use though from /usr/ports/Mk/bsd.openssl.mk. "WITH_OPENSSL_PORT=yes - Use the OpenSSL port, even if base is up to date"
 
It might very well be valid, but that doesn't mean there's not a bug in lang/python27. It's probably worth opening a PR against it. You can modify pkg-plist locally but it should be fixed everywhere.

My feeling is that there is a good chance that lang/python27 doesn't account for this and it needs to.
 
I'm not sure WITH_OPENSSL_PORT=yes is an issue. If it is, it's at least not universal as I use it for both 10-STABLE and 11-CURRENT with Synth without problems.
 
Put it this way, all of those entries in that file are identical to ones that I have been using for years in /etc/make.conf and lang/python27 has never had that issue with a standard port compile. But I will experiment with it later and try different things (including deleting the file) to see if I can get it to work. So watch this space.

Saying that... I've never tried to make package before.
 
That being said, I just tried it and like kpa says, python27 builds fine with ports openssl. It's something else.
 
marino@ said:
xtaz@ there's only one place where host /etc/make.conf is read, and that is where the jail's makeconf is being created. Some variables are cached so the tree scans faster, and by defining MAKE_JOBS_NUMBER it caused _SMP_CPUS variable to remain undefined, which eventually defined the make jobs. Obscure, but something I need to handle.
Click to expand...
Just wanted to let you know this solved my issue too -- I commented out MAKE_JOBS_NUMBER in my /etc/make.conf, and synth now works. Thanks!
 
Wapcaplet, great! When 1.00 is released you can re-enable that setting. I've fixed the problem permanently.
 
Last edited by a moderator:
xtaz said:
Saying that... I've never tried to make package before.
Click to expand...

Doing make package and make install on a port are almost identical. Both will check the pkg-plist for omitted entries after the build has finished and do other consistency checks. The only difference is that in the former the result is a package file made from the contents of the stage directory, in the latter the files are installed on the system from the stage directory and registered as an installed package.
 
I just finished my first run of synth upgrade-system, and it looks like the line WITH_OPENSSL_PORT=yes inside my /etc/make.conf was ignored.

After synth upgrade-system completed, I ran pkg autoremove, and security/openssl was offered for deletion. After deleting it, I went back and checked on my installed packages, and none of them depended on security/openssl anymore.

Does WITH_OPENSSL_PORT=yes need to be explicitly included in /usr/local/etc/synth/LiveSystem-make.conf for this to work? Right now I have no such file. As I understand it, <profile>-make.conf should be appended to /etc/make.conf and not replace it.
 
Yes. /etc/make.conf is not used by synth. Check the man page, FILES section, second entry, <profile>-make.conf
 
Last edited by a moderator:
marino@ said:
yes. /etc/make.conf is not used by synth. Check the man page, FILES section, second entry, <profile>-make.conf
Click to expand...
After rereading the man page, as I understand it, it looks like /etc/make.conf is pulled in only if <profile>-make.conf exists:

Code: 
This is an optional, user-provided file. If it exists, the builder's [file]/etc/make.conf[/file] will be appended with the contents of this file.
So /etc/make.conf is not included at all, even if <profile>-make.conf exists? I guess the word "appended" is confusing me.
 
Look at any build log, you'll see a make.conf. It's not yours, it's a standard one. <profile>-make.conf is appended to that. The host /etc/make.conf is not used at all, under any circumstance.
 
Last edited by a moderator:
Yes, the host's /etc/make.conf is not used in any way. This is intentional I assume because it often contains settings that can mess up the builder badly. Other package builders operate with the same principle and only allow make.conf(5) customization trough the dedicated customization files.
 
You must log in or register to reply here.
Back
Top