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

I switched to synth from portmaster and it works great.
I had some problem. I got failure for building lang/sbcl and math/maxima which I thing is not related to synth but I have also
devel/libc++ and archivers/file-roller which I get "failed dependency check" but building is successful.
On the and I have:
Scanning existing packages
Checking integrity...done (2 conflicting)
pkg: Cannot solve problem using SAT solver:
Checking integrity...done (0 conflicts)
Unfortunately, the system upgraded failed

Everything is updated and it works but every time it rebuilt devel/libc++ and archivers/file-roller.
Thank you.
 
fernandel, I see a problem with libc++ as well. I assume /usr/lib/libcxxrt.so exists on your system so
Code:
LIB_DEPENDS=    libcxxrt.so:${PORTSDIR}/devel/libcxxrt
is a bad specification.
I won't fix this myself, but I'll tell dim@ about it.
 
Unfortunately, the system upgraded failed
I think this is an indication that you aren't on the most recent version. I also know personally, that the newest version fixed an issue I had. Just thought I'd mention it. :)

--Chris
 
no, it's not. That bug has been fixed in the repository, but it's not been pushed to ports. It's not the only fix either that's not in ports yet.
 
marino@ , I sent an ESC to synth, last night. It sent me the message that it was shutting down. However, it's still running this morning. It had two targets in the queue. One finished about a half hour later, but it's still working on the other one, apparently (screen is corrupt, so I can't tell what the other one is).
I'm thinking at this point I should probably send it a HUP signal. But am wondering what sort of cleanup I have to deal with, afterwards. Any pointers?

Thanks, John.

--Chris
 
no, it's not. That bug has been fixed in the repository, but it's not been pushed to ports. It's not the only fix either that's not in ports yet.
Oh, OK. I remembered a discussion about that, earlier in this thread, and (mistakenly) assumed that it had (already) been pushed to the current version. My bad. I'll shut up now. :)

--Chris
 
marino@
I'm thinking at this point I should probably send it a HUP signal. But am wondering what sort of cleanup I have to deal with, afterwards. Any pointers?

Just hit control-C, then type synth configure and hit "enter". Synth will see that the previous build didn't clean up after itself and it will clean it up, if it can.

(obviously the "enter" just leaves configure screen without doing anything)
 
Feature request
Given that this (currently) requires being root. (and) given that (I, as root) receive messages at the console; was wondering if you could somehow buffer those messages, for display after synth has finished it's tasks. Somewhat like ports-mgmt/portmaster does with the ports(7) messages that normally are displayed after the port has been installed. My issue is; that the (root) messages sent to the screen, corrupt the synth output. I could overcome this by temporarily diverting the messages to syslog(3) via syslog.conf(5) . But thought this might be nice feature. At least until this can be run by a normal user. But even then, I still think this would be a nice feature.

Thanks for your time, John.

--Chris
 
OK. Just got another /libexec/ld-elf.so.1 error. Would you advise I bail, and start a new session? Is there any information that I could supply, that would help you find the culprit, to overcome this error?

Thanks!

--Chris
 
1) It's not supposed to output at all
2) Every 100 seconds, the display completely redraws, so the display is only corrupted for a maximum of 1 minute, 40 seconds.

I would figure out what package is causes the ld.elf error and what is special about it. (e.g. linux?)
 
Thanks for the quick response, John.
1) It's not supposed to output at all
2) Every 100 seconds, the display completely redraws, so the display is only corrupted for a maximum of 1 minute, 40 seconds.
Odd. That's not my experience. Things get redrawn, alright. But the layout is all screwed up. The top 1/3rd of the screen is all out-of-whack, which includes the current builds. So time, and such don't jive with what's being displayed, and the top statistics display numbers, but the labels are gone.
I would figure out what package is causes the ld.elf error and what is special about it. (e.g. linux?)
Yes. I have the Linux ABI loaded. If that's what you mean.

I'll bail, and start a new session.

Thanks again, John, for taking the time to respond.

--Chris
 
make sure the window is wide enough for 80 characters (for virtual terminals). If it's more narrow it may not redraw right.

I wasn't asking if you *have* linux, I was given an example of a "special" port, e.g. one that requires linux emulation.
 
