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

Okay, my first build attempt was gcc6-aux on poudriere in Release 10.2 jail. It built fine.
I suspect this is a CURRENT regression. Just for fun, I'll try on synth on FreeBSD 10.2 release system, and I expect it to succeed.
 
By they way, ports builders already have gcc6-aux-20160124 on 9.3 and 10.2, both amd64 and i386 platforms.
 
Last edited by a moderator:
gcc6-aux builds fine in synth on 10.2-amd64 system as well.
This looks like a FreeBSD-CURRENT regression. If it's old, maybe it's time to update the system (the regression may have been fixed since the last update)
 
No, I still can't.
Code:
This webpage is not available


DNS_PROBE_FINISHED_NXDOMAIN
...Not sure why the site is being blocked however we try to discourage people from posting long logs directly to posts here as not to clutter up threads. I'll send you a PM with the log contents to read since your accessing the forums fine.
 
I could read the attachment, I've already seen it.
I just can't reproduce the error on releases.
The only recent "CURRENT" have I is the latest i386 version and that's a couple of days older than what you are showing.
 
Last edited by a moderator:
No, I still can't.
Code:
This webpage is not available


DNS_PROBE_FINISHED_NXDOMAIN
FWIW this is what I get:
Code:
drill pastebin.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 8889
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4
;; QUESTION SECTION:
;; pastebin.com.  IN  A

;; ANSWER SECTION:
pastebin.com.  300  IN  A  104.20.63.56
pastebin.com.  300  IN  A  104.20.64.56

;; AUTHORITY SECTION:
pastebin.com.  112119  IN  NS  todd.ns.cloudflare.com.
pastebin.com.  112119  IN  NS  sue.ns.cloudflare.com.

;; ADDITIONAL SECTION:
sue.ns.cloudflare.com.  112119  IN  A  173.245.58.145
todd.ns.cloudflare.com. 31240  IN  A  173.245.59.146
sue.ns.cloudflare.com.  112119  IN  AAAA  2400:cb00:2049:1::adf5:3a91
todd.ns.cloudflare.com. 31240  IN  AAAA  2400:cb00:2049:1::adf5:3b92
 
Ok. I haven't tried on 10.2-STABLE or 10.2-RELEASE yet so I'll take your word it builds fine. Since this is an issue with CURRENT, not sure where to go from here other than the mailing lists.
 
Ok. I haven't tried on 10.2-STABLE or 10.2-RELEASE yet so I'll take your word it builds fine. Since this is an issue with CURRENT, not sure where to go from here other than the mailing lists.
Maybe monitor portsmon -- it must try to build gcc6-aux on CURRENT very soon. And I'll get fallout logs mailed to me if they fail. And if they succeed? Then I'd guess the jail is older than what you have, prior to the regression. Either way that's useful information.
 
Note that synth is not really different to anything else there in this regard, if an important and widely used port has a new version there is absolutely no way to avoid rebuilding everything that depends on that port directly or indirectly. There was lot of discussion about that with Poudriere and initially Poudriere tried to avoid rebuilding everything but that resulted in broken builds because of subtle changes at binary level that can not be detected automatically.

Any time saved, is time saved. :)

But now I gotta ask: By using the [N] option do I run the risk of a messed up system because synth rebuilt/compiled some ports, but for other just straight downloaded the package?

And if the answer is "yes" then this is not really caused by synth but simply by packages not being updated as often as ports right? In other words no different then me manually using port build for some and packages for others. (Which is what got me in trouble a year ago when I was new to FreeBSD.) But I'm not installing here, I am just upgrading so does the scenario still apply?

I'm willing to use the [N] option on one of my machines (FreeBSD 10.2-RELEASE + XCFE4 + some other stuff) to see what happens over time. Gladly will provide any info that is useful to others,
 
But now I gotta ask: By using the [N] option do I run the risk of a messed up system because synth rebuilt/compiled some ports, but for other just straight downloaded the package?

Not in my opinion. The dependencies to exact package names, options configuration, and ABI are all verified. they should work just as if they were built by synth. In theory.
 
No, does not work ...
#
was only a loud sigh.

After two further failed tries, now it works. I don't really know was it caused it, or what I am made wrong.

Only two packages failed (editors/abiword and sysutils/htop). But that's no problem, both are buggy and I can live without them.
Interesting the error messages of sysutils/htop:
Code:
htop(1) requires linprocfs(5) to be mounted. If you don't
have it mounted already, please add this line......

but all other linux-programs works.
 
Only problem left:

Code:
jackit-0.124.1_5.txz failed dependency check.
ffmpeg-2.8.5,1.txz failed dependency check.
gstreamer1-libav-1.6.3.txz failed dependency check.
fluidsynth-1.1.6_2.txz failed dependency check.
mplayer-1.2.r20151219_2.txz failed dependency check.
opencv-2.4.9_7.txz failed dependency check.
alsa-plugins-1.1.0.txz failed dependency check.
chromaprint-1.1.txz failed dependency check.
gstreamer1-plugins-opencv-1.6.3.txz failed dependency check.
gstreamer1-plugins-chromaprint-1.6.3.txz failed dependency check.
gstreamer1-plugins-jack-1.6.3.txz failed dependency check.
gstreamer1-plugins-all-1.4_3.txz failed dependency check

It does not find one (or more) dependcies of gstreamer & co.
Don't know how to locate this. Synth should say which package is missing.

Edit: found one, reduces the list to:
Code:
jackit-0.124.1_5.txz failed dependency check.
ffmpeg-2.8.5,1.txz failed dependency check.
gstreamer1-plugins-jack-1.6.3.txz failed dependency check
 
htop: That's a run-time message right? You shouldn't need linprocs to build htop

The "failed dependency check" messages: I think you are confused about these.
It is finding existing packages that are no longer useful. It doesn't matter exactly why they are not useful. If not a "status" command it will DELETE these packages and then rebuild them.

If these package show up as failed check after rebuilding, then there's a problem with the port itself (which is quite possible). In cases like that, I have a debug mode that can tell me exactly why and I can fix the port.
 
I said *I* can do it. I did not say it is a user feature. It would be used to help identify a problem with a port. It is out of scope of a synth user, they don't fix ports.
 
I think it is a problem with audio/jack - maybe it is the name. The package is named jackit and the port jack.
The problem is: it tries each run to rebuild 10 or 12 audio/multimedia related packages.
 
Last edited by a moderator:
okay, synth will have to be modified to support htop.
I'll have to confirm jack rebuilds over and over and if confirmed, fix the port.
 
I've pushed version 0.99_1 to ports:

Code:
ports-mgmt/synth: minor fixes plus linprocfs fix

1) When using prefetch option, list the packages that failed to download
   rather than just say, "at least one failed to download"
2) sysutils/htop requires linprocfs but doesn't set USE_LINUX.  Set this
   port to mount linprocfs based on its origin
3) Fix linprocfs implementation, it was mounting out of order, basically
   resulting in that it was non-functional
4) Close all the logs in the case where no packages are built.  In that
   case, the logs were never modified.  Changes discarded?
 
talsamon: please check if version 0.99_1 solves the htop issue for you.

everyone else: While testing on FreeBSD release 10.1 (not 10.2) I noticed synth just exits leaving up the curses screen. It's not supposed to do that, it is supposed to restore the terminal to how it was before synth was executed. Morever, that's hiding the "tally" that shows a summary of the build results.

Is everyone seeing the same thing? Or do some people see the terminal restore as expected? I was using syscons, not a vt.
 
Last edited by a moderator:
Back
Top