How to use ports-mgmt/synth

I have installed and tried to use synth, but I clearly have missed something. I basically installed and ran it, but something is broken.

1. I do portsnap fetch upgrade; synth upgrade-system, which rebuilds hundreds of ports. Two odd days later when that finally completes, I repeat it, and it rebuilds hundreds of ports again. Rinse and repeat. Surely this can't be correct, as my system will be doing nothing but upgrading this way. I must somehow be set to rebuild ports that don't need it.

2. It refuses to upgrade anything that depends on math/openblas. The reason it gives for refusing to build it is ' 00:04:12 math/openblas: has to be built manually: Optimizes for the build machine.' - a bogus error because the build machine is the machine it will run on, and the machine it should be optimized for. Building it manually with 'make clean build deinstall reinstall' goes fine, but synth still skips any ports that depend on openblas.

So I'm missing something. How does on use synth?
 
Don't use synth if you have less than eight cores. It's overkill. It is better you use ports-mgmt/poudriere
Hold on. I do not follow. You say to not use Synth if you < 8 cores, but then suggest to use Poudriere? This does not make sense.

math/openblas can't build with ports-mgmt/poudriere or synth. The only way is to build it with the port (or with ports-mgmt/portmaster).
If that is true then why do we have an openblas package on pkg.FreeBSD.org? I also just checked and it builds fine in Poudriere for me.

The reason it gives for refusing to build it is ' 00:04:12 math/openblas: has to be built manually: Optimizes for the build machine.'
Please look at the build log in /var/log/synth and make sure that the DYNAMIC_ARCH option is on.
 
t the build log in /var/log/synth and make sure that the DYNAMIC_ARCH option is on.

No, DYNAMIC_ARCH is not on, as It is not the default, and I am building for this system only, not many others - I don't need code for other processors, just this one. Is it really now impossible to build ports optimized for your system?
 
No, DYNAMIC_ARCH is not on, as It is not the default, and I am building for this system only, not many others - I don't need code for other processors, just this one. Is it really now impossible to build ports optimized for your system?
DYNAMIC_ARCH is the default on amd64 and i386.

No, it's not impossible. It's just math/openblas doing weird things. If you think it's bogus just comment the MANUAL_PACKAGE_BUILD line in /usr/ports/math/openblas/Makefile and see if it works.
 
DYNAMIC_ARCH is the default on amd64 and i386.

No, it's not impossible. It's just math/openblas doing weird things. If you think it's bogus just comment the MANUAL_PACKAGE_BUILD line in /usr/ports/math/openblas/Makefile and see if it works.
Interesting. Looking at the port, it isn't the default unless BATCH or PACKAGE_BUILDING is defined - so as I had built it normally, then the options was set without it.

I'll follow your instructions and nuke that line, and long term hope that portmaster is fixed soon so we can go back to normal.
 
I have installed and tried to use synth, but I clearly have missed something. I basically installed and ran it, but something is broken.

1. I do portsnap fetch upgrade; synth upgrade-system, which rebuilds hundreds of ports. Two odd days later when that finally completes, I repeat it, and it rebuilds hundreds of ports again. Rinse and repeat. Surely this can't be correct, as my system will be doing nothing but upgrading this way. I must somehow be set to rebuild ports that don't need it.

If it takes your machine two days to build hundreds of ports, then by that time the ports tree will have been updated a few times. Key dependency ports could have changed and will trigger rebuilding of lots of ports. With respect to #1, it sounds like your Synth is actually working. I get the same behavior on an old machine that runs
ports/x11/gnome3
. I do updates on that machine every couple months versus daily. (And actually now I use another machine to do the building for it.) Is your machine configured for quarterly or live packages? pkg -vv will tell you that. Using "live packages" packages will result in more building because you are using daily tree updates instead of quarterly.
 
I am running -current so I can test ports as I need to, and, of course, I follow HEAD. A quarterly ports tree would leave me criminally out of date most of the time.
 
Aaahh. If you are testing ports consider trying to buy more capable hardware. I bought an old Dell 1950 with dual Harpertown processors and 8GB of ram for cheap, its a pig on electricity, but with a FreeBSD bare metal install, Synth flies through building. It can do hundreds of ports in about 4 to 6 hours. I have Synth configure to use devel/ccache, and: number of builders (4), number of jobs (3), and fetch pre-built packages - YES.
 
It can do hundreds of ports in about 4 to 6 hours.
You don't really need any beefy machine for that, my "lowly" Core i5 server does 600+ packages in about 6 hours. And I don't even use CCache. I do have a nice, fast, LSI controller in that machine. Most of the "slowness" of building tends to come from I/O starvation. Building packages is really I/O intensive, especially if you have a lot of build queues running at the same time.
 
I have installed and tried to use synth, but I clearly have missed something. I basically installed and ran it, but something is broken.

1. I do portsnap fetch upgrade; synth upgrade-system, which rebuilds hundreds of ports. Two odd days later when that finally completes, I repeat it, and it rebuilds hundreds of ports again. Rinse and repeat. Surely this can't be correct, as my system will be doing nothing but upgrading this way. I must somehow be set to rebuild ports that don't need it.
I personally split my list of ports up into a couple sections so that I'm not stuck waiting for all of them to finish before I can use them. I have a list of just my base most important ports another for the ones I always install and a third for the ones that I'm testing out.

You can split them into a larger number of lists if you like and then just build them. Don't update your ports tree in the middle, just update it right before you start the whole process.

I also often use just-build to build repository and don't bother installing until all of the ports I'm interested in are done, but that's not really necessary as the dependencies should be handled as long as you're not updating the ports in the middle.
 
Ah, I think I see the issue. Many ports are showing up with ' failed dependency check', and others (mostly py-something ports) with ' Installed package ignored, xx/yyy package unmatched'. What these error messages mean, and how to fix them, seems to be information that doesn't exist anywhere - searching for them leads to no results.

It is probably because the ports are still pointing to deleted flavorless python ports - an issue I'd normally have solved quickly and without fuss using portmaster -o. Does anyone know how I can fix this without portmaster?

Edit: It seems that they aren't causing the problem - but errors are still there - package unmatched is - and there does not seem to be a way to resolve it. We also need a way to skip rebuilding ports whose dependencies change but haven't had a version change. Most run dependency changes do not require a rebuild of the child port!
 
It is probably because the ports are still pointing to deleted flavorless python ports...

I believe that's been rectified. A new version of ports-mgmt/portmaster that can utilize flavors was released yesterday. I rebuilt one of my boxen overnight and used it to build all the ports I normally use without any problems.
 
Back
Top