Ahh. OK.
1) I'm running it on a (p)tty (Xorg, or other is not running)
2) OK. No, it wasn't building a Linux (related) port. So don't know what else to think. Could it be chroot(8) related? Are they large enough? I already have tmpfs(5) managing /tmp. But I've never observed swap exceed 23%. So I'm not sure what to expect. Load has never exceeded 4.3, either.

Thanks, John.

--Chris

OH! Forgot to mention;
I'm using an nVidia card, and as a result, using kern.vty=sc, as opposed to vt. In case it matters.
 
fernandel, I see a problem with libc++ as well. I assume /usr/lib/libcxxrt.so exists on your system so
Code:
LIB_DEPENDS=    libcxxrt.so:${PORTSDIR}/devel/libcxxrt
is a bad specification.
I won't fix this myself, but I'll tell dim@ about it.

It does:

locate libcxxrt.so
/lib/libcxxrt.so.1
/usr/lib/libcxxrt.so
/usr/lib32/libcxxrt.so
/usr/lib32/libcxxrt.so.1
/usr/local/lib/libcxxrt.so
 
Things get redrawn, alright. But the layout is all screwed up.
I am starting to think the ncurses redraw doesn't work like I thought it did. From the symptoms, it seems to only redrawn what it thinks has changed. In other words, if it thinks the line is "xx00045" and you redraw it to "xx10045", only the "1" is updated. I expected a full overwrite, but the image only fully redraws if I adjust the window of the virtual terminal.

I'm not a big fan of ncurses...
 
I am starting to think the ncurses redraw doesn't work like I thought it did. From the symptoms, it seems to only redrawn what it thinks has changed. In other words, if it thinks the line is "xx00045" and you redraw it to "xx10045", only the "1" is updated. I expected a full overwrite, but the image only fully redraws if I adjust the window of the virtual terminal.
Ahh. Sure. That makes sense.
I'm not a big fan of ncurses...
Hmm, I wonder if it can be improved in such a way as to keep a map of it's current/last state, and fully redraw itself?
I''l have a look at the source, and see if I can see any possibilities.
EDIT
Never mind. I spoke too soon. After giving it more thought, I realized that it would obviously be the responsibility of your (or any) application to keep/maintain the current state, and (in this case) redraw the entire screen/framework. sorry for the noise.

Thanks for the reply, John!

--Chris
 
I've pushed a significant bug fix and new feature update, 0.98_5, to ports:

Code:
ports-mgmt/synth: Finish test mode and various fixes

The following changes have been implemented:
  * The "test" command checks for file system violations between
    the configure and build targets (inclusive)
  * The "test" command checks for leftover (extra), missing, and
    unexpectedly modified files and directories between the stage and
    deinstall targets (inclusive)
  * Fix bug where successful system-upgrade was indicated as a failure
  * Bring in procfs mounts for x11-toolkits/gnustep-gui (only!)
    It appears to the be only port that needs it, but procfs appears to be
    pretty unstable, so we don't mount/dismount it unconditionally
  * Similarly, change linprocfs mounts/dismounts to only occur when when
    linux ports are building.  Linprocfs stability is unknown (and I can't
    test it on DF) so be conservative and use it as little as possible.
  * Fix bug on builders /etc/group file (some groups were missing)
  * Install /etc/master.passwd in builders, it is required for at least
    one port
  * Install /etc/rc.d and /etc/defaults/rc.conf in builders.  It is
    required for at least one port
  * Disable repository rebuild after synth-everything.  Twice it has
    removed all packages (over 23,000!) after a build, so there's a bug
    or missing safeguard there.
  * Watchdog status: Situation is better if scons ports are unwatched, but
    python3* freezes along with a handful of other ports.  It works 99% of
    the time, but not reliably enough yet to re-enable.
 
Seems synth status does not what I want. It tells me
Code:
Total packages that would be built: 1436
and pkg version|wc -l says 1426 (And I don't want rebuild all packages before 11.0-RELEASE).
 
You have zero packages.
If you upgrade system, it will build all of them. You should expect this.
Obviously it builds more than it installs. It will not install build dependencies. So you should also expect the number built to be greater than the number currently installed.

The option to use prebuilt packages if available is not there yet.

So it seems to be this is exactly what you are asking for. The first time will be a full build (1400+ packages). The next time will be incremental.

Right? What else could you be expecting?
 
Back
Top