Re: [ GSOC ] Differences in shell behaviour
Good morning.
On 06/01/2012 07:53, Jason Hellenthal wrote:
On Thu, May 31, 2012 at 11:21:10PM +0400, Alexander Pronin wrote:
The problem is:
### sh in 8.3
$ false pid=$!
$
[1] Done (1)false
$ wait ${pid}
wait: No such job: 4852
I don't see this behavior on 8.3-STABLE @r236350 i386
---
Console false pid=$!
Console wait ${pid}
[1] Done (1)false
Console echo $?
1
It seems to behave differently, when you issue some additional commands
or interact with shell.
first case (8.3 r234443):
$ false pid=$!
$ wait ${pid}
[1] Done (1)false
$ echo $?
1
second case (8.3 r234443):
$ false pid=$!
$ # some interaction with shell
[1] Done (1)false
$ wait ${pid}
wait: No such job: 59092
Now, on 9.0-RELEASE
first case:
$ false pid=$!
$ wait ${pid}
[1] Done(1) false
$ echo $?
1
second case:
$ false pid=$!
$ # some activity
[1] Done(1) false
$ wait ${pid}
$ echo $?
1
Do you see the difference ? Which behavior is correct? Can it be a sh bug?
--
Best regards,
Alexander Pyhalov,
system administrator of Computer Center of Southern Federal University
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ GSOC ] Differences in shell behaviour
Hello. On 06/01/2012 05:47, Doug Barton wrote: On 5/31/2012 12:21 PM, Alexander Pronin wrote: But, is it suitable to write sh script for 9.0, that does not work in 8.3? No. Our tools need to work in all supported versions of FreeBSD, which at this time includes 7 as well. I see two points... First one is that parallel building is an optional feature wich can be made conditionally available for systems with $OSVERSION = 90. The second one is the following. Is the difference in sh behavior intentional? Can it be considered a bug and thus the right thing is to fix it in FreeBSD 7/8? However, as it leads to difference in shell behavior, it can be undesirable. -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ GSOC ] Differences in shell behaviour
On Fri, Jun 01, 2012 at 09:38:38AM +0400, Alexander Pyhalov wrote:
Good morning.
On 06/01/2012 07:53, Jason Hellenthal wrote:
On Thu, May 31, 2012 at 11:21:10PM +0400, Alexander Pronin wrote:
The problem is:
### sh in 8.3
$ false pid=$!
$
[1] Done (1)false
$ wait ${pid}
wait: No such job: 4852
I don't see this behavior on 8.3-STABLE @r236350 i386
---
Console false pid=$!
Console wait ${pid}
[1] Done (1)false
Console echo $?
1
It seems to behave differently, when you issue some additional commands
or interact with shell.
first case (8.3 r234443):
$ false pid=$!
$ wait ${pid}
[1] Done (1)false
$ echo $?
1
second case (8.3 r234443):
$ false pid=$!
$ # some interaction with shell
[1] Done (1)false
$ wait ${pid}
wait: No such job: 59092
Now, on 9.0-RELEASE
first case:
$ false pid=$!
$ wait ${pid}
[1] Done(1) false
$ echo $?
1
second case:
$ false pid=$!
$ # some activity
[1] Done(1) false
$ wait ${pid}
$ echo $?
1
Do you see the difference ? Which behavior is correct? Can it be a sh bug?
Adding jilles to CC, he worked on sh(1) during the last months.
pgpPbzyffKaQE.pgp
Description: PGP signature
Re: [ GSOC ] Differences in shell behaviour
On 05/31/2012 22:55, Alexander Pyhalov wrote: Hello. On 06/01/2012 05:47, Doug Barton wrote: On 5/31/2012 12:21 PM, Alexander Pronin wrote: But, is it suitable to write sh script for 9.0, that does not work in 8.3? No. Our tools need to work in all supported versions of FreeBSD, which at this time includes 7 as well. I see two points... First one is that parallel building is an optional feature wich can be made conditionally available for systems with $OSVERSION = 90. Um, no. The question was asked, Is it acceptable to do this? and the answer is, No, it's not. One of the key virtues of the ports system is that it runs on all supported versions of FreeBSD. There may be individual _ports_ that don't work with some versions, but the infrastructure itself needs to. The second one is the following. Is the difference in sh behavior intentional? Can it be considered a bug and thus the right thing is to fix it in FreeBSD 7/8? However, as it leads to difference in shell behavior, it can be undesirable. It's still up in the air whether there has been identified a bug, or even a difference, but hopefully Jilles can shed some light on any actual differences in behavior between versions. -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: make failed for graphics/gdk-pixbuf2
Leslie Jensen wrote: ... ImportError: /usr/local/lib/gobject-introspection/giscanner/_giscanner.so: Undef ined symbol PyUnicodeUCS4_AsUTF8String gmake[4]: *** [GdkPixbuf-2.0.gir] Fel 1 gmake[4]: Lämnar katalogen It's difficult to determine the source of the problem without more information -- are you using python26-2.6.8_1 or python27-2.7.3_1? If so, try updating to the latest revision ( _2, in each case) of your python port, with UCS4 support enabled, and then rebuild the ports that depend upon it. There were problems in the penultimate revisions of those ports, which have since been corrected. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: make failed for graphics/gdk-pixbuf2
On Fri, 01 Jun 2012 10:34:27 +0200, Leslie Jensen wrote: [...] ImportError: /usr/local/lib/gobject-introspection/giscanner/_giscanner.so: Undef ined symbol PyUnicodeUCS4_AsUTF8String gmake[4]: *** [GdkPixbuf-2.0.gir] Fel 1 gmake[4]: Lämnar katalogen Rebuilding devel/gobject-introspection fixed that problem for me. -- Thomas Mueller ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: kde3-network compile error, is this fixable?
On Thu, May 31, 2012 at 6:52 PM, Per olof Ljungmark p...@intersonic.se wrote: BTW, if KDE3 is unmaintained and this gous for FreeBSD too, perhaps it should be mentioned in the Handbook? I submitted these lines for the Handbook some time ago: There are two versions of KDE available on FreeBSD. Version 3 has been around for a long time, and is still available in the Ports Collection though it's now unmaintained and partially broken. Version 4 is punctually updated and is the default choice for KDE users. They can even be installed side by side. I think they're enough. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PHP 5.4.0 : lang/php54
On 31-5-2012 5:00, Doug Barton wrote: On 05/30/2012 12:32, Mel Flynn wrote: On 29-5-2012 19:06, Doug Barton wrote: On 5/29/2012 4:00 AM, Mel Flynn wrote: On 29-5-2012 7:23, Doug Barton wrote: Right. The issue I'm talking about is that fixing the problem of staying with a version, introduces a problem for people that have their software up-to-date and don't use deprecated features. Instead of simply upgrading they now have to jump through hoops of changing origins on multiple ports and their depending ports. Each time a new perl version is introduced or the default changes there are failure reports and compared to php, perl is easy as the modules have a single prefix (p5-) vs the versioned prefix now used by the php ports. I understand what you're saying, but in practice users generally don't need to upgrade the version of a dependency that they are using, at least not until it goes EOL. In the case of PHP, users actively oppose being forced to upgrade, as indicated pretty clearly by the demand for php52 and php53 ports. And users using the latest php in production don't have anything to complain about as they have no problem. Maybe that's two people, maybe it's the silent masses that will rain down on the mail servers once we break their easy upgrade path. That said, I agree that we need a more robust way to say Upgrade my perl/php/whatever from version N to version N+M. I am happy to put effort into that if we can get general agreement on what a versioned infrastructure should look like. Right now we have at least 4 different models that I can think of off the top of my head, none of which robustly address our users' needs. Yep, that's what I'm trying to get at. The ideal solution is to have a system that can upgrade between minor versions and micro versions without a difference to the end user. Major version upgrades are a different ballgame entirely as upstream uses a much bigger axe, though the differences between python2.x and 3.x are less big then I expected initially. But, if the ideal solution cannot be achieved, I'm not sure it's wise to sacrifice a system that already does painless minor upgrades so that we can have painless micro version upgrades. 2) All ports that depend on the previous default version are assumed to be working with the new default version. Hopelessly naive. And demonstrably untrue in the case of PHP. No, it's the assumption made by the ports system as is - both now and if you'd version all PHP ports. And as you say below, Stating it doesn't make it true. We already know that it absolutely is *not* true for PHP, it's only sometimes true for Perl, often isn't true for Python ... etc. I know we'd really like it if this were true, but it quite simply isn't; and isn't going to be any time in the foreseeable future. We need to code for what is, not what we wish it would be. Right and I'm describing the state of the code in the ports tree at the moment. Even with ports that are fully versioned, they get marked for specific versions based on user reports or maintainer insights. But if a port works with all versions in the ports tree at the moment then it's not tagged USE_PYTHON= =32. It's marked as USE_PYTHON=yes, which means 'any'. The only way to fix that is to use an opt-in system for supported versions, similar to MAKE_JOBS_SAFE. Right now, it's opt-out. Instead of an omfg I don't wanna upgrade problem, you have an I installed php-foo but it don't work! problem and an additional how do I upgrade to the new version? problem. The latter problem is soluble. Making the first problem go away is critical. Stating it, doesn't make it true. Not sure which you are referring to here. The upgrade to the new version problem is a SMOP. If we can agree on what a framework should look like, we can write tools to do it. But the haphazard way in which it's handled now does not lend itself to a programmatic solution. Well, if we agree that switching a branch should be no different to the end user as upgrading within a branch then the additional issues I think are: - branches marked EOL upstream shall not live on forever (something to think about really, since this will make people lazier) - conflict resolution for modules that have been imported into or ejected from the main source - opt-in mechanism for versions rather than the current opt-out - support for different maintainers per branch - automatic activation of compiled modules in the case of php specifically - a unified system for naming module ports from which the installed interpreter version can be derived preferably without having multiple origin incarnations of the same software - Decision on whether to support multiple versions of the same interpreter being installed and how to handle that if so (non-trivial) Finally, if you have a vast number of machines to worry about, know how the php port works and see trouble ahead because of incompatibilities introduced, then why
Re: make failed for graphics/gdk-pixbuf2
Thomas Mueller skrev 2012-06-01 13:01: On Fri, 01 Jun 2012 10:34:27 +0200, Leslie Jensen wrote: [...] ImportError: /usr/local/lib/gobject-introspection/giscanner/_giscanner.so: Undef ined symbol PyUnicodeUCS4_AsUTF8String gmake[4]: *** [GdkPixbuf-2.0.gir] Fel 1 gmake[4]: Lämnar katalogen Rebuilding devel/gobject-introspection fixed that problem for me. Unfortunately it fails as well. I'm on another machine at the moment so I can't give you the output :-) /Leslie ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: make failed for graphics/gdk-pixbuf2
b. f. skrev 2012-06-01 12:47: Leslie Jensen wrote: ... ImportError: /usr/local/lib/gobject-introspection/giscanner/_giscanner.so: Undef ined symbol PyUnicodeUCS4_AsUTF8String gmake[4]: *** [GdkPixbuf-2.0.gir] Fel 1 gmake[4]: Lämnar katalogen It's difficult to determine the source of the problem without more information -- are you using python26-2.6.8_1 or python27-2.7.3_1? If so, try updating to the latest revision ( _2, in each case) of your python port, with UCS4 support enabled, and then rebuild the ports that depend upon it. There were problems in the penultimate revisions of those ports, which have since been corrected. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org I did make config and changed from UCS2 to UCS4. Unfortunately I now get a make failure with devel/gobject-introspection A make deinstall and make reinstall does not help. /Leslie ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ GSOC ] Differences in shell behaviour
On Fri, Jun 01, 2012 at 09:43:08AM +0200, Lars Engels wrote:
On Fri, Jun 01, 2012 at 09:38:38AM +0400, Alexander Pyhalov wrote:
Good morning.
On 06/01/2012 07:53, Jason Hellenthal wrote:
On Thu, May 31, 2012 at 11:21:10PM +0400, Alexander Pronin wrote:
The problem is:
### sh in 8.3
$ false pid=$!
$
[1] Done (1)false
$ wait ${pid}
wait: No such job: 4852
I don't see this behavior on 8.3-STABLE @r236350 i386
---
Console false pid=$!
Console wait ${pid}
[1] Done (1)false
Console echo $?
1
It seems to behave differently, when you issue some additional commands
or interact with shell.
first case (8.3 r234443):
$ false pid=$!
$ wait ${pid}
[1] Done (1)false
$ echo $?
1
second case (8.3 r234443):
$ false pid=$!
$ # some interaction with shell
[1] Done (1)false
$ wait ${pid}
wait: No such job: 59092
Now, on 9.0-RELEASE
first case:
$ false pid=$!
$ wait ${pid}
[1] Done(1) false
$ echo $?
1
second case:
$ false pid=$!
$ # some activity
[1] Done(1) false
$ wait ${pid}
$ echo $?
1
Do you see the difference ? Which behavior is correct? Can it be a sh bug?
Adding jilles to CC, he worked on sh(1) during the last months.
In 8.x, the 'jobs' utility and the implicit 'jobs -n'-like operation
before a prompt always cause sh to discard the record of the job and
its exit status. In 9.x, sh remembers jobs for which $! has been
referenced until they are 'wait'ed for, even if their completion is
otherwise reported, while jobs for which $! was not referenced are
forgotten as soon as they terminate.
This change was made to reduce memory usage from long-running scripts
that do not care about job completion, see PR bin/55346.
The part of the change that applies to interactive mode may, in fact, be
wrong, however useful it may be.
Some of the strange differences are due to an inherent race condition:
the child process may terminate before or after sh's check just before
displaying the prompt.
If you do your experiments using scripts instead of in interactive mode,
they should work in 8.x as well as in 9.x.
--
Jilles Tjoelker
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cannot compile VirtualBox-ose 4.1.16 on FreeBSD 8.3-RELEASE amd64
On 31.05.2012 14:34, Miroslav Lachman wrote:
Hi,
I tried to install virtualbox-ose on our new testmachine, but
compilation ends with error:
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/src/VBox/HostServices/auth/pam/VBoxAuthPAM.c:408:
error: expected '{' at end of input
kmk: ***
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxAuth/pam/VBoxAuthPAM.o]
Error 1
The failing command:
@cc -c -O2 -g -pipe -pedantic -Wshadow -Wall -Wextra
-Wno-missing-field-initializers -Wno-unused -Wno-trigraphs
-fdiagnostics-show-option -Wno-long-long -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations
-Werror-implicit-function-declaration -Wno-variadic-macros -O2
-mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing
-fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN
-DRT_USE_VISIBILITY_DEFAULT -fPIC -m64 -I/usr/include
-I/usr/X11R6/include -I/usr/local/include
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/include
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/out/freebsd.amd64/release
-DVBOX -DVBOX_WITH_DEBUGGER -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS
-DVBOX_WITH_HARDENING
-DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\
-DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\
-DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\
-DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\
-DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DIN_RING3
-DHC_ARCH_BITS=64 -DGC_ARCH_BITS=64 -DPIC
-Wp,-MD,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxAuth/pam/VBoxAuthPAM.o.dep
-Wp,-MT,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxAuth/pam/VBoxAuthPAM.o
-Wp,-MP -o
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxAuth/pam/VBoxAuthPAM.o
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/src/VBox/HostServices/auth/pam/VBoxAuthPAM.c
kmk: *** Waiting for unfinished jobs
kmk: *** Exiting with status 2
*** Error code 2
Stop in /usr/ports/emulators/virtualbox-ose.
*** Error code 1
Stop in /usr/ports/emulators/virtualbox-ose.
Full output can be seen on http://pastebin.com/raw.php?i=7eDEWze8
The error above is completely unrelated because the problem starts much
earlier:
In file included from
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/src/VBox/HostServices/auth/pam/VBoxAuthPAM.c:81:
/usr/include/security/pam_appl.h:43:35: error: security/openpam_attr.h:
No such file or directory
So it seems your system is broken. On my system I have the file and I
have just
checked that vbox 4.1.16 did build fine on a stock FreeBSD 8.3
Tinderbox.
# ident /usr/include/security/pam_appl.h
/usr/include/security/pam_appl.h:
$Id: pam_appl.h 408 2007-12-21 11:36:24Z des $
# uname -a
FreeBSD chii.bluelife.at 9.0-STABLE FreeBSD 9.0-STABLE #10: Wed May 23
23:30:26 CEST 2012
r...@chii.bluelife.at:/usr/obj/usr/src/sys/GENERIC amd64
--
Bernhard Froehlich
http://www.bluelife.at/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cannot compile VirtualBox-ose 4.1.16 on FreeBSD 8.3-RELEASE amd64
Bernhard Froehlich wrote: On 31.05.2012 14:34, Miroslav Lachman wrote: Hi, I tried to install virtualbox-ose on our new testmachine, but compilation ends with error: [...] Full output can be seen on http://pastebin.com/raw.php?i=7eDEWze8 The error above is completely unrelated because the problem starts much earlier: In file included from /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/src/VBox/HostServices/auth/pam/VBoxAuthPAM.c:81: /usr/include/security/pam_appl.h:43:35: error: security/openpam_attr.h: No such file or directory So it seems your system is broken. On my system I have the file and I have just checked that vbox 4.1.16 did build fine on a stock FreeBSD 8.3 Tinderbox. # ident /usr/include/security/pam_appl.h /usr/include/security/pam_appl.h: $Id: pam_appl.h 408 2007-12-21 11:36:24Z des $ # uname -a FreeBSD chii.bluelife.at 9.0-STABLE FreeBSD 9.0-STABLE #10: Wed May 23 23:30:26 CEST 2012 r...@chii.bluelife.at:/usr/obj/usr/src/sys/GENERIC amd64 You are right! The system is missing /usr/include/security/openpam_attr.h - I don't know the reason. I successfully build VirtualBox on another machine. But there were some other problems: On one run, installation ends with: === Checking if emulators/virtualbox-ose already installed === Creating users and/or groups. Creating group 'vboxusers' with gid `920'. Creating user `vboxusers' with uid `920'. pw: user 'vboxusers' disappeared during update *** Error code 67 On the next run: === Checking if emulators/virtualbox-ose already installed === Creating users and/or groups. Using existing group `vboxusers'. Creating user `vboxusers' with uid `920'. pw: user 'vboxusers' already exists *** Error code 74 After few next runs (and manual deletion of the vboxusers) it was built and now I am running VirtualBox headless. So thank you very much for you time and work on VirtualBox! Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cannot compile VirtualBox-ose 4.1.16 on FreeBSD 8.3-RELEASE amd64
On 01.06.2012 19:18, Miroslav Lachman wrote: Bernhard Froehlich wrote: On 31.05.2012 14:34, Miroslav Lachman wrote: Hi, I tried to install virtualbox-ose on our new testmachine, but compilation ends with error: [...] Full output can be seen on http://pastebin.com/raw.php?i=7eDEWze8 The error above is completely unrelated because the problem starts much earlier: In file included from /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.16/src/VBox/HostServices/auth/pam/VBoxAuthPAM.c:81: /usr/include/security/pam_appl.h:43:35: error: security/openpam_attr.h: No such file or directory So it seems your system is broken. On my system I have the file and I have just checked that vbox 4.1.16 did build fine on a stock FreeBSD 8.3 Tinderbox. # ident /usr/include/security/pam_appl.h /usr/include/security/pam_appl.h: $Id: pam_appl.h 408 2007-12-21 11:36:24Z des $ # uname -a FreeBSD chii.bluelife.at 9.0-STABLE FreeBSD 9.0-STABLE #10: Wed May 23 23:30:26 CEST 2012 r...@chii.bluelife.at:/usr/obj/usr/src/sys/GENERIC amd64 You are right! The system is missing /usr/include/security/openpam_attr.h - I don't know the reason. I successfully build VirtualBox on another machine. But there were some other problems: On one run, installation ends with: === Checking if emulators/virtualbox-ose already installed === Creating users and/or groups. Creating group 'vboxusers' with gid `920'. Creating user `vboxusers' with uid `920'. pw: user 'vboxusers' disappeared during update *** Error code 67 On the next run: === Checking if emulators/virtualbox-ose already installed === Creating users and/or groups. Using existing group `vboxusers'. Creating user `vboxusers' with uid `920'. pw: user 'vboxusers' already exists *** Error code 74 After few next runs (and manual deletion of the vboxusers) it was built and now I am running VirtualBox headless. So thank you very much for you time and work on VirtualBox! That is a symptom of a broken password database. So your password database /etc/pwd.db and /etc/master.passwd are out of sync and so pw complains. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cannot compile VirtualBox-ose 4.1.16 on FreeBSD 8.3-RELEASE amd64
Bernhard Froehlich wrote: On 01.06.2012 19:18, Miroslav Lachman wrote: Bernhard Froehlich wrote: On 31.05.2012 14:34, Miroslav Lachman wrote: [...] I successfully build VirtualBox on another machine. But there were some other problems: On one run, installation ends with: === Checking if emulators/virtualbox-ose already installed === Creating users and/or groups. Creating group 'vboxusers' with gid `920'. Creating user `vboxusers' with uid `920'. pw: user 'vboxusers' disappeared during update *** Error code 67 On the next run: === Checking if emulators/virtualbox-ose already installed === Creating users and/or groups. Using existing group `vboxusers'. Creating user `vboxusers' with uid `920'. pw: user 'vboxusers' already exists *** Error code 74 After few next runs (and manual deletion of the vboxusers) it was built and now I am running VirtualBox headless. So thank you very much for you time and work on VirtualBox! That is a symptom of a broken password database. So your password database /etc/pwd.db and /etc/master.passwd are out of sync and so pw complains. I think that pwd.db and master.passwd are OK. This error was shown on two different machines during the virtualbox-ose install. But as I already fixed it, there are no more problems with VBox. Thank you! Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] New framework options aka optionng
On Wed, 2012-05-30 at 23:48:03 +0200, Baptiste Daroussin wrote: On Wed, May 30, 2012 at 05:38:26PM -0400, Michael Scheidell wrote: On 5/30/12 5:33 PM, Kevin Oberman wrote: would only cause confusion. I'll go one further and suggest that the vast majority who don't want these features are building specialized systems and they know very well what they are doing. A global setting for these would be desirable, though, as someone building a specialized distribution for, say, an embedded system, will want no docs or examples for any port. I suspect it is ALMOST always an all or nothing issue, not per port. -- for our commercial systems, we don't install man, docs, examples. and, I would suspect that I would be a little peeved if next time I recompile all the ports, I had to stop and hit 'WITHOUT_PORTDOCS, WITHOUT_PORTEXAMPLES' on every port. Upward compatibility folks, if at all possible. You are not guaranteed that all ports implement NOPORTDOCS, so what do you do with those? If folks really are that allergic against docs, then they need to do rm -rf /usr/local/share/doc anyway. I don't quite get why people think WITHOUT_NLS and NO_PORTDOCS are useful or even worth the burden they put on the porters and maintainers. echo OPTIONS_UNSET+= DOCS /etc/make.conf echo NO_DIALOG=yes /etc/make.conf having NOPORTSDOC and NOPORTEXAMPLES, KNOBS and OPTIONS has been a constant demand by lots of users that is why I wrote it that way and merged NOPORTDOCS and NOPORTEXAMPLES and WITHOUT_NLS btw to optionsng, I may be wrong, if that is the case please speak loudly, saying why, what would be best what do you expect. Keep in mind that currently lots of ports already define OPTIONS only concerning documentation, also note that some DOCS might bring some heavy depencies like doxygen. That's about the only justifiable use-case IMHO. There should be a DOC_DEPENDS that pulls in ports necessary for building documentation (if required) and perhaps (perhaps!) a knob to not pull that in and install documentation. A better solution, saving hundreds of cpu-hours world-wide, would be to persuade upstream to include fully rendered documentation (HOW HARD CAN IT BE?). The fall-back could be to have the maintainer provide the set of documentation. It will usually not change between distfile releases, so re-rolling the documentation could be part of the port update that the maintainer does. Last but not least, by chance (for once I'm happy with chance :)) you do not have to add DOCS or EXAMPLES to OPTIONS_DEFINE to be able to use them in your ports! So you can use it just like NOPORTDOCS and NOPORTEXAMPLES use to work. IE without and make config needed. that mean a single way to define/check for it but 2 different kind of options. Not sure this mail is clear :) I hate WITHOUT_NLS and NO_PORTDOCS with a passion. They work for 80% of the ports you are likely to install, so they are not a safe way to escape docs or NLS. Why bother? Seriously, could someone give me a usecase for them? Cheers, Uli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cannot compile VirtualBox-ose 4.1.16 on FreeBSD 8.3-RELEASE amd64
On 01.06.2012 21:11, Miroslav Lachman wrote: Bernhard Froehlich wrote: On 01.06.2012 19:18, Miroslav Lachman wrote: Bernhard Froehlich wrote: On 31.05.2012 14:34, Miroslav Lachman wrote: [...] I successfully build VirtualBox on another machine. But there were some other problems: On one run, installation ends with: === Checking if emulators/virtualbox-ose already installed === Creating users and/or groups. Creating group 'vboxusers' with gid `920'. Creating user `vboxusers' with uid `920'. pw: user 'vboxusers' disappeared during update *** Error code 67 On the next run: === Checking if emulators/virtualbox-ose already installed === Creating users and/or groups. Using existing group `vboxusers'. Creating user `vboxusers' with uid `920'. pw: user 'vboxusers' already exists *** Error code 74 After few next runs (and manual deletion of the vboxusers) it was built and now I am running VirtualBox headless. So thank you very much for you time and work on VirtualBox! That is a symptom of a broken password database. So your password database /etc/pwd.db and /etc/master.passwd are out of sync and so pw complains. I think that pwd.db and master.passwd are OK. This error was shown on two different machines during the virtualbox-ose install. Just for the record. The virtualbox port only tells the ports framework that it needs some users/groups to install correctly by setting USERS= vboxusers but the actual creation of that happens within the ports framework (See create-users-groups target in /usr/ports/Mk/bsd.port.mk). So this has nothing to do with virtualbox itself - it just happens to be one of the ports that need a special user/group. Use pwd_mkdb(8) to recreate your password database and everything should be fine again. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Audacious startup error
Suddenly started seeing this recently: $ audacious WARNING: Audacious seems to be already running but is not responding. (audacious:46486): GLib-GObject-WARNING **: gsignal.c:2275: signal `draw' is invalid for instance `0x80d1b4c70' (audacious:46486): GLib-GObject-WARNING **: gsignal.c:2275: signal `draw' is invalid for instance `0x80d1b4ce0' Any clues, anyone? Thanks! -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Ruby 1.9 as default
Hi All, I think we should try to make Ruby 1.9 the default Ruby again and would like to see it done before 9.1 is released. I've submitted a patch which does this and requested and exp-run from portmgr. I would like to get feedback on this idea. If you have experience with Ruby 1.9 as default, good or bad, please speak up. You can test this by setting RUBY_DEFAULT_VER=1.9 in /etc/make.conf or editing Mk/bsd.ruby.mk and setting the same variable there. Thanks, Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ruby 1.9 as default
On Fri, 01 Jun 2012 21:32:53 -0400 Steve Wills swi...@freebsd.org mentioned: Hi All, I think we should try to make Ruby 1.9 the default Ruby again and would like to see it done before 9.1 is released. I've submitted a patch which does this and requested and exp-run from portmgr. I would like to get feedback on this idea. If you have experience with Ruby 1.9 as default, good or bad, please speak up. You can test this by setting RUBY_DEFAULT_VER=1.9 in /etc/make.conf or editing Mk/bsd.ruby.mk and setting the same variable there. I'm not sure it's a good idea. Ruby 1.9 still has some nasty bugs on FreeBSD, related to the threads and fork. That is fork in ruby 1.9 hangs sometimes... OTOH, I've been running ruby 1.9 as default on both of my desktops and have not seen major problems except this one. Still, it'd be nice for someone to fix it first (I remember there were a lot of eager commiters at the time I gave up my commit bit). The main question is whether the switch to 1.9 will be beneficial for our users. Apart from some libraries targeting 1.9 exclusivly now, most of of them still work with 1.8 and there're still some that work with 1.8 only. Given that most of the ports users mostly care for 3rd party applications to work, I'm not sure if the switch to 1.9 will be a win for them... -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
OPTIONS framework unwell? Additional ports installed unexpectedly
I just had a whole bunch of ports install unexpectedly. portmaster -D -r png-1.4.11 One of the ports that pulled in for rebuilding was graphics/php5-gd. That's fair enough, and it is depended on by lang/php5-extensions, so that got pulled in too. That's fine, but then php5-extensions pulled in all of the other default extensions to *install* - all of the ones a have deselected in my config. === Done updating ports that depend on png-1.4.11 === The following actions were performed: Upgrade of png-1.4.11 to png-1.5.10 Upgrade of gd-2.0.35_7,1 to gd-2.0.35_8,1 Upgrade of p5-GD-2.46 to p5-GD-2.46_1 Installation of archivers/php5-phar (php5-phar-5.4.3) Installation of databases/php5-pdo_sqlite (php5-pdo_sqlite-5.4.3) Installation of databases/php5-sqlite3 (php5-sqlite3-5.4.3) Installation of devel/php5-json (php5-json-5.4.3) Installation of devel/php5-tokenizer (php5-tokenizer-5.4.3) Re-installation of php5-gd-5.4.3 Installation of security/php5-filter (php5-filter-5.4.3) Installation of sysutils/php5-posix (php5-posix-5.4.3) Installation of textproc/php5-simplexml (php5-simplexml-5.4.3) Installation of textproc/php5-xmlreader (php5-xmlreader-5.4.3) Installation of textproc/php5-xmlwriter (php5-xmlwriter-5.4.3) Re-installation of php5-extensions-1.7 Upgrade of rrdtool-1.2.30_1 to rrdtool-1.2.30_2 Upgrade of webalizer-geoip-2.23.5 to webalizer-geoip-2.23.5_1 So, what happened? Those extensions OPTIONS are all disabled in my config. rwsrv03# cd /usr/ports/lang/php5-extensions rwsrv03# make showconfig === The following configuration options are available for php5-extensions-1.7: BCMATH=off: bc style precision math functions BZ2=off: bzip2 library support CALENDAR=on: calendar conversion support CTYPE=on: ctype functions CURL=off: CURL support DBA=off: dba support DOM=on: DOM support EXIF=off: EXIF support FILEINFO=off: fileinfo support FILTER=off: input filter support FTP=off: FTP support GD=on: GD library support GETTEXT=on: gettext library support GMP=off: GNU MP support HASH=on: HASH Message Digest Framework ICONV=on: iconv support IMAP=off: IMAP support INTERBASE=off: Interbase 6 database support (Firebird) JSON=off: JavaScript Object Serialization support LDAP=on: OpenLDAP support MBSTRING=on: multibyte string support MCRYPT=off: Encryption support MSSQL=off: MS-SQL database support MYSQL=on: MySQL database support MYSQLI=on: MySQLi database support ODBC=off: ODBC support OPENSSL=on: OpenSSL support PCNTL=off: pcntl support (CLI only) PDF=off: PDFlib support (implies GD) PDO=on: PHP Data Objects Interface (PDO) PDO_SQLITE=off: PDO sqlite driver PGSQL=on: PostgreSQL database support PHAR=off: phar support POSIX=off: POSIX-like functions PSPELL=off: pspell support READLINE=on: readline support (CLI only) RECODE=off: recode support SESSION=on: session support SHMOP=off: shmop support SIMPLEXML=off: simplexml support SNMP=off: SNMP support SOAP=off: SOAP support SOCKETS=off: sockets support SQLITE3=off: sqlite3 support SYBASE_CT=off: Sybase database support SYSVMSG=off: System V message support SYSVSEM=off: System V semaphore support SYSVSHM=off: System V shared memory support TIDY=off: TIDY support TOKENIZER=off: tokenizer support WDDX=off: WDDX support (implies XML) XML=on: XML support XMLREADER=off: XMLReader support XMLRPC=off: XMLRPC-EPI support XMLWRITER=off: XMLWriter support XSL=on: XSL support (Implies DOM) ZIP=off: ZIP support ZLIB=on: ZLIB support === Use 'make config' to modify these settings rwsrv03# rwsrv03# cat /var/db/ports/php5-extensions/options # This file is auto-generated by 'make config'. # Options for php5-extensions-1.7 _OPTIONS_READ=php5-extensions-1.7 _FILE_COMPLETE_OPTIONS_LIST=BCMATH BZ2 CALENDAR CTYPE CURL DBA DOM EXIF FILEINFO FILTER FTP GD GETTEXT GMP HASH ICONV IMAP INTERBASE JSON LDAP MBSTRING MCRYPT MSSQL MYSQL MYSQLI ODBC OPENSSL PCNTL PDF PDO PDO_SQLITE PGSQL PHAR POSIX PSPELL READLINE RECODE SESSION SHMOP SIMPLEXML SNMP SOAP SOCKETS SQLITE3 SYBASE_CT SYSVMSG SYSVSEM SYSVSHM TIDY TOKENIZER WDDX XML XMLREADER XMLRPC XMLWRITER XSL ZIP ZLIB OPTIONS_FILE_UNSET+=BCMATH OPTIONS_FILE_UNSET+=BZ2 OPTIONS_FILE_SET+=CALENDAR OPTIONS_FILE_SET+=CTYPE OPTIONS_FILE_UNSET+=CURL OPTIONS_FILE_UNSET+=DBA OPTIONS_FILE_SET+=DOM OPTIONS_FILE_UNSET+=EXIF OPTIONS_FILE_UNSET+=FILEINFO OPTIONS_FILE_UNSET+=FILTER OPTIONS_FILE_UNSET+=FTP OPTIONS_FILE_SET+=GD OPTIONS_FILE_SET+=GETTEXT OPTIONS_FILE_UNSET+=GMP OPTIONS_FILE_SET+=HASH OPTIONS_FILE_SET+=ICONV OPTIONS_FILE_UNSET+=IMAP OPTIONS_FILE_UNSET+=INTERBASE OPTIONS_FILE_UNSET+=JSON OPTIONS_FILE_SET+=LDAP
Re: Ruby 1.9 as default
On Jun 1, 2012, at 10:30 PM, Stanislav Sedov wrote: On Fri, 01 Jun 2012 21:32:53 -0400 Steve Wills swi...@freebsd.org mentioned: Hi All, I think we should try to make Ruby 1.9 the default Ruby again and would like to see it done before 9.1 is released. I've submitted a patch which does this and requested and exp-run from portmgr. I would like to get feedback on this idea. If you have experience with Ruby 1.9 as default, good or bad, please speak up. You can test this by setting RUBY_DEFAULT_VER=1.9 in /etc/make.conf or editing Mk/bsd.ruby.mk and setting the same variable there. I'm not sure it's a good idea. Ruby 1.9 still has some nasty bugs on FreeBSD, related to the threads and fork. That is fork in ruby 1.9 hangs sometimes... Could you give me some more info on this? If I can reproduce it perhaps I can track it down and solve it. OTOH, I've been running ruby 1.9 as default on both of my desktops and have not seen major problems except this one. Still, it'd be nice for someone to fix it first (I remember there were a lot of eager commiters at the time I gave up my commit bit). The main question is whether the switch to 1.9 will be beneficial for our users. Apart from some libraries targeting 1.9 exclusivly now, most of of them still work with 1.8 and there're still some that work with 1.8 only. Given that most of the ports users mostly care for 3rd party applications to work, I'm not sure if the switch to 1.9 will be a win for them... Isn't 1.9 a bit faster than 1.8? And 1.8 doesn't build with clang while 1.9 does, so we'll at least want to switch it before 10.0 comes out, IMHO. Also, 1.9 has been the default version from ruby-lang.org for a long time and the community is making good progress towards moving to 1.9 over all. I think most things work with 1.9 now, but I could be wrong. Are there specific apps that you are thinking of that don't work with 1.9? 1.9 definitely seems to pass all the tests that 1.8 passes and more. As far as what users of ports want, the point of this mail was to get them to speak up and voice their opinions. :) BTW, do you use 1.8 or 1.9? Actually, I'm betting you use Rubinius now that I think about it, no? Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ruby 1.9 as default
The community is indeed moving to 1.9 and 1.8 is nearing end of life. I have been using 1.9 on FreeBSD for months now without any issues, and I would suggest we switch and try to iron out any remaining issues. Jos ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: make failed for graphics/gdk-pixbuf2 and also for devel/gobject-introspection
2012-06-01 13:01, Thomas Mueller skrev: On Fri, 01 Jun 2012 10:34:27 +0200, Leslie Jensen wrote: [...] ImportError: /usr/local/lib/gobject-introspection/giscanner/_giscanner.so: Undef ined symbol PyUnicodeUCS4_AsUTF8String gmake[4]: *** [GdkPixbuf-2.0.gir] Fel 1 gmake[4]: Lämnar katalogen Rebuilding devel/gobject-introspection fixed that problem for me. I tried that with failure and then I did make deinstall followed by make reinstall and unfortunately the same result. So what do I do now? Command '['/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.1 0.8/tests/scanner/tmp-introspectaTSYlw/Regress-1.0', '--introspect-dump=/usr/por ts/devel/gobject-introspection/work/gobject-introspection-0.10.8/tests/scanner/t mp-introspectaTSYlw/types.txt,/usr/ports/devel/gobject-introspection/work/gobjec t-introspection-0.10.8/tests/scanner/tmp-introspectaTSYlw/dump.xml']' returned n on-zero exit status 1 gmake[4]: *** [Regress-1.0.gir] Fel 1 gmake[4]: Lämnar katalogen /usr/ports/devel/gobject-introspection/work/gobject- introspection-0.10.8/tests/scanner gmake[3]: *** [all-recursive] Fel 1 gmake[3]: Lämnar katalogen /usr/ports/devel/gobject-introspection/work/gobject- introspection-0.10.8/tests gmake[2]: *** [all] Fel 2 gmake[2]: Lämnar katalogen /usr/ports/devel/gobject-introspection/work/gobject- introspection-0.10.8/tests gmake[1]: *** [all-recursive] Fel 1 gmake[1]: Lämnar katalogen /usr/ports/devel/gobject-introspection/work/gobject- introspection-0.10.8 gmake: *** [all] Fel 2 *** Error code 1 Stop in /usr/ports/devel/gobject-introspection. === make failed for devel/gobject-introspection === Aborting update === Update for gobject-introspection-0.10.8_2 failed === Aborting update ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
