Although you haven't stated which CVSync server you are using, I can only guess that you are connecting to one which is running on AMD64. I have run into a similar problem some time back which is chronicled in the misc@ archives:

While we are on this subject, it should be clarified that while the kernel can be built with a non-root account which is a member of the wsrc group, building the userland still needs to be done as root.

This is true.

Most folks follow FAQ 5, but the definitive system build instructions are in the release(8) man page. There, it shows the kernel build being done by a normal user, but it shows the kernel install and the userland/xenocara builds being done with a blend of sudo and su.

Lots of ways to tell what kernel you're running. During the boot itself, if you're nervous, you can use "boot -c" at the boot> prompt, which will stop the kernel after the first few messages, to enter the user kernel configurator. Use "quit" at the UKC> prompt to continue after confirmation of the kernel you are running.

Once up, the easiest way to see what you're running is to use "sysctl kern.version". You could use "dmesg" but ... dmesg's wrap, and if you are rebooting a system with a BIOS that does not clear RAM, you may have multiple dmesg's to sort through. On a freshly powered up system, "dmesg|head -3" should work. The sysctl always works, however.

Lots of ways to tell what kernel you're running. During the boot itself, if you're nervous, you can use "boot -c" at the boot> prompt, which will stop the kernel after the first few messages, to enter the user kernel configurator. Use "quit" at the UKC> prompt to continue after confirmation of the kernel you are running.

Once up, the easiest way to see what you're running is to use "sysctl kern.version". You could use "dmesg" but ... dmesg's wrap, and if you are rebooting a system with a BIOS that does not clear RAM, you may have multiple dmesg's to sort through. On a freshly powered up system, "dmesg|head -3" should work. The sysctl always works, however.

thank you

OpenBSD 4.4-stable (GENERIC) #0

thanks for your easy help, the fellas at #openbsd on freenode are quite less helpful.

when i try to install opera with ports it stalls after it gets to 100%, don't know the reason why but I guess i'll have to find an alternative. (its not just opera, it did it for xfce4 too but i can just use pkg_add for it, opera i don't think it's on any package lists right?)

when i try to install opera with ports it stalls after it gets to 100%, don't know the reason why but I guess i'll have to find an alternative. (its not just opera, it did it for xfce4 too but i can just use pkg_add for it, opera i don't think it's on any package lists right?)

Hijacking your own thread, eh?

Opera cannot be distributed as a package due to licensing. But it is available as a "binary port" as it is a closed source application. The port merely places it in a package for install. (All ports build packages.)

I'm going to assume that because you are seeing a percentage complete, you have reached the point where the port is in its "make install" phase, and is running pkg_add(8) for you. You might be able to obtain more information by manually using pkg_add -v. The package can be found under /usr/ports/packages/<arch>/all/.

Last edited by jggimi; 16th April 2009 at 11:44 AM.
Reason: clarity of license phrase

Tutorials are frequently out of date, & give little if any indication as to what version was used when the tutorial was written.

All assumptions made in the tutorial are rarely explicitly mentioned.

Something unique about the author's configuration is not mentioned.

The author may or may not have understood the problem or clearly communicated a solution which works across numerous situations.

Many how-to's in the Linux world have matured such that they can somewhat be inherently trusted. Such is not the case in the OpenBSD world. This is a very small project. You are best to stay with information found in the project's FAQ & manpages.

If you are in serious need of Flash, OpenBSD may not be the best operating system for your situation. Some third-party applications such as gnash kinda sorta work, but it is not guaranteed to work with newer Flash versions. To search for what alternatives can be found in the packages/ports system, use the OpenPorts Website:

The same procedure is used for dependencies as well as the "calling" package. So, I will guess that whatever the problem was, it was transitory.

While I understand your complaint, I cannot tell, from the information you've supplied, why the initial installation attempt hung. There are diagnostic tools that you might have used -- and because the pkg* tools are written in perl, even perl debugging traces -- but as you now have it installed, I guess it's moot.

Should you have problems with future package installations, start with pkg_add -v, then consider using top, systat, .... even perl -d if used carefully. This last is described well in perldebtut(1).

Tutorials are frequently out of date, & give little if any indication as to what version was used when the tutorial was written.

All assumptions made in the tutorial are rarely explicitly mentioned.

Something unique about the author's configuration is not mentioned.

The author may or may not have understood the problem or clearly communicated a solution which works across numerous situations.

Many how-to's in the Linux world have matured such that they can somewhat be inherently trusted. Such is not the case in the OpenBSD world. This is a very small project. You are best to stay with information found in the project's FAQ & manpages.

If you are in serious need of Flash, OpenBSD may not be the best operating system for your situation. Some third-party applications such as gnash kinda sorta work, but it is not guaranteed to work with newer Flash versions. To search for what alternatives can be found in the packages/ports system, use the OpenPorts Website: