Reaction score: 330
Reaction score: 222
synth prepare-systemor something like that? (as opposed to a static build list?)
synth prepare-systemand that is what triggered it.
I really hope that isn't the case!then i would guess that it's code that makes poudriere faster that isn't active for any other system
last pid: 14470; load averages: 1.16, 0.93, 0.54 31 processes: 2 running, 25 sleeping, 4 zombie CPU 0: 28.0% user, 0.0% nice, 6.5% system, 0.5% interrupt, 65.0% idle CPU 1: 12.6% user, 0.0% nice, 4.7% system, 0.0% interrupt, 82.7% idle CPU 2: 15.0% user, 0.0% nice, 6.1% system, 0.0% interrupt, 79.0% idle CPU 3: 22.4% user, 0.0% nice, 6.5% system, 0.0% interrupt, 71.0% idle Mem: 32M Active, 368M Inact, 945M Wired, 536M Buf, 6471M Free Swap: 3852M Total, 3852M Free
[I] Num. concurrent builders 4 [J] Max. jobs per builder 4 [K] Use tmpfs for work area true [L] Use tmpfs for localbase true
[backup@localhost ~]$ pkg stats Local package database: Installed packages: 15 Disk space occupied: 37 MiB Remote package database(s): Number of repositories: 1 Packages available: 32 Unique packages: 32 Total size of packages: 101 MiB
[backup@localhost ~]$ date && sudo synth status && date Mon Mar 5 17:52:58 PST 2018 Regenerating flavor index: this may take a while ... Scanning entire ports tree. Querying system about current package installations. Stand by, comparing installed packages against the ports tree. Scanning existing packages. These are the ports that would be built ([N]ew, [R]ebuild, [U]pgrade): Total packages that would be built: 0 The complete build list can also be found at: /var/synth/synth_status_results.txt Mon Mar 5 18:14:00 PST 2018 [backup@localhost ~]$
Because the ports tree design sucks. And this is a misleading question. The same exact operation on DragonFly takes about 2-3 minutes. Yes, DragonFly Dports is 10x faster than FreeBSD ports because most of the inefficient crap that is in the ports tree was removed/fixed on dports.But Poudriere doesn't spend any time generating long indexes so I'm wondering why Synth needs to take that long.
False. It's scanning the tree when the tree changes. People don't update the tree, build one port, update the tree again, build another port.But for that use it's now recursing the entire port tree every time you use it which negates this purpose.
portsnap fetch update&
synth statuson cron, but I still run them manually before I upgrade any ports to ensure I have the latest versions. So I'm seeing that 21 minute delay each time.