overlay troubles with mplayer

[[LoN]Kamikaze]

The following scenario

FreeBSD 7.0-Beta-2 on i386 with a Radeon Mobility 7500

$ xrandr
Screen 0: minimum 320 x 200, current 2464 x 900, maximum 3072 x 1536
VGA-0 connected 1440x900+1024+0 (normal left inverted right x axis y axis)
410mm x 257mm
   1440x900   59.9*+   75.0 59.9
LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768   59.9*+   60.0
S-video disconnected (normal left inverted right x axis y axis)


I want to play a video on the right screen (external 16:10 LCD screen) with
mplayer. Moving the window to the screen and resizing works fine, but as soon
as I hit F for the full screen mode the video is scaled inside a 1024x768
region in the top left corner of screen (the remaining space is black), as if
it was meant to be drawn on the first screen.

The workaround is to make the larger screen the primary one by moving it to
the left

$ xrandr --output VGA-0 --left-of LVDS

I don't know weather this is a bug in mplayer or in xorg, so I'm sending this
to ports@ and [EMAIL PROTECTED]

Suggestions about the cause as well as workarounds that don't require me to
move the monitors around (from an xrandr perspective) are highly appreciated.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: suggestions for ports screening

[[LoN]Kamikaze]

Chuck Robey wrote:
> ...

This might either turn into a bikeshed or a creative brainstorming. I hope for
the latter, so I take part.

> Anyhow, here's the suggestion.  The system we have, currently, is
> basically dependent on people who write ports instrumenting options to
> include or not include various options.  A very large portion of those
> options are written up in such a way as to make it nearly impossible for
> a non-expert to figure out if a particular option is good for their use
> of not.

My rule of thumb is to stick to the defaults if I don't know what I'm doing. I
think that could be put mentioned in the handbook, just to make beginners feel
more confident about what they're doing.

