ports-mgmt/portupgrade problem

Y

YuryG

Since some (long) time ago I have problems with ports-mgmt/portupgrade on two very different FreeBSD 10.3-STABLE machines. So, it is not only because of accidentally corrupted database.
For some ports it can't get dependencies right. Two different machines (amd64 and i386) have problems with the same ports. For example,
Code: 
portupgrade -c mate-settings-daemon
[Reading data from pkg(8) ... - 1601 packages found - done]
[Gathering depends for sysutils/mate-settings-daemon .................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................../usr/local/sbin/portupgrade:894:in `get_all_depends': recursive dependency (RecursiveDependencyError)
   from /usr/local/sbin/portupgrade:917:in `block in get_all_depends'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each_key'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each'
   from /usr/local/sbin/portupgrade:916:in `get_all_depends'
   from /usr/local/sbin/portupgrade:917:in `block in get_all_depends'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each_key'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each'
   from /usr/local/sbin/portupgrade:916:in `get_all_depends'
   from /usr/local/sbin/portupgrade:917:in `block in get_all_depends'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each_key'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each'
   from /usr/local/sbin/portupgrade:916:in `get_all_depends'
   from /usr/local/sbin/portupgrade:917:in `block in get_all_depends'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each_key'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each'
   from /usr/local/sbin/portupgrade:916:in `get_all_depends'
   from /usr/local/sbin/portupgrade:658:in `block (4 levels) in main'
   from /usr/local/sbin/portupgrade:621:in `each'
   from /usr/local/sbin/portupgrade:621:in `block (3 levels) in main'
   from /usr/local/sbin/portupgrade:594:in `catch'
   from /usr/local/sbin/portupgrade:594:in `block (2 levels) in main'
   from /usr/local/lib/ruby/2.3/optparse.rb:1591:in `block (2 levels) in parse_in_order'
   from /usr/local/lib/ruby/2.3/optparse.rb:1586:in `catch'
   from /usr/local/lib/ruby/2.3/optparse.rb:1586:in `block in parse_in_order'
   from /usr/local/lib/ruby/2.3/optparse.rb:1534:in `catch'
   from /usr/local/lib/ruby/2.3/optparse.rb:1534:in `parse_in_order'
   from /usr/local/lib/ruby/2.3/optparse.rb:1528:in `order!'
   from /usr/local/lib/ruby/2.3/optparse.rb:1520:in `order'
   from /usr/local/sbin/portupgrade:571:in `block in main'
   from /usr/local/lib/ruby/2.3/optparse.rb:1062:in `initialize'
   from /usr/local/sbin/portupgrade:238:in `new'
   from /usr/local/sbin/portupgrade:238:in `main'
   from /usr/local/sbin/portupgrade:2380:in `<main>'
Is it curable? For, there's no chance to make portupgrade -a after rebuilding world, for example. As far as I remember, the similar problem at first occured after ruby became version 2.
 
getopt said:
I saw that you also need to build for i386. Think about crossbuilding i386 packages on a fast amd64 box using ports-mgmt/poudriere. It is fun having local amd64 and i386 repositories. An i386 box is typically updated within less of a minute with a single command.
Click to expand...
Well, I tried to ask somewhere here weather is it possible and how far it is explained in details. I didn't get positive answers, or easy enough for me. May be some tutorial you can advise me, can you? For building, say www/chromium, on an old i386 (Pentium-4, specifically) is a real pain.
 
sidetone said:
ports-mgmt/portmaster works better than portupgrade, but many on here prefer newer synth.

Maybe you need to look at or clear /var/db/ports/, where your previously chosen dependencies for ports are saved.
Click to expand...
Can you help me saying what to look at? And yes, the problem is the same and with the same ports on two different not connected machines: amd64 and i386. The latter one had FreeBSD installation much later than the former one.
 
YuryG said:
May be some tutorial you can advise me, can you?
Click to expand...
https://github.com/freebsd/poudriere/wiki

1. Install Poudriere on your fastest machine
2. Read the manpage!
2. Configure it
3. Get a new portstree with Poudriere command
4. create a jail for building amd64 with Poudriere command
5. create a jail for building i386 with Poudriere command
6. Create bulk-lists with the ports to be build
7. run poudriere bulk with the lists
8. Set up a local webserver for the repositories (i.e Nginx in a jail)
9. Configure your clients to use your local repos.
10. run pkg upgrade on your clients and have fun.

Just start to try it and come back with the questions you may have in a new thread. Take your time playing with this, to get some understanding.
 
/var/db/ports/ has options saved, just erase everything in the directory, to start with fresh options. From past ports releases, it saves the options, and it keeps them even when the ports change, thus saving irrelevant options. Each file in it is saved options, that are set by make config, or similar. I was suggesting to check differences in past and present options, but just clear as in remove all files from that directory. You can also run a make rmconfig-recursive from each ports category directory in /usr/ports/, which is an example that will take too long.

Since you said, that it was by different machine architectures, it could be just that. Different programs come with different base systems (32 or 64 bit), then some ports get ignored for one architecture, because it is already in the base system. After starting fresh with new port options, if there are any differences, at least they will be more minimal.

Also, be aware that mixing ports and packages can have set different dependencies. If you do mix them, which many advise against, at least be mindful of what you are doing.

Reinstall your ports from scratch after a make world.
 
You must log in or register to reply here.
Back
Top