Synth v1.00 has been released

I'm not sure if it's a bug ... but synth show theses errors for a "pseudo-package" like graphics/ImageMagick-nox11 (ImageMagick without x11). Synth seems to ignore all the options from parent port

Code: 
ImageMagick-nox11-6.9.2.10,1.txz has less options than required (31)
ImageMagick-nox11-6.9.2.10,1.txz failed option check.
 
You're reaching the wrong conclusion based on the error messages. There error is saying that the port (ImageMagic-nox11) has 31 options listed and the existing package (of ImageMagic-nox11) lists less than 31.

This happens commonly when the port itself has a bug in it. It requires careful inspection of the port to determine which option is bad (often the port maintainer tries to get clever with dynamically adding options based on what's on the host system and synth hates that. it's also wrong. those types of things need to be fixed)
 
marcpearsonti@
First, this is not a drastic issue. The impact of doing nothing is that the port rebuilds every single time. If you run synth weekly, it's just building that port usually unnecessarily. So in the end, it's not really a big deal.

secondly: you can report the issue on bugzilla and CC me. Then maybe I can look or the maintainer can look. Or when I find the problem, the maintainer will be informed. I have not looked yet, but I fully expect it will not be difficult to find the culprit (even though there are 31 options which kind of sounds like a nightmare)
 
marino@ said:
I don't think it will work. The port itself is broken with regard to the number of options. The value of the options is not the problem.
Click to expand...

I'm not a ports professionnal, but i think it's related to how graphics/ImageMagick and graphics/ImageMagick-nox11 share port options. ImageMagick-nox11 unset 3 options from ImageMagick parent port. In the end, the package built by synth have 28 options (pkg info reports 28 options) missing the 3 ones unset by ImageMagick-nox11 so the count doesn't match.

I hope this info we help a little bit !
 
that's not it. that's a very common thing to do. just the fact that ImageMagick-nox11 is slave port is not significant.
 
Now a other question...

Since a few days synth always finish with this error

Code: 
/usr/sbin/chroot /usr/obj/synth-live/SL09 /usr/local/sbin/pkg-static repo /packages => failed (exit code not 0)

and /var/synth/live_packages/ missing the meta, digest and packagesite.

I need to run the pkg-static command manually to rebuild my repository

I don't know how to debug this situation, nothing found in synth's logs files about the rebuild-repository phase
 
marcpearsonti said:
I don't know how to debug this situation, nothing found in synth's logs files about the rebuild-repository phase
Click to expand...

Synth 1.02 had a regression where some failed commands didn't announce. It's possible that an earlier failure is manifesting here. What's in the github repo now fixes the regression but it's not been released yet.

Summary: I don't know what could be causing it, but we need to try again with the next release to see if we get more information.
 
Here another one:

Code: 
databases/rrdtool package has more dependencies than the port requires (8)
Query: textproc/libxml2:libxml2-2.9.3
x11-toolkits/pango:pango-1.36.8_2
lang/perl5.20:perl5-5.20.3_8
x11-fonts/dejavu:dejavu-2.35
graphics/cairo:cairo-1.14.6,2
graphics/png:png-1.6.20
print/freetype2:freetype2-2.6.2
devel/glib20:glib-2.44.1_3
devel/gettext-runtime:gettext-runtime-0.19.6

Tripped on: gettext-runtime-0.19.6.txz:devel/gettext-runtime
rrdtool-1.4.8_9.txz failed dependency check.

What's mean «Tripped on» ?
How to correct this?
 
rrdtool has already been fixed, but was not backported to Q1.
I almost wouldn't recommend Synth until Q2 for this reason (rrdtool isn't the only one that was fixed in head only)
 
marcpearsonti said:
NO and FYI i'm running FreeBSD 9.3 release amd64 with ports from 2016Q1 branch
Click to expand...
So the early possibilities are:
  • it's already been fixed in ports HEAD (iow it's a Q1-only problem)
  • It's a FreeBSD-specific issue (normally related to base libraries)
I'd guess the first one.
 
Snow is all gone. :(

Any idea what would cause this? This is in version 0.99. I'll try to get it updated soon, but I'm curious as to what would cause this:

Code: 
# synth rebuild-repository
Scanning entire ports tree.
Scanning existing packages. 
Failed to install pkg-static in builder 9
Failed to rebuild repository  (Synth must exit)

Code: 
# synth status
Querying system about current package installations.
Stand by, comparing installed packages against the ports tree.
Failed to install pkg(8) scanner  (Synth must exit)
Unfortunately, the system upgrade failed.
 
The next release might show the error better but it's failing on running this command in chroot:
/usr/bin/tar -xf /packages/Latest/pkg.txz -C / */pkg-static

maybe there's a problem with pkg.txz and it might be fixed by deleting it (so it will be rebuilt). Just a wild guess because there's not much that could go wrong with a tar extract command.
 
Hi marino@

I always use synth this way

1. synth status
2. synth prepare-system
3. pkg upgrade -r Synth

When dependencies change, synth status will report all ports who needs to be rebuild

But when i run the step 3, only some packages (2 of 25) are upgraded

Why synth needs to rebuild ports if at the end they will not be reinstall ?
I was thinking all the rebuilt ports will be reinstall to fix broken dependency ?

I'm not sure i understand how dependencies are working ...
 
marcpearsonti said:
Hi marino@

I always use synth this way

1. synth status
2. synth prepare-system
3. pkg upgrade -r Synth

When dependencies change, synth status will report all ports who needs to be rebuild

But when i run the step 3, only some packages (2 of 25) are upgraded

Why synth needs to rebuild ports if at the end they will not be reinstall ?
I was thinking all the rebuilt ports will be reinstall to fix broken dependency ?

I'm not sure i understand how dependencies are working ...
Click to expand...

It's because nothing will tell you or the build tools if the rebuild of the dependent ports really would result in updated packages or not and which one would change. Packages that did not change in pkg's eyes will not be updated even if the package builder rebuilt them. It would be of course nice to have a crystal ball that could tell you if it is necessary the to rebuild all the dependents of a changed port but so far no one has come up with one.
 
well, i definitely know an algorithm that would greatly reduce rebuilds [1] but what isn't know is if something will subtlely break.

[1] example: lang/python is bumped. If you run poudriere/synth it will remove python and then around 10,000 ports will fail dependency checks in a recursive cascade. If synth detected that and rebuilt python in a single port run, then the cascade would be avoided. But who is to say that won't cause problems? It's also complex to determine all these single port runs before "real" bulk run. very complex, i guess so far considered too risky and too much trouble.
 
@marino Thank a lot for the great tool and explanation what and why it does. I used to have mysterious crashes after running portmaster. These days I use synth exclusively and crashes don't happen anymore. I tried to use poudriere and it was just too much and slow-ish for my simple needs (home desktop).

BTW what is a good size for ccache cache? I set max size at 12GB and currently the size is 7.4. Is it a good idea to clean the cache from time to time?
 
tankist02 said:
BTW what is a good size for ccache cache? I set max size at 12GB and currently the size is 7.4. Is it a good idea to clean the cache from time to time?
Click to expand...
No, that's not a good idea. It's self-cleaning. In normal cases, you don't need to touch it at all.
I just set my max to 20G or 25G because
  • i build a lot of stuff, probably more than most
  • it doesn't use that space unless it needs to
  • diskspace is cheap
I would think 12G is sufficient for most people though.
 
You must log in or register to reply here.
Back
Top