> An example?  If a programmer asks you if you want the blotz program (I
> make up great fake names, don't I?) hows the user going to know the the
> blotz program is a particular sound program, when they have no sound card?

That problem really exists, though.

> There are ways to fix this, you know.  Read on.
> 
> OK, My suggestion is for a two level system (yes, some of you are going
> to recognize some of this from other OSes.  G'wan, brag about it).  The
> first part is a small list of keywords (well, not terribly small, maybe
> 100-200 of them, but most user's personal lists would be far shorter).
> These words are descriptive of the sort of machine environment the user
> wants, like, they might have the words SOUND, FMRADIO and TELEVISION to
> show that they care to have those sort of dependencies built.  All ports
> would be required to export a list of words that they check for, before
> they  build.  If a browser sees no SOUND word, it requires to sound
> dependencies be built.

I like the sound of that. It might be a bigger change that would have to be
implemented into ports over a long period of time. And of course it would only
appear in ports where maintainer are willing to spend the time to support it.

> These dependencies can show up on the list in the form of KEYWORD=VALUE,
> where value can be used to point towards a user's preference.  A user
> might set BROWSER=www/seamonkey,www/mozilla in the list, so this gives a
> port all the info it would need to match dependencies nicely, without
> having to get interactive about it.

How would you deal with cases in which following the users wishes is not
supported. What if a user has SOUND=direct defined to tell programs to use
/dev/dsp instead of a sound server like arts or estd? Most KDE applications
only work with arts, no matter how much you wish otherwise.

> OK, this is only the first part ... the second part is a list of the
> names of ports.  This REJECT list serves as a rejection filter: if a
> port finds it's way upon that list, it can't get put on any dependency
> list at all.  I, personally, never like any Samba ports, so I could
> stick all the Samba ports on the REJECT list, or I could just fail to
> put SAMBA as a keyword.  My choice, although if I stuck a particular set
> of ports on that list, I'd have to watch new ports, so  new Samba port
> didn't sneak past me.  Still, it would allow a user to really have all
> the control anyone could ask for. or they could ignore it and still not
> face disaster as long as they maintained the KEYWORD list.

That's kinda possible already.

.if ${.CURDIR:M*/ports/*samba*}
IGNORE= I don't like samba!
.endif

This would keep everything with samba in the name from being built. I don't
know how the depending ports would react to that, though.

> 3 stale to the first programmer who notices where I stole the idea from,
> and a used mousetrap to him (or her?) who knows the correct name of the
> KEYWORD list.  If you hate the idea, just say so, believe me I will be
> catching all responses, and I will report your overwhelming acceptance
> or rejection, as the case may be.  It shouldn't take a master's degree
> to guess my own opinion.

I came over from an OS without a package system (Windows), so I've got no idea
where you took all that from.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Error upgrading firefox to 2.0.0.9

[[LoN]Kamikaze]

Norberto Meijome wrote:
> On Wed, 07 Nov 2007 07:27:30 +0100
> "[LoN]Kamikaze" <[EMAIL PROTECTED]> wrote:
> 
>> Norberto Meijome wrote:
>>> hi,
>>> Anyone can shed any light on this?
>>>
>>> portupgrade -p firefox
>>> []
>> Well, are you using any unusual CFLAGS? I don't see any CFLAGS at all, which
>> is odd, because FreeBSD supplies default values.
> 
> nothing in make.conf :

Then I'd guess it's a dependency problem. Try portupgrade -R
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Error upgrading firefox to 2.0.0.9

[[LoN]Kamikaze]

Norberto Meijome wrote:
> hi,
> Anyone can shed any light on this?
> 
> portupgrade -p firefox
> []
> 
> cc -o experimental.o -c -I../../../dist/include/system_wrappers -include 
> ../../../config/gcc_hidden.h -DSQLITE_ENABLE_REDEF_IO 
> -DSQLITE_SECURE_DELETE=1 -DTHREADSAFE=1 -DOSTYPE=\"FreeBSD7\" 
> -DOSARCH=\"FreeBSD\" -DBUILD_ID=00 -I.  
> -I../../../dist/include/sqlite3 -I../../../dist/include 
> -I/usr/local/include/nspr -I/usr/local/include -I/usr/local/include 
> -I/usr/include -I../../../dist/sdk/include -I/usr/local/include   -fPIC 
> -I/usr/local/include/nss -I/usr/local/include/nss/nss  -I/usr/local/include  
> -I/usr/local/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align 
> -Wno-long-long -O2 -fno-strict-aliasing -pipe -march=pentium-m -O2 
> -fno-strict-aliasing -O2 -pipe  -DNDEBUG -DTRIMMED -O2  
> -I/usr/local/include/nss -I/usr/local/include/nss/nss  -I/usr/local/include  
> -I/usr/local/include -include ../../../mozilla-config.h -DMOZILLA_CLIENT 
> experimental.c
> expr.c
> cc -o expr.o -c -I../../../dist/include/system_wrappers -include 
> ../../../config/gcc_hidden.h -DSQLITE_ENABLE_REDEF_IO 
> -DSQLITE_SECURE_DELETE=1 -DTHREADSAFE=1 -DOSTYPE=\"FreeBSD7\" 
> -DOSARCH=\"FreeBSD\" -DBUILD_ID=00 -I.  
> -I../../../dist/include/sqlite3 -I../../../dist/include 
> -I/usr/local/include/nspr -I/usr/local/include -I/usr/local/include 
> -I/usr/include -I../../../dist/sdk/include -I/usr/local/include   -fPIC 
> -I/usr/local/include/nss -I/usr/local/include/nss/nss  -I/usr/local/include  
> -I/usr/local/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align 
> -Wno-long-long -O2 -fno-strict-aliasing -pipe -march=pentium-m -O2 
> -fno-strict-aliasing -O2 -pipe  -DNDEBUG -DTRIMMED -O2  
> -I/usr/local/include/nss -I/usr/local/include/nss/nss  -I/usr/local/include  
> -I/usr/local/include -include ../../../mozilla-config.h -DMOZILLA_CLIENT 
> expr.c
> expr.c: In function 'lookupName':
> expr.c:1031: warning: comparison between signed and unsigned
> gmake[3]: *** No rule to make target `func.c', needed by `func.o'.  Stop.
> gmake[3]: Leaving directory 
> `/usr/ports/www/firefox/work/mozilla/db/sqlite3/src'
> ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.85508.0 
> env UPGRADE_TOOL=portupgrade UPGRADE_PORT=firefox-2.0.0.8,1 
> UPGRADE_PORT_VER=2.0.0.8,1 make DEPENDS_TARGET=package
> ** Fix the problem and try again.
> ** Listing the failed packages (*:skipped / !:failed)
> ! www/firefox (firefox-2.0.0.8,1)   (unknown build error)
> --->  Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed
> 
> ports tree up to date, 
> $ uname -a
> FreeBSD ayiin.xxx.com.au 7.0-BETA2 FreeBSD 7.0-BETA2 #0: Sat Nov  3 11:48:34 
> EST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AYIIN-7  i386
> 
> thx

Well, are you using any unusual CFLAGS? I don't see any CFLAGS at all, which
is odd, because FreeBSD supplies default values.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Diablo on 7.0-BETA

[[LoN]Kamikaze]

Peter Thoenen wrote:
> I don't get an error to be honest.
> 
> I maintain both games/ftjava and games/sfbol and when I run them they
> simply don't work.  A window pops up for a second or so and then closes.
>If I add -verbose to the wrappers I see no errors either.  They
> worked fine on 6.x though.  I can troubleshoot them more but not sure
> how .. pointers?
> 
> -Peter

I tested them with jdk-1.6 and they work. It might be a compat problem.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Diablo on 7.0-BETA

[[LoN]Kamikaze]

Peter Thoenen wrote:
> The Java JDK binary put out by the FBSD Foundation.  While only 5.x and
> 6.x binaries are out, either they should work on 7.0 or it should be
> marked broken on 7.0 in the port tree (instead of letting me install it
> via ports).
> 
> NOT the game

I'd rather add a dependency to COMPAT6x
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

to bsdadminscripts users

[[LoN]Kamikaze]

Since the new release wasn't committed before the freeze I recommend you to
update your ports manually if you combine the use of ccache and distcc.

The new release changes the handling of this combination to allow ccache to
detect compiler changes and not to mistake distcc changes for compiler changes.

Also the new version introduces a script called pkg_libchk. The command
'pkg_libchk -q' will list all packages that need to be rebuild because they
link to libraries in /usr/local/lib/compat or link to a missing library. This
is useful after a major upgrade to avoid a 'portupgrade -fa'.

It also helps you to find the packages that need to be rebuild after a
portupgrade to delete the contents in /usr/local/lib/compat/pkg. After all
having outdated libraries lying around on your system can turn out to be a
security risk.

The patch can be obtained in the following way:
# cd /usr/ports
# fetch -o bsda 'http://www.freebsd.org/cgi/query-pr.cgi?prp=117533-1-diff'
# patch < bsda
# rm bsda

Afterwards you can upgrade sysutils/bsdadminscripts.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: the coming cold ... I mean freeze

[[LoN]Kamikaze]

Mark Linimon wrote:
> On Tue, Oct 30, 2007 at 11:35:48PM +0100, [LoN]Kamikaze wrote:
>> I put a lot of effort to get the release done (4 days) before the freeze. So
>> it's kind of frustrating that it doesn't get in.
> 
> I sympathize, but if we let one update in, it is very difficult to not let
> them all in.  We (portmgr) will have several hundred approval requests just
> for bugfixing during the freeze.
> 
> At some point you simply have to say "today's the day" and draw a line,
> otherwise, the release process will never get done.
> 
> mcl
> 

I understand this, of course. It's just bad luck that no one picked up the PR
before the freeze. I often had my PRs committed within minutes of writing the
PR. This time no one took it within 4 days.
Well, it's my fault to rely on something that cannot be relied on.

When the ports page on bsdstats was still open it said that only between 10
and 20 people (I do not remember the exact figure) use my port, so it ain't
that bad.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: the coming cold ... I mean freeze

[[LoN]Kamikaze]

Mark Linimon wrote:
> On Tue, Oct 30, 2007 at 09:54:54AM +0100, [LoN]Kamikaze wrote:
>> I hope that when the freeze comes (wasn't that supposed to happen today?) the
>> maintainer updates from before the freeze will still get committed.
> 
> No, the idea is that during the freeze period we turn our attention to
> fixing bugs and get as many packages building as possible.  If an
> update is the only way to do that, fine.  Otherwise, there's not much
> point in having a freeze.
> 
> mcl
> 

I put a lot of effort to get the release done (4 days) before the freeze. So
it's kind of frustrating that it doesn't get in.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

the coming cold ... I mean freeze

[[LoN]Kamikaze]

I hope that when the freeze comes (wasn't that supposed to happen today?) the
maintainer updates from before the freeze will still get committed. It seems
that under the current workload the committing takes a little longer than usual.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Appropriate way of submitting multiple related ports at once?

[[LoN]Kamikaze]

Boris Samorodov wrote:
> On Sat, 20 Oct 2007 16:09:56 +0200 [LoN]Kamikaze wrote:
>> Q wrote:
> 
>>> I have written a collection of ports (16 in total) for building a
>>> typical Apple WebObjects deployment environment. As most of these ports
>>> depend on one another in some way could someone advise what the most
>>> appropriate way to submit these ports as a bundle would be?
> 
>> Why don't you just pack them all into a single shar archive and submit them 
>> as
>> one PR? That's what I'd do.
> 
> I'd say that this depends upon the sibmitters' experience with ports
> PRs. If there is none committers' questions, etc at the PR - it's
> fine. Otherwise I'd prefer to deal with ports per PR.
> 
> 
> WBR

Well, you can submit several shar files in one PR and they can be tested,
patched and commited one by one. The PR simply would be closed after all ports
have successfully been committed.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Appropriate way of submitting multiple related ports at once?

[[LoN]Kamikaze]

Q wrote:
> Hi,
> 
> I have written a collection of ports (16 in total) for building a
> typical Apple WebObjects deployment environment. As most of these ports
> depend on one another in some way could someone advise what the most
> appropriate way to submit these ports as a bundle would be?
> 
> Thanks.
> 

Why don't you just pack them all into a single shar archive and submit them as
one PR? That's what I'd do.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: graphics/OpenEXR fails

[[LoN]Kamikaze]

Paul Schmehl wrote:
> I'm getting failures when trying to upgrade OpenEXR.
> 
> /usr/bin/ld: warning: libHalf.so.4, needed by
> /usr/local/lib/libIlmImf.so, may conflict with libHalf.so.6
> /usr/bin/ld: warning: libIex.so.4, needed by
> /usr/local/lib/libIlmImf.so, may conflict with libIex.so.6
> /usr/bin/ld: warning: libIlmThread.so.4, needed by
> /usr/local/lib/libIlmImf.so, may conflict with libIlmThread.so.6
> 
> Would it work to delete the old libs and then symlink from the newer ones?
> 

a) Don't symlink libraries, make entries in libmap.conf.

b) The best solution would be to rebuild the port /usr/local/lib/libIlmImf.so
belongs to. I suppose lib*.so.4 are in /usr/local/lib/compat/pkg, because
there normally aren't several versions of one library available.

I'll soon release a script that lists packages that link against libraries in
/usr/local/lib/compat or are linked with missing libraries in a
sysutils/bsdadminscripts release.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Weird problem with ports

[[LoN]Kamikaze]

Luchezar Petkov wrote:
> [LoN]Kamikaze wrote:
>> Luchezar Petkov wrote:
>>> Hello,
>>> First, let me note that I'm not subscribed to this list, so CC me.
>>> Now, about my problem. I've installed -CURRENT from the latest snapshot,
>>> it worked perfectly. Now, after 2 days with -CURRENT, for some reason
>>> all ports refuse to install, giving me weird errors. Example:
>>> (Inkscape is not installed, hence the src tarball is not in distfiles, etc.)
>>>
>>> lilly# cd /usr/ports/graphics/inkscape/
>>> lilly# make install clean
>>> cd: can't cd to /usr/ports/graphics/inkscape/work/inkscape-0.45.1
>>> *** Error code 2
>>> ===>  Cleaning for inkscape-0.45.1
>>> 1 error
>> make -j
>>
>> is broken on the 7-branch. Do you have something like MAKE_ARGS=-j4 in your
>> make.conf? Weather this is the case or not, try to run
>>
>> make -B
>>
> 
> Apparently that was the case. Afaik -j isnt working for ports, but is
> working for base and other apps the user is compiling by hand. Didn't
> knew it will break my whole ports system. :-)
> Thank you very much.
> 

It breaks buildkernel for me, too. This is why I think it's not a ports, but a
make bug.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Weird problem with ports

[[LoN]Kamikaze]

Luchezar Petkov wrote:
> Hello,
> First, let me note that I'm not subscribed to this list, so CC me.
> Now, about my problem. I've installed -CURRENT from the latest snapshot,
> it worked perfectly. Now, after 2 days with -CURRENT, for some reason
> all ports refuse to install, giving me weird errors. Example:
> (Inkscape is not installed, hence the src tarball is not in distfiles, etc.)
> 
> lilly# cd /usr/ports/graphics/inkscape/
> lilly# make install clean
> cd: can't cd to /usr/ports/graphics/inkscape/work/inkscape-0.45.1
> *** Error code 2
> ===>  Cleaning for inkscape-0.45.1
> 1 error

make -j

is broken on the 7-branch. Do you have something like MAKE_ARGS=-j4 in your
make.conf? Weather this is the case or not, try to run

make -B
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Missing libstdc++.so.6 for openoffice in stable

[[LoN]Kamikaze]

Brian Josefsen wrote:
> [LoN]Kamikaze wrote:
>> Brian Josefsen wrote:
>>> Hello all
>>>
>>> I installed the openoffice package
>>> ftp://ooopackages.good-day.net/pub/OpenOffice.org/FreeBSD/2.3.0/i386/FreeBSD6/OOo_2.3.0_FreeBSD62Intel_install_da.tbz
>>>
>>> yesterday, now when i try to execute openoffice.org-2.3.0 it complaints
>>> about libstdc++.so.6 is missing. As far as i remember libstdc++.so.6 is
>>> part of GCC 4.2 and therefore first availible in -current. Now, am i a
>>> moron and got everything wrong, or is this an error by whoever built
>>> this package?
>>>
>>> I simply can't allow myself 2 days to build this one.
>>
>> You can install lang/gcc42 to get the file.
> 
> Ok, never thought of that. Will that involve any problems for me if i
> upgrade to -CURRENT or 7-release when it's ready ?

This will not cause problems, however the package will still be linked against
 lang/gcc42, because that's what it was built with. You have to build it on 7
to have it linked against base libraries.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Xorg initial resolution broken

[[LoN]Kamikaze]

Mark Knight wrote:
> Just restarted X after various Xorg updates.  Now the server seems to be
> completely ignoring the "Modes" line in the config file's Screen/Display
> section and picking its own initial resolution.
> 
> No problem switching to the desired resolution later on when logged in.
> 
> Config and log files here:
> 
>   http://www.knigma.org.uk/scratch/resolution.txt
> 
> This configuration has worked for years so I'm sure it's down to the
> Xorg update.  Any ideas please?
> 
> Cheers,

Set PreferredMode and check for the Virtual screen size in the log, you might
have to increase that to.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: xorg-7.3 xdm ignores /etc/login.conf

[[LoN]Kamikaze]

[LoN]Kamikaze wrote:
> Since the update xdm seems to ignore environment variables set in
> /etc/login.conf such as PATH or LANG...

I have deactivated xdm in /etc/ttys and tried starting it manually from the
CLI. The problem persists, but if I instead use startx the environment is just
fine. So my assumption that xdm causes the problem is correct.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

xorg-7.3 xdm ignores /etc/login.conf

[[LoN]Kamikaze]

Since the update xdm seems to ignore environment variables set in
/etc/login.conf such as PATH or LANG. I've tried inserting

printenv > ~/.env

into my ~/.xsession and the result looks rather bleak. E.g. PATH looks like 
this:
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/gnu/bin:/usr/local/bin

Which seems to be some kind of xdm default. LANG is not even set.

Executing
su - $USER

leads to the correct PATH and LANG settings:
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/kamikaze/bin
LANG=en_GB.UTF-8
MM_CHARSET=UTF-8

But of course this will cast away variables like DISPLAY, so putting the line
into my .xsession is not really a satisfying solution.

Does anyone else encounter this problem? Are there any suggestions how to get
behind the reason or even a solution?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

x11/ecore outdated

[[LoN]Kamikaze]

Hello,

I wanted to port entrance, but it seems the ecore Snapshot in ports is too old.
Is there an update to be expected?

Regards
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [EMAIL PROTECTED]: freehdl-0.0.4_1 failed on amd64 7]

[[LoN]Kamikaze]

Kris Kennaway wrote:
> FYI; can you please investigate and/or report to the developers?  If
> you are already aware of this problem but do not yet have a fix,
> please mark the port BROKEN in the appropriate case, so that users do
> not unexpectedly encounter it.
> 
> See http://pointyhat.freebsd.org for the full log.
> 
> Thanks,
> Kris

I cannot find a PR about this. So I'm just replying to the mail.

The problem only appears when the gcc4 branch is used. The freehdl developers
as well as me are mystified, because the gcc output does not contain any hints
about the nature of the problem.

I didn't find a way to check the gcc version in bsd.gcc.mk, so I don't know how
to mark it broken properly.

I had something like:

.if GCC_VERSION >= 40
BROKEN= gcc3 branch required
.endif

in mind.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports/113685: [patch] devel/subversion: install broken

[[LoN]Kamikaze]

Lev Serebryakov wrote:
> Hello bug-followup,
> 
>   Did you have `/usr/local' as symlink? Or something other non-standard in 
> your tree?
>   I can not reproduce this one, and I don't like `magic fix' without 
> understanding of problem...
> 

No, I don't have any such thing. The problem is that the subversion makefiles
are written for GNU Make and at least on my system without USE_GMAKE the
default make /usr/bin/make is used.

I don't know why it seems to work with USE_GMAKE for others, it really
shouldn't the way I see it.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports/113685: [patch] devel/subversion: install broken

[[LoN]Kamikaze]

[LoN]Kamikaze wrote:
> Lev Serebryakov wrote:
>> Hello bug-followup,
>>
>>   Did you have `/usr/local' as symlink? Or something other non-standard in 
>> your tree?
>>   I can not reproduce this one, and I don't like `magic fix' without 
>> understanding of problem...
>>
> 
> No, I don't have any such thing. The problem is that the subversion makefiles
> are written for GNU Make and at least on my system without USE_GMAKE the
> default make /usr/bin/make is used.
> 
> I don't know why it seems to work with USE_GMAKE for others, it really
> shouldn't the way I see it.

s/work with/work without/1
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

pulseaudio upgrade fails

[[LoN]Kamikaze]

The tail of the 'make install' output:

gmake[2]: Leaving directory
`/usr/obj/mobileKamikaze.norad/usr/ports/audio/pulseaudio/work/pulseaudio-0.9.6'
gmake[1]: Leaving directory
`/usr/obj/mobileKamikaze.norad/usr/ports/audio/pulseaudio/work/pulseaudio-0.9.6'
install  -o root -g wheel -m 444
/usr/obj/mobileKamikaze.norad/usr/ports/audio/pulseaudio/work/pulseaudio-0.9.6/src/default.pa
 /usr/local/etc/pulse/default.pa-dist
install  -o root -g wheel -m 444
/usr/obj/mobileKamikaze.norad/usr/ports/audio/pulseaudio/work/pulseaudio-0.9.6/src/daemon.conf
 /usr/local/etc/pulse/daemon.conf-dist
install  -o root -g wheel -m 444
/usr/obj/mobileKamikaze.norad/usr/ports/audio/pulseaudio/work/pulseaudio-0.9.6/src/client.conf
 /usr/local/etc/pulse/client.conf-dist
pw: gid `557' has already been allocated
Adding group "pulse-rt" failed...
*** Error code 1

Stop in /usr/ports/audio/pulseaudio.
*** Error code 1

Stop in /usr/ports/audio/pulseaudio.
*** Error code 1

Stop in /usr/ports/audio/pulseaudio.


Gid 557 is occupied by a group called realtime. I suspect this is a problem of
the deinstall routine of the previous version, because /usr/ports/GIDs states
it should be called pulse-rt.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ports system cvsup failure

[[LoN]Kamikaze]

David Southwell wrote:
> I missed this message on my consol
> 
> TreeList failed: Network write failure: Connection closed
> 
> There seems to be no network problem at my end.
> 
> I have just managed a connection to cvsup3 but that seems to be hanging -- so 
> maybe there is more to it.
> 
> David

Just switch to csup. Depending on your system it might even be part of your
base system. If not: net/csup.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [Call for Review] The FreeBSD German Porter's Handbook

[[LoN]Kamikaze]

Martin Wilke wrote:
> 
> For a long time questions come up again and again concerning FreeBSD
> Ports in the German Communities:
> 
> - How can I create a Port?
> - What do I have to consider?
> - Is there a documentation and where can I find it?
> 
> However, this is unfortunately only available in English, which
> complicates the access and the overall understanding for the users,
> because of the enormous amount of techchnical terms that it contains.
> 
> Since the 19.06.07, some members of Unixfreunde (http://unixfreunde.de) 
> and BSDGroup (http://bsdgroup.de) have decided to work together on this
> and future translation projects.
> 
> The result of this intense work is the Wiki article "Helping in the
> Ports" in the BSDWiki (https://www.bsdwiki.de/Helfen_in_den_Ports).
> With continuously rising man-power, we came up with the idea to create
> a German version of the Porter's Handbook.
> 
> An overview of the projects can be found at https://doc.bsdgroup.de. 
> Take a look at https://doc.bsdgroup.de/porter-book/ for the translation
> of the PH.
> 
> Everyone can contribute to the project. We are deeply grateful for your
> assistance. Please note that our main target was to translate it in the
> shortest time possible. There are most likely some errors which should
> be found and corrected soon. We look forward to any assistance from
> you. You can send us suggestions/corrections or patches in our IRC
> channel (#freebsd-doc.de on Freenode.net), by mail to [EMAIL PROTECTED] or
> to me at [EMAIL PROTECTED]
> 
> - Thanks Martin
> 

I doubt the wisdom of this. We will end up with maintainers whose English
doesn't suffice to handle PRs sufficiently. I think for developing positions,
even as simple as maintaining a small port, English is obligatory.

Just my 2¢, I know many will disagree.

- Dominic Fandrey
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PORTDOCS issue.

[[LoN]Kamikaze]

Nikolay Pavlov wrote:
> Hello guys i have this section in my Makefile:
> 
> .if !defined(NOPORTDOCS)
>   PORTDOCS= ${WRKSRC}/LICENSE.html ${WRKSRC}/README.html \
> ${WRKSRC}/changelog.html ${WRKSRC}/documentation/docs
> 
>   ${MKDIR} ${DOCSDIR};
> 
>   (cd ${WRKSRC} && ${INSTALL_DATA} \
>   LICENSE.html README.html changelog.html ${DOCSDIR});
> 
>   (cd ${WRKSRC}/documentation/docs && ${FIND} . \
>   | ${CPIO} -pdmu -R ${SHAREOWN}:${SHAREGRP} ${DOCSDIR} > /dev/null 2>&1 )
> .endif
> 
> But i am getting this error during the installation:
> 
> PORTDOCS= /home/quetzal/openfire/work/openfire_src/LICENSE.html 
> /home/quetzal/openfire/work/openfire_src/README.html  
> /home/quetzal/openfire/work/openfire_src/changelog.html 
> /home/quetzal/openfire/work/openfire_src/documentation/docs
> 
> /home/quetzal/openfire/work/openfire_src/LICENSE.html: Permission denied
> *** Error code 126
> 
> All this files exist and i am installing them as root.
> 
> [EMAIL PROTECTED]:~/openfire# ls -la 
> /home/quetzal/openfire/work/openfire_src/LICENSE.html
> -rw-r--r--  1 quetzal  quetzal  18329 22 июн 22:25 
> /home/quetzal/openfire/work/openfire_src/LICENSE.html
> 
> P.S. 
> Please CC me because i am not subscribed.
> 

Abandon the indenting.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

portupgrade creates bogus messages

[[LoN]Kamikaze]

A portupgrade -a creates the following messages:

** Package 'e17-theme-milky' has been removed from ports tree.
** Package 'e17-theme-simply_white' has been removed from ports tree.
** Package 'e17-theme-gant' has been removed from ports tree.
** Package 'e17-theme-japan2007' has been removed from ports tree.

which are bogus, since these ports do exist. It's not an origin problem as
well, I portupgrade -f'ed them all.

The problem is entirely cosmetic so I didn't file a PR. Anyway, something seems
to be wrong. Does anyone have an idea what?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [Fwd: freehdl-0.0.4_1 failed on i386 7]

[[LoN]Kamikaze]

Pav Lucistnik wrote:
> [LoN]Kamikaze píše v út 03. 07. 2007 v 16:04 +0200:
>> [LoN]Kamikaze wrote:
>>> Pav Lucistnik wrote:
>>>>  Přeposlaná zpráva 
>>>>> Od: User Ports-i386 <[EMAIL PROTECTED]>
>>>>> Komu: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
>>>>> Předmět: freehdl-0.0.4_1 failed on i386 7
>>>>> Datum: Tue, 3 Jul 2007 02:20:29 GMT
>>>>>
>>>>> ...
>>>>>
>>>>> c++ -DPACKAGE_NAME=\"freehdl\" -DPACKAGE_TARNAME=\"freehdl\"
>>>>> -DPACKAGE_VERSION=\"0.0.4\" "-DPACKAGE_STRING=\"freehdl 0.0.4\""
>>>>> -DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]" -DSTDC_HEADERS=1
>>>>> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
>>>>> -DHAVE_STRING_H=1
>>>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
>>>>> -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DYYTEXT_POINTER=1 -DHAVE_FLEXLEXER_H=1
>>>>> -DHAVE_GETOPT_H=1 -DSIZEOF_INT=4 -DHAVE_VASPRINTF=1 -DHAVE_ALLOCA=1
>>>>> -DHAVE_SOCKET=1 -I. -I. -I .. -I .. -O2 -fno-strict-aliasing -pipe -MT
>>>>> vital_timing.lo -MD -MP -MF .deps/vital_timing.Tpo -c vital_timing.cc -o
>>>>> vital_timing.o >/dev/null 2>&1
>>>>> gmake[2]: *** [vital_timing.lo] Error 1
>>>>> gmake[2]: Leaving directory 
>>>>> `/work/a/ports/cad/freehdl/work/freehdl-0.0.4/ieee'
>>>>> gmake[1]: *** [all] Error 2
>>>>> gmake[1]: Leaving directory 
>>>>> `/work/a/ports/cad/freehdl/work/freehdl-0.0.4/ieee'
>>>>> gmake: *** [all-recursive] Error 1
>>>>> *** Error code 2
>>>>>
>>>>> Stop in /a/ports/cad/freehdl.
>>>>> 
>>>>> build of /usr/ports/cad/freehdl ended at Tue Jul  3 02:20:39 UTC 2007
>>> I was able to reproduce this on 6-Stable using gcc42 from ports and I will
>>> report this to the appropriate freehdl developers. Thank you for informing 
>>> me.
>>
>> I have to revoke that statement. Neither the mailing list, nor the emails
>> listed in AUTHORS are reachable. It's as if the project was silently 
>> abandoned.
>>
>> As a workaround, please try to add USE_GCC=3.4 to cad/freehdl/Makefile and 
>> tell
>> me weather it works.
> 
> I'm afraid you're supposed to tell me if adding USE_GCC works :)
> I'd much prefer fixing the port to compile with gcc42 than forcing old
> GCC on users - GCC is 40MB download. It's probably something trivial,
> anyway. Removing >/dev/null from the Makefiles will be a good first step
> to figure it out.
> 

If only I found these >/dev/null . But autotools and GNU Make are a mystery to
me. Also I don't see why someone would hide error messages on purpose.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [Fwd: freehdl-0.0.4_1 failed on i386 7]

[[LoN]Kamikaze]

Xin LI wrote:
> Pav Lucistnik wrote:
> [...]
>> I'm afraid you're supposed to tell me if adding USE_GCC works :)
>> I'd much prefer fixing the port to compile with gcc42 than forcing old
>> GCC on users - GCC is 40MB download. It's probably something trivial,
>> anyway. Removing >/dev/null from the Makefiles will be a good first step
>> to figure it out.
> 
> Is the problem i386 specific?  Can't reproduce on my amd64 box...
> 
> Cheers,
> 

What does
# gcc --version
report?

Which version of FreeBSD are you using?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [Fwd: freehdl-0.0.4_1 failed on i386 7]

[[LoN]Kamikaze]

[LoN]Kamikaze wrote:
> Pav Lucistnik wrote:
>>  Přeposlaná zpráva 
>>> Od: User Ports-i386 <[EMAIL PROTECTED]>
>>> Komu: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
>>> Předmět: freehdl-0.0.4_1 failed on i386 7
>>> Datum: Tue, 3 Jul 2007 02:20:29 GMT
>>>
>>> ...
>>>
>>> c++ -DPACKAGE_NAME=\"freehdl\" -DPACKAGE_TARNAME=\"freehdl\"
>>> -DPACKAGE_VERSION=\"0.0.4\" "-DPACKAGE_STRING=\"freehdl 0.0.4\""
>>> -DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]" -DSTDC_HEADERS=1
>>> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
>>> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
>>> -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DYYTEXT_POINTER=1 -DHAVE_FLEXLEXER_H=1
>>> -DHAVE_GETOPT_H=1 -DSIZEOF_INT=4 -DHAVE_VASPRINTF=1 -DHAVE_ALLOCA=1
>>> -DHAVE_SOCKET=1 -I. -I. -I .. -I .. -O2 -fno-strict-aliasing -pipe -MT
>>> vital_timing.lo -MD -MP -MF .deps/vital_timing.Tpo -c vital_timing.cc -o
>>> vital_timing.o >/dev/null 2>&1
>>> gmake[2]: *** [vital_timing.lo] Error 1
>>> gmake[2]: Leaving directory 
>>> `/work/a/ports/cad/freehdl/work/freehdl-0.0.4/ieee'
>>> gmake[1]: *** [all] Error 2
>>> gmake[1]: Leaving directory 
>>> `/work/a/ports/cad/freehdl/work/freehdl-0.0.4/ieee'
>>> gmake: *** [all-recursive] Error 1
>>> *** Error code 2
>>>
>>> Stop in /a/ports/cad/freehdl.
>>> 
>>> build of /usr/ports/cad/freehdl ended at Tue Jul  3 02:20:39 UTC 2007
> 
> I was able to reproduce this on 6-Stable using gcc42 from ports and I will
> report this to the appropriate freehdl developers. Thank you for informing me.


I have to revoke that statement. Neither the mailing list, nor the emails
listed in AUTHORS are reachable. It's as if the project was silently abandoned.

As a workaround, please try to add USE_GCC=3.4 to cad/freehdl/Makefile and tell
me weather it works.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [Fwd: freehdl-0.0.4_1 failed on i386 7]

[[LoN]Kamikaze]

Pav Lucistnik wrote:
>  Přeposlaná zpráva 
>> Od: User Ports-i386 <[EMAIL PROTECTED]>
>> Komu: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
>> Předmět: freehdl-0.0.4_1 failed on i386 7
>> Datum: Tue, 3 Jul 2007 02:20:29 GMT
>>
>> ...
>>
>> c++ -DPACKAGE_NAME=\"freehdl\" -DPACKAGE_TARNAME=\"freehdl\"
-DPACKAGE_VERSION=\"0.0.4\" "-DPACKAGE_STRING=\"freehdl 0.0.4\""
-DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DYYTEXT_POINTER=1 -DHAVE_FLEXLEXER_H=1
-DHAVE_GETOPT_H=1 -DSIZEOF_INT=4 -DHAVE_VASPRINTF=1 -DHAVE_ALLOCA=1
-DHAVE_SOCKET=1 -I. -I. -I .. -I .. -O2 -fno-strict-aliasing -pipe -MT
vital_timing.lo -MD -MP -MF .deps/vital_timing.Tpo -c vital_timing.cc -o
vital_timing.o >/dev/null 2>&1
>> gmake[2]: *** [vital_timing.lo] Error 1
>> gmake[2]: Leaving directory 
>> `/work/a/ports/cad/freehdl/work/freehdl-0.0.4/ieee'
>> gmake[1]: *** [all] Error 2
>> gmake[1]: Leaving directory 
>> `/work/a/ports/cad/freehdl/work/freehdl-0.0.4/ieee'
>> gmake: *** [all-recursive] Error 1
>> *** Error code 2
>>
>> Stop in /a/ports/cad/freehdl.
>> 
>> build of /usr/ports/cad/freehdl ended at Tue Jul  3 02:20:39 UTC 2007
>

I was able to reproduce this on 6-Stable using gcc42 from ports and I will
report this to the appropriate freehdl developers. Thank you for informing me.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: +CONTENTS files

[[LoN]Kamikaze]

Garrett Cooper wrote:
> Pardon me for being naive, but wouldn't it be wiser for all of the data
> in the +CONTENTS file to be aggregated into sections instead of having
> line by line info?
> 
> Example (net/samba_3.0.25a):
> 
> @comment MD5:9e94560ac5e757d3bc5f922dcf3ab4fb
> man/man1/log2pcap.1.gz
> [~100 lines of repetitive data...]
> @comment MD5:9f5fc8df2a1383a175e165ef2e0b10cc
> man/man8/vfs_notify_fam.8.gz
> 
>Could be aggregated into:
> 
> @MD5
> 9e94560ac5e757d3bc5f922dcf3ab4fb man/man1/log2pcap.1.gz
> c58f068d603a12d4af867c15cf77e636 man/man1/nmblookup.1.gz
> [etc..]
> @end MD5
> 
>or something similar to XML.
> 
>This would reduce the filesize from n bytes to n - (9 + 4 -1) *
> i_entries + 8. In larger package files this would reduce the amount of
> data parsing by a long shot. Also, more powerful scripting languages
> like Perl, Python, or smart parsers in C could make short work of this
> data and just extract the MD5 elements for comparison.
> 
>Also, by doing a little extra work when creating packages by
> organizing all the sections together, I think that the file size could
> be reduced by a large degree.
> 
>Similar fields to @comment MD5 could be reduced I believe, but with
> less benefit maybe, other than just the @unexec rmdir, etc lines.
> 
>Either that, or the data should be organized into separate files I
> think (increases number of files, but reduces overall processing time IMO).
> 
> Thanks,
> -Garrett


In some cases the order of data stored is important and thus it cannot be
seperated into section. Also, this layout allows for very simple parsing with
usual UNIX tools (sed, cut, awk, perl, simply everything). Unlike XML, which is
rather complex and thus does not belong into base, in my opinion.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: audio/gstreamer-plugins-ivorbis does not build

[[LoN]Kamikaze]

Romain LE DISEZ wrote:
> Le Mar 26 juin 2007 21:01, [LoN]Kamikaze a écrit :
>> ===>  Building for gstreamer-plugins-ivorbis-0.10.5_2,3
>> ...
>> vorbis.c:26:23: vorbisdec.h: No such file or directory
>> vorbis.c: In function `plugin_init':
>> vorbis.c:40: warning: implicit declaration of function
>> `gst_ivorbis_dec_get_type'
>> distcc[10042] ERROR: compile vorbis.c on localhost failed
>> gmake: *** [libgstivorbis_la-vorbis.lo] Error 1
>> gmake: *** Waiting for unfinished jobs
>> *** Error code 2
>>
>>
>> Before you ask, I tried without make -j, ccache and distcc, it doesn't
>> make any
>> difference.
>>
>> The search:
>> # find /usr/obj -name vorbisdec.h
>> does not yield any results, just like
>> # find / -name vorbisdec.h
>>
>> The file simply isn't there. Am I the only person experiencing this?
> You are not alone. I have this problem since some days (weeks ?).
>
> I'm running Freebsd-CURRENT. I use portupgrade-devel to manage the ports.
>
> --
> Romain LE DISEZ


I couldn't find any PRs about this, so I opened one:
http://www.freebsd.org/cgi/query-pr.cgi?pr=114136
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: audio/gstreamer-plugins-ivorbis does not build

[[LoN]Kamikaze]

Romain LE DISEZ wrote:
> You are not alone. I have this problem since some days (weeks ?).
> 
> I'm running Freebsd-CURRENT. I use portupgrade-devel to manage the ports.

I'm running 6-Stable. I'd guess that either the distfile is incomplete or
something goes wrong during configure. Probably a port not listed as a
dependency triggers something in configure that is not supported.
I find my first guess more likely, though.<
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

audio/gstreamer-plugins-ivorbis does not build

[[LoN]Kamikaze]

===>  Building for gstreamer-plugins-ivorbis-0.10.5_2,3
if /bin/sh
/usr/obj/mobileKamikaze.norad/usr/ports/audio/gstreamer-plugins-ivorbis/work/gnome-libtool
--tag=CC --mode=compile /usr/local/bin/ccache /usr/local/bin/distcc cc
-DHAVE_CONFIG_H -I. -I. -I../..   -I/usr/local/include -I/usr/local/include
-I../../gst-libs -I../../gst-libs -D_REENTRANT
-I/usr/local/include/gstreamer-0.10 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
-I/usr/local/include   -Wall  -g   -DGST_DISABLE_DEPRECATED  -D_REENTRANT
-I/usr/local/include/gstreamer-0.10 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
-I/usr/local/include   -O2 -fno-strict-aliasing -pipe -march=pentium-m
-I/usr/local/include -MT libgstivorbis_la-vorbis.lo -MD -MP -MF
".deps/libgstivorbis_la-vorbis.Tpo" -c -o libgstivorbis_la-vorbis.lo `test -f
'vorbis.c' || echo './'`vorbis.c; \
then mv -f ".deps/libgstivorbis_la-vorbis.Tpo"
".deps/libgstivorbis_la-vorbis.Plo"; else rm -f
".deps/libgstivorbis_la-vorbis.Tpo"; exit 1; fi
if /bin/sh
/usr/obj/mobileKamikaze.norad/usr/ports/audio/gstreamer-plugins-ivorbis/work/gnome-libtool
--tag=CC --mode=compile /usr/local/bin/ccache /usr/local/bin/distcc cc
-DHAVE_CONFIG_H -I. -I. -I../..   -I/usr/local/include -I/usr/local/include
-I../../gst-libs -I../../gst-libs -D_REENTRANT
-I/usr/local/include/gstreamer-0.10 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
-I/usr/local/include   -Wall  -g   -DGST_DISABLE_DEPRECATED  -D_REENTRANT
-I/usr/local/include/gstreamer-0.10 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
-I/usr/local/include   -O2 -fno-strict-aliasing -pipe -march=pentium-m
-I/usr/local/include -MT libgstivorbis_la-vorbisfile.lo -MD -MP -MF
".deps/libgstivorbis_la-vorbisfile.Tpo" -c -o libgstivorbis_la-vorbisfile.lo
`test -f 'vorbisfile.c' || echo './'`vorbisfile.c; \
then mv -f ".deps/libgstivorbis_la-vorbisfile.Tpo"
".deps/libgstivorbis_la-vorbisfile.Plo"; else rm -f
".deps/libgstivorbis_la-vorbisfile.Tpo"; exit 1; fi
mkdir .libs
 /usr/local/bin/ccache /usr/local/bin/distcc cc -DHAVE_CONFIG_H -I. -I. -I../..
-I/usr/local/include -I/usr/local/include -I../../gst-libs -I../../gst-libs
-D_REENTRANT -I/usr/local/include/gstreamer-0.10 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
-I/usr/local/include -Wall -g -DGST_DISABLE_DEPRECATED -D_REENTRANT
-I/usr/local/include/gstreamer-0.10 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
-I/usr/local/include -O2 -fno-strict-aliasing -pipe -march=pentium-m
-I/usr/local/include -MT libgstivorbis_la-vorbis.lo -MD -MP -MF
.deps/libgstivorbis_la-vorbis.Tpo -c vorbis.c  -fPIC -DPIC -o
.libs/libgstivorbis_la-vorbis.o
 /usr/local/bin/ccache /usr/local/bin/distcc cc -DHAVE_CONFIG_H -I. -I. -I../..
-I/usr/local/include -I/usr/local/include -I../../gst-libs -I../../gst-libs
-D_REENTRANT -I/usr/local/include/gstreamer-0.10 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
-I/usr/local/include -Wall -g -DGST_DISABLE_DEPRECATED -D_REENTRANT
-I/usr/local/include/gstreamer-0.10 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
-I/usr/local/include -O2 -fno-strict-aliasing -pipe -march=pentium-m
-I/usr/local/include -MT libgstivorbis_la-vorbisfile.lo -MD -MP -MF
.deps/libgstivorbis_la-vorbisfile.Tpo -c vorbisfile.c  -fPIC -DPIC -o
.libs/libgstivorbis_la-vorbisfile.o
distcc[10044] ERROR: compile (null) on localhost failed
vorbisfile.c: In function `gst_ivorbisfile_play':
vorbisfile.c:684: warning: null format string
vorbisfile.c:684: warning: null format string
vorbisfile.c:745: warning: null format string
vorbisfile.c:745: warning: null format string
 /usr/local/bin/ccache /usr/local/bin/distcc cc -DHAVE_CONFIG_H -I. -I. -I../..
-I/usr/local/include -I/usr/local/include -I../../gst-libs -I../../gst-libs
-D_REENTRANT -I/usr/local/include/gstreamer-0.10 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
-I/usr/local/include -Wall -g -DGST_DISABLE_DEPRECATED -D_REENTRANT
-I/usr/local/include/gstreamer-0.10 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/libxml2
-I/usr/local/include -O2 -fno-strict-aliasing -pipe -march=pentium-m
-I/usr/local/include -MT libgstivorbis_la-vorbisfile.lo -MD -MP -MF
.deps/libgstivorbis_la-vorbisfile.Tpo -c vorbisfile.c -o
libgstivorbis_la-vorbisfile.o >/dev/null 2>&1
vorbis.c:26:23: vorbisdec.h: No such file or directory
vorbis.c: In function `plugin_init':
vorbis.c:40: warning: implicit declaration of function 
`gst_ivorbis_dec_get_type'
distcc[10042] ERROR: compile vorbis.c on localhost failed
gmake: *** [libgstivorbis_la-vorbis.lo] Error 1
gmake: *** Waiting for unfinished jobs
*** Error code 2


Before you ask,

Re: openoffice.org 2.2.1 on amd64

[[LoN]Kamikaze]

Oliver Lehmann wrote:
> Hi,
> 
> after updating my installed openoffice from 2.2.0 to 2.2.1 I'm now left
> with an openoffice installation where I'm not able to save files.
> 
> Everytime I try to save a file openoffice exits leaving a 0 byte file.
> Do you intend to fix this? I'll now go and try to move back to 2.2.0
> which worked if it wouldn't take ages to compile... *SIGH*
> 
> Greetings, Oliver
> 

Did you try the workaround for OO instabilities mentioned in previous threads?

OO_FORCE_DESKTOP=none or OO_FORCE_DESKTOP=kde

in the environment.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD ports: 1 unfetchable distfile: cad/freehdl

[[LoN]Kamikaze]

Bill distfiles Fenner wrote:
> Dear [EMAIL PROTECTED],
> 
>   You are listed as the FreeBSD port maintainer for 1 port
> whose distfiles are not fetchable from their MASTER_SITES.  Could
> you please visit
> 
> http://people.freebsd.org/~fenner/portsurvey/[EMAIL PROTECTED]
> 
> and correct the problems listed there?  The individual port with
> a problem is cad/freehdl.
> 
> ... 
> 
> Thanks,
>   Bill "distfiles" Fenner.
> 

I got this email a couple of weeks ago and a patch was commited within a couple
of days. Now I get it again for apparently no reason. Shouldn't there be
testing weather the problem persists, ere the mail gets resent?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: openoffice.org & SAL_IGNOREXERRORS=true, anyone else?

[[LoN]Kamikaze]

Paul Fraser wrote:
> On 6/14/07, [LoN]Kamikaze <[EMAIL PROTECTED]> wrote:
>> Arno J. Klaassen wrote:
>> > Hello,
>> >
>> > does someone else see this as well? :
> 
>> The issue seems to be GTK related. Set OOO_FORCE_DESKTOP to kde or
>> none in your
>> environment as a temporary workaround.
> 
> I can also confirm this. Does anybody have an update on an expected fix?

I've been told that the bug went away for some, after a portupgrade last week.
However, it persists for me.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

xrandr returns failed request with radeon driver

[[LoN]Kamikaze]

I have submitted a problem report about my problems with xrandr/radeon.

> http://www.freebsd.org/cgi/query-pr.cgi?pr=113861

$ xrandr
X Error of failed request:  BadRequest (invalid request code or no such 
operation)
  Major opcode of failed request:  154 (RANDR)
  Minor opcode of failed request:  6 ()
  Serial number of failed request:  9
  Current serial number in output stream:  9

Does anyone else have this problem?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a list of all kernel modules

[[LoN]Kamikaze]

Edwin Groothuis wrote:
> On Sun, Jun 17, 2007 at 09:18:55AM +0200, [LoN]Kamikaze wrote:
>> M. Warner Losh wrote:
>>> In message: <[EMAIL PROTECTED]>
>>> [EMAIL PROTECTED] (Mark Linimon) writes:
>>> : On Sun, Jun 17, 2007 at 12:42:01AM -0600, M. Warner Losh wrote:
>>> : > I'd kinda hoped there was a pseudo category that I could key off of.
>>> : 
>>> : Kinda sounds like there should be.
>>>
>>> That would make grepping the info out of INDEX easy
>> I'm with Mark here, there definitely should be one.
>>
>> I think it would be best to create it and send a HEADS UP to ports@ or to all
>> maintainers.
> 
> If you decide on a name for the category, I'll send-pr it and ask
> the maintainer of portlint to incoperate a check for it.
> 
> Edwin

The way I understand the Porter's Handbook virtual categories are introduced
simply by using them in a port. So the only work that would have to be done is
to inform maintainers and update the Porter's Handbook chapter 5.3.

Apart from that Warner's suggestion of kmod sounds very reasonable to me.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a list of all kernel modules

[[LoN]Kamikaze]

M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] (Mark Linimon) writes:
> : On Sun, Jun 17, 2007 at 12:42:01AM -0600, M. Warner Losh wrote:
> : > I'd kinda hoped there was a pseudo category that I could key off of.
> : 
> : Kinda sounds like there should be.
> 
> That would make grepping the info out of INDEX easy
> 
> Warner
> 

I'm with Mark here, there definitely should be one.

I think it would be best to create it and send a HEADS UP to ports@ or to all
maintainers.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Problem with xorg 7.2 upgrade - xorg-docs and xorg-apps

[[LoN]Kamikaze]

Hello Nasty wrote:
> 
> "[LoN]Kamikaze" <[EMAIL PROTECTED]> wrote: Hello Nasty wrote:
>> I upgraded to xorg 7.2 a while ago, and everything seems to be working well, 
>> but my ports list shows the following out-of-date ports, and I can't seem to 
>> do anything about them:
>>
>> xorg-clients-6.9.0_3<   needs updating (port has 7.2)
>> xorg-documents-6.9.0<   needs updating (port has 1.3,1)
>  
> Use pkg_delete.
> 
> I try: "pkg_delete xorg-clients".
> 
> I get: "pkg_delete: no such package 'xorg-clients' installed".
> 
> Similar for xorg-documents.
> 
> Looking at the man page for pkg_delete, I tried "-f" ("Force removal of the 
> package"), but the same thing occurred.
> 
> Am I doing something wrong? Or any other suggestions?
> 
> Thanks.

Yes, you're not using the wohle package name. Use the complete package name.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a list of all kernel modules

[[LoN]Kamikaze]

M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
>         "[LoN]Kamikaze" <[EMAIL PROTECTED]> writes:
> : I see I misunderstood, sorry about that. So how about that one:
> : 
> : # find /usr/ports/ -type f -name pkg-plist -exec grep -El
> : '[EMAIL PROTECTED]:space:]]+/boot' \{} \; | sed -E 's|^/usr/ports/||1' | 
> sed -E
> : 's|/pkg-plist$||1'
> : 
> : It only works with ports that have a pkg-plist file, though.
> 
> This won't quite work because there are things like:
> 
> % cat multimedia/pvr250/pkg-plist
> @unexec rm %%MODULESDIR%%/cxm.ko
> @unexec rm %%MODULESDIR%%/cxm_iic.ko
> bin/pvr250-setchannel
> 
> I'd kinda hoped there was a pseudo category that I could key off of.
> pvr250 is also kinda a mess too, since I can't build it w/o a CD I
> don't have...
> 
> Warner

The only completely reliable way I see is to install all ports, because the
TMPPLIST only reaches its final state in the post-install target.

Then you could use my first solution, to grep through the output of
pkg_info -qaL
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a list of all kernel modules

[[LoN]Kamikaze]

[LoN]Kamikaze wrote:
> M. Warner Losh wrote:
>> In message: <[EMAIL PROTECTED]>
>>     "[LoN]Kamikaze" <[EMAIL PROTECTED]> writes:
>> : [LoN]Kamikaze wrote:
>> : > M. Warner Losh wrote:
>> : >> Greetings,
>> : >>
>> : >> is there an easy way to get a list of all the ports that compile
>> : >> kernel modules?  I'd like to add them to my kernel build.  I did this
>> : >> once before, but I lost all information on how to do it when I lost my
>> : >> laptop's hard disk after the last bsdcan...
>> : >>
>> : >> Warner
>> : > 
>> : > # find /boot/ -type f -exec pkg_info -W \{} \;
>> : 
>> : Sorry about that, it takes very long. Better is:
>> : 
>> : # sh -c 'for mod in `pkg_info -qaL|grep -E "^/+boot"`; { pkg_info -W 
>> "$mod"; }
>>
>> This sounds great, except for one problem.  This will tell me all the
>> modules that I've installed that are from ports.  Since I've never
>> installed any from ports, this will not work for what I want.  I want
>> a list of all the ports in /usr/ports that install kernel modules.
>> I'd even settle for a list of all the ports in /usr/ports that only
>> install modules.
>>
>> Something like
>>  egrep -l '\.ko$' /usr/ports/*/*/pkg-plist | sed -e s=/pkg-plist//
>> might do the trick, but that blows the command line limits out of the
>> water.  Replacing egrep with 'find' would need to be carefully
>> constructed to avoid false positives in any work directories I have
>> laying around.  I was hoping for something a little easier to do...
>>
>> Warner
> 
> I see I misunderstood, sorry about that. So how about that one:
> 
> # find /usr/ports/ -type f -name pkg-plist -exec grep -El
> '[EMAIL PROTECTED]:space:]]+/boot' \{} \; | sed -E 's|^/usr/ports/||1' | sed 
> -E
> 's|/pkg-plist$||1'
> 
> It only works with ports that have a pkg-plist file, though.

It's all a bit tricky, now. This only returns a very small number of ports.
Changing '[EMAIL PROTECTED]:space:]]+/boot' to '[EMAIL PROTECTED]:space:]]+/' 
helps, but returns
lots of false positives, too:

archivers/dpkg
audio/mt-daapd
comms/hylafax
comms/smstools
databases/cyrus-imspd
databases/firebird-server
databases/firebird2-server
databases/sqlrelay
devel/linux-js
emulators/vmware-guestd6
emulators/snespp
emulators/its
emulators/vmware-guestd4
emulators/vmware-guestd5
games/freebsd-games
games/barrage
games/childsplay
games/lbreakout
games/wanderer
games/xpat2
german/staroffice5
mail/fetchmail
mail/dspam-devel
mail/dspam
mail/mimedefang
mail/py-spambayes
mail/zmailer
multimedia/linux-gspca-kmod
multimedia/linux-ov511-kmod
multimedia/pwcbsd
net-mgmt/cisco_conf
net-mgmt/ng_ipacct
net/acx100
net/asterisk-bristuff
net/asterisk12
net/ipvs
net/ipw-firmware-kmod
net/ipw-firmware
net/iwi-firmware-kmod
net/iwi-firmware
net/openldap23-server
net/openpbx.org
net/asterisk
net/ng_netflow
net/nvnet
net/openldap24-server
news/noffle
print/bjfilter360
print/bjfilter850
print/bjfilter850ug
print/bjfilter860
print/bjfilter870
print/bjfilters600
print/bjfilters630
print/bjfilters6300
print/bjfiltercom
russian/tac+ia
security/bioapi
security/cyrus-sasl
security/drweb
security/ipsec-tools
security/pam-pgsql
security/vncrypt
sysutils/apt
sysutils/devcpu
sysutils/fcron
sysutils/graphicboot
sysutils/heartbeat
sysutils/pmap
textproc/dixit
www/hinventory-client
www/interchange
www/linux-flashplugin9
www/middleman
www/wwwoffle
x11/nvidia-driver

I suppose these would have to be hand-checked.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a list of all kernel modules

[[LoN]Kamikaze]

M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
>         "[LoN]Kamikaze" <[EMAIL PROTECTED]> writes:
> : [LoN]Kamikaze wrote:
> : > M. Warner Losh wrote:
> : >> Greetings,
> : >>
> : >> is there an easy way to get a list of all the ports that compile
> : >> kernel modules?  I'd like to add them to my kernel build.  I did this
> : >> once before, but I lost all information on how to do it when I lost my
> : >> laptop's hard disk after the last bsdcan...
> : >>
> : >> Warner
> : > 
> : > # find /boot/ -type f -exec pkg_info -W \{} \;
> : 
> : Sorry about that, it takes very long. Better is:
> : 
> : # sh -c 'for mod in `pkg_info -qaL|grep -E "^/+boot"`; { pkg_info -W 
> "$mod"; }
> 
> This sounds great, except for one problem.  This will tell me all the
> modules that I've installed that are from ports.  Since I've never
> installed any from ports, this will not work for what I want.  I want
> a list of all the ports in /usr/ports that install kernel modules.
> I'd even settle for a list of all the ports in /usr/ports that only
> install modules.
> 
> Something like
>   egrep -l '\.ko$' /usr/ports/*/*/pkg-plist | sed -e s=/pkg-plist//
> might do the trick, but that blows the command line limits out of the
> water.  Replacing egrep with 'find' would need to be carefully
> constructed to avoid false positives in any work directories I have
> laying around.  I was hoping for something a little easier to do...
> 
> Warner

I see I misunderstood, sorry about that. So how about that one:

# find /usr/ports/ -type f -name pkg-plist -exec grep -El
'[EMAIL PROTECTED]:space:]]+/boot' \{} \; | sed -E 's|^/usr/ports/||1' | sed -E
's|/pkg-plist$||1'

It only works with ports that have a pkg-plist file, though.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a list of all kernel modules

[[LoN]Kamikaze]

[LoN]Kamikaze wrote:
> M. Warner Losh wrote:
>> Greetings,
>>
>> is there an easy way to get a list of all the ports that compile
>> kernel modules?  I'd like to add them to my kernel build.  I did this
>> once before, but I lost all information on how to do it when I lost my
>> laptop's hard disk after the last bsdcan...
>>
>> Warner
> 
> # find /boot/ -type f -exec pkg_info -W \{} \;

Sorry about that, it takes very long. Better is:

# sh -c 'for mod in `pkg_info -qaL|grep -E "^/+boot"`; { pkg_info -W "$mod"; }
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a list of all kernel modules

[[LoN]Kamikaze]

M. Warner Losh wrote:
> Greetings,
> 
> is there an easy way to get a list of all the ports that compile
> kernel modules?  I'd like to add them to my kernel build.  I did this
> once before, but I lost all information on how to do it when I lost my
> laptop's hard disk after the last bsdcan...
> 
> Warner

# find /boot/ -type f -exec pkg_info -W \{} \;
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Keeping track of automatically installed dependency-only ports

[[LoN]Kamikaze]

Stephen Hurd wrote:
> Jeremie Le Hen wrote:
>> Hi Stephen,
>>
>> On Sat, Jun 16, 2007 at 02:54:27AM -0700, Stephen Hurd wrote:
>>  
>>>  All of this rather assumes that *everything* is installed from
>>> ports.  1) install portXXX which requires SDL, so SDL gets sucked in
>>>  2) build thingYYY (which uses configure and only uses SDL if it's
>>> already  installed - common) manually and install it
>>> 
>>
>> If thingYYY detects SDL and uses it at configure stage, it should be
>> recorded in the dependency list.  I suppose this is up to the
>> maintainer to deal with this as whether the aforementioned feature
>> exists or not, nothing would prevent the user from deinstalling SDL
>> and break thingYYY otherwise.
>>   
> 
> Hrm?  In step 2, "manually" meant "Not using ports"
> That is to say that I downloaded it from Sourceforge myself, extracted
> it myself, built and installed it myself.
> 
> I do this fairly often.

When I want to use Software that is not in ports, I get it into the ports tree.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

conflicts and broken plists

[[LoN]Kamikaze]

www/apache22 forgets to install the following files:

/usr/local/www/apache22/data/apache_pb.gif
/usr/local/www/apache22/data/apache_pb.png
/usr/local/www/apache22/data/apache_pb22.gif
/usr/local/www/apache22/data/apache_pb22.png
/usr/local/www/apache22/data/apache_pb22_ani.gif
/usr/local/www/apache22/data/index.html

multimedia/gstreamer-plugins-bad forgets to install these:
/usr/local/lib/gstreamer-0.10/libgstmodplug.a
/usr/local/lib/gstreamer-0.10/libgstmodplug.la
/usr/local/lib/gstreamer-0.10/libgstmodplug.so

Also devel/apr and www/apache22 install more than 50 files into the same 
location.

Does anyone witness the same problems?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [devel/subversion] install broken

[[LoN]Kamikaze]

David Southwell wrote:
> On Thursday 14 June 2007 09:59:44 [LoN]Kamikaze wrote:
>> The installation of devel/subversion seems to be broken. Does anyone else
>> have this problem?
>>
>> My blind guess is that it's because I have set
>> WRKDIRPREFIX=/usr/obj/${HOST} in my make.conf.
>>
>> ===>  Installing for subversion-1.4.3_2
>> ===>   subversion-1.4.3_2 depends on shared library: expat.6 - found
>> ===>   subversion-1.4.3_2 depends on shared library: neon.26 - found
>> ===>   subversion-1.4.3_2 depends on shared library: apr-1.2 - found
>> ===>   subversion-1.4.3_2 depends on shared library: intl - found
>> ===>   Generating temporary packing list
>> subversion/svnversion/svnversion . /repos/svn/trunk >
>> /usr/local/include/subversion-1/svn-revision.txt
>> cannot create /usr/local/include/subversion-1/svn-revision.txt: No such
>> file or directory
>> *** Error code 2
>> 1 error
>> *** Error code 2
>>
>> Stop in /usr/ports/devel/subversion.
>> *** Error code 1
>>
>> Stop in /usr/ports/devel/subversion.
> 
> 
> I do not think  there is any connection with your problem and another one I 
> had but see ports thread:
> 
> subversion -- compile file - requires lgssapi_krb5 __SOLVED.
> 
> I have submitted a PR for that one, which has not yet been given a PR number. 
> No doubt we will hear from the maintainer sometime.  I am now working on 
> identifying another subversion problem re building of dav_svn_module which is 
> giving me a headache.
> 
> david
> 
> david

Defining USE_GMAKE=yes in the ports Makefile solves my problem.

My PR is here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=113685


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[devel/subversion] install broken

[[LoN]Kamikaze]

The installation of devel/subversion seems to be broken. Does anyone else have
this problem?

My blind guess is that it's because I have set WRKDIRPREFIX=/usr/obj/${HOST} in
my make.conf.

===>  Installing for subversion-1.4.3_2
===>   subversion-1.4.3_2 depends on shared library: expat.6 - found
===>   subversion-1.4.3_2 depends on shared library: neon.26 - found
===>   subversion-1.4.3_2 depends on shared library: apr-1.2 - found
===>   subversion-1.4.3_2 depends on shared library: intl - found
===>   Generating temporary packing list
subversion/svnversion/svnversion . /repos/svn/trunk >
/usr/local/include/subversion-1/svn-revision.txt
cannot create /usr/local/include/subversion-1/svn-revision.txt: No such file or
directory
*** Error code 2
1 error
*** Error code 2

Stop in /usr/ports/devel/subversion.
*** Error code 1

Stop in /usr/ports/devel/subversion.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: openoffice.org & SAL_IGNOREXERRORS=true, anyone else?

[[LoN]Kamikaze]

Arno J. Klaassen wrote:
> Hello,
> 
> does someone else see this as well? : 
> 
> I now need to set SAL_IGNOREXERRORS=true in order to correctly
> run openoffice.org (June 11 world & ports x86-stable).
> Otherwise it will almost immediately quit after lauch; gdb
> does not learn me more than 'Program exited with code 0116.'
> 
> I worked OK after the xorg72 upgrade, but broke after un
> update this weekend.
> I rebuild openoffice.org-2.2 from scratch (LOCALIZED_LANG=fr),
> same result.
> 
> Regards,
> 
> Arno

The issue seems to be GTK related. Set OOO_FORCE_DESKTOP to kde or none in your
environment as a temporary workaround.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: make update broken

[[LoN]Kamikaze]

Erwin Lansing wrote:
> On Wed, Jun 13, 2007 at 06:47:41PM +0200, Alex Dupre wrote:
>> [LoN]Kamikaze wrote:
>>> It still seems not to be fixed and I cannot find the PR either. Can you 
>>> give me
>>> the number?
>> I didn't open a PR, I contacted directly who proposed/committed that
>> change and portmgr. But after a couple of mail exchanges nobody took a
>> final decision (i.e. I'm still waiting a reply or an action).
>>
> As I described earlier, SUP_UPDATE, CVS_UPDATE and PORTSNAP_UPDATE are
> mutually exclusive and cannot be used at the same time.  That it worked
> before was an artifact which has been fixed.  That is doesn't work
> anymore means the designed behaviour finally has been fixed and not
> broken :-)

So you cannot maintain /usr/src if you wish to use portsnap for /usr/ports? The
intended behaviour is stupid. I would prefer a fall back to portsnap if
PORTSSUPFILE is not provided.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: make update broken

[[LoN]Kamikaze]

Alex Dupre wrote:
> [LoN]Kamikaze ha scritto:
>> Make update is broken on my system. Due to the removal of
>> PORTSNAP_UPDATE it
>> now complains about a missing PORTSSUPFILE (SUP_UPDATE is defined for
>> updating
>> /usr/src) instead of using portsnap.
> 
> I've already notified portmgr and proposed two solutions for this issue.
>  Hopefully it will be fixed soon.

It still seems not to be fixed and I cannot find the PR either. Can you give me
the number?

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ./options-descr file suggestion for ports

[[LoN]Kamikaze]

Vivek Khera wrote:
> 
> On Jun 13, 2007, at 3:36 AM, Alexander Leidinger wrote:
> 
>> First there where no OPTIONS, then OPTIONS was introduced. If you feel
>> annoyed by those ports which are not converted yet to OPTIONS (because
>> nobody felt annoyed enough to convert them), feel free to submit
>> patches for them.
> 
> personally, I'm annoyed by ports that use OPTIONS because I cannot then
> set them globally in my make.conf file (which is copied around to all my
> servers).  I have to ensure that the proper OPTIONS are set on every
> machine on which I may build a port.
> 
> Is it possible (and/or is anyone working on) a way to make the options
> setting non-interactive and pull the settings from a config file instead?

Look at the ports man page:

BATCH=yes

If not options files exist the options as set in /etc/make.conf will be used.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Portsnap files?

[[LoN]Kamikaze]

Ivan Voras wrote:
> Hi
> 
> Are files in /var/db/portsnap/files important after "portsnap update"
> has been run, or can they be deleted, from example within a cron job?
> 

They have to be downloaded again the next time "portsnap fetch" is called.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

warning to users of sysutils/bsdadminscripts

[[LoN]Kamikaze]

Users of sysutils/bsdadminscripts who use buildflags with SUBTHREADS should
avoid the update of graphics/cairo until bsdadminscripts-2.1.4 appears in the
ports.

The update thereof should of course be done before graphics/cairo.


Excerpt from the project homepage:

It has today come to my attention that some FreeBSD ports remember the -j flag
from the configure stage and thus break during install, which causes package
database corruption.

This update forces -j1 for install to solve this. Please update before
installing cairo 1.4.8, if you use buildflags with SUBTHREADS.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD ports: 1 unfetchable distfile: emulators/klh10

[[LoN]Kamikaze]

Kenneth Stailey wrote:
> --- Bill distfiles Fenner <[EMAIL PROTECTED]> wrote:
>> Dear [EMAIL PROTECTED],
>>
>>  You are listed as the FreeBSD port maintainer for 1 port
>> whose distfiles are not fetchable from their MASTER_SITES.  Could
>> you please visit
>>
>> http://people.freebsd.org/~fenner/portsurvey/[EMAIL PROTECTED]
>>
>> and correct the problems listed there?  The individual port with
>> a problem is emulators/klh10.
>>
>> ...
> 
> So sorry I run Gentoo now.

So you better file a PR to step back from maintainership, so that volunteers
don't have to wait for a time out.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: mplayer buildproblem FreeBSD 6-stable

[[LoN]Kamikaze]

Hagen Kühl wrote:
> Hi,
> since the 0.99.09 or so I can't build mplayer anymore.
> 
> Helpful information I can think of is here or attached(snipped script
> of build and make.conf). The complete build.log is at:
> http://www.stud.tu-ilmenau.de/~haku-in/mplayer_build.log
> 
> [EMAIL PROTECTED]:[~]% uname -a
> FreeBSD feanor 6.2-STABLE FreeBSD 6.2-STABLE #2: Thu May 31 12:13:02
> CEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FEANOR i386
> 
> If you need any more information, please let me know.
> Thanks in advance,
>   Hagen

WITH_DEBUG triggers

.if defined(WITH_DEBUG)

no matter what it's sat to, so it will cause many ports to actually build WITH
debugging. Setting WITH_DEBUG=no doesn't make any sense.

About your problem, try a 'portupgrade -Rf' that will take a lot of time, but
normally it solves this kind of problem.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: X.org 7.2 and Radeon question

[[LoN]Kamikaze]

Philipp Ost wrote:
> Ivan Voras wrote:
>> Philipp Ost wrote:
>>
>>> Perhaps you can get the new fglrx-driver which ATi released recently 
>>
>>
>> I didn't know about this, but I can't find it on their drivers'
>> section: http://ati.amd.com/support/driver.html - do you know more
>> about this driver (e.g. where is it)?
> 
> Sorry, I forgot that to mention: ATi only provides a driver for Linux.
> 
> But there is/was a project[0] which did a port to FreeBSD. A older
> version of this driver is hosted by Alexander Leidinger:
> http://www.leidinger.net/FreeBSD/ATI/
> 
> Personally, I do not have any experiences with this driver as my video
> card (Radeon 9250) is fully supported by X.

I have one too and Quake3 causes a panic when a level is loaded since the
upgrade to Xorg 7.2. My radeon mobility 7500 doesn't have this problem, however
there are many visual problems (flickering textures) since the upgrade. And on
both xrandr is unable to detect the available resolutions, which is
inconvenient, because I use it in many scripts and it is used by wine and
prevents the starting of Diablo 2.

Anyway, what I want to say is that Radeon support has clearly suffered.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: startup scripts executed twice after X11R6 and local merge

[[LoN]Kamikaze]

Doug Barton wrote:
> [LoN]Kamikaze wrote:
>> Maybe the suggestion to add
>>
>> local_startup="/usr/local/etc/rc.d"
>>
>> to /etc/rc.conf after the merge should be added to /usr/ports/UPDATING.
> 
> The mergebase script does that for you (and periodic too).
> 
> Doug
> 

Too bad that I merged by hand. Maybe this should be added to the list of things
the script does, so that other hand-mergers know what they have to do.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

startup scripts executed twice after X11R6 and local merge

[[LoN]Kamikaze]

Maybe the suggestion to add

local_startup="/usr/local/etc/rc.d"

to /etc/rc.conf after the merge should be added to /usr/ports/UPDATING.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

make update broken

[[LoN]Kamikaze]

Make update is broken on my system. Due to the removal of PORTSNAP_UPDATE it
now complains about a missing PORTSSUPFILE (SUP_UPDATE is defined for updating
/usr/src) instead of using portsnap.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Uggg!

[[LoN]Kamikaze]

Ade Lovett wrote:
> 
> On Jun 01, 2007, at 01:33 , Kris Kennaway wrote:
>> Download the packages from the FTP site and either reinstall them or
>> extract the +CONTENTS.  This will work best if you don't have local
>> make.conf customizations, otherwise you will see variance.
> 
> Actually, this does bring up a meta-issue that ports, pkgsrc, portage,
> all suffer from.
> 
> What happens when the metadata gets blown away (by accident, hardware
> crash, flaming meteor from Mars, etc.)
> 
> Is there anything we can do to mitigate this?
> 
> Yes.  It's an open-ended question.  I also have no obvious solution. 
> But I do see the need for such.


Talking about obvious solutions - backup and restore.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

xorg-server radeon support - working better than yesterday

[[LoN]Kamikaze]

Since todays update of xorg-server, the mesa-demos work now on my radeon 9200.
However some ports like xrandr still give opcode errors.

# xrandr
X Error of failed request:  BadRequest (invalid request code or no such 
operation)
  Major opcode of failed request:  154 (RANDR)
  Minor opcode of failed request:  6 ()
  Serial number of failed request:  9
  Current serial number in output stream:  9

Quake 3 has a similar message in its console, but it causes panics, so I don't
want to go on testing with it until xrandr works.

By the way, using xrandr -s still works.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [patch] Xorg 7.2 - graphics/mesa-demos broken for non-NVIDIA

[[LoN]Kamikaze]

Marcelo Araujo wrote:
> Hey folks!
> 
> I investigated this problem.
> I'm not sure about this!
> But, you must OPEN the PRs, for I will check it.
> You has to use for doing this, the tools, GNATS-WEB,
> ports-mgmt/porttools or sysutils/gtk-send-pr.
> 
> Best Regards.
> 

The PR is there. Please have a look, as usual it might take a couple of minutes
before it shows up.

http://www.freebsd.org/cgi/query-pr.cgi?pr=112668
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

Thomas Sparrevohn wrote:
>> If you follow the thread, there's already some success in reducing the
>> time
>> required to register ports with many dependencies. On my system
>> registering
>> x11/xorg now takes between 2 to 3 minutes instead of 10, with all the
>> changes.
>> I consider that a remarkable improvement.
> 
> Absolutely a worthy improvement - by all means lets test it
> 

Search for the archive for the second incarnation of Stephen Montgomery-Smith's
 patch to pkg_create. Besides not yet being fully functional, my work is far
less significant.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[patch] Xorg 7.2 - graphics/mesa-demos broken for non-NVIDIA

[[LoN]Kamikaze]

I appear to be stuck with blindness, I don't find where to submit patches for
the new ports-tree.

There are actually 2 mistakes in the port:
-DWITH_NVIDIA_GL=0
triggers
#ifdef WITH_NVIDIA_GL

and the patchfile that introduces the NVIDIA preprocessor macro contains #elif
where it should be #else.
diff -Pur graphics/mesa-demos.orig/Makefile graphics/mesa-demos/Makefile
--- graphics/mesa-demos.orig/Makefile   Mon May 14 08:08:47 2007
+++ graphics/mesa-demos/MakefileMon May 14 08:10:43 2007
@@ -97,8 +97,6 @@
 
 .if defined(WITH_NVIDIA_GL)
 CFLAGS+=   -DWITH_NVIDIA_GL=1
-.else
-CFLAGS+=   -DWITH_NVIDIA_GL=0
 .endif
 
 .include 
diff -Pur graphics/mesa-demos.orig/files/patch-progs-xdemos-yuvrect_client.c 
graphics/mesa-demos/files/patch-progs-xdemos-yuvrect_client.c
--- graphics/mesa-demos.orig/files/patch-progs-xdemos-yuvrect_client.c  Mon May 
14 08:08:47 2007
+++ graphics/mesa-demos/files/patch-progs-xdemos-yuvrect_client.c   Mon May 
14 08:09:29 2007
@@ -7,7 +7,7 @@
 -   glx_memory = glXAllocateMemoryMESA(dpy, screen, ImgWidth * ImgHeight * 2, 
0, 0 ,0);
 +   #ifdef WITH_NVIDIA_GL
 +  glx_memory = glXAllocateMemoryNV(ImgWidth * ImgHeight * 2, 0, 0 ,0);
-+   #elif
++   #else
 +  glx_memory = glXAllocateMemoryMESA(dpy, screen, ImgWidth * ImgHeight * 
2, 0, 0 ,0);
 +   #endif
 if (!glx_memory)
@@ -20,7 +20,7 @@
 -   glXFreeMemoryMESA(dpy, DefaultScreen(dpy), glx_memory);
 +   #ifdef WITH_NVIDIA_GL
 +  glXFreeMemoryNV(glx_memory);
-+   #elif
++   #else
 +  glXFreeMemoryMESA(dpy, DefaultScreen(dpy), glx_memory);
 +   #endif
 glXDestroyContext(dpy, ctx);
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

Garrett Cooper wrote:
> [LoN]Kamikaze wrote:
>> With Xorg updated to 7.2 many ports take much longer to register than
>> to download, build and install.
>> I think it's time to abandon the recursive pulling in of dependencies.
> 
> I think that you're missing the point of modular X; it was designed so
> that things could be plugged into one another and in the end everything
> would work as a fully functioning, cohesive system, where components
> could be prototyped, and where if there was a small change in the system
> you wouldn't have to rebuild all the components -- just the one modified
> component (and possibly the dependencies).
> 
> Initial upbringing make take a lot more time than monolithic X, but it's
> easier to maintain over the long-term.

This is not about X, but about the overhead the ports system causes. X only
triggered this discussion, because it introduced many ports with a lot of
dependencies.

If you follow the thread, there's already some success in reducing the time
required to register ports with many dependencies. On my system registering
x11/xorg now takes between 2 to 3 minutes instead of 10, with all the changes.
I consider that a remarkable improvement.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

Stephen Montgomery-Smith wrote:
> Basically I think we are stuck on making "make package-depends" go any
> faster.
> 
> However I do think that the modifications I made to pkg_create go a very
> significant way to solving the problem of registration taking so very long.
> 
> Stephen
> 

You are right about invoking make being the problem. However, I was able to
increase the performance of package-depends by 20 to 30 percent, by avoiding
recursive make calls and moving the recursion into the stack of the shell
invocation.

With my changes there's less than 10% overhead over the sum of make calls. I.e.
 for 56 seconds of make calls (x11/xorg on my system) there are only 4 more
seconds of processing, instead of 15 to 20 seconds.

The original make package-depends does some things I don't understand. Once
I've figured them out I will post my little patch here.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: xorg7.2 upgrade and glxgears

[[LoN]Kamikaze]

[LoN]Kamikaze wrote:
> Kris Kennaway wrote:
>> On Sun, May 13, 2007 at 08:05:18AM +0200, [LoN]Kamikaze wrote:
>>> David Thiel wrote:
>>>> On Sun, May 13, 2007 at 01:42:23AM +0200, [LoN]Kamikaze wrote:
>>>>> After the upgrade I don't have glxgears or glxinfo on my system. Could 
>>>>> anyone
>>>>> tell me which port they belong to?
>>>> graphics/mesa-demos.
>>> Thanks a lot for the pointer. It really doesn't look pretty on my system:
>>>
>>> cc -c -I. -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM
>>> -DHZ=100 -O2 -fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0
>>> xuserotfont.c
>>> cc -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM -DHZ=100 
>>> -O2
>>> -fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0 xrotfontdemo.o
>>> xuserotfont.o -L/usr/local/lib -lglut -lGLU -lGL -lXext -lXmu -lXi -lX11 
>>> -lm -o
>>> xrotfontdemo
>>> cc -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM -DHZ=100 
>>> -O2
>>> -fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0 
>>> yuvrect_client.c
>>> -L/usr/local/lib -lglut -lGLU -lGL -lXext -lXmu -lXi -lX11 -lm -o 
>>> yuvrect_client
>>> /var/tmp//ccK3MhR9.o(.text+0x1088): In function `main':
>>> : undefined reference to `glXAllocateMemoryNV'
>>> /var/tmp//ccK3MhR9.o(.text+0x14dd): In function `main':
>>> : undefined reference to `glXFreeMemoryNV'
>>> gmake[1]: *** [yuvrect_client] Error 1
>>> gmake[1]: Leaving directory
>>> `/usr/obj/homeKamikaze.norad/usr/ports/graphics/mesa-demos/work/Mesa-6.5.3/progs/xdemos'
>>> gmake: *** [default] Error 1
>>> *** Error code 2
>>>
>>> Stop in /usr/ports/graphics/mesa-demos.
>> Yep, broken.
>>
> 
> It seems that the WITH_NVIDIA_GL=0 triggers the ifdef statements in
> yuvrect_client.c. So I suggest this is a bug in the port. Setting
> WITH_NVIDIA_GL simply shouldn't happen.

After fixing the port it builds and installs fine. However, glxgears also
reports a failed request. I cannot help but think that mesa with radeon is 
broken.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: xorg7.2 upgrade and glxgears

[[LoN]Kamikaze]

Kris Kennaway wrote:
> On Sun, May 13, 2007 at 08:05:18AM +0200, [LoN]Kamikaze wrote:
>> David Thiel wrote:
>>> On Sun, May 13, 2007 at 01:42:23AM +0200, [LoN]Kamikaze wrote:
>>>> After the upgrade I don't have glxgears or glxinfo on my system. Could 
>>>> anyone
>>>> tell me which port they belong to?
>>> graphics/mesa-demos.
>> Thanks a lot for the pointer. It really doesn't look pretty on my system:
>>
>> cc -c -I. -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM
>> -DHZ=100 -O2 -fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0
>> xuserotfont.c
>> cc -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM -DHZ=100 
>> -O2
>> -fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0 xrotfontdemo.o
>> xuserotfont.o -L/usr/local/lib -lglut -lGLU -lGL -lXext -lXmu -lXi -lX11 -lm 
>> -o
>> xrotfontdemo
>> cc -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM -DHZ=100 
>> -O2
>> -fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0 
>> yuvrect_client.c
>> -L/usr/local/lib -lglut -lGLU -lGL -lXext -lXmu -lXi -lX11 -lm -o 
>> yuvrect_client
>> /var/tmp//ccK3MhR9.o(.text+0x1088): In function `main':
>> : undefined reference to `glXAllocateMemoryNV'
>> /var/tmp//ccK3MhR9.o(.text+0x14dd): In function `main':
>> : undefined reference to `glXFreeMemoryNV'
>> gmake[1]: *** [yuvrect_client] Error 1
>> gmake[1]: Leaving directory
>> `/usr/obj/homeKamikaze.norad/usr/ports/graphics/mesa-demos/work/Mesa-6.5.3/progs/xdemos'
>> gmake: *** [default] Error 1
>> *** Error code 2
>>
>> Stop in /usr/ports/graphics/mesa-demos.
> 
> Yep, broken.
> 

It seems that the WITH_NVIDIA_GL=0 triggers the ifdef statements in
yuvrect_client.c. So I suggest this is a bug in the port. Setting
WITH_NVIDIA_GL simply shouldn't happen.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

Lev Serebryakov wrote:
> Hello [LoN]Kamikaze,
> Sunday, May 13, 2007, 3:53:29 PM, you wrote:
> 
> 
> LK> the decision has been made long ago
>   I want to understand: WHY has such decision been made?
> 

Then I suppose you should take a look at CVS and have a look way back in time
when ports were first conceived.

My guess is that it makde some things easier to implement, like 'make clean' or
package fetching with all dependencies.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

Lev Serebryakov wrote:
> Hello Kris,
> 
> Saturday, May 12, 2007, 9:40:11 PM, you wrote:
> 
> KK> I think that before you abandon something you should first understand
> KK> it.
>   Can you explain, why we need to register "A depends on C / C required by A" 
> in A -> B -> C chain?
>   I can not see any advantages, only disadvantages:
> 
>  (1) Long registration time in case of big dependency trees
>  (2) There is no way to say quick, why port X is installed: it can have 
> zillion other ports in +REQUIRY_BY, but, really, be only optional dependency 
> of one of these ports Y (and don't needed by others, but others really need 
> Y).
>  (3) If port A has optional dependincy B and C depends on A, we need to fix C 
> registartion when A is rebuilt without B...
> 
>   I'm not smarter than ports subsystem authros and maintainers. It means, 
> that I overlook some HUGE advantage to have flatten dependency tree in every 
> port/package registartion.
>   What do I overlook?

I tried it and the change would probably require a massive overhaul of the
ports infrastructure.

Apart from that, I still think not pulling in dependencies would be better, but
the decision has been made long ago and now can hardly be reversed. Maybe
something in the scale of a summer of code project could address this, but
external tools like portupgrade would have to be changed as well.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

Kris Kennaway wrote:
> On Sun, May 13, 2007 at 10:44:19AM +0200, [LoN]Kamikaze wrote:
>> [LoN]Kamikaze wrote:
>>> Stephen Montgomery-Smith wrote:
>>>> OK chaps, this is what I came up with.  So for example, if I do "make
>>>> install" on /usr/ports/x11/xorg (having made all the dependencies), on
>>>> my computer it turns the pkg_create from taking about 4 minutes to the
>>>> blink of an eye.  Now people need to figure out how to speed up the
>>>> "make package-depends" in bsd.ports.mk, but that is beyond my abilities.
>>> I will give that a try, I've been experimenting with make a lot lately. 
>>> Thank
>>> you for your patch, the second attempt seems to work fine on my system.
>> So far I've got a 20% performance increase, not really satisfying. The 
>> trouble
>> is that for every dependency the whole bsd.port.mk and whatever else is 
>> pulled
>> in by the dependency has to be parsed again. So the only way to make a
>> significant improvement is to have a short bsd.port.mk.
> 
> Again, what evidence do you have that *that* is really the problem?
> Please try to be more scientific in your approach, it will help all of
> us to figure this out.
> 
> Kris

Well, it takes about 1 minute and 15 seconds for x11/xorg on my system, which
has 273 dependencies, with my optimizations it still takes 60 seconds.

Parsing bsd.port.mk takes an average of 0.2 seconds on my system. 0.2 * 273 =
54.6 seconds. Which looks like the major part of computation time to me.

The only way to avoid this I see, is to abandon the recursive pulling in.
Packages wouldn't know all their dependencies any more, but the dependencies
would still know what they depend on and so forth.

I will just change my system and see weather it breaks. I suspect that some
things like pkg_add -r would have to be slightly adjusted to support such a 
change.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

[LoN]Kamikaze wrote:
> Stephen Montgomery-Smith wrote:
>> OK chaps, this is what I came up with.  So for example, if I do "make
>> install" on /usr/ports/x11/xorg (having made all the dependencies), on
>> my computer it turns the pkg_create from taking about 4 minutes to the
>> blink of an eye.  Now people need to figure out how to speed up the
>> "make package-depends" in bsd.ports.mk, but that is beyond my abilities.
> 
> I will give that a try, I've been experimenting with make a lot lately. Thank
> you for your patch, the second attempt seems to work fine on my system.

So far I've got a 20% performance increase, not really satisfying. The trouble
is that for every dependency the whole bsd.port.mk and whatever else is pulled
in by the dependency has to be parsed again. So the only way to make a
significant improvement is to have a short bsd.port.mk.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: xorg7.2 upgrade and glxgears

[[LoN]Kamikaze]

Sampson Stein wrote:
> +++ [LoN]Kamikaze [freebsd] [13/05/07 08:05 +0200]:
>> David Thiel wrote:
>>> On Sun, May 13, 2007 at 01:42:23AM +0200, [LoN]Kamikaze wrote:
>>>> After the upgrade I don't have glxgears or glxinfo on my system.
>>>> Could anyone
>>>> tell me which port they belong to?
>>>
>>> graphics/mesa-demos.
>>
>> Thanks a lot for the pointer. It really doesn't look pretty on my system:
>>
>> cc -c -I. -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM
>> -DHZ=100 -O2 -fno-strict-aliasing -pipe -march=pentium4
>> -DWITH_NVIDIA_GL=0
>> xuserotfont.c
>> cc -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM
>> -DHZ=100 -O2
>> -fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0
>> xrotfontdemo.o
>> xuserotfont.o -L/usr/local/lib -lglut -lGLU -lGL -lXext -lXmu -lXi
>> -lX11 -lm -o
>> xrotfontdemo
>> cc -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM
>> -DHZ=100 -O2
>> -fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0
>> yuvrect_client.c
>> -L/usr/local/lib -lglut -lGLU -lGL -lXext -lXmu -lXi -lX11 -lm -o
>> yuvrect_client
>> /var/tmp//ccK3MhR9.o(.text+0x1088): In function `main':
>> : undefined reference to `glXAllocateMemoryNV'
>> /var/tmp//ccK3MhR9.o(.text+0x14dd): In function `main':
>> : undefined reference to `glXFreeMemoryNV'
>> gmake[1]: *** [yuvrect_client] Error 1
>> gmake[1]: Leaving directory
>> `/usr/obj/homeKamikaze.norad/usr/ports/graphics/mesa-demos/work/Mesa-6.5.3/progs/xdemos'
>>
>> gmake: *** [default] Error 1
>> *** Error code 2
>>
>> Stop in /usr/ports/graphics/mesa-demos.
>>
> It compiles for me; are you using an nvidia card?

No, ATI rv200 chipset.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

Stephen Montgomery-Smith wrote:
> OK chaps, this is what I came up with.  So for example, if I do "make
> install" on /usr/ports/x11/xorg (having made all the dependencies), on
> my computer it turns the pkg_create from taking about 4 minutes to the
> blink of an eye.  Now people need to figure out how to speed up the
> "make package-depends" in bsd.ports.mk, but that is beyond my abilities.

I will give that a try, I've been experimenting with make a lot lately. Thank
you for your patch, the second attempt seems to work fine on my system.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: xorg7.2 upgrade and glxgears

[[LoN]Kamikaze]

David Thiel wrote:
> On Sun, May 13, 2007 at 01:42:23AM +0200, [LoN]Kamikaze wrote:
>> After the upgrade I don't have glxgears or glxinfo on my system. Could anyone
>> tell me which port they belong to?
> 
> graphics/mesa-demos.

Thanks a lot for the pointer. It really doesn't look pretty on my system:

cc -c -I. -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM
-DHZ=100 -O2 -fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0
xuserotfont.c
cc -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM -DHZ=100 -O2
-fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0 xrotfontdemo.o
xuserotfont.o -L/usr/local/lib -lglut -lGLU -lGL -lXext -lXmu -lXi -lX11 -lm -o
xrotfontdemo
cc -I../../include -fPIC -pedantic -I/usr/local/include -DUSE_XSHM -DHZ=100 -O2
-fno-strict-aliasing -pipe -march=pentium4 -DWITH_NVIDIA_GL=0 yuvrect_client.c
-L/usr/local/lib -lglut -lGLU -lGL -lXext -lXmu -lXi -lX11 -lm -o yuvrect_client
/var/tmp//ccK3MhR9.o(.text+0x1088): In function `main':
: undefined reference to `glXAllocateMemoryNV'
/var/tmp//ccK3MhR9.o(.text+0x14dd): In function `main':
: undefined reference to `glXFreeMemoryNV'
gmake[1]: *** [yuvrect_client] Error 1
gmake[1]: Leaving directory
`/usr/obj/homeKamikaze.norad/usr/ports/graphics/mesa-demos/work/Mesa-6.5.3/progs/xdemos'
gmake: *** [default] Error 1
*** Error code 2

Stop in /usr/ports/graphics/mesa-demos.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: xorg7.2 upgrade and glxgears

[[LoN]Kamikaze]

vehemens wrote:
> I have the following error when running glxgears using the ATI driver:
> 
> X Error of failed request:  BadRequest (invalid request code or no such 
> operation)
>   Major opcode of failed request:  158 (DAMAGE)
>   Minor opcode of failed request:  4 ()
>   Serial number of failed request:  37
>   Current serial number in output stream:  38

I have a rv200 chipset.

After the upgrade I don't have glxgears or glxinfo on my system. Could anyone
tell me which port they belong to?

I'm using Quake3 for testing and it floods the console with the message:
Major opcode of failed request: 155
Minor opcode of failed request: 4
Serial number of failed request: 31851

The serial number is a growing number that has reached 31000 after about 2 
minutes.

Running mplayer with -vo gl or -vo gl2 will open the video window for a moment
before the program terminates with the following message:
X11 error: BadRequest (invalid request code or no such operation)

xrandr leads to the following message:
X error of failed request: BadRequest (invalid request code or no such 
operation)
Major opcode of failed request: 154 (RANDR)
Minor opcode of failed request: 6 ()
Serial number of failed request: 9
Current serial number in output stream: 9
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

Stephen Montgomery-Smith wrote:
> 
> 
> On Sat, 12 May 2007, Kris Kennaway wrote:
> 
>> On Sat, May 12, 2007 at 07:54:57PM +0200, [LoN]Kamikaze wrote:
>>>
>>>
>>> Kris Kennaway wrote:
>>>> On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote:
>>>>> With Xorg updated to 7.2 many ports take much longer to register than
>>>>> to download, build and install. I think it's time to abandon the
>>>>> recursive pulling in of dependencies.
>>>>
>>>> I think that before you abandon something you should first understand
>>>> it.  Figure out what is taking so long to register the port and then
>>>> work out whether it can be optimized.
>>>
>>> What takes so long in my opinion, is that not only the dependencies are
>>> registered as dependencies, but that the dependencies of dependencies
>>> are also
>>> registered as dependencies and so forth. Since all the commands
>>> supplied by
>>> ports walk dependencies recursively, as well as tools like
>>> portupgrade, this
>>> is unnecessary (that is, assuming that I understood bsd.port.mk
>>> correctly).
>>>
>>> To abandon this behaviour would in my opinion only have advantages.
>>
>> Go and substantiate your opinion with some facts, then we'll talk.
> 
> I've done a little poking around.  As of right now, I think that the
> registering takes a huge amount of time inside of a function called
> "sortdeps" which may be found in /usr/src/usr.sbin/pkg_install/lib/deps.c.
> 
> Stephen
> 

Thank you for looking into this. I was expecting to have to make experminental
patches for the pkg tools as well as in bsd.port.mk to back my opinion. However
I wouldn't have been able to start earlier than two weeks from now. And before
that I want to look into some acpi_ibm and psm regressions I'm experiencing
with stable.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

Kris Kennaway wrote:
> On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote:
>> With Xorg updated to 7.2 many ports take much longer to register than
>> to download, build and install. I think it's time to abandon the
>> recursive pulling in of dependencies.
> 
> I think that before you abandon something you should first understand
> it.  Figure out what is taking so long to register the port and then
> work out whether it can be optimized.

What takes so long in my opinion, is that not only the dependencies are
registered as dependencies, but that the dependencies of dependencies are also
registered as dependencies and so forth. Since all the commands supplied by
ports walk dependencies recursively, as well as tools like portupgrade, this
is unnecessary (that is, assuming that I understood bsd.port.mk correctly).

To abandon this behaviour would in my opinion only have advantages.

> Kris
> 
> P.S. Please wrap your lines so your emails may be easily read

Hope it works, now.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

RW wrote:
> On Sat, 12 May 2007 12:32:38 +0200
> "[LoN]Kamikaze" <[EMAIL PROTECTED]> wrote:
> 
>> With Xorg updated to 7.2 many ports take much longer to register than
>> to download, build and install. I think it's time to abandon the
>> recursive pulling in of dependencies.
> 
> Does that matter all that much when there are ports that take
> several hours to build?
> 
> As I see it the important figure is the total time taken to register
> all installed ports, divided by the total time to download, build and
> install them. As long as that figure remains small it doesn't really
> matter that small ports install inefficiently.


My guess is that registering takes about 15% of the total upgrade time. Is that 
a small figure?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Time to abandon recursive pulling of dependencies?

[[LoN]Kamikaze]

With Xorg updated to 7.2 many ports take much longer to register than to 
download, build and install. I think it's time to abandon the recursive pulling 
in of dependencies.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Xorg 7.2 index problem

[[LoN]Kamikaze]

Kris Kennaway wrote:
> On Fri, May 11, 2007 at 08:45:56AM +0200, [LoN]Kamikaze wrote:
>> # make index
>> Generating INDEX-6 - please wait..cut: stdin: Illegal byte sequence
>> "Makefile", line 32: warning: "/usr/bin/cut -f 1 -d '|' < 
>> /usr/ports/audio/mbrolavox/voices.conf" returned non-zero status
>>
>> Does anyone else have this problem?
> 
> Do you have a nonstandard locale set, and does this warning also occur with 
> CVS index?
> 
> Kris

My locale is en_GB.UTF-8. I don't really think this will be a problem for me, I 
do not use this port. I only downloaded the file you put up for download, so I 
do not know about CVS index. I suppose I'd have to configure something in order 
to have 'make fetchindex' get the right index for me. I won't try that until it 
turns out the reported warnings cause problems.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Xorg 7.2 index problem

[[LoN]Kamikaze]

# make index
Generating INDEX-6 - please wait..cut: stdin: Illegal byte sequence
"Makefile", line 32: warning: "/usr/bin/cut -f 1 -d '|' < 
/usr/ports/audio/mbrolavox/voices.conf" returned non-zero status

Does anyone else have this problem?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: games/sauerbraten

[[LoN]Kamikaze]

Mark Linimon wrote:
> On Tue, May 08, 2007 at 07:49:02AM +0200, [LoN]Kamikaze wrote:
>> Submit a PR and request a maintainer timeout. This will take a long time,
>> but it's the only way.
> 
> "long time" = "2 weeks"
> 
> mcl

The last time I requested a maintainer time out it was something like two 
months.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to prevent make compiling a binary?

[[LoN]Kamikaze]

Stevan Tiefert wrote:
> Am Montag, den 07.05.2007, 20:12 +0400 schrieb Stanislav Sedov:
>> On Mon, 07 May 2007 17:05:26 +0200
>> Stevan Tiefert <[EMAIL PROTECTED]> mentioned:
>>
>>> Hello list,
>>>
>>> I've tar'ed and gzip'ed a binary library. Put on a web-server. Wrote a
>>> Makefile like the Porter's Handbook describes. It fetches the *.tar.gz
>>> and so on.
>>>
>>> But during the "make install" he asks for a Makefile (I think
>>> PORTNAME/work/DISTNAME/Makefile) but there is no Makefile because it is
>>> not needed. The library is compiled!
>>>
>>> I thought the "NO_BUILD= yes" would be enough. But it seems I need
>>> addiotional work.
>>>
>>> Again: I want to prevent make to search for */work/*/Makefile!
>>>
>>> Can somebody kick me to the right direction?
>> NO_BUILD should generally work. Could you, please, post the entire
>> Makefile here for us to help you?
>>
>> --
>> Stanislav Sedov
>> ST4096-RIPE
> 
> Thank you for trying helping me. I am very thankfully but with the
> "do-install:" -thing is it working!!! :-)  I have already posted my port
> via send-pr.

For a binary port you will also have to set ONLY_FOR_ARCHS in your ports 
Makefile. Also, I do not know what kind of irresistible magic is performed by 
your library, but I do not think many people will be willing to use a 
pre-compiled library.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: games/sauerbraten

[[LoN]Kamikaze]

Sam Stein wrote:
> There is a new version out; the port has an old one, the new version works
> fine; I've emailed the maintainer twice; no reply.. what should I do now?

Submit a PR and request a maintainer timeout. This will take a long time, but 
it's the only way.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg upgrade plans

[[LoN]Kamikaze]

mal content wrote:
>> /usr/local
> 
> Hello.
> 
> Why is FreeBSD using /usr/local instead of /usr/X11R7?
> 
> thanks,
> MC

A version dependant directory structure hasn't been a good idea in the first 
place. No one was really able to tell weather to put a port into /usr/X11R6 or 
/usr/local anyway.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Packages not respecting DESTDIR ( perl5.8 )

[[LoN]Kamikaze]

Steven Hartland wrote:
> [LoN]Kamikaze wrote:
>> Steven Hartland wrote:
>>> I'm trying to install ports into a jail but even some
>>> key ports like don't seen to support this option
>>> even to the extent they appear to break the host OS
>>> deleting files.
>>>
>>> I'm assuming this shouldn't be the case?
>>
>> I don't see DESTIR mentioned in ports(7) or in the Porters' Handbook,
>> how did you acquire this assumption?
>>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html

I suppose this version of the Handbook has not yet found its way into 6-STABLE, 
because my local copy only mentions PREFIX in this chapter.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Packages not respecting DESTDIR ( perl5.8 )

[[LoN]Kamikaze]

Steven Hartland wrote:
> I'm trying to install ports into a jail but even some
> key ports like don't seen to support this option
> even to the extent they appear to break the host OS
> deleting files.
> 
> I'm assuming this shouldn't be the case?

I don't see DESTIR mentioned in ports(7) or in the Porters' Handbook, how did 
you acquire this assumption?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

install fails because / is not writeable

[[LoN]Kamikaze]

Once in a while a port fails to upgrade, because it wants to write something in 
/etc. E.g. perl into /etc/make.conf or other ports into /etc/group.

On my systems / is normally a read only mount. These ports build fine during a 
portupgrade and fail during install, leaving most of the port installed, but 
unregistered (i.e. the package database is broken).

I think such ports should set something like USE_WRITE_SLASH=yes and refuse to 
install if / is not writeable.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Thunderbird 2.0 coming to ports today, any need for Thunderbird 1.5?

[[LoN]Kamikaze]

Michael Johnson wrote:

Hello,
I'm pleased to announce we are going to import Thunderbird 2.0 to ports 
later today, we don't plan on repo-coping mail/thunderbird -> 
mail/thunderbird15 unless there is a high demand for it. If you want 
Thunderbird 1.5 to stay in ports then please speak up!


Michael


It would be nice to have an enigmail upgrade. At the moment I cannot read my 
own emails.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Lynx -vulnerabilities- is this permanent?

[[LoN]Kamikaze]

David Southwell wrote:
> Hi
> 
> portupgrade -a produces following output for lynx on cvsup from today.
> freebsd 6.1
> -
> --->  Upgrading 'lynx-2.8.5_2' to 'lynx-2.8.6_4' (www/lynx)
> --->  Building '/usr/ports/www/lynx'
> ===>  Cleaning for lynx-2.8.6_4
> ===>  lynx-2.8.6_4 has known vulnerabilities:
> => lynx -- remote buffer overflow.
>Reference: 
> 
> => Please update your ports tree and try again.
> *** Error code 1
> 
> Stop in /usr/ports/www/lynx.
> 
> Any news or advice forthcoming?
> 
> david

Did you try a 'portaudit -F'?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

devel/apr and PYTHON_VERSION

[[LoN]Kamikaze]

I have defined

PYTHON_VERSION=2.5

in my make.conf and devel/apr cannot find python during the configure stage. 
Making a symlink from the python2.5 binary to python solves the problem.

I guess this might be a problem with autoconf or USE_PYTHON_BUILD.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: parallel builds revisited

[[LoN]Kamikaze]

Kris Kennaway wrote:
> On Thu, Apr 12, 2007 at 09:31:37PM +0200, [LoN]Kamikaze wrote:
> 
>>> Btw, do you think it's possible that a port can only be built with, n 
>>> parallel make jobs, but will fail with n+1?
>> No. I do not think this can be the case.
> 
> It certainly is the case.  If a makefile has incorrectly specified
> dependencies then it may build by accident for certain values of n.
> There are also lots of ports with race conditions which means they may
> sometimes build but not always.

I am aware of the theoretical existence of such problems, but has that ever 
actually happened? In my experience the port fails whenever something is wrong. 
I've never had a case where a port that didn't work because of 'make -j' worked 
when I tried again or with a different number of jobs.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: parallel builds revisited

[[LoN]Kamikaze]

Peter Jeremy wrote:
> Can anyone come up with either examples of ports that fall into the
> second category above or counter-examples to my first paragraph?

I have used 'make -j' for quite some time, and to my experience it either works 
or doesn't. I've never seen a port that works sometimes.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: parallel builds revisited

[[LoN]Kamikaze]

Benjamin Lutz wrote:
> On Thursday 12 April 2007 11:06, Garrett Cooper wrote:
>> I dunno how you want to approach this, but gmake does recommend 2
>> jobs be run in parallel for HTT enabled chips, and 3 or 4 jobs for a
>> dual core machines.
>> -Garrett
> 
> So far the approach is one job per CPU. I'll do some benchmarks lateron 
> to determine wether it really helps to run more jobs. For the KDE 
> ports, my gut feeling is that the improvement would be negligible. I'll 
> have to evaluate non-C++ ports like gnome-*, where the compilation time 
> per file is shorter.

I find the benefit especially big with Gecko based ports like Firefox or
Thunderbird.
 
> Of course, to make proper use of distcc, at least #cores + 1 jobs are 
> required. I'll keep that in mind.

The recommendation of the Distcc developers is 2 jobs per core, as long as
the machines contain sufficient memory.

My personal experience says that it's rarely possible to divide a Makefile
into more than 6 threads.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"