3.5-DEVELOPMENT python27 one option from UCS single

[davshao]

master branch commit da6ea3c on i386 3.5-DEVELOPMENT, commit c3bdd8ca Sat Apr 6 "ftp: Update files for tnftp-20121224 import.

Installing python27 fails at the config with default "EXAMPLES" "IPV6" "NLS" "PYMALLOC" "THREADS" "UCS4" ====> You must select one and only one option from the UCS single Config is invalid. Re-edit?

/etc/make.conf is CFLAGS+=-g STRIP=

[davshao]

Further details: I have replicated the problem on an x86_64 machine.

I use say an existing pkgsrc git to update /usr/dports with # git pull then move /usr/pkg to /usr/pkg_pkgsrc and # rehash then

# cd /usr/dports/ports-mgmt/pkg
# make install clean
# rehash
# cd /usr/dports/lang/python27
# make install clean

When the installation comes to running the dialog for the config options for python27, the same problem occurs.

[jrmarino]

I can't reproduce this. I type "make config", verify one option set, and save. Then "make" works. Perhaps dialog4ports is not the latest? you could try deinstalling/reinstalling dialog4ports and trying to build lang/python27 again starting with "make config"

[davshao]

Should I use the staged or master branch of dports?

[jrmarino]

master should be fine, they are probably equivalent. (Staged is < 1 day old)

[davshao]

Here is what I am doing to try and bootstrap from as pristine a setup as possible without reinstalling from a recent snapshot.

I am using master through commit c74c7be57968d6aa048f81a4d5a2ffdbe6f21945 Date: Sun Apr 7 23:59:44 2013 +0200

mined(1): Fix alignment issue on strict alignment architectures.

with a full make -j7 buildworld buildkernel

After using pkgsrc git to update /usr/dports to the latest, I move /usr/pkg to /usr/pkg_pkgsrc.

I removed a previous installation of dports using pkg delete -f -a, then deleted all contents of /var/db/ports and /usr/local.

Now cd /usr/dports/ports-mgmt/pkg, make install clean, cd /usr/dports/lang/python27, make config, and after dialog4ports is installed, the error occurs for python's config.

Is there some document that explains exactly the steps to boostrap dports from scratch?

[jrmarino]

The only thing I would comment about your procedure is that it's not necessary to install pkg individually. You could have just gone to lang/python27 and pkg would have been installed automatically just like dialog4ports was.

There's no "bootstrap" procedure as it should be possible to build any port without doing anything special from early DragonFly 3.3 and later (actually now it's post-new-dialog since dialog4ports requires it).

I couldn't replicate your error and home (on x86_64), and this VM I'm using here needs to have the world updated to post-new-dialog to check that. Obviously there are workarounds, e.g. "make NO_DIALOG=yes" or even "make BATCH=yes" that will bypass dialog4ports. The question is why, after "make config", are there multiple options set to yes within an option group. There shouldn't be -- the fact you see it suggests a bug in dialog4ports but such a bug would affect FreeBSD as well. Any old options configuration would have been stored at /var/db/ports/python27/options but you indicated that you deleted that. I am stumped.

[ftigeot]

This error may come from incompatible configuration information stored by a previous version of make config. Removing /var/db/ports/* may fix the issue.

[jrmarino]

Yeah, that's what I said too, but previously David said this, "deleted all contents of /var/db/ports". I interpreted that as he had already removed any previous options configuration, and he still had the issue.

[davshao]

The first thing I do is remove all of /var/db/ports.

[jorisgio]

Similar issue with databases/libzdb.

make rmconfig /var/db/ports/libzdb/options does not exist

make config select only eg SQLITE cat /var/db/ports/libzdb/options

 # This file is auto-generated by 'make config'.
 # Options for libzdb-2.11.1
_OPTIONS_READ=libzdb-2.11.1
_FILE_COMPLETE_OPTIONS_LIST=MYSQL PGSQL SQLITE
OPTIONS_FILE_UNSET+=MYSQL
OPTIONS_FILE_UNSET+=PGSQL
OPTIONS_FILE_UNSET+=SQLITE

[jrmarino]

I can only reproduce this on i386. On x86_64, dialog4ports works as expected.

[jrmarino]

Maybe it's hammer vs ufs? the x86_64 has hammer. Are the people seeing this using x86_64 but with ufs?

[jrmarino]

Tuxillo says he sees this with x86-64 and hammer so that's not it. My x86-64 is older, version 0.1.1. The new version (0.1.3) on i386 is what is failing. I need to diff the sources perhaps

[jrmarino]

dialog4ports is currently on version 0.1.3. When it was upgraded from 0.1.1 to 0.1.2, dialog4ports stopped working. The cause was traced back to a file in Tools/scripts. This commit fixes the problem: https://github.com/jrmarino/DPorts/commit/12ea61be8401d61430c7afaa2fce62d197e81b39

Pull the latest dports and the issue should be gone. You may need to "make rmconfig" first to get the defaults back.