Re: compat4x ldconfig

[Doug Barton]

Simon Morgan wrote:
> compat4x doesn't seem to be running ldconfig after it's installed

You don't say what version you're using currently, but have you run
mergemaster lately? The ldconfig magic for this stuff is in /etc/rc* now.

hth,

Doug

-- 

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

Re: New version of portmaster available for testing

[Doug Barton]

Hans Lambermont wrote:
> Doug Barton wrote:
> 
>> Hans Lambermont wrote:
>>> Doug Barton wrote:
>>>> 3. Add -o option to replace an installed port with a new port from a
>>>> different location (e.g., portmaster -o emulators/linux_base-fc4
>>>> linux_base) The second argument can also be specified as the name of
>>>> the installed port (e.g., linux_base-8-8.0_15)
>>> nice, a hard-needed feature. Can you have multiple -o options in
>>> combination with -a ?
>> No, you'd have to do all your -o operations individually first. Anything
>> else is too messy to try and track.
> 
> Ok, 'was afraid of that.

Well this doesn't happen all that often, so IMO the amount of work to handle
this special case would outweigh the benefit.

>>> 1)
>>> portmaster -b -n -a
>>> ...
>>> ===>>> The devel/gnu-libtool port has been deleted: Has expired: 
>>> devel/libtool15 is now stock and should be used instead
>>> ===>>> Aborting update
>>>
>>> I think the -n should not abort.
>> I've tried to be very conservative with the use of fail() in the script,
>> it's only used when something is so far out of the ordinary that it really
>> requires user attention/intervention. So, even in -n mode I'm inclined to
>> bomb out and let the user sort things out before proceeding.
> 
> Ok, I can understand this reasoning. On the other hand; I like to get a
> list of what ports will be updated beforehand, how can I get this list
> from portmaster now when the -n aborts ? I can use pkg_version of
> course, but that doesn't show build order (or dependencies).

What would you think about something like this?
http://dougbarton.us/portmaster-listplus.diff

> I gave portmaster 1.5 a 3-day-test.

Thanks for doing this, and thanks as always for your feedback, it's very
valuable. I deleted examples from your post that don't seem to be portmaster
issues. If you think my judgment was wrong, please feel free to provide more
details.

> Here is what I ran into, and what I
> did to continue. I'd like to get pointers from anyone for anything I did
> that can be improved upon.

> # portmaster -GavD
> 
> ===>   kdelibs-3.5.3 depends on: /usr/ports/misc/kdehier
> ===>Verifying install for /usr/ports/misc/kdehier
> ===>   kdehier-1.0_9 is already installed
>   You may wish to ``make deinstall'' and install this port again
>   by ``make reinstall'' to upgrade it properly.
>   If you really wish to overwrite the old port of misc/kdehier
>   without deleting it first, set the variable "FORCE_PKG_REGISTER"
>   in your environment or the "make install" command line.
> Stop in /usr/ports/misc/kdehier.
> Stop in /usr/ports/x11/kdelibs3.
> # cd /usr/ports/misc/kdehier
> # make deinstall
> # make reinstall
> # cd
> ## Can this be done from portmaster somehow ?

Not sure what needs to be done here, from what you sent it looks like an
error in the dependency list for kdelibs.

> # portmaster -GavD
> 
> => kdebase-3.5.3.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/KDE.
> => MD5 Checksum mismatch for KDE/kdebase-3.5.3.tar.bz2.
> => SHA256 Checksum mismatch for KDE/kdebase-3.5.3.tar.bz2.
> ===>  Giving up on fetching files: KDE/kdebase-3.5.3.tar.bz2 
> KDE/kdebase-3.5.3.t
> ar.bz2
> # rm /usr/ports/distfiles/KDE/kdebase-3.5.3.tar.bz2
> ## Can this be done from portmaster somehow ?

When it launches the 'make checksum' in the background, it should handle
this case by refetching automatically (because that's what the checksum
target does). But, see below.

> # portmaster -GavD
> 
> ## system seems slow, top shows 2 dialogs eating 60% CPU
> # pstree
>  | |-+- 21720 root /bin/sh /usr/local/sbin/portmaster -D -v kde-3.5.2
>  | | \-+- 21722 root /bin/sh /usr/local/sbin/portmaster -D -v kde-3.5.2
>  | |   \-+- 21723 root make checksum
>  | | \-+- 21877 root [sh]
>  | |   \-+- 21878 root /bin/sh /usr/ports/x11/kde3/scripts/configure.kde3
>  | | \--- 21889 root [dialog]
>  | \-+- 86643 root /bin/sh /usr/local/sbin/portmaster -D -v kde-3.5.2
>  |   \-+- 86645 root /bin/sh /usr/local/sbin/portmaster -D -v kde-3.5.2
>  | \-+- 86646 root make checksum
>  |   \-+- 86798 root [sh]
>  | \-+- 86800 root /bin/sh /usr/ports/x11/kde3/scripts/configure.kde3
>  |   \--- 86809 root [dialog]
&

Re: call for testers: update print/acroread7 to 7.0.8

[Doug Barton]

Hiroki Sato wrote:
> Hi all,
> 
>  Adobe has released Adobe Reader 7.0.8 for Linux and
>  it seems to work properly on FreeBSD's Linux emulation
>  environment.
> 
>  I am planning to commit the necessary patch[*] to update
>  the port, but I would like to hear about if it works on other
>  systems before the commit.  Could anyone try it and let me
>  know if there is a problem or not?
> 
>  [*] http://people.allbsd.org/~hrs/FreeBSD/acroread7.diff
> 
>  If it works without problems, I will commit this patch and
>  desktop entry handling suggested by [EMAIL PROTECTED]  Thanks.

I use acroread a lot, so I tested it on my 6-stable and -current systems
(both i386) and the new version works great, including printing through cups.

hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: cups-base build error

[Doug Barton]

Olivier Certner wrote:
>   I've also seen that 12 hours ago. My ports tree was a few weeks old. I 
> then 
> cvsuped the ports tree, uninstalled cups-base and cups-lpr, that seemed to 
> come from the same origin (reported by pkgdb -Fu) which I felt was quite odd. 
> I finally recompiled cups-base (with php interfacing still) and all went OK.

I had a portmaster user send me a similar issue. Having used portupgrade to
try to handle the cups-lpr change, it seems that portupgrade tried to
maintain cups-lpr as its own port, and "installed" it from print/cups-base,
leading to two ports in /var/db/pkg having the same ORIGIN. In addition to
this being a bad thing generally, when the guy that wrote to me eventually
tried using portmaster to fix the problem, he got an error because
portmaster does not have any code currently to handle more the "more than
one port with the same ORIGIN" issue (since it should never happen).

I suppose I could add code to deal with this, but I'd really prefer some
kind of assurance that I'm right in thinking it shouldn't happen. :)

Doug

-- 

This .signature sanitized for your protection

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

Ports support for RELENG_4 (Was: Re: Question about ports builds)

[Doug Barton]

Mark Linimon wrote:

> The burden of trying to keep everything working on 4 i386 branches, 3
> amd64 branches, and 3 sparc64 branches is too high at this point, especially
> with the degree of drift in such things as header files and base compiler
> between -4 and -5.  Of course, most of these things can be fixed given
> sufficient maintainer and committer interest, but at some point you have
> to conclude that you're in the realm of diminishing returns.

I think you're right about that, and my preferred method of operation for
the ports that I maintain has been to try and test on RELENG_4 whenever
possible, but not let not testing stop me from updating a port that works on
7-current and 6-stable. What I've found is that in those rare cases where
there is an intersection between a port that is broken on RELENG_4 and users
that care about that, I'm notified fairly promptly. If not by users, I
usually get a krismail to the same effect. :) Thus, things in my little
world don't stay broken for too long.

All that said, I'd love to officially drop support for RELENG_4, but I think
that until we drop support for RELENG_4 in the base, dropping support for
the ports would break faith with our users. At the same time, I think that
some bit rot at the edges (of the seldom-used ports) is natural, and not to
be mourned.

> there are 206 legitimate build errors on i386-4 now; that doesn't include
> any port already marked as BROKEN.  That's quite high.

The way you break those numbers down is interesting. On i386 there are 206
errors on -4, 277 on -5, 119 on -6, and 151 on -7. I would be interested to
know what the percentage of overlap is ... in other words what percentage of
the 119 ports broken on -6 also comprise the broken ports on the other
releases. Based on a cursory examination of the errors on -4, I'd estimate
that percentage to be quite high. Assuming that it's 90%, that means that 99
ports are uniquely broken on -4, which is a very small percentage of the
packages that actually built (0.097%). IOW, there is actually less bit rot
(in terms of unintended brokenness) than I would have expected.

Doug

-- 

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

Re: portupgrade portupgrade leaves an error....

[Doug Barton]

yattaran wrote:

> I then replaced db42 with db44:
> portmaster -o /usr/ports/databases/db44 db42-4.2.52_4

I have to say, using portmaster to fix portupgrade is not an application I
had in mind when I wrote it, but you do get points for creativity. :)

> Then figured out what depended on db44:
> pkg_info -Rr 'db44*'
> 
>   Information for db44-4.4.20.2:
> 
>   Depends on:
>   Required by:
>   apr-db42-1.2.7_1
>   nicotine-1.0.8_1
>   portupgrade-2.1.3.2,2
>   py24-bsddb-2.4.3_2
>   ruby18-bdb-0.5.9
> 
> Rebuild each by running portmaster for each and everyone of those.

For future reference, you could also do 'portmaster -r db44' and it will
rebuild them for you.

hth,

Doug

-- 

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

Re: firefox + cups problem

[Doug Barton]

M. Warner Losh wrote:
> With my old laptop, a FreeBSD/i386 box running current, I was able to
> print to my cups printers w/o a problem with firefox.
> 
> That laptop died a horrible death.  So I bought a amd64 laptop and am
> running FreeBSD/amd64.  Every time I print now in firefox, firefox
> dies a horrible death.  I just did a portupgrade -a, and that hasn't
> solved the issue, so I thought I'd ask here if people have seen this.

Happened to me yesterday, although cups managed to grab the print job before
firefox died, which saved me a lot of time and aggravation.

In the past this has been solved by rebuilding things in the following order:

1. gnutls
2. cups
3. firefox

so if you have to rebuild one of those, you have to rebuild everything after
it. However, there is no guarantee that it will work even after you do that.

This is an ugly problem that has been around for a while, and so far no one
has stepped up to make a definitive fix.

Doug

-- 

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

Re: RFC: Merging X11BASE to LOCALBASE

[Doug Barton]

Dejan Lesjak wrote:
> On Friday 14 July 2006 08:58, Maxim Sobolev wrote:
>> What's the gain? 
> 
> I believe I mentioned some of gains in first mail. There is also the benefit 
> of less divergence to upstreams as ./configure scripts of various ports 
> use /usr/local as default prefix, but more importantly as modular X.org is 
> becoming more widespread there is tendency of various packagers (for example 
> Linux distributions already mentioned) to install all packages under same 
> prefix. We expect that if we follow that trend, we would make maintainers and 
> users' lives a bit easier in the long run.

Note, I am still making up my mind about whether what you're proposing is a
good idea or not, so I'm not intending this as a criticism. However, the
argument you propose above as a benefit for the move is completely specious.
Our ports are supposed to be prefix-clean no matter what the defaults in the
distributed software are, and no matter what prefix the user chooses. Thus
(other than ports which are broken now which need fixing anyway), the only
thing this move will do is ADD work for maintainers (at least in the short
run), it will not make anyone's life easier in this area.

I would also like to reinforce Maxim's point here, since I think it's
getting lost in the shuffle. The burden to the users is NOT just
reinstalling, which with modern tools like portmaster or portupgrade should
be pretty painless, if not time consuming. There is also the burden to our
users of editing config files, firefox app preferences, etc. etc. Some of
these can be handled automatically by the ports, many of them cannot.

Frankly, I'm still waiting to hear some really good reasons to make this
change, but my mind is still open.

Doug

-- 

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

Re: RFC: Merging X11BASE to LOCALBASE

[Doug Barton]

Dejan Lesjak wrote:

> Actually, I didn't mean the prefix that some port installs into would be the 
> truble, rather where given port looks for includes, libraries and other files 
> from ports that it depends upon.

But that's all part of the same issue. If the port is prefix-clean, than
this won't matter. If it's not, it needs to be fixed, regardless of what the
default values of *BASE are.

Doug

-- 

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

Re: RFC: Merging X11BASE to LOCALBASE

[Doug Barton]

Brooks Davis wrote:

> Assuming we deal with all the conflicting ports in the first round
> I don't fully buy this argument.  If most people can simply upgrade
> the ports in question then "rm -rf /usr/X11RC && ln -s /usr/local
> /usr/X11R6" will take care of config files.  That's admittedly a large
> assumption, but I don't think it's all that unreasonable.

That might add confusion for ports that are still have hidden dependencies
on /usr/X11R6, and also won't work at all if the decision is made to keep
the xorg/XFree bits in that directory.

> I think the argument for this change is that the use of X11BASE is
> pretty much random so it's no longer serving any useful purpose and the
> lack of consistency is a minor negative since you never know where an X
> related port will end up without reading the Makefile.

In my mind that's a good argument for making and enforcing consistent
policies, not for changing the defaults. But reasonable minds can differ on
this issue. Like I said, my mind is not made up yet one way or another, but
I have yet to see a very good reason for making the change.

Doug

-- 

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

New portmaster version available for testing/feedback

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks to all who've sent in their bugs, suggestions, and ideas for
improvement, I've got a new version of portmaster ready for those who would
like to check it out. It implements the following:

1. Trap a ^C (SIGINT) to the parent process, and attempt to kill off all the
child processes that have spawned.

2. Add -L mode, which generates the same list as -l, but also checks for
updated versions of the installed ports.

3. Do a better job of tracking the parent process, and use that information
to make the internal housecleaning easier.

4. While doing the 'make config' run through the dependency tree, if no
dependencies need updating then jump straight to the build, rather than
walking the dependency tree again. This saves a lot of time for those that
keep their ports relatively up to date, especially for ports that have a lot
of dependencies.

5. When running in interactive (-i) mode, store the user's preferences
during the 'make config' run so that we don't have to ask him again when
building. This is particularly helpful with the -a or -r options.

6. Implement support for portupgrade's /var/db/pkg/*/+IGNOREME files. If
this file is seen in the master port (the one specified on the command line)
the user is given the option to upgrade or not. If it's seen in a port that
is a dependency, it is ignored silently, except in verbose mode where it's
ignored with a warning. This seemed like the cleanest way to implement an
"ignore feature," which also has the virtue of adding support for something
the user might already have in place.

7. Add -f to pkg_delete in the -s case, just as it is already used for the
general case.

8. In -va mode, print the name of the port we're checking in the config step
too.

9. Reverse the wording of the verbose message in -r mode to actually make sense.

10. Warn the user during config mode if a port sets IS_INTERACTIVE.


You can find the new version at http://dougbarton.us/portmaster. Thanks in
advance for any feedback.

Doug

- --

This .signature sanitized for your protection

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (FreeBSD)

iD8DBQFEueCFyIakK9Wy8PsRAjvRAKC0k6vLzh3hQ24rugaOtGyn3MEJHACeJw46
mQ73Tl9eSKLZEFgI4vpPzp0=
=iFcB
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: hpijs/hplip, foomatic-rip, and CUPS 1.2.0

[Doug Barton]

For future reference, please don't post to both -ports and -questions.

Anthony Agelastos wrote:

> Does anyone out there have network printing working with hpijs/hplip and
> CUPS 1.2.0?

Yes. You need to follow the instructions at
file:///usr/local/share/doc/hplip-0.9.11/install/step4/cups/net.html

> On a sidenote, I was having difficulties installing hpijs when hplip was
> already installed 

I'm working on that.

Doug

-- 

This .signature sanitized for your protection

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

Re: New portmaster version available for testing/feedback

[Doug Barton]

Ricardo A. Reis wrote:

>   Hi Barton,
> 
> 
>  More one idea for portmaster, is possible  limit the number of
> concurrent fetch ?

[ snip ]

>I use portmaster for update 138 ports and now i don't have more
> bandwidth :-(

heh, sorry about that. I could look into the idea of limiting the number of
fetches, but it's a balancing act, since people with a lot of bandwidth
would like to have more, and adding another tunable for this seems like
overkill to me.

The good news is that in your situation, you can alleviate some of the
problem by not using portmaster -a, and instead updating one or a few ports
at a time. If you do (with the new version) 'portmaster -L' it will show you
what you have installed, and what updates are available. If you start your
updates with the root and trunk ports (that have no, or few dependencies)
then you won't be doing so many fetches at once. You can keep moving "up"
the dependency "tree" a port at a time, or once you get most of the ports
updated you could then use -a safely.

hth,

Doug

-- 

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

Re: New portmaster version available for testing/feedback

[Doug Barton]

Hans Lambermont wrote:
> While testing the new version I ran into a -o problem, so it's not
> related to the 10 improvements, but here it is :
> 
> I started with this situation :
> 
> # pkg_info | grep avahi
> avahi-0.6.10_3  Service discovery on a local network
> 
> # pkg_info -R avahi-0.6.10_3
> Required by:
> vlc-0.8.5_2
> 
> # pkg_info | grep howl
> howl-1.0.0_1Zeroconf/Bonjour(tm) implementation
> 
> # pkg_info -R howl-1.0.0_1
> Required by:
> gimp-2.2.11,1
> kde-3.5.2
> planner-0.13_3
> 
> Avahi should replace howl (UPGRADING entry 20060429)
> 
> # portmaster -o net/avahi howl
> ...
> ===>  Installing for avahi-0.6.11_1
> ===>  Checking if net/avahi already installed
> ===>   An older version of net/avahi is already installed (avahi-0.6.10_3)
> Stop in /usr/ports/net/avahi.

I just uploaded a version that has what should be a fix for this, can you
give it a try? And thanks for catching this, you're right, it's an oversight
on my part.

>> 2. Add -L mode, which generates the same list as -l, but also checks
>> for updated versions of the installed ports.
> 
> Small question : don't you think its better to merge the two lines ?

Well, I don't, but you obviously do. :)  Let me think about it, doing what
you suggest makes the code more complicated, but if I can find a simple way
to do it, I'll think about it. FYI, the other reason I like this format (and
added tabs to another message that prints in -v mode) is that it is very
visually distinct, and does not run the risk of getting missed in a quick scan.

> I'll continue testing now.

Thanks!

Doug

-- 

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

Re: HEADS UP: BIND9's resolver and reentrant version of netdb functions are MFC'ed

[Doug Barton]

Hajimu UMEMOTO wrote:
> Hi,
> 
> I've just MFC'ed the BIND9's resolver stuff and reentrant version of
> netdb functions.
> It is known that some ports are confused by existence of reentrant
> functions.  So, I've bumped __FreeBSD_version to 601103.

This is very exciting stuff! Thanks for your hard work on this.

Doug

-- 

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

Re: FreeBSD Port: net/bfilter: rc.d script broken

[Doug Barton]

Nikolaus Waxweiler wrote:
> Hi,
> there's a bug in the rc.d script that prevents bfilter from being
> stopped: "sig_stop=-KILL" should be "sig_stop=KILL", since the script
> adds a "-" automatically. Currently, a "kill --KILL " is issued,
> which does nothing. The script waits for bfilter to stop until it times
> out.

Thanks for bringing this to our attention. I fixed up that rc.d script and
bumped the PORTREVISION, so please let us know if that works for you.

I also fixed up the sig_stop values in other scripts where they were
incorrectly specified.

hth,

Doug

-- 

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

Re: New portmaster version available for testing/feedback

[Doug Barton]

Doug Barton wrote:

> I just uploaded a version that has what should be a fix for this, can you
> give it a try? And thanks for catching this, you're right, it's an oversight
> on my part.

Hans,

I'm curious if you've had a chance to try that fix, as I'd like to commit
the new version sometime soon.

Also, in re-reading your message it occurs to me that one of the problems
with what you did previously is that you specified just 'howl' as the second
argument to -o, and that isn't enough. You either need to specify net/howl
ala portupgrade, or howl-1.0.0_1 (i.e., the installed port name from
/var/db/pkg).

hth,

Doug

-- 

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

Re: New portmaster version available for testing/feedback

[Doug Barton]

Hans Lambermont wrote:
> Doug Barton wrote:
> 
>> Doug Barton wrote:
>>
>>> I just uploaded a version that has what should be a fix for this, can
>>> you give it a try? And thanks for catching this, you're right, it's
>>> an oversight on my part.
>> I'm curious if you've had a chance to try that fix, as I'd like to
>> commit the new version sometime soon.
> 
> It's nice to have bootable backups ;-)

heh

> I just tested the same upgrade and it works OK now :
> 
> ===>>> Upgrade for howl-1.0.0_1 to avahi-0.6.11_1 succeeded
> 
> I miss one dependency though :
> 
> # pkg_info -R avahi-0.6.11_1
> Required by:
> gimp-2.2.11,1
> kde-3.5.2
> planner-0.13_3
> 
> The old avahi-0.6.10_3 also had :
>> # pkg_info -R avahi-0.6.10_3
>> Required by:
>> vlc-0.8.5_2
> 
> Is this a dependency-merge omission ? It looks like avahi-0.6.11_1 only
> has the howl-1.0.0_1 dependencies.

D'oh. This is an ugly problem, but I just uploaded a new version at
http://dougbarton.us/portmaster that fixes this issue. This time around I
created an artificial environment with both howl and avahi dependencies, and
with both ports installed, and tested the update. I'm confident that this
new version does what _I_ expected it to do, but if you can still test one
more time, that would be appreciated. If you don't get a chance to test,
that's cool too, just let me know so that I can check in the new version.

>> Also, in re-reading your message it occurs to me that one of the problems
>> with what you did previously is that you specified just 'howl' as the second
>> argument to -o, and that isn't enough. You either need to specify net/howl
>> ala portupgrade, or howl-1.0.0_1 (i.e., the installed port name from
>> /var/db/pkg).
> 
> Ah yes, perhaps this is a good thing to check for ? ;-)

Too dangerous in this situation. I'd rather not guess what the user is
trying to do. I did however improve the code that reads the port directory
as the second argument, so now you can do (for example) net/howl,
/usr/ports/net/howl, or howl-1.0.0_1 and they all work.

FYI, the other change I made to the version I just posted is that the -s
option to remove stale ports is now recursive, so if you're deleting a big
chunk (like the avahi mess that I was testing with) it keeps going till
there are no more stale ports to find, rather than having to run it
repeatedly like you did previously.

Doug

-- 

This .signature sanitized for your protection

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

Re: dependencies

[Doug Barton]

Emil Holmstr|m wrote:
> Isn't it a better way to fix +REQUIRED_BY than by portmaster?

Well, portmaster is a pretty good solution, but then again, I'm biased.

> Or better no need to fix it all.
> 
> Scenario:
> I install port a, it requires port b and c.
> After a while a new version of port a, I uninstalls port a and install
> the new version.
> Vola!
> port a have vanished from /var/db/pkg/port_b/+REQUIRED_BY list.

That shouldn't happen (even without using a port management tool), can you
fill in some names for port_[abc] so we can test it?

Doug

-- 

This .signature sanitized for your protection

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

Re: New portmaster version available for testing/feedback

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've just uploaded a new version of portmaster to
http://dougbarton.us/portmaster that in addition to the stuff from the
message below, also implements the following:

1. Fix handling of [/usr/ports/]foo/bar as second option to -o

2. Correctly handle the -o case where both ports are already installed

3. If an initial 'make checksum' run fails, delete the distfiles and start
over again (still in the background)

4. When deleting stale distfiles, start with the longest match, then
truncate the file name recursively till we find something to delete, or run
out of file name. (IOW, for a distfile named a-b-c-1.23.tar.gz, first try
a-b-c*, then a-b*, etc.)

5. Don't try to delete directories as if they were distfiles

6. Add PATCHFILES to the list of potentially stale files to test


As always, your testing and feedback are welcome.

Doug


-  Original Message 
Date: Sat, 15 Jul 2006 23:45:26 -0700

Thanks to all who've sent in their bugs, suggestions, and ideas for
improvement, I've got a new version of portmaster ready for those who would
like to check it out. It implements the following:

1. Trap a ^C (SIGINT) to the parent process, and attempt to kill off all the
child processes that have spawned.

2. Add -L mode, which generates the same list as -l, but also checks for
updated versions of the installed ports.

3. Do a better job of tracking the parent process, and use that information
to make the internal housecleaning easier.

4. While doing the 'make config' run through the dependency tree, if no
dependencies need updating then jump straight to the build, rather than
walking the dependency tree again. This saves a lot of time for those that
keep their ports relatively up to date, especially for ports that have a lot
of dependencies.

5. When running in interactive (-i) mode, store the user's preferences
during the 'make config' run so that we don't have to ask him again when
building. This is particularly helpful with the -a or -r options.

6. Implement support for portupgrade's /var/db/pkg/*/+IGNOREME files. If
this file is seen in the master port (the one specified on the command line)
the user is given the option to upgrade or not. If it's seen in a port that
is a dependency, it is ignored silently, except in verbose mode where it's
ignored with a warning. This seemed like the cleanest way to implement an
"ignore feature," which also has the virtue of adding support for something
the user might already have in place.

7. Add -f to pkg_delete in the -s case, just as it is already used for the
general case.

8. In -va mode, print the name of the port we're checking in the config step
too.

9. Reverse the wording of the verbose message in -r mode to actually make sense.

10. Warn the user during config mode if a port sets IS_INTERACTIVE.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (FreeBSD)

iD8DBQFEyHtqyIakK9Wy8PsRAqIQAKC9koJ34gF0Cz4YNmkm1mHi6jChCwCg+Miv
2M7EUVSehGn7Av6HkST3CmA=
=GKoe
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: portmaster, bison, java/jdk15

[Doug Barton]

Jeremy Messenger wrote:

> It is a known issue, I have reported to Doug a while back.

*nod*

> As for solution, right now I am thinking about check on each port's
> conflict. Like for example:
> 
> - Check on if devel/bison has any of CONFLICT.
> - CONFLICTS is devel/bison2, then check if
>   devel/bison2 exists.
> - devel/bison2 does exist, then remove the
>   devel/bison out of dependency check list.
> - Check if devel/bison2 needs to update.
> - [...goes on as normal...]
> 
> I don't know if it's good idea.

That is a good idea, thanks for suggesting it. I will look at some code to
do that, although I might not get it into the current version, as I'm almost
done with some serious performance optimizations that I'd like to get out
the door.

> Looks like create a database is a better solution?

Heh, no.

Doug

-- 

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

LOCALBASE vs. X11BASE (head to head deathmatch!)

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Ok, I'm kidding about the deathmatch part. :)

I have put some thought, and testing into this question though, so I thought 
I would post my results. First the conclusion. IMO the ideal technical 
solution would be to add a new variable, something like X11_CODE_BASE for 
the X11R7 bits, but default LOCALBASE, X11BASE, and the new one all to 
/usr/local. However, given that the resources to provide any kind of 
reasonable testing and user support to those different variables (there are 
8 combinations at least that would require testing, multiplied by > 15,000 
ports) does not now, and is not likely to ever exist, my actual 
recommendation is to collapse everything into one prefix.


I came to this conclusion by actually testing the various options. I decided 
to delete all my ports, and install something big and hairy to see where we 
stand. I chose gnome for my guinea pig (which also had the side effect of 
allowing me to torture-test the new version of portmaster, but that's 
another e-mail). My first test was to set LOCALBASE and X11BASE (*BASE) 
both to the same, non-standard location. Fortunately for me, that failed on 
the very first port it tried to compile (python), so I settled for setting 
them both to /usr/local.


The good news is that with *BASE set to /usr/local, everything built just 
fine, so we are at least PREFIX-clean enough so that things build. 
Everything runs fine for the most part as well, although when things failed, 
it was in non-obvious and annoying ways. In particular, gdm took me a long 
time to fix because of its multiple config file locations, and weird 
assumptions about PATH, etc. (It also has a really annoying "feature" of 
source'ing ~/.profile, but that's also another story altogether.)


These tests, and the work I put into stuff to get everything to work, lead 
me to the conclusion that it doesn't actually matter if we put the new bits 
into /usr/X11R7, or /usr/local. The two problems look exactly the same from 
the standpoint of the rest of the ports. For example, the problems I ran 
into with gdm need to be fixed by patching the original files with something 
like %%LOCALBASE%%, then sed'ing that out to be whatever the variable is set 
to in the ports (or make.conf). Thus, it doesn't really matter which change 
we make, if we start with the assumption that we're not going to install 
xorg 7.x into /usr/X11R6 (which is my understanding) then the solution to 
making the rest of the ports work with the new location looks the same 
regardless of the destination. Stated more simply, my previous contention 
that the real problem needs to be defined as, "Our ports need to be 
PREFIX-clean, period" seems to have been proved out.


This leads to my "ideal" solution, which would be to have the stuff split 
into 3 locations, instead of the current 2. There is a nice architectural 
purity to that, and I could envision scenarios where it would be useful to 
have things divided this way. The problem is that we simply don't have the 
resources to handle the 2 locations we have now (never mind enforcing 
PREFIX-cleanliness in general), and therefore I feel that the most rational 
way of dealing with this is to collapse it all into the same location. This 
does several things for us. It makes the development problem easier, since 
we'll always know where to find the bits (no artificial distinction between 
x11 bits, and "other" bits). It makes the support problem easier, because if 
a user is trying to do something non-standard, at least they will only be 
able to do _one_ thing in a non-standard way, which will make it easier to 
debug. It will also make the testing problem easier, since testing all the 
ports for installation into a non-standard PREFIX can be done with one pass 
on pointyhat.


It's also probably worth noting that I don't see any valid reason for 
continuing to support two discrete locations for ports to install to 
(LOCALBASE and X11BASE). If we're going to bite the bullet, we should bite 
the whole bullet, get it over with, and move on. If I'm understanding the 
discussions around DESTDIR correctly (and there is no guarantee that I am), 
then I think the work that will go into making that successful can also be 
leveraged into helping make collapsing the *BASE stuff successful.


This has been long, so if you're still reading, thanks! :) I hope that it's 
useful, and that we can continue having a rational discussion about the pros 
and cons of the various alternatives.


Regards,

Doug

- -- 


This .signature sanitized for your protection

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFE1YsIyIakK9Wy8PsRArDPAKCMIfXUsQITNTLChNOvQclRGzbCCACfbdeD
czbec9WIGtVWxlI+eD0AzEE=
=L2u8
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTE

Re: portmaster, bison, java/jdk15

[Doug Barton]

Doug Barton wrote:
> Jeremy Messenger wrote:
> 
>> It is a known issue, I have reported to Doug a while back.
> 
> *nod*
> 
>> As for solution, right now I am thinking about check on each port's
>> conflict. Like for example:
>>
>> - Check on if devel/bison has any of CONFLICT.
>> - CONFLICTS is devel/bison2, then check if
>>   devel/bison2 exists.
>> - devel/bison2 does exist, then remove the
>>   devel/bison out of dependency check list.
>> - Check if devel/bison2 needs to update.
>> - [...goes on as normal...]
>>
>> I don't know if it's good idea.
> 
> That is a good idea, thanks for suggesting it. I will look at some code to
> do that, although I might not get it into the current version, as I'm almost
> done with some serious performance optimizations that I'd like to get out
> the door.

Ok, I FINALLY got the new version (1.6) done, and committed. The good news
is that the delay was caused by my finding more things to optimize. :)

I have been giving some thought to your scenario, and while I still do not
have an automated solution, I do have a workaround that will work from the
command line. In the new version I enhanced the -i (interactive mode)
feature to remember the user's choices made during the 'make config'
recursive check so that you don't have to re-enter them at build time. So,
let's say that you want to build build /usr/ports/foo/bar which has a
dependency on bison, but you have bison2 installed. You would launch
'portmaster -i -p foo/bar' and when the dependency check got to bison, say
no to building it. When the build for foo/bar starts, the ports tree will
see that the bison dependency is filled by bison2, and not try to launch a
build for it, and neither will portmaster.

Like I said, it's not ideal or automated, but it does "fix" the problem
while I work on the CONFLICTS idea you proposed (or some other solution if
that doesn't work).

hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: extract both bz2 and gz files from distfiles

[Doug Barton]

Alexander Leidinger wrote:
> Quoting Pav Lucistnik <[EMAIL PROTECTED]> (Mon, 07 Aug 2006 23:20:55 +0200):
> 
>> So you prefer imposing yet another dependency on the user is less evil
>> than adding few lines of extra code in port Makefile?
>>
>> Interesting PoV.
> 
> We're talking about 4.x. It's on the way out. So it's about increased
> complexity (own do-extract target) on the well supported systems, or
> about another dependency on the old and "we support it if it isn't a
> hassle" versions. For the linux ports Boris is needing this part, I
> vote for another dependency (like we have already with USE_GCC in other
> ports).

FWIW, I agree with Brooks and Pav here, and that's speaking as someone who
still actively maintains his ports on RELENG_4 (although I'm looking forward
to not having to do so).

Doug

-- 

This .signature sanitized for your protection

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

Re: conflict check for upcoming merge

[Doug Barton]

[LoN]Kamikaze wrote:

> Here is the output of the script from another machine. Lots of
> qmake/qt conflicts, it seems:

FWIW, I ran this on my 6-stable box that still has the LOCAL/X11 split (list
of ports attached), and got similar results. The qt stuff should be fairly
easily solved, so that isn't too worrisome.

If I could suggest some improvements for the script (awkward since I can't
help code them atm) :)

1. Ignore info/dir and man/whatis. They are non-issues.
2. It would be useful (IMO) to flag files vs. directories. Files are more of
a problem, since two ports could be installing different versions of a file
with the same name and path. If we find that there are common directories
that a lot of ports need, we can add them to the mtree files and remove them
from the pkg-plists. There is a non-zero amount of work involved there of
course, but it's a lot less difficult than the file problem.

Finally there is enough mime related stuff in the output of conflicts for me
that it would seem the project that was suggested here a while back to
create a unified mime port could probably bear a lot of fruit in the new
world order, but once again, I'm in the awkward position of not being able
to contribute work towards this goal, just "helpful" suggestions. :)

One place to start might be the division between
*share/gnome/applications/mimeinfo.cache (interesting that gnome has it in
both places itself) and *share/applications/mimeinfo.cache.

hth,

Doug

-- 

This .signature sanitized for your protection

===>>> Root ports (No dependencies, not depended on)
===>>> bash-static-3.1.17
===>>> bind9-9.4.0.a6
===>>> cabextract-1.1
===>>> ccache-2.4_4
===>>> gmake-3.81_1
===>>> libtool-1.5.22_2
===>>> nasm-0.98.39,1
===>>> portmaster-1.6
===>>> qmake-3.3.6
===>>> wavplay-1.4_2
===>>> xorg-documents-6.9.0
===>>> xorg-manpages-6.9.0
===>>> zip-2.32
===>>> 13 root ports

===>>> Trunk ports (No dependencies, are depended on)
===>>> amspsfnt-1.0_4
===>>> cdparanoia-3.9.8_8
===>>> cdrtools-2.01_5
===>>> cmpsfont-1.0_5
===>>> curl-7.15.4
===>>> djbfft-0.76_2
===>>> expat-2.0.0_1
===>>> gdbm-1.8.3_2
===>>> gsfonts-8.11_2
===>>> heimdal-0.6.6
===>>> ispell-3.2.06_15
===>>> jbigkit-1.6
===>>> jpeg-6b_4
===>>> lcms-1.14_1,1
===>>> libdaemon-0.10_1
===>>> libdrm-2.0.2
===>>> libdvdcss-1.2.9_2
===>>> libfame-0.9.1_2
===>>> libfpx-1.2.0.12
===>>> libgpg-error-1.3
===>>> libiconv-1.9.2_2
===>>> libltdl-1.5.22
===>>> libogg-1.1.3,3
===>>> libusb-0.1.12_1
===>>> libwww-5.4.0_3
===>>> linux_base-fc-4_6
===>>> localedata-5.4
===>>> m4-1.4.4
===>>> nspr-4.6.1_2
===>>> openldap-client-2.3.25
===>>> perl-5.8.8
===>>> pkg-config-0.20_2
===>>> png-1.2.12_1
===>>> popt-1.7_1
===>>> python-2.4.3
===>>> svgalib-1.4.3_5
===>>> tex-texmflocal-1.9
===>>> unrar-3.60.b6,3
===>>> unzip-5.52_2
===>>> win32-codecs-3.1.0.p7_2,1
===>>> xmlcatmgr-2.2
===>>> xorg-fonts-encodings-6.9.0_1
===>>> xvid-1.1.0,1
===>>> 43 trunk ports

===>>> Branch ports (Have dependencies, are depended on)
===>>> ImageMagick-6.2.8.5
===>>> ORBit2-2.14.2_1
===>>> aalib-1.4.r5_2
===>>> acroreadwrapper-0.0.20060221
===>>> aspell-0.60.4_4
===>>> at-spi-1.7.7_1
===>>> atk-1.11.4_1
===>>> autoconf-2.13.000227_6
===>>> autoconf-2.59_2
===>>> avahi+libdns-0.6.12
===>>> bitstream-vera-1.10_2
===>>> bug-buddy-2.14.0
===>>> cairo-1.0.4_1
===>>> compat5x-i386-5.4.0.8_7
===>>> cups-base-1.2.2
===>>> cups-pstoraster-8.15
===>>> dasher-4.0.4,1
===>>> dbus-0.62
===>>> deskbar-applet-2.14.2
===>>> desktop-file-utils-0.11
===>>> docbook-sk-4.1.2_3
===>>> docbook-xml-4.2_1
===>>> docbook-xml-4.3
===>>> docbook-xml-4.4
===>>> docbook-xsl-1.70.1
===>>> dvd+rw-tools-6.1
===>>> eel-2.14.3
===>>> ekiga-2.0.2_1
===>>> eog-2.14.3
===>>> epiphany-2.14.3
===>>> esound-0.2.36_1
===>>> evince-0.5.3_1
===>>> evolution-2.6.3
===>>> evolution-data-server-1.6.3
===>>> evolution-exchange-2.6.3
===>>> evolution-webcal-2.6.0
===>>> fast-user-switch-applet-2.14.2
===>>> file-roller-2.14.4,1
===>>> firefox-1.5.0.6,1
===>>> flac-1.1.2_1
===>>> fontconfig-2.3.2_5,1
===>>> fox-1.4.32
===>>> freetype2-2.1.10_3
===>>> gail-1.8.11_1
===>>> gamin-0.1.7_2
===>>> gcalctool-5.7.32,2
===>>> gconf-editor-2.14.0_1,1
===>>> gconf2-2.14.0_2
===>>> gd-2.0.33_4,1
===>>> gdm-2.14.10
===>>> gedit-2.14.4
===>>> gettext-0.14.5_2
===>>> ghostscript-gnu-7.07_15
===>>> gimp-print-4.2.7_2
===>>> gle-3.1.0
===>>> glib-2.10.3
===>>> glibmm-2.10.4
===>>> glitz-0.4.4_1
===>>> gnome-applets-2.14.2_1
===>>> gnome-audio-2.0.0
===>>> gnome-backgrounds-2.14.2.1
===>>> gnome-control-center-2.14.2
===>>> gnome-desktop-2.14.3
===>>> gnome-doc-utils-0.6.1
===>>> gnome-games-2.14.3
===>>> gnome-icon-theme-2.14.2
===>>> gnome-keyring-0.4.9
===>>> gnome-keyring-manager-2.14.0
===>>> gnome-mag-0.12.6
===>>> gnome-media-2.14.2
===>>> gnome-menu-editor-0.6
===>>> gnome-menus-2.14.3
===>>> gnome-mime-data-2.4.2
===>>> gnome-netstatus-2.12.0_2
===>>> gnome-nettool-2.14.2,1
===>>> gnome-panel-2.14.3
===>>> gnome-screensaver-2.14.3
===>>> gnome-session-2.14

Re: cvs commit: ports/net Makefile ports/net/bwi-firmware-kmod Makefile distinfo pkg-descr pkg-plist

[Doug Barton]

Scot Hetzel wrote:
> This shouldn't be flaged as an mtree error.  The reason that
> linker.hints was left behind is due to this file is generated by
> kldxref.  The port/package runs kldxref during the install of the
> firmware module to update the existing or create a linker.hints file,
> and when the package is removed, it runs kldxref again to clean up the
> linker.hints file to only contain the modules in /boot/modules.  It
> has no way to know if it is safe to remove this file.

Would it be safe to remove if it's empty?

-- 

This .signature sanitized for your protection

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

Re: portmaster vs openoffice.org-3 (dmake)

[Doug Barton]

Andriy Gapon wrote:
> I am not exactly sure what's going on, but I see that dmake crashes with 
> SIGBUS
> during editors/openoffice.org-3 (version 3.1.0) build when executed via 
> portmaster.
> Simple make of the port doesn't trigger the problem.
> 
> I examined dmake core file with gdb and it seems that some memory gets 
> overwritten
> with text, so I assume that portmaster may set some peculiar environment 
> variables
> that dmake couldn't digest properly. Maybe the variable(s) is just 
> sufficiently
> big and dmake has a bug.

portmaster has no knowledge of dmake, and it doesn't set make
variables unless the user specifies them. It does set a few
enviornment variables, but nothing that should have an effect here. It
would help to debug this if you could narrow it down a little.

Also, are you setting anything interesting in make.conf? Particularly
the new make jobs safe stuff?


Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster vs openoffice.org-3 (dmake)

[Doug Barton]

Andriy Gapon wrote:
> on 20/05/2009 14:59 Andriy Gapon said the following:
>> In any case, it must be a bug in dmake code.
> 
> BTW, I can reliably reproduce this on amd64, but can not do it in i386 jail.
> Ports tree is exactly the same, ditto for portmaster version.

Ok, that sounds like a dmake memory bug on amd64. The stuff you pasted
from gdb is in fact portmaster stuff, and CUR_DEPS is an environment
variable that can grow quite large depending on what you're doing with
portmaster.


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: portmaster overzealous on distfiles?

[Doug Barton]

On Tue, 26 May 2009, Andriy Gapon wrote:
> on 26/05/2009 19:31 Andriy Gapon said the following:
>> I run the following command to upgrade from audacious 1.5.* to 
>> 2.0.*: $ portmaster audacious\*

FYI, the \* at the end of that is not necessary. If the command line
argument doesn't match a specific port it is treated as a glob pattern.

>> This starts to build three ports: audacious, audacious-plugins, 
>> audacious-skins. At the end of audacious upgrade portmaster asked
>>  me if I want to delete not only the older distfile of audacious 
>> but also about the newer one, and the one for audacious-skins.
> 
> After the above upgrade I re-run the command again (forceful 
> upgrade, so to say) and, again, after upgrading audacious port 
> portmaster asked me if I want to delete new-and-only distfiles for 
> other two ports.

If the various distfiles all start with audacious-* then portmaster
will ask you about them. I have gone back and forth in my mind about
hiding that code behind an option now that I have fairly effective
mechanisms in place to handle distfile stuff without resorting to the
glob matching. The reason I haven't done it yet is that cases like you
describe are actually fairly rare, and easily overcome with a
combination of the -D option and the --clean-distfiles option later on
at your convenience.

The course of action that I've basically settled on at this point is
rather than actually asking you if you want to remove the glob-match
distfiles to issue a suggestion to try the --clean-distfiles option at
some point in the future, which seems like a happy medium to me. As
soon as I get time to do it anyway. :)


hope this helps,

Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [Call For Testing] VirtualBox for FreeBSD! take 4

[Doug Barton]

Vlad GALU wrote:
> As a side note, loading vboxdrv.ko while X was running crashed my
> machine, in RTMpGetOnlineCount (). Unfortunately, all frames between
> that and frame 0 were corrupt. After rebooting, I was able to log on
> ttyv0 and loaded it without any issues.

Regarding my previous message about loading vboxdrv causing my machine
to wedge, it happens to me both in X and on the console. Haven't tried
with v5 of the port yet though.

Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: emulators/linux_base-f10 = Fedora 8?

[Doug Barton]

Boris Samorodov wrote:
> On Mon, 25 May 2009 20:49:50 +0100 Steven Hartland wrote:
> 
>> Why does emulators/linux_base-f10 contain a Fedora 8 port
>> most confusing!
> 
> It was just a repocopy. I'm working on it, just enotime now.

Then mark the port BROKEN, or some such. User confusion is a bad thing. :)


Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] FreeBSD python25 move to python26 as default version.

[Doug Barton]

Kelly Hays wrote:
> On Sun, May 17, 2009 at 11:54 AM, Martin Wilke  wrote:
>>Once the installed Python has been updated to 2.6, by using one of the
>>methods above, it is required to run the upgrade-site-packages target in
>>lang/python to assure that site-packages are made available to the new 
>> Python
>>version.
>>
>># cd /usr/ports/lang/python && make upgrade-site-packages
>>
>> This Makefile target requires ports-mgmt/portupgrade to be installed.
>>
> A lot of us are no longer using ports-mgmt/portupgrade in favor of
> ports-mgmt/portmaster. Please support both tools.

First, I don't use python, so I'm not directly affected by this.
Second, I don't think it's reasonable to _require_ that a user needs
to use any additional tools (such as portupgrade or portmaster) to do
something with the ports system. I do think it's reasonable to provide
instructions such as, "If you use toolA, do X, for toolB do Y, and if
you don't use a tool do Z, etc."

That said, if someone can explain what it is that needs to be done, I
will be glad to help write instructions for doing it with portmaster.


Doug

-- 

This .signature sanitized for your protection

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

Re: [Call For Testing] VirtualBox for FreeBSD! take 4

[Doug Barton]

Martin Wilke wrote:
> http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz

On a newly up to date -current (r192914) with world and kernel in
synch and ports up to date I get the same panic when trying to kldload
vboxdrv. This is on a C2D running i386 SMP.

panic: boot: not running on cpu0
cupid = 1

Also, I got the following when trying to build with debug. Building
without debug worked.

hth,

Doug


kBuild: Compiling vboxdrv -
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c
kBuild: Compiling vboxdrv -
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support/SUPDrv.c
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c:
In function 'VBoxDrvFreeBSDOpen':
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c:299:
error: invalid operands to binary &
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c:
In function 'VBoxDrvFreeBSDClose':
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c:355:
error: invalid operands to binary &
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support/SUPDrv.c:
In function 'supdrvIOCtl':
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support/SUPDrv.c:1429:
warning: format '%#lx' expects type 'long unsigned int', but argument
3 has type 'unsigned int'
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support/SUPDrv.c:1610:
warning: format '%#lx' expects type 'long unsigned int', but argument
3 has type 'unsigned int'
kmk[2]: ***
[/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/out/freebsd.x86/debug/obj/vboxdrv/freebsd/SUPDrv-freebsd.o]
Error 1
The failing command:
@gcc -c -g -Wall -Wextra -Wno-missing-field-initializers -Wno-unused
-Wno-trigraphs -Wpointer-arith -Winline -Wno-pointer-sign
-Wstrict-prototypes -Wmissing-prototypes -Wstrict-prototypes
-Wnested-externs -O2 -fformat-extensions -ffreestanding
-fno-strict-aliasing -fno-common -finline-limit=8000
-fno-stack-protector -march=i586 -O0 -fno-omit-frame-pointer -nostdinc
-std=c99 -m32 -mno-align-long-strings -mpreferred-stack-boundary=2
-mno-mmx -mno-3dnow -mno-sse -mno-sse2
-I/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support
-I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/../include
-I/usr/include
-I/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/include
-I/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/out/freebsd.x86/debug
-DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_HARDENING
-DRTPATH_APP_PRIVATE=\"/usr/local/lib/virtualbox\"
-DRTPATH_APP_PRIVATE_ARCH=\"/usr/local/lib/virtualbox\"
-DRTPATH_SHARED_LIBS=\"/usr/local/lib/virtualbox\"
-DRTPATH_APP_DOCS=\"/usr/local/share/doc/virtualbox\" -DDEBUG
-DDEBUG_dougb -DDEBUG_USERNAME=dougb -DRT_OS_FREEBSD -D__FREEBSD__
-DRT_ARCH_X86 -D__X86__ -D_KERNEL -DKLD_MODULE -DIN_RING0 -DIN_RT_R0
-DIN_RT_R0 -DIN_SUP_R0 -DSUPDRV_WITH_RELEASE_LOGGER
-DVBOX_SVN_REV=19957
-Wp,-MD,/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/out/freebsd.x86/debug/obj/vboxdrv/freebsd/SUPDrv-freebsd.o.dep
-Wp,-MT,/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/out/freebsd.x86/debug/obj/vboxdrv/freebsd/SUPDrv-freebsd.o
-Wp,-MP -o
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/out/freebsd.x86/debug/obj/vboxdrv/freebsd/SUPDrv-freebsd.o
/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c
kmk[2]: *** Waiting for unfinished jobs
kmk[2]: Leaving directory
`/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980'
kmk[2]: Entering directory
`/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980'
kmk[2]: *** Exiting with status 2
kmk[1]: *** [pass_binaries_this] Error 2
kmk[1]: Leaving directory
`/usr/local/home/dougb/virtualbox/work/virtualbox-2.2.2r19980'
kmk: *** [pass_binaries_order] Error 2
*** Error code 2

Stop in /usr/local/home/dougb/virtualbox.
*** Error code 1

Stop in /usr/local/home/dougb/virtualbox.


-- 

This .signature sanitized for your protection


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

Re: [CFT] FreeBSD python25 move to python26 as default version.

[Doug Barton]

Wesley Shields wrote:
> On Wed, May 27, 2009 at 10:58:05AM -0700, Doug Barton wrote:
>> Kelly Hays wrote:
>>> On Sun, May 17, 2009 at 11:54 AM, Martin Wilke  wrote:
>>>>Once the installed Python has been updated to 2.6, by using one of the
>>>>methods above, it is required to run the upgrade-site-packages target in
>>>>lang/python to assure that site-packages are made available to the new 
>>>> Python
>>>>version.
>>>>
>>>># cd /usr/ports/lang/python && make upgrade-site-packages
>>>>
>>>> This Makefile target requires ports-mgmt/portupgrade to be installed.
>>>>
>>> A lot of us are no longer using ports-mgmt/portupgrade in favor of
>>> ports-mgmt/portmaster. Please support both tools.
>> First, I don't use python, so I'm not directly affected by this.
>> Second, I don't think it's reasonable to _require_ that a user needs
>> to use any additional tools (such as portupgrade or portmaster) to do
>> something with the ports system. I do think it's reasonable to provide
>> instructions such as, "If you use toolA, do X, for toolB do Y, and if
>> you don't use a tool do Z, etc."
>>
>> That said, if someone can explain what it is that needs to be done, I
>> will be glad to help write instructions for doing it with portmaster.
> 
> At first glance it looks like pkg_which can be replaced with
> 'pkg_info -W' (the grep stuff may have to be changed, I haven't looked
> into it) and the portupgrade piece can be replaced with the
> equivalent in portmaster. There could be an
> upgrade-site-packages-portmaster target or the equivalent instructions
> can be added to UPDATING.

Thanks for taking a look at this. I tend to agree with you that it
should be easy to replace. For that matter, it should even be possible
to replace the portupgrade piece with 'make -DFORCE_PKG_REGISTER' but
I certainly wouldn't deny people who use the various maintenance tools
the opportunity to use them.

FWIW, portmaster does the equivalent of 'portupgrade -f' by default,
so the equivalent in the code below would simply be:
${PORTMASTER_CMD} $$UPD;

hope this helps,

Doug


> # Major upgrade support
> PORTUPGRADE_CMD?=   ${LOCALBASE}/sbin/portupgrade
> PKG_WHICH_CMD?= ${LOCALBASE}/sbin/pkg_which
> upgrade-site-packages:
> @if [ ! -x ${PORTUPGRADE_CMD} ]; then \
> ${ECHO_MSG} "Please install ports-mgmt/portupgrade."; \
> ${FALSE}; \
>  fi
> 
> @for ver in `echo ${_PYTHON_ALLBRANCHES}|${SED} 's/${PYTHON_VER}//'`; 
> do \
> if [ -d ${PREFIX}/lib/python$$ver ]; then \
> UPD=`${FIND} ${PREFIX}/lib/python$$ver \
> -type f -print0 | \
> ${XARGS} -0 ${PKG_WHICH_CMD} | \
> ${GREP} -Fv '?' | \
> ${EGREP} -v '^python2?[0-5]?-2' | \
> ${SORT} -u`; \
> if [ "$$UPD" ]; then \
> ${PORTUPGRADE_CMD} -f $$UPD; \
> fi; \
> fi; \
>  done \
> 
> -- WXS
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 

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

Re: [Call For Testing] VirtualBox for FreeBSD! take 4

[Doug Barton]

Daniel O'Connor wrote:
> I see those options in the Makefile under a .if for 
> WITH_GUESTADDITIONS - however I don't think that variable is set 
> properly.

A quick glance at the Makefile indicates that the test for that knob
needs to be moved down below the pre- inclusion of bsd.port.mk.
Portlint will bark about various things being added too late in the
file, but there are no other options (pardon the pun). :)


Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: emulators/linux_base-f10 = Fedora 8?

[Doug Barton]

Mark Linimon wrote:
 Then mark the port BROKEN, or some such. User confusion is a bad thing. :)
>>> s/BROKEN/IGNORE/
>> Just wonder, can/should it be implemented automagically via
>> the repocopy script?
> 
> I have no opinion, but will note that as long as you don't connect
> the ports to the category Makefile, you don't need to worry about
> things like this :-)

The problem that I responded to was users who surf into those
directories that expect useful things to happen. That problem isn't
fixed by not hooking them up.

If it's easy to add this feature to the repocopy script then I would
suggest it be done.

Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Port of "service" command

[Doug Barton]

Edwin Shao wrote:
> Hello,
> 
> I was wondering if there was a port of the Linux/UNIX service
> ,
>  command? If not, is there any
> philosophical reason or roadblock to my creating one?

I think you'd need to answer the question of how is this solution
similar to just running '/etc/rc.d/foo start'?

Doug

-- 

This .signature sanitized for your protection

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

Re: Port of "service" command

[Doug Barton]

Doug Barton wrote:
> Edwin Shao wrote:
>> Hello,
>>
>> I was wondering if there was a port of the Linux/UNIX service
>> <http://www.manpagez.com/man/8/service/>,
>> <http://linux.die.net/man/8/service> command? If not, is there any
>> philosophical reason or roadblock to my creating one?
> 
> I think you'd need to answer the question of how is this solution
> similar to just running '/etc/rc.d/foo start'?

D'oh ... s/similar/superior/

Doug

-- 

This .signature sanitized for your protection

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

Re: Port of "service" command

[Doug Barton]

Kevin Downey wrote:
> I have a similar shell function I am rather fond of:
> 
> rc(){
> find /etc/rc.d/"$1" /usr/local/etc/rc.d/"$1" -exec sudo {} `echo
> "$*"|cut -f 2- -d \ ` \;
> }

Wow, that's painful. :) The only reason you don't notice how painful
is because those two directories have only a few files. Much much more
efficient would be something like:

rc () {
local script=$1
shift

if [ -x "/etc/rc.d/$script" ]; then
/etc/rc.d/$script $*
elif [ -x "/usr/local/etc/rc.d/$script" ]; then
/usr/local/etc/rc.d/$script $*
else
echo "$script does not exist in /etc/rc.d or"
echo "/usr/local/etc/rc.d"
return 1
fi
}


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: [REPOST] problem upgrading perl

[Doug Barton]

Scott Bennett wrote:
>  I got no responses when I posted this a few days ago, so I'm reposting
> it now.  I'd really like to finish the perl upgrade process, so I could move
> on to installing/updating other ports safely, but could use some advice.
>
>  Following the instructions in /usr/ports/UPDATING for upgrading from
> lang/perl5.8 to lang/perl5.10 using portmaster, the first part seems to go
> well.  The last line of that process is where the excerpt below begins.
> The second step, as you will see, fails with the error message shown.
> /usr/ports/UPDATING neglects to mention what to do next, and the process
> looks incomplete at this point.  If someone could offer instructions for
> completing the process, I would be grateful.
> 
> ===>>> Upgrade of perl-5.8.9_2 to perl-threaded-5.10.0_3 complete
> 
> hellas# nice +18 portmaster -v -r perl\*

As someone else already pointed out, the -r option can only take one
port, so if the glob matches more than one it won't work. Specifying
the specific installed port from the directory in /var/db/pkg is the
way to go.


hope this helps,

Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [REPOST] problem upgrading perl

[Doug Barton]

Jim Trigg wrote:
> Actually, he was suggesting changing from perl\* to perl-\* so it would
> only match the perl port. 

FYI, the \* at the end is not needed, 'portmaster perl-' will work
just fine.

> Unfortunately, that won't work as there is at
> least one other port that will match that -- net/p5-perl-ldap (portname
> perl-ldap). 

It's generally a good idea to check your facts before posting to the
list. Since the glob code goes by the directory names in /var/db/pkg,
and since the prefix will be there in the directory name, this won't
be an issue.

In any case, I updated the instructions for this, and the other
portmaster examples in /usr/ports/UPDATING a couple days ago so
hopefully no one else will stumble over this.

Doug

-- 

This .signature sanitized for your protection

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

Re: [RFC] New category proposal, i18n

[Doug Barton]

Thomas Abthorpe wrote:
> I would like to propose a new ports category, i18n, it would become the new 
> home, physical or virtual, for ports that are i18n or l10n based.
> 
> While researching the topic, I found the two terms, i18n and l10n, are often
> used interchangeably, and while either word could be used as the new category
> name, I chose i18 because it seems to keep in line with the efforts of
> freebsd-i18n team.

While I (as an ignorant 'merican) would tend to agree with you that
the terms are close in meaning, my experience is that the people who
care about the differences _really_ care about them. Rather than have
FreeBSD appear to take a position on the debate I would suggest that
we use a term that is both neutral and more descriptive, like
"localization" or something similar.

That said I think that anything we can do to encourage localization as
a goal we should do.

> Currently in the ports tree there are about 220 ports with i18n or l10n as
> part of their package name. Of these ports 159 are in the misc category,
> virtually all of which are related to KDE or Qt.
> 
> Should this new category come to being, the self identified ports in misc
> would get relocated. All other ports would simply be extended with the new
> virtual category name.

You've probably already covered this, but are you making a distinction
between ports that are used to _do_ localization-related tasks, and
ports that are localized versions of existing ports?


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: Removed port OPTIONS linger in /var/db/ports/.../options

[Doug Barton]

Nick Withers wrote:
> Hello all!
> 
> I was surprised to see, when trying to update lang/ruby18 today, that
> the to-be-installed package would be named "ruby
> +nopthreads-1.8.7.160_3,1", rather than the expected
> "ruby-1.8.7.160_3,1".
> 
> Checked out the port's Makefile, and indeed this name is now set when
> "WITHOUT_PTHREADS" is defined. Righto, no worries.
> 
> I hadn't defined WITHOUT_PTHREADS though... Or at least, didn't think I
> had! "make config" for lang/ruby18 didn't even show such an option.
> 
> "/var/db/ports/ruby/options", however, did, left over from a while back:
> 
> 
> # This file is auto-generated by 'make config'.
> # No user-servicable parts inside!
> # Options for ruby-1.8.7.72_1,1
> _OPTIONS_READ=ruby-1.8.7.72_1,1
> WITHOUT_PTHREADS=true
> WITHOUT_ONIGURUMA=true
> WITHOUT_GCPATCH=true
> WITH_IPV6=true
> WITHOUT_RDOC=true
> WITHOUT_DEBUG=true
> 
> 
> I must admit, I thought that when options were added or removed, the
> OPTIONS dialogue was redisplayed automatically, but it seems this is
> only when options are added (consistent with what seems to be implied in
> http://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html).

If that's accurate then it's a bug, although IME the cases where an
option is removed are few and far between.

> I don't really want to clear all ports options before each
> portmaster / portupgrade run

You don't need to clear them all with portmaster, you can use the
--force-config option which will run 'make config' for each port but
preserve the choices you've already made. There is also the
--check-port-dbdir option if you want to clear out options files for
ports you're no longer using.


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: [RFC] New category proposal, i18n

[Doug Barton]

Thomas Abthorpe wrote:
> To have localization, you need internationalization, so from this, I stand by 
> my original proposal of i18n.

I have no objection to your reasoning, but continue to object to the
specific string. If you're going to go down this road then
"internationalization" would be the better choice.

Doug

-- 

This .signature sanitized for your protection

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

Re: [REPOST] problem upgrading perl

[Doug Barton]

Scott Bennett wrote:
>  Thank you for doing that.  Unfortunately, it might have been more
> appropriate to have simply replaced that note with another that cautions
> anyone attempting the perl upgrade that the upgrade has not been fully
> tested against all ports that may list the new perl as a build dependency.

First off, I'm sorry to hear that you're having problems, particularly
that you're having problems with portmaster.

In regards to the upgrade process not being tested, with over 20,000
ports it's basically impossible to guarantee that something as
complicated as upgrading perl will work 100% of the time for every
user and every combination of perl-dependent ports. I think it's sort
of a given that "beware of dragons" is posted over the door.

> It should also warn that portmaster is *NOT* a good tool to use for this
> upgrade, even if the note shows how to attempt it.

I think it depends on your definition of "good," and also how you use
the tool. Since I use it every day, including for things like
upgrading perl, I happen to think it's a pretty good tool, but YMMV.

>  Using the specific port name for perl when restarting the upgrade
> process, I was able to resume for a short time.  However, portmaster has
> two design problems that apply here.  The first is that if portmaster
> encounters a port that fails to build properly, it stops cold, rather than
> continuing to build other ports that do build correctly, summarizing the
> build errors at the end. 

Because it's impossible for portmaster to know which are the
"important" errors to a given user I regard this as a feature, rather
than a problem. Also, errors like the ones you're experiencing
_should_ be rare, so in general this feature/bug/whatever doesn't
affect users all that often.

>  The second design problem is that the -R option, which is supposed to
> avoid rebuilding ports that have already been successfully rebuilt,
> nevertheless rebuilds the specified dependency port--in this case,
> perl-threaded-5.10.0_3--*every single time* without checking to see whether
> it was already successfully built. 

Have you tried using the -x option to exclude it? You can also use the
-i option, although for a lot of ports that can get annoying.

>  Back to the problems with the builds...a half dozen or more port
> rebuild failures were correctable by simply entering the failed port's
> directory, doing a "make deinstall && make reinstall", and then returning
> to restart (again) portmaster, which then, of course, began by rebuilding
> perl another time (sigh).  Full testing of the perl upgrade should have
> made this process unnecessary, it seems to me.

Perl is traditionally very twitchy about stuff like this, and the
solution you used is often the only one possible.

>  Eventually, though, I encountered a problem with a port called
> misc/gnome-icon-theme-2.26.0_1.  (I do not use and haven't knowingly
> installed gnome, so I really don't know why this port was installed in
> the first place. 

pkg_info -R should give you that information.

>  If someone can tell me how to proceed from here, I'll give it another
> try.  However, once again the ports subsystem is testing my tolerance for
> frustration, so if there's no real hope of completing the entire rebuilding
> process for ports with build dependencies upon perl

You should probably use the -i option, and only rebuild the actual p5-
ports. A lot of ports have what I consider "indirect" dependencies on
perl that make the -r option for portmaster and portupgrade do more
work than it probably ought to. However that's a topic for another
thread. :)


Good luck,

Doug

-- 

This .signature sanitized for your protection

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

Re: thank you for portmaster

[Doug Barton]

Dan Naumov wrote:
> Hey
> 
> Just thought I'd drop a line to thank you for creating portmaster.
> After discovering it yesterday thanks to a tip I got from somebody on
> IRC, it has now completely replaced portupgrade for me. Keep up the
> great work!

Thank you for the kind words, they are greatly appreciated. :)


Doug

-- 

This .signature sanitized for your protection

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

Re: [REPOST] problem upgrading perl

[Doug Barton]

Scott Bennett wrote:
>  On Tue, 23 Jun 2009 10:30:11 -0700 Doug Barton 
> wrote:
>  There ought to be an automated way to deal with the package issue that
> causes the failure of the entire update run just because it wants a human
> to type "make deinstall && make reinstall".

Sorry I wasn't clear, the inherent problem I described is with perl,
not with the ports. Because perl stores its libraries in a file
hierarchy based on version number (arguably, a feature) when you do a
straight upgrade from one version of perl to another IME the only
really good way to do that is to make a list of perl-related stuff you
have installed, delete everything, and reinstall. For those that only
have a few libraries installed using portmaster/portupgrade -r will
probably work, and is certainly worth a try.

>> Have you tried using the -x option to exclude it? You can also use the
>> -i option, although for a lot of ports that can get annoying.
> 
>  I had not, thanks to my having misread something in the portmaster man
> page. 

If you have any suggestions for improving the text I'm open to them.

> However, since reading your reply, I have tried (without -R)
> 
> # nice +18 portmaster -x perl-threaded-5.10.0 -rv perl-threaded-5.10.0_3

If this is a literal copy of what you did I'm surprised it worked
since you've placed the -v option between the -r and its argument.

> which did rebuild perl

Yes, I just checked the code and portmaster does not check the -x
argument for the main port specified in the command line. I'll take a
look at that.

> (along with many other already rebuilt ports, of
> course).  At this moment, I have
> 
> # nice +18 portmaster -x perl-threaded-5.10.0_3 -R -rv perl-threaded-5.10.0_3
> 
> running, and it is currently rebuilding perl yet again.  So the -x option
> appears to be useless, at least in this context.

You might want to be a little more careful with your adjectives. My
feelings aren't hurt but when you're asking for help, especially for
something you're not paying anything for, words like "useless" tend
not to make you any friends.

>  I began using FreeBSD at 5.2.1.  Along the way, my other complaints have
> largely been fixed, but the ports subsystem remains to this day the weakest
> part of all of FreeBSD.  I realize that the problem of coordinating the
> installation and maintenance of such a widely diverse body of ports and
> packages is a complex one,

Having spent a non-trivial amount of time in the bowels of the ports
system I would argue that "complex" is a dramatic understatement.

> but the problems the current tools, dependency
> lists, Makefiles, etc. present to the user are often insoluble by anyone but
> an expert in the internal workings of each of the pieces of the subsystem.
>  The packages subsystem is in about as bad shape, and in spite of the
> degree to which the two are intertwined, they really do not play nicely
> together.

Once again, being more careful with your rhetoric would go a long way
here. This is a volunteer project, and no one would argue that there
is nothing left to improve. Feel free to roll up your sleeves and get
to work. :)


Doug

-- 

This .signature sanitized for your protection

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

Re: portsclean deletes necessary distfiles

[Doug Barton]

You might want to try 'portmaster --clean-distfiles' for this purpose.
It parses the distinfo files from each installed port to generate the
list of current distfiles so there is no chance of deleting something
that you need. It's also quite fast.


hope this helps,

Doug

-- 

This .signature sanitized for your protection

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

Excluding multiple ports with -x (Was: Re: portmaster -x not working?)

[Doug Barton]

Lawrence Stewart wrote:
> Hijacking the thread slightly,

Generally better to start a new one, FYI.

> but is there a way to exclude multiple
> ports using the -x switch 

Not at this time, you'll want to use the -i option.


hth,

Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster -x not working?

[Doug Barton]

Try using just this:

portmaster -x mysql-client- phpMyAdmin-3.1.5

That should work. If it does not, please let me know.


Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: unable to make package for php-5.2.10

[Doug Barton]

Anton - Valqk wrote:
> works now, but now the libiconv breaks with missing mans...
> there is something wrong in whole thing...

You need to report these problems to the maintainers of the affected
ports.

hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: graphics/jpeg especially UPDATING

[Doug Barton]

Jason J. Hellenthal wrote:
> If you pkg_delete -r that will remove every package that depends on jpeg. 
> This is not the right way of just getting rid of jpeg considering it involves 
> the complete almost full re-installation of the entire system manually.
> 
> A better route to upgrade would be: pkg_delete -f jpeg-\*
> reinstall the new jpeg and then portmaster -r jpeg-\*

There is no need to do the pkg_delete first, and in fact I do not
recommend it. 'portmaster -r jpeg-' will accomplish what you want to
do on its own.

On the other hand, since just about every X-related binary links to
libjpeg you may want to consider using 'portmaster -w jpeg-' instead.
That will update you to jpeg-7 but leave the old library in
/usr/local/lib/compat/pkg. That way things linked against the old
library will still work and at some point in the future you can delete
the old library when everything (or almost everything) has been
updated in the natural course of events.


hope this helps,

Doug

-- 

This .signature sanitized for your protection

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

Re: graphics/jpeg especially UPDATING

[Doug Barton]

On Mon, 27 Jul 2009, Mel Flynn wrote:

Unfortunately, that can lead to problems as well. I don't have the precise
error anymore, but it is possible for programs to be linked to two different
libjpeg's and fail the assertion that (paraphrased) "foo wants JPEG_70 API yet
JPEG_62 API available". This was me trying to start kde, while the complete
upgrade did not finish yet.


That can happen sometimes, yes, but not often. I did what I suggested in 
my post (portmaster -w) and haven't had any problems yet.



Doug

--

This .signature sanitized for your protection

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

Re: updating to ghostscript8-8.64_2 fails

[Doug Barton]

On Tue, 28 Jul 2009, Scott Bennett wrote:


I finally got around it by putting a +IGNOREME file into
/var/db/pkg/ghostscript8-8.64_2/ after the following attempts to skip it
using the -x option for portmaster failed to do that.

portmaster -x print/ghostscript8 -v -w -a
portmaster -x print/ghostscript8\* -v -w -a
portmaster -x print/ghostscript8-8.64_2 -v -w -a


'portmaster -x ghostscript' should work.


Good luck,

Doug

--

This .signature sanitized for your protection

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

Re: Don't know how to make /usr/ports/dns/bind96/work/.build....

[Doug Barton]

Mel Flynn wrote:
> On Tuesday 28 July 2009 20:24:27 Dan Mahoney, System Admin wrote:
> 
>> make: don't know how to make
>> /usr/ports/dns/bind96/work/.build_done.bind96._usr_local. Stop
>> *** Error code 2
> 
>> Someone else had the same problem, and they also chose overwrite-base:
>>
>> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2007-08/msg00035.
>> html
>>
>> But it was dismissed because he was using "sudo", however the real reason
>> is because this problem goes away a second time.
> 
> Most likely because that option changes PREFIX, so the BUILD_COOKIE changed, 
> but the target was already in make's list of targets to make. After options 
> are stored in /var/db/ports, BUILD_COOKIE will end in ._usr.

I believe Mel is right here. 'make clean ; make config ; make' worked
for me.


Please let me know if it doesn't work for you.


Doug

-- 

This .signature sanitized for your protection

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

Re: Don't know how to make /usr/ports/dns/bind96/work/.build....

[Doug Barton]

Dan Mahoney, System Admin wrote:

>> I believe Mel is right here. 'make clean ; make config ; make' worked
>> for me.
> 
> As does a second make after getting this error, but it's nonintuitive,
> and probably a ports bug.

I'm not sure why 'make clean' is nonintuitive in the context of
changing OPTIONS. What is your expectation of how it should work?

Doug

-- 

This .signature sanitized for your protection

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

[Fwd: Re: cvs commit: ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo ports/dns/bind96 Makefile distinfo]

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

> FYI, The checksums in the bind94 distinfo file seem to be wrong.
>
> /usr/ports/dns/bind94
>
> => MD5 Checksum mismatch for bind-9.4.3-P3.tar.gz.asc.
> => SHA256 Checksum mismatch for bind-9.4.3-P3.tar.gz.asc.

They created new signature files with a different key. I've updated
the ports just now.

Unfortunately some of ISC's mirrors still have the old signature
files, so there will be a period of time that this is problematic.


Please be patient,

Doug

- --

This .signature sanitized for your protection

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (FreeBSD)

iEYEAREDAAYFAkpwnKgACgkQyIakK9Wy8Ptd9wCfdgGG3Yw4lajFH86dUgROT5Yd
wdYAn2BHCfJFeEkT9Gjt3lvQ85+yck4Q
=hM2X
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: this time it's vim/distfiles

[Doug Barton]

Scott Bennett wrote:
>  When portmaster tries to rebuild vim-lite, it tries to verify the
> checksums of 239 (?) patches. 

To be a little more accurate, the ports infrastructure is doing the
verification. Portmaster just calls 'make checksum'.

>  I looked in distfiles and found that the line in question apparently
> had an extraneous character that displays in less and vi as a percent sign.
> 
> DISTFILE:vim/7.2.040:SIZE=1836:SHA256=ad320d45c2541a767b351fdb8720c349c468acec8cf54dcfced0a6d1e58e5d8e:MD5=4c493255ae227498016f30a0002ec1cc
> DISTFILE:vim/7.2.041%:SIZE=22405:SHA256=2f48e173df3d306edd982f8a3d5a15c65ba19694ca32bdbdaa51f8bcc48a3d06:MD5=107ba5dccb1df727601aead37abf8cd3
> DISTFILE:vim/7.2.042:SIZE=4987:SHA256=d5fa884a7c5ee77b60fe512ceccaac640c0dfc00bd435211f4e4597ae3bee2cd:MD5=99baedef8a9c908774b7ed74deacf184

The information stored in /var/db/ports/*/distfiles is only used to
make sure all of the distfiles associated with a port are deleted if
the user chooses that option. The checksum information is stored, but
is not used at this time. See also
http://www.freebsd.org/cgi/query-pr.cgi?pr=106483


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: Don't know how to make /usr/ports/dns/bind96/work/.build....

[Doug Barton]

Mel Flynn wrote:
> On Wednesday 29 July 2009 10:57:05 Doug Barton wrote:
>> Dan Mahoney, System Admin wrote:
>>>> I believe Mel is right here. 'make clean ; make config ; make' worked
>>>> for me.
>>> As does a second make after getting this error, but it's nonintuitive,
>>> and probably a ports bug.
>> I'm not sure why 'make clean' is nonintuitive in the context of
>> changing OPTIONS. What is your expectation of how it should work?
> 
> What he means is that make without arguments or make install as per handbook, 
> will build the build target which will invoke the config target if OPTIONS 
> changed or no options file is found.

In the original post the build was already done, but it had been done
with a different set of OPTIONS choices. My question is, why is
running 'make clean' in the scenario of:
1. build
2. change options
[make clean should happen here]
3. install

not intuitive?

> However, this is a corner case, as it applies to:
> - Ports that change PREFIX using OPTIONS
> - For which no options file is available or the OPTIONS list has changed
> - When the PREFIX is actually changed through toggling the appropriate option.
> 
> This applies surely to less then 100 (probably more like a dozen) ports on 
> the 
> 18k that are in the tree and only affects people who do not use ports-mgmt 
> software. As such it is not worth fixing, IMHO.

Forget this particular problem, you're right that the fact that the
ports system doesn't know how to deal with an obsoleted build-cookie
actually is a corner case.

My concern is the general user expectation of what should happen in
this scenario. If it's generally expected that magic should happen if
a users changes OPTIONS after building the port we need to make that
magic happen. Otherwise people will be installing things that are not
built the way that they think they are.


Doug

-- 

This .signature sanitized for your protection

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

Re: Don't know how to make /usr/ports/dns/bind96/work/.build....

[Doug Barton]

Dan Mahoney, System Admin wrote:
> The fact that the error occurs AT ALL is the bug and what is
> counterintuitive, and many people would not think to try typing "make"
> again, and instead would just assume the thing's broken.

Ok, I actually misunderstood the problem that you were reporting. I
thought that the reference to .build_done.bind96._usr_local indicated
that the port had already been built once, but that is not the case.
To reproduce the bug, you need to do the following:

1. Make sure there is nothing in /var/db/ports/bind96
2. cd /usr/ports/dns/bind96
3. make
4. Enable the "replace base" option
5. Save the config

You will then see the following error:

make: don't know how to make
/usr/local/tmp/usr/local/ports/dns/bind96/work/.build_done.bind96._usr_local.
Stop
*** Error code 2

I think Mel is right that the problem is changing PREFIX, but that's
the whole purpose of the option.

Could you please open a PR about this with a subject something to the
effect of "OPTIONS that change PREFIX cause an error after 'make
config'" and describe how to reproduce this?


Thanks,

Doug

-- 

This .signature sanitized for your protection

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

Re: after update - not all jpeg files are displayable

[Doug Barton]

Joe Marcus Clarke wrote:
> Oliver Lehmann wrote:
>> ajtiM wrote:
>>
>>> http://bbs.archlinux.org/viewtopic.php?pid=585987
>> sounds good
>> @marcus - will this fix be integrated into FreeBSDs gtk port?
> 
> Sure, but it may take me some time.

FWIW, I had the bug with gqview as well, and the cinfo->scale_denom
patch to gtk on that forum worked for me.


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: BIND help

[Doug Barton]

On Jul 29, 2009, at 6:06 PM, "Albert Thiel"  
 wrote:


I know you don't support Version 7.0 release since April, but the  
BIND patch

on freebsd.org's main site... will it work?


The patch is quite simple, so yes.

I tried compiling the 9.4.3-P3 on a 7.0 box and it does compile but  
will not

run.


I assume you mean the port? What do you mean by it won't run? How are  
you starting it?


Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: dns/bind96 doesn't register idnkit dependency

[Doug Barton]

Oliver Fromme wrote:
> However, pkg_infor -r doesn't list any dependencies.
> I compiled bind96 with the IDN option, so it also
> compiled and installed dns/idnkit.  

Mistake on my part that I just fixed. Thanks to danger@ for submitting
it.


Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports/*/jpeg "Thanks a lot guys"

[Doug Barton]

Garrett Cooper wrote:

> Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P)
> has a script called `revdep-rebuild' which goes and runs ldd on all
> pieces of software that are installed in portage (ok, substitute ports
> here). What I'm driving at is that we can use pkg_info and/or the
> mtree generated files to determine what files are installed, find out
> which packages have been broken up an update, then rebuild the port
> and all dependencies (LIB_DEPENDS?). What say you to that :)?

I was experimenting with various scripts using ldd in parallel to my
most recent portmaster update and I think there is a problem with that
solution. If libA is linked against libB which in turn is linked
against libMISSING (such as libjpeg.so.9 for example) then ldd against
libA will show libMISSING even though that problem can be solved by
simply updating libB (i.e., without recompiling libA). This same issue
applies to the idea of running ldd against things at install time and
recording the list.

Perhaps someone smarter than I about ldd can come up with a solution
to this, but until then I think that using ldd after the fact is a
stopgap measure to repair things if the ports infrastructure fails us.

In theory the dependency graphing in our existing ports infrastructure
should deal with this problem. In practice at the moment I personally
feel that we record too many "indirect" dependencies (such as libA
above) and that we would serve our users better if we stuck to direct
dependencies only (libB in the example above).

What should have happened in this case is that the ports that depend
DIRECTLY on libjpeg should have had their revisions bumped at the same
time as the update to libjpeg. Since that is what usually happens,
hopefully we can stop flogging this horse soon.

That said, if anyone really really wants to pursue the dependency
graphing issue further, can I suggest a new thread focused on that topic?


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: FreeBSD Port: psi-0.12.1_2 need update to 0.13

[Doug Barton]

Alexey Golodov wrote:
> Please, note that psi has been updated to0.13.
> Also, if you can, see psi+ (http://code.google.com/p/psi-dev/) and,
> probably, good idea to add this to ports.
> 

You might want to take a look at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html
and figure out how to do this work yourself. It is just like any other
skill, it gets easier with practice. :)


Doug

-- 

This .signature sanitized for your protection

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

Re: Compile error mail/alpine

[Doug Barton]

FYI, In the future you're likely to get faster results if you send
your problem report to the port's maintainer as well as the
freebsd-ports@ list.

David Southwell wrote:
>  FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 r...@amd64-
> builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> on intel quad core
> 
> 
> cc -std=gnu99 -g -D_THREAD_SAFE -O2 -fno-strict-aliasing -pipe -
> DLDAP_DEPRECATED -rpath=/usr/local/lib -o alpine addrbook.o adrbkcmd.o 
> after.o 
> alpine.o arg.o busy.o colorconf.o confscroll.o context.o dispfilt.o 
> flagmaint.o folder.o help.o imap.o init.o kblock.o keymenu.o ldapconf.o 
> listsel.o mailcmd.o mailindx.o mailpart.o mailview.o newuser.o pattern.o 
> pipe.o print.o radio.o remote.o reply.o roleconf.o send.o setup.o signal.o 
> status.o takeaddr.o titlebar.o smime.o date.o  -lcrypt -lpam -L/usr/lib -
> L/usr/local/openssl/lib -L/usr/local/lib ../pico/libpico.a 
> ../pico/osdep/libpicoosd.a ../pith/libpith.a ../pith/osdep/libpithosd.a 
> ../pith/charconv/libpithcc.a osdep/libpineosd.a ../c-client/c-client.a 
> /usr/local/lib/libldap.so -lcrypto -ltinfo /usr/local/lib/liblber.so -lssl -
> Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib
> ../c-client/c-client.a(osdep.o)(.text+0x68a1): In function `ssl_onceonlyinit':
> /usr/ports/mail/alpine/work/alpine-2.00/imap/c-client/osdep.c:335: warning: 
> warning: tmpnam() possibly used unsafely; consider using mkstemp()
> after.o(.text+0x36d): In function `start_after':
> /usr/ports/mail/alpine/work/alpine-2.00/alpine/after.c:77: undefined 
> reference 
> to `pthread_create'
> *** Error code 1

I just tried building it on a 7.2-STABLE amd64 from June 13th
(r194101) and didn't have any problems. Can you please post the
contents of /var/db/ports/alpine/options? Also, do you have any
options related to thread libraries in /etc/make.conf, and are you
using openssl from the ports, or in the base?


Doug

-- 

This .signature sanitized for your protection

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

Re: Getting a lot of - pkg_version: corrupted record (pkgdep line without argument), ignoring

[Doug Barton]

eculp wrote:
> I'm getting a lot of the following messages and have no idea how to find
> which package is causing the problem. 

This is one of those times that opening up the files and having a look
for yourself might be a good way to start. :)

> pkg_version: corrupted record (pkgdep line without argument), ignoring

egrep '(pkgdep$|pkgdep $)' /var/db/pkg/*/+CONTENTS

However, you indicate below that you are using 'portmaster
--check-depends' which should be fixing those for you. So try this:

cd /var/db/
cp -Rp pkg pkg-before
portmaster --check-depends
diff -ur pkg-before pkg > ~/pkg-dir.diff1
cp -Rp pkg pkg-after
portmaster --check-depends
diff -ur pkg-after pkg > ~/pkg-dir.diff2
cd pkg
egrep -l '(pkgdep$|pkgdep $)' */+CONTENTS > ~/pkg-dir.egrep

Ideally pkg-dir.diff2 pkg-dir.egrep should both be empty there. If
not, you will need to rebuild all of the ports listed in the egrep
file. One easy way to do that would be to use vi to strip everything
but the directory name out of that file then do this:

portmaster `cat ~/pkg-dir.egrep`

> While I'm bothering you, could someone give me some tips on the best
> ways to find corrupted files in /var/db/pkgs, /var/db/ports and any
> other places that they might be hiding.  I run
>  portmaster --check-depends
>  portmaster --check-port-dbdir

Those are both good examples from my perspective. :)  One thing
though, --check-port-dbdir won't find anything that is corrupt, it
will only find things that don't apply to your currently installed ports.


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: Error when using 'portupgrade -ay' (and several others) [Second attempt]

[Doug Barton]

[If you reply, please strip off freebsd-stable@, thanks.]

Jens Rasmus Liland wrote:
> That seems to have have done something more. But I still got some funky
> errors after running portmaster -a:

> ===>>> The x11/xphelloworld port has been deleted: Xprint application,
> deprecated upstream
> ===>>> Aborting update

That's just telling you that it can't update that app because the port
doesn't exist anymore. You have several options at that point. If you
want to keep it you can read the portmaster man page about +IGNOREME
files. If you don't need it anymore (and in this case you almost
certainly do not) then you can use 'portmaster -e xphelloworld' to
delete it (or just good old 'pkg_delete -f').


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: recent update causes perl5.10 build failure

[Doug Barton]

Scott Bennett wrote:
>  An update yesterday or today results in perl5.10's build aborting.  When
> it failed under portmaster, the messages from several processes were too
> jumbled for me to see easily what had happened, so I tried portinstall 
> instead.

If you get a non-obvious port build failure in portmaster your next
step should be to try just building the port itself without any tools
(i.e., cd /usr/ports/foo/bar ; make clean ; make). That will give you
the idea of whether or not the error is related to the tool, or the
port itself.

>  At least on a first look, it seems that perl5.10 has "MAKE_JOBS_SAFE= 
> yes"
> in its Makefile, but that it should not.  I changed that to
> "MAKE_JOBS_SAFE= no"

The ports infrastructure does not care what the value of the define
is, it just cares if it is defined. You need to do this:

cd /usr/ports/lang/perl5.10
vi Makefile (replace the MAKE_JOBS_SAFE with MAKE_JOBS_UNSAFE)
make clean
make config
make

Then report your results.


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: Don't know how to make /usr/ports/dns/bind96/work/.build....

[Doug Barton]

Dan Mahoney, System Admin wrote:
> On Wed, 29 Jul 2009, Doug Barton wrote:
> 
>> Dan Mahoney, System Admin wrote:
>>> The fact that the error occurs AT ALL is the bug and what is
>>> counterintuitive, and many people would not think to try typing "make"
>>> again, and instead would just assume the thing's broken.
>>
>> Ok, I actually misunderstood the problem that you were reporting. I
>> thought that the reference to .build_done.bind96._usr_local indicated
>> that the port had already been built once, but that is not the case.
>> To reproduce the bug, you need to do the following:
>>
>> 1. Make sure there is nothing in /var/db/ports/bind96
>> 2. cd /usr/ports/dns/bind96
>> 3. make
>> 4. Enable the "replace base" option
>> 5. Save the config
>>
>> You will then see the following error:
>>
>> make: don't know how to make
>> /usr/local/tmp/usr/local/ports/dns/bind96/work/.build_done.bind96._usr_local.
>>
>> Stop
>> *** Error code 2
>>
>> I think Mel is right that the problem is changing PREFIX, but that's
>> the whole purpose of the option.
>>
>> Could you please open a PR about this with a subject something to the
>> effect of "OPTIONS that change PREFIX cause an error after 'make
>> config'" and describe how to reproduce this?
> 
> Done, just got the mail from gnats: 137250.

Looks good, thanks!


Doug

-- 

This .signature sanitized for your protection

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

Re: is upgrade of devel/lib{tool, tldl}15 to devel/lib{tool, tldl}22 worth it?

[Doug Barton]

Scott Bennett wrote:
>  I see that /usr/ports/UPDATING describes an upgrade of devel/libtool15
> and devel/libtldl15 to devel/libtool22 and devel/libtldl22, respectively.
> Is this a good enough thing to do to justify the probable misery and risk
> of disaster that would be necessary to get through it? 

Excessive dramatics aside, the short answer is yes.

The longer answer is that the process described in UPDATING (using
either portupgrade or portmaster) is painless. Also, if you don't do
the update now the next time you try to build a port that requires
libtool you _will_ have pain.


hope this helps,

Doug

-- 

This .signature sanitized for your protection

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

Re: status of FreeBSD ports you maintain as of 20090705

[Doug Barton]

Diego Depaoli wrote:

> There are too many ports and too few people who care them.
> IMHO the options are:
> - decrease the number of ports

We trim dead/useless ports all the time.

> - increase the number of  volunteers/committers/testers...

This is the only valid answer for FreeBSD.

> - switch to a multi-level solution (e.g. Archlinux).

In DiegoBSD you should feel free to use any solution you think is
useful. :)


Doug

-- 

This .signature sanitized for your protection

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

Re: recent update causes perl5.10 build failure

[Doug Barton]

Scott Bennett wrote:

>  Keep in mind that this experience did appear to reveal a portmaster bug.
> After the "portmaster -w -v -a" had already asked whether to rebuild perl5.8
> even though it had a +IGNOREME file and had gotten an enter key in response,
> which should have selected the "n" shown as the default ("[n]"), it later
> went ahead and built perl5.8 anyway.  From what you and the documentation
> have told me, that should never happen.

I don't think it can happen if the build of all the dependencies is
under portmaster's control. However there are edge cases when
dependencies don't show up when portmaster polls the port for the list
but the ports infrastructure builds them anyway. I'd have to look at a
log of the whole session to be sure.

Having both perl5.8 and perl5.10 installed at the same time is kind of
an odd configuration, and could very well produce the kind of edge
case I described above.


hope this helps,

Doug

-- 

This .signature sanitized for your protection

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

Re: Compile error mail/alpine

[Doug Barton]

David Southwell wrote:

> I have tried with:
> WITH_THREADS=true
> WITH_MOUSE=true
> WITHOUT_NLS=true
> WITHOUT_ISPELL=true
> WITHOUT_NOSPELL=true
> WITH_PICO=true
> WITH_IPV6=true
> WITH_LDAP=true
> WITHOUT_PASSFILE=true
> WITH_CONS25=true
> WITHOUT_QUOTA=true
> WITH_MAILDIR=true
> 
> AND
> WITHOUT_IPV6=true

This isn't going to make a difference.

> With the same results
> 
> openssl:
> dns1# pkg_info |grep openssl
> openssl-0.9.8k_2SSL and crypto library
> php5-openssl-5.2.10 The openssl shared extension for php
> py26-openssl-0.8_1  Python interface to the OpenSSL library
> 
> I also recompiled openssl to make sure all was well.

Do you still have the openssl stuff in the base? This might cause a
conflict such as the one you're seeing. Also, try disabling threads in
OPTIONS and see if it builds for you then.

Doug

-- 

This .signature sanitized for your protection

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

Re: Getting a lot of - pkg_version: corrupted record (pkgdep line without argument), ignoring

[Doug Barton]

eculp wrote:

> I rebuilt the packages and all is well.

Glad to hear that it worked out for you. :)

> Thanks again for the explanation, the script and especially for
> Postmaster that I have been using almost exclusively since the first
> version and has been improving .with each subsequent release.

Thank you for the kind words, they are appreciated.

Doug

-- 

This .signature sanitized for your protection

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

Re: x11-toolkits/xview (actually contool)

[Doug Barton]

Carlos A. M. dos Santos wrote:
> On Wed, Aug 5, 2009 at 5:50 PM, Tom Uffner wrote:
>> Carlos A. M. dos Santos wrote:
>>
>>> Can't xconsole do the job for you instead of contool?
>> more or less. i am using xconsole by default. however i prefer contool
>> because it has the following features which are missing from every other
>> X console program that I am aware of:
>>
>> 1. it can remain iconified (or entirely unmapped) and out of my way most
>> of the time.
>> 2. it can timestamp the messages it prints
>> 3. it can alert me to the presence of new console messages by flashing
>> its icon, beeping, and/or opening its window
>> 4. it allows me to specify, using regular expression filters, the types
>> of messages it should or should not alert on.
>>
>>> BTW, what problems do you have with contool? Are they the same ones
>>> discussed before in these threads?
>>>
>>>
>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026516.html
>>>
>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026722.html
>> my xconsole still exhibits those problems. don't know about contool yet.
> 
> It is even worst on 8.0, now. Even making xconsole SUID root I can't
> see any of the messages written to /dev/console. Using "xterm -C" does
> not work.
> 
>> as i said, i haven't had the time to diagnose it yet. what console i use
>> on my X workstations is not really that high a priority in the grand scheme
>> of things. contool is exiting with this message:
>>
>> Assertion failed: (ret != inval_id), function _XAllocID, file xcb_io.c, line
>> 378.
>> Abort
>>
>> which may be another symptom of the tty layer changes, but i haven't really
>> had time to look at it yet.
> 
> Looks like a bug in XCB. This would not be a surprise, given the poor
> engineering of Xorg these days (lack of it, in fact). Try rebuilding
> libX11 with the patch I sent in this PR:
> 
>  http://www.freebsd.org/cgi/query-pr.cgi?pr=137373
> 
> You will not miss XCB. It is as useful as hole int your head.

I thought contool looked interesting so I tried build it. It requires
xview, which fails as follows on a fairly recent -current (8.0-BETA2
r195917: Mon Jul 27 16:09:24 PDT 2009):

cc -fPIC   -O2 -pipe -ggdb -fno-strict-aliasing -ggdb
-I../../../build/include  -I/usr/local/include-DCSRG_BASED
-I/include -DSUNOS41 -DX11R6 -DFUNCPROTO=15 -DNARROWPROTO
-DOS_HAS_LOCALE -DOS_HAS_MMAP
-DEXTRASMENU="\"/usr/local/lib/.text_extras_menu\""
-I../../../build/include  -I/usr/local/include-DCSRG_BASED
-I/include -DSUNOS41 -DX11R6 -DFUNCPROTO=15 -DNARROWPROTO
-DOS_HAS_LOCALE -DOS_HAS_MMAP
-DEXTRASMENU="\"/usr/local/lib/.text_extras_menu\""   -c ps_impl.c  -o
shared/ps_impl.o
ps_impl.c: In function 'ps_create':
ps_impl.c:183: warning: passing argument 1 of 'xv_error' makes integer
from pointer without a cast
rm -f ev_display.o shared/ev_display.o
cc -fPIC   -O2 -pipe -ggdb -fno-strict-aliasing -ggdb
-I../../../build/include  -I/usr/local/include-DCSRG_BASED
-I/include -DSUNOS41 -DX11R6 -DFUNCPROTO=15 -DNARROWPROTO
-DOS_HAS_LOCALE -DOS_HAS_MMAP
-DEXTRASMENU="\"/usr/local/lib/.text_extras_menu\""
-I../../../build/include  -I/usr/local/include-DCSRG_BASED
-I/include -DSUNOS41 -DX11R6 -DFUNCPROTO=15 -DNARROWPROTO
-DOS_HAS_LOCALE -DOS_HAS_MMAP
-DEXTRASMENU="\"/usr/local/lib/.text_extras_menu\""   -c ev_display.c
 -o shared/ev_display.o
In file included from ../../../build/include/xview_private/tty_impl.h:216,
 from ev_display.c:36:
/usr/include/sys/ioctl_compat.h:42:2: error: #error "Definitions not
available without TTY ioctl compat."
ev_display.c: In function 'ev_init_X_carets':
ev_display.c:89: warning: passing argument 1 of 'xv_error' makes
integer from pointer without a cast
ev_display.c: In function 'ev_put_caret':
ev_display.c:138: warning: passing argument 1 of 'xv_error' makes
integer from pointer without a cast
*** Error code 1



-- 

This .signature sanitized for your protection

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

Re: devel/dbus-qt4 won't build

[Doug Barton]

Lars Eighner wrote:
> Okay after it didn't work a few times I did
> 
> portupgrade -fr qt4\*
> 
> and still the make of devel/dbus-qt4 fails thus:

What happens if you do this:

cd /usr/ports/devel/dbus-qt4
make clean
make config
make


Doug

-- 

This .signature sanitized for your protection

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

Re: getting bogged down by malfunctioning ports subsystem

[Doug Barton]

Scott Bennett wrote:
>  Yesterday's ports updates are just *loads* of fun. :-(  Until portmaster
> reached the rebuilding of perl5.10, *every* *single* *port* that got rebuilt
> ended in failure on a "make deinstall/make reinstall" recommendation, *none*
> of which actually worked when tried. 

You've heard the definition of insanity right? Doing the same thing
over and over and expecting a different result? If you're having
problems like this it's a good idea to report them sooner than later.
Unless you can give specifics it's basically impossible to help you.

> The only thing that worked was to ignore
> that part of the recommendation and instead to do a
> "env FORCE_PKG_REGISTER make install".  I didn't isolate that until after
> several rebuilt ports (mostly qt4- ports) were lost due to the failures of
> the recommended solution.

Personally I have had good luck with FORCE_PKG_REGISTER in these
situations, although it's probably worth noting for the record that
this recommendation comes from the ports infrastructure, not portmaster.

I would also like to point out that if you have problems with *every*
*single* *port* you might want to consider that you have a more
systemic problem with your particular pkg directory having become
corrupt, or something else on a grander scale than just "the ports
subsystem sucks."

>  perl5.10, however, now fails to update on something different.  It gets
> an error that says,
> 
>.
>.
>.
> ===>>> Starting check for runtime dependencies
> ===>>> Gathering dependency list for lang/perl5.10 from ports
> ===>>> Starting dependency check
> ===>>> Checking dependency: /usr/ports/databases/gdbm
> ===>>> Dependency check complete for lang/perl5.10
> 
> /usr/bin/make install.perl install.man STRIPFLAGS= DESTDIR=""
> /usr/bin/strip: '/usr/local/bin/perl5.10.0': No such file
> /usr/bin/strip: '/usr/local/bin/perl': No such file
> /usr/local/bin/pod2man: not found
> *** Error code 127
> 
> It then proceeds to rebuild the port and install much of it before failing
> with
> 
> 1 error

In a situation like this what I would do is 'pkg_delete -f' the port,
then immediately rebuild it with portmaster again (so that portmaster
can register the dependencies properly when it installs). I agree that
is not "graceful," but the perl (and as I understand it python as
well) stuff is notoriously twitchy when it comes to these kinds of
problems.

I have considered changing the order of how portmaster does things from:

build
backup package (unless -B)
deinstall
install

to:
backup package
deinstall
build
install

That is undoubtedly more dangerous, and would require the "automated
backout" feature that I have yet to write, but it would solve a lot of
these problems.

-- 

This .signature sanitized for your protection

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

Re: devel/dbus-qt4 won't build

[Doug Barton]

Naram Qashat wrote:

> Actually, I had this problem as well, I found the solution (after a bit
> of Googling), is to deinstall devel/dbus-qt4 and then install it again. 
> Apparently the update conflicts with the older version already installed.

Oy, that's not a good thing. I notice that there is now an entry in
ports/UPDATING that covers this though, so at least users who pay
attention to that file will not run into the same problem.


Doug

-- 

This .signature sanitized for your protection

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

Re: x11-toolkits/xview (actually contool)

[Doug Barton]

Tom Uffner wrote:
> Doug Barton wrote:
>> I thought contool looked interesting so I tried build it. It requires
>> xview, which fails as follows on a fairly recent -current (8.0-BETA2
>> r195917: Mon Jul 27 16:09:24 PDT 2009):
> 
> i posted an ugly workaround for this a few days ago, which started this
> thread, and Mel Flynn replied with a better one.

Ok, committed, thanks!


-- 

This .signature sanitized for your protection

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

Re: x11-toolkits/xview (actually contool)

[Doug Barton]

Ok, so now I'm up to the point where starting contool give me this:

contool
Assertion failed: (ret != inval_id), function _XAllocID, file
xcb_io.c, line 378.
Abort trap: 6 (core dumped)

gdb log attached

-- 

This .signature sanitized for your protection

$ gdb /usr/local/bin/contool contool.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols 
found)...
Core was generated by `contool'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/local/lib/libxview.so.3...done.
Loaded symbols for /usr/local/lib/libxview.so.3
Reading symbols from /usr/local/lib/libolgx.so.3...done.
Loaded symbols for /usr/local/lib/libolgx.so.3
Reading symbols from /usr/local/lib/libXext.so.6...done.
Loaded symbols for /usr/local/lib/libXext.so.6
Reading symbols from /usr/local/lib/libX11.so.6...done.
Loaded symbols for /usr/local/lib/libX11.so.6
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/libxcb.so.2...done.
Loaded symbols for /usr/local/lib/libxcb.so.2
Reading symbols from /usr/local/lib/libXdmcp.so.6...done.
Loaded symbols for /usr/local/lib/libXdmcp.so.6
Reading symbols from /usr/lib/librpcsvc.so.5...done.
Loaded symbols for /usr/lib/librpcsvc.so.5
Reading symbols from /usr/local/lib/libXau.so.6...done.
Loaded symbols for /usr/local/lib/libXau.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x283e48c7 in kill () at kill.S:3
3   RSYSCALL(kill)
(gdb) bt
#0  0x283e48c7 in kill () at kill.S:3
#1  0x283e4826 in __raise (s=6) at /usr/local/src/lib/libc/gen/raise.c:46
#2  0x283e342a in abort () at /usr/local/src/lib/libc/stdlib/abort.c:65
#3  0x283c98f6 in __assert (func=0x6 , 
file=0x5 , line=0, 
failedexpr=0x28298178 "ret != inval_id")
at /usr/local/src/lib/libc/gen/assert.c:54
#4  0x2822d2ba in _XAllocID (dpy=0x28523600) at xcb_io.c:378
#5  0x281611b5 in server_init (parent=0, server_public=676349152, 
avlist=0xbfbfdc84) at server.c:746
#6  0x281b2a9d in xv_create_avlist (parent=0, pkg=0x281cb360, 
avlist=0xbfbfdc84) at xv.c:391
#7  0x281b2c6f in xv_create (parent=0, pkg=0x281cb360) at xv.c:307
#8  0x281b4924 in xv_init (attr1=1241974786) at xv_init.c:308
#9  0x0804b801 in ?? ()
#10 0x4a070802 in ?? ()
#11 0xbfbfea70 in ?? ()
#12 0xbfbfea90 in ?? ()
#13 0x in ?? ()
#14 0x in ?? ()
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0x in ?? ()
#20 0xbfbfea90 in ?? ()
#21 0xbfbfea70 in ?? ()
#22 0x in ?? ()
#23 0x in ?? ()
#24 0x in ?? ()
#25 0x in ?? ()
#26 0x in ?? ()
#27 0x in ?? ()
#28 0x in ?? ()
#29 0x in ?? ()
#30 0x in ?? ()
#31 0x in ?? ()
#32 0x in ?? ()
#33 0x in ?? ()
#34 0x in ?? ()
#35 0x in ?? ()
#36 0x in ?? ()
#37 0x in ?? ()
#38 0x in ?? ()
#39 0x in ?? ()
#40 0x in ?? ()
#41 0x in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x in ?? ()
#47 0x in ?? ()
#48 0x in ?? ()
#49 0x in ?? ()
---Type  to continue, or q  to quit---
#50 0x in ?? ()
#51 0x in ?? ()
#52 0x in ?? ()
#53 0x in ?? ()
#54 0x in ?? ()
#55 0x in ?? ()
#56 0x in ?? ()
#57 0x in ?? ()
#58 0x in ?? ()
#59 0x in ?? ()
#60 0x in ?? ()
#61 0x in ?? ()
#62 0x in ?? ()
#63 0x in ?? ()
#64 0x in ?? ()
#65 0x in ?? ()
#66 0x in ?? ()
#67 0x in ?? ()
#68 0x in ?? ()
#69 0x in ?? ()
#70 0x in ?? ()
#71 0x in ?? ()
#72 0x in ?? ()
#73 0x in ?? ()
#74 0x in ?? ()
#75 0x in ?? ()
#76 0x in ?? ()
#77 0x in ?? ()
#78 0x in ?? ()
#79 0x in ?? ()
#80 0x in ?? ()
#81 0x in ?? ()
#82 0x in ?? ()
#83 0x in ?? ()
#84 0x in ?? ()
#85 0x in ?? ()
#86 0x in ?? ()
#87 0x in ?? ()
#88 0x in ?? ()
#89 0x in ?? ()
#90 0x in ?? ()
#91 0x in ?? ()
#92 0x in ?? ()
#93 0x in ?? ()
#94 0x in ?? ()
#95 0x in ?? ()
#96 0x in ?? ()
#97 0x in ?? ()
#98 0x in ?? ()
#99 0x in ?? ()
#100 0x in ?? ()
#101 0x in ?? ()
#102 0x in ?? ()
#103 0x in ?? ()
#104 0x in ?? ()
---Type  to continue, or q  to quit---
#105 0x000

Re: devel/glib install is not correct.

[Doug Barton]

khsing wrote:
> I have found the reason. because libtool15 have been mv to libtool22.
> 
> so upgrade libtool from 15 to 22 will resolve this problem.
> 
> portmaster -Btuw libtool

Please check ports/UPDATING for the correct procedure. Of the flags
you suggested, -t and -u are meaningless in this scenario, and -w is
actually a bad idea, FYI.

Doug

-- 

This .signature sanitized for your protection

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

devel/qt4-designer fails on -current

[Doug Barton]

All the other qt4 stuff updated just fine, this one doesn't (and I
already disabled make-jobs).


Doug

c++ -c -pipe -g -g -O2 -Wall -W -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_SCRIPT_LIB -DQT_XML_LIB
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/local/share/qt4/mkspecs/freebsd-g++ -I.
-I../../../../include/QtCore -I../../../../include/QtNetwork
-I../../../../include/QtGui -I../../../../include/QtXml
-I../../../../include/QtScript -I../../../../include
-I../../../../include/QtDesigner
-I/usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.5.2/include/QtDesignerComponents
-I../lib/sdk -I../lib/extension -I../lib/shared -I../lib/uilib -Iextra
-I../../../shared/fontpanel -I../../../shared/qttoolbardialog
-I.moc/release-shared -I.uic/release-shared -I/usr/local/include -o
.obj/release-shared/qrc_qttoolbardialog.o
.rcc/release-shared/qrc_qttoolbardialog.cpp
g++ -Wl,-O1 -pthread -Wl,-rpath,/usr/local/lib/qt4
-Wl,-rpath,/usr/local/lib/qt4 -o ../../../../bin/designer-qt4
.obj/release-shared/fontpanel.o  .obj/release-shared/qttoolbardialog.o
 .obj/release-shared/main.o  .obj/release-shared/qdesigner.o
.obj/release-shared/qdesigner_toolwindow.o
.obj/release-shared/qdesigner_formwindow.o
.obj/release-shared/qdesigner_workbench.o
.obj/release-shared/qdesigner_settings.o
.obj/release-shared/qdesigner_server.o
.obj/release-shared/qdesigner_actions.o
.obj/release-shared/qdesigner_appearanceoptions.o
.obj/release-shared/saveformastemplate.o
.obj/release-shared/newform.o  .obj/release-shared/versiondialog.o
.obj/release-shared/appfontdialog.o
.obj/release-shared/preferencesdialog.o
.obj/release-shared/assistantclient.o
.obj/release-shared/mainwindow.o  .obj/release-shared/moc_fontpanel.o
 .obj/release-shared/moc_qdesigner.o
.obj/release-shared/moc_qdesigner_toolwindow.o
.obj/release-shared/moc_qdesigner_formwindow.o
.obj/release-shared/moc_qdesigner_workbench.o
.obj/release-shared/moc_qdesigner_actions.o
.obj/release-shared/moc_qdesigner_server.o
.obj/release-shared/moc_qdesigner_appearanceoptions.o
.obj/release-shared/moc_saveformastemplate.o
.obj/release-shared/moc_newform.o
.obj/release-shared/moc_versiondialog.o
.obj/release-shared/moc_appfontdialog.o
.obj/release-shared/moc_preferencesdialog.o
.obj/release-shared/moc_mainwindow.o
.obj/release-shared/qrc_designer.o
.obj/release-shared/qrc_qttoolbardialog.o-L/usr/local/lib/qt4
-L/usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.5.2/lib
-L/usr/local/lib -L../../lib -L../../../../lib -lQtDesignerComponents
-lQtDesigner -lQtScript -L/usr/local/lib/qt4 -L/usr/local/lib -pthread
-pthread -lQtXml -pthread -pthread -lQtGui -pthread -lpng -lfreetype
-lSM -lICE -pthread -pthread -lXrender -lfontconfig -lXext -lX11
-lQtNetwork -pthread -pthread -lQtCore -lz -lm -pthread -lgthread-2.0
-lglib-2.0 -liconv
.obj/release-shared/qdesigner.o(.text+0x4ad): In function
`QDesigner::parseCommandLineArgs(QStringList&, QString&)':
/usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.5.2/tools/designer/src/designer/qdesigner.cpp:205:
undefined reference to
`QDesignerPropertySheet::setInternalDynamicPropertiesEnabled(bool)'
.obj/release-shared/qdesigner_formwindow.o(.text+0x45d): In function
`QDesignerFormWindow::QDesignerFormWindow(QDesignerFormWindowInterface*,
QDesignerWorkbench*, QWidget*, QFlags)':
/usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.5.2/tools/designer/src/designer/qdesigner_formwindow.cpp:96:
undefined reference to
`qdesigner_internal::FormWindowBase::setupDefaultAction(QDesignerFormWindowInterface*)'
.obj/release-shared/qdesigner_formwindow.o(.text+0x67d): In function
`QDesignerFormWindow::QDesignerFormWindow(QDesignerFormWindowInterface*,
QDesignerWorkbench*, QWidget*, QFlags)':
/usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.5.2/tools/designer/src/designer/qdesigner_formwindow.cpp:96:
undefined reference to
`qdesigner_internal::FormWindowBase::setupDefaultAction(QDesignerFormWindowInterface*)'
.obj/release-shared/qdesigner_workbench.o(.text+0x1af8): In function
`QDesignerWorkbench::loadForm(QString const&, bool, bool*, QString*)':
/usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.5.2/tools/designer/src/designer/qdesigner_workbench.cpp:936:
undefined reference to
`qdesigner_internal::FormWindowBase::setLineTerminatorMode(qdesigner_internal::FormWindowBase::LineTerminatorMode)'
.obj/release-shared/qdesigner_workbench.o(.text+0x2500): In function
`QDesignerWorkbench::saveSettings() const':
/usr/local/tmp/usr/local/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.5.2/tools/designer/src/designer/qdesigner_workbench.cpp:636:
undefined reference to
`QDesignerFormEditorInterface::settingsManager() const'
.obj/release-shared/qdesigner_workbench.o(.text+0x48ed): In function
`QDesignerWorkbench::QDesignerWorkbench()':
/usr/local/tmp/usr/local/ports/devel/qt4-designer/work

Re: [kde-freebsd] devel/qt4-designer fails on -current

[Doug Barton]

Kent Stewart wrote:

> I had the same problem. It was fixed in a later update. You need to cvsup 
> again or what ever you use. 

I already have the latest version.

> You may hit problem with phonon, which the current UPDATING tells you to 
> delete. Using portupgrade, kdepim was updated after kdepimlibs and 
> kdepim-runtime were created and that deleted files in both that are needed by 
> *-workspace. You should delete kdepim before you continue.

I'm not using KDE, I'm just using vlc which requires qt (and IMO way
too much of it). I just tried deleting qt4-designer and vlc's
operation does not seem to be adversely affected, so that's how I'll
leave it for now.

Doug

-- 

This .signature sanitized for your protection

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

Re: getting bogged down by malfunctioning ports subsystem

[Doug Barton]

Matthias Andree wrote:
> Am 06.08.2009, 05:38 Uhr, schrieb Doug Barton :
> 
> 
>> I have considered changing the order of how portmaster does things from:
>>
>> build
>> backup package (unless -B)
>> deinstall
>> install
>>
>> to:
>> backup package
>> deinstall
>> build
>> install
>>
>> That is undoubtedly more dangerous, and would require the "automated
>> backout" feature that I have yet to write, but it would solve a lot of
>> these problems.
> 
> I recall very few cases where this change would have helped me; one was
> the recent GD2 update (arguably that would be a bug of the individual
> port - often an upstream bug - that picked up an old /usr/local library
> version during the build), and a minor one was an earlier
> e2fsprogs-libuuid issue (which was in fact just exposing genuine
> upstream bugs that impaired portability); it also impairs system
> functionality during the whole build phase.

I agree on both points, which is why I said I've considered it, not
done it yet. :)


Doug

-- 

This .signature sanitized for your protection

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

Re: devel/dbus-qt4 won't build

[Doug Barton]

Lars Eighner wrote:
> On Wed, 5 Aug 2009, Doug Barton wrote:
> 
>> Naram Qashat wrote:
>>
>>> Actually, I had this problem as well, I found the solution (after a bit
>>> of Googling), is to deinstall devel/dbus-qt4 and then install it again.
>>> Apparently the update conflicts with the older version already
>>> installed.
>>
>> Oy, that's not a good thing. I notice that there is now an entry in
>> ports/UPDATING that covers this though, so at least users who pay
>> attention to that file will not run into the same problem.
> 
> It sure looks like this thing gets worse, and worse.  If you try to fix
> devel/qt4-designer as suggested in UPDATING it turns out it won't install
> without devel/qt4-assistant being updated.
> 
> Does anyone check these things before they are committed?

Nope, we just commit random crap and sit around laughing while users
suffer.

Seriously though, think about the enormity of the current ports
system, the effectively-infinitely variable state of user systems at
upgrade time, and do the math. It's not possible to test every
scenario, and yes, sometimes there are inconveniences.

If you'd like to make a constructive contribution you should consider
sending k...@freebsd.org a note with suggestions on how to make the
UPDATING entry more accurate.

Doug

-- 

This .signature sanitized for your protection

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

Re: devel/qt4-designer fails on -current

[Doug Barton]

Doug Barton wrote:
> All the other qt4 stuff updated just fine, this one doesn't (and I
> already disabled make-jobs).

Well I'm a bit embarrassed. :-/  I just re-read the UPDATING entry on
qt4 stuff and it turns out that this issue is mentioned. Deleting the
port first and then installing it works as advertised.


Apologies for the noise,

Doug

-- 

This .signature sanitized for your protection

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

Re: Ports completely and permanently hosed

[Doug Barton]

Lars Eighner wrote:

> Believe me, if I can get back to my printer, camera, and mp3 player
> all working (which last occurred about 6.2 or so) I'll never upgrade
> again.  Of course it is kind of lonely when your release is orphaned,
> which happens in the blink of an eye, but if the kernel supports all the
> hardware, I'm pretty sure I can install any apps that I suddenly decide I
> have to have myself.

I'm not saying this to be snarky, but you might seriously consider
trying another open source operating system to see if it meets your
needs better. There is a reason that there are so many choices out
there nowadays, different people have different needs. For all the
strides we've made in the "desktop/end user" areas in the 15 years
I've been a FreeBSD user it is still, primarily, a server system;
especially when compared to other systems like Ubuntu that are focused
on the end user.

You're clearly very frustrated, and I'm not going to judge whether
your frustration is justified or not. But before you expend a lot more
energy railing about the sad state FreeBSD is in you might want to put
that energy in a more productive direction.


Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

enigmail error on -current

[Doug Barton]

I've got an up to date -current, and up to date thunderbird, and tried
updating enigmail today and got this:

/libexec/ld-elf.so.1:
~/.thunderbird/a.default/extensions/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/FreeBSD_x86-gcc3/components/libenigmime-x86-gcc3.so:
Undefined symbol "_ZN14nsAutoLockBaseC2EPvNS_14nsAutoLockTypeE"

The 0.95.7 from the enigmail web page works just fine.


Doug

-- 

This .signature sanitized for your protection

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

Re: portmaster -x not working?

[Doug Barton]

Lawrence Stewart wrote:

> Today, I again had need of the ability to exclude multiple ports from an
> update run. It turns out your tip doesn't work with portmaster, though I
> suspect it would with portupgrade.

For now, if you need to exclude more than one port you can check the
man page about +IGNOREME files.

> Doug, what do you think of the attached patch?

I think it's interesting, but not quite how I would do it. I have
plans to rewrite the command line parser in order to accommodate this,
and make things easier to work with generally, so stay tuned.

Doug

-- 

This .signature sanitized for your protection

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

Re: portmaster -x not working?

[Doug Barton]

Lawrence Stewart wrote:

> Ok cool. I would definitely like to be able to specify things
> dynamically on a per-run basis as well though without adding +IGNOREME
> files. I often want to special case the exclusion of ports one time only.

I agree that it's something that we need to be able to do. If you want
to do it on the command line instead you can also use -i, but if
you're dealing with a lot of ports (like with -a) that can get annoying.

Doug

-- 

This .signature sanitized for your protection

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

No sound in linux-flashplugin-9.0r246 on -current

[Doug Barton]

I vaguely recall seeing something about this, but don't recall if
there was a resolution.


Doug

-- 

This .signature sanitized for your protection

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

Re: No sound in linux-flashplugin-9.0r246 on -current

[Doug Barton]

Juergen Lock wrote:
> In article <4a7dd122.10...@freebsd.org> you write:
>> I vaguely recall seeing something about this, but don't recall if
>> there was a resolution.
> 
> Well head defaults to f10 linux base now

I've been using that for a while even before it became the default.

>  Btw, any particular reason you don't want flash10?

Well in the past I had a vague understanding that support for 9 was
"better," somehow, but good news:

I just installed 10 and it works fine, sound and everything. It has a
LOT more dependencies in comparison to 9, but working is better than
not working. :)

Doug

===>>> The following actions were performed:
Installation of databases/linux-f10-sqlite3
Installation of devel/linux-f10-nspr
Installation of net/linux-f10-openldap
Installation of security/linux-f10-cyrus-sasl2
Installation of ftp/linux-f10-curl
Installation of security/linux-f10-openssl
Installation of security/linux-f10-libssh2
Installation of security/linux-f10-nss
Installation of www/linux-f10-flashplugin10

-- 

This .signature sanitized for your protection

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

Re: No sound in linux-flashplugin-9.0r246 on -current

[Doug Barton]

Jason J. Hellenthal wrote:

> Is this something that could be handled through libmap.conf rather
> than adding an extraneous symlink to that may stick around after
> package deletion ?

Erroneous libmap.conf entries are just as likely to stick around. :)

You must have missed the part of the thread where I said this problem
was better handled by installing flash 10.

Doug
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [HEADSUP]: Ports freeze schedule for 8.0-RELEASE

[Doug Barton]

Erwin Lansing wrote:
> Below is the tentative schedule for the ports freeze in preparation for
> 8.0-RELEASE.  If any major delays occur in the overall release schedule,
> the dates may be postponed, but please start preparing to have your
> changed committed to the tree before August 17 to ensure they are
> included in the release.  Also, portmgr kindly asks anyone who has
> anything major lined up to already from today start mailing portmgr
> about these so we know what to expect and not be surprised by any major
> fallout that might extend the short freeze we have planned.
> 
> August 17: ports tree is frozen and package build begin
> August 24: ports tree is thawed and final package builds begin
> August 31: FreeBSD 8.0-RELEASE is released and ports tree is unfrozen

Since the release date is slipping is this schedule going to be adjusted?

Doug

-- 

This .signature sanitized for your protection

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

Re: graphics/netpbm & netpbm-devel

[Doug Barton]

cc'ing the maintainer since this is an issue that needs to be addressed.


Doug


Jason J. Hellenthal wrote:
> graphics/netpbm & netpbm-devel:
> 
> These two ports dont list and CONFLICTS for either one of them. They do on 
> the other hand list a conflict with "mgetty ???". Why don't these list 
> conflicts with each other?. As of now I am doing cleanup once again for two 
> versions of netpbm that have somehow been installed by portmaster during the 
> mass confusion of graphics/jpeg.
> 
> Best regards.
> 


-- 

This .signature sanitized for your protection

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

Re: portversion and pkg_version have different opinions on current versions

[Doug Barton]

N.J. Mann wrote:

> Some years ago I tried using portupgrade, but had all sorts of problems
> with its database getting corrupted.  In desparation I tried portmaster
> and have been a very happy since.  (Thanks Doug!).

Well I don't know about the desperation part, but you're welcome in
any case. :)

-- 

This .signature sanitized for your protection

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

Re: portversion and pkg_version have different opinions on current versions

[Doug Barton]

Thomas Backman wrote:
> First off: not subscribed to this list, please make sure to Cc me or I
> won't see your answers! :)
> 
> Oh, and I use portsnap, in crontab:
> 0 19 * * *  portsnap -I cron update
> 
> So, long story short:
> 
> [r...@chaos ~]# pkgdb -aF
> --->  Checking the package registry database
> [r...@chaos ~]# portversion -l '<'
> dnsmasq <
> ezm3<
> libtool <
> python26<
> [r...@chaos ~]# pkg_version | awk '$2 !~ /=/'
> [r...@chaos ~]# portupgrade -a
> [r...@chaos ~]#

Off hand I'd say this looks like your pkgdb might be corrupt or out of
sync, but I am far from an expert in portupgrade.

> ... How do I figure out which is correct,

pkg_version is authoritative since by default it checks the version of
what you have installed against what's in the port's Makefile. Nick
was right and you can just use the following:

pkg_version -L '='

> and which/what should I use in
> my crontab to check for out-of-date packages?

If you want to run it every night after portsnap runs I'd just add "&&
pkg_version -L '='" to the end of your crontab. If you want a little
nicer output there is a periodic script to check package status. You
could copy the lines about 400.status-pkg from
/etc/defaults/periodic.conf to /etc/periodic.conf, enable it there,
and then do: && /etc/periodic/weekly/400.status-pkg at the end of your
crontab line.

> I'm pretty new to FreeBSD

Welcome!

> (testing use since May, but I've used it briefly before), but have
> almost 10 years of Linux experience, mostly Gentoo, so I'm not new to
> *nix-like OS's, not to mention that Gentoo's portage is based on FreeBSD
> ports - except that it has an official interface (i.e. emerge), rather
> than portupgrade, portmaster, portmanager, etc. A bit of a mess in my
> outsider opinion. ;)

One person's mess is another person's freedom of choice. :)  Each of
those tools has its positives and negatives, and each of them has a
user base that is happy with the tool.

In any case, hope that answers your question and good luck!


Doug

-- 

This .signature sanitized for your protection

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

Re: portversion and pkg_version have different opinions on current versions

[Doug Barton]

Thomas Backman wrote:

> Thanks, guys!
> However, a new issue appeared... Kind of. I know I read something about
> portsnap and INDEX on the -current list recently, so I'm guessing this
> is related? Maybe not, though (see later in the mail).
> 
> [r...@chaos /usr/ports/ports-mgmt]# portsnap -I fetch update >/dev/null
> [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vL=
> [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vIL=
> curl-7.19.5_1   <   needs updating (index has 7.19.6)
> dnsmasq-2.49_1  <   needs updating (index has 2.49_2)
> ezm3-1.1_2  <   needs updating (index has 1.2_1)

Can you check the files in your ports tree to see if they have the
older versions or the newer? You can either read the Makefiles or do this:

cd /usr/ports/ftp/curl
make -V PKGNAME

I suspect that somehow the INDEX file and your ports tree are out of
date, although my understanding was that this should not happen with
portsnap.

> libtool-1.5.26  !   Comparison failed

Read /usr/ports/UPDATING, you need to fix this.

> [r...@chaos /usr/ports/ports-mgmt]# ls -l /usr/ports/INDEX-*
> -rw-r--r--  1 root  wheel  17370624 Jul 31 19:45 /usr/ports/INDEX-5
> -rw-r--r--  1 root  wheel  19813792 Aug 15 20:42 /usr/ports/INDEX-6
> -rw-r--r--  1 root  wheel  19808537 Aug 15 20:42 /usr/ports/INDEX-7
> -rw-r--r--  1 root  wheel  34316288 May  8 10:35 /usr/ports/INDEX-7.db
> -rw-r--r--  1 root  wheel  19816190 Aug 15 20:42 /usr/ports/INDEX-8
> -rw-r--r--  1 root  wheel   1291821 May 30 12:06 /usr/ports/INDEX-8.bz2
> -rw-r--r--  1 root  wheel  34869248 Aug 14 19:30 /usr/ports/INDEX-8.db

I would 'rm /usr/ports/INDEX*' before doing your next portsnap update
just to be sure.


hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: portversion and pkg_version have different opinions on current versions

[Doug Barton]

Jason J. Hellenthal wrote:

> Why not just add weekly_status_pkg_enable="YES" to /etc/periodic.conf.local 
> and youll be informed of packages that need updating.

Sorry to pick on your response, but this thread is a good time to
remind people of some basic mailing list etiquette:

1. Read the whole thread before you reply (the suggestion you made
above was already made earlier in this thread).

2. Make sure you understand the real problem before you reply (the OP
has some sort of problem with his INDEX and ports tree not matching,
we've moved past just finding out what needs updating).

3. Don't speculate. If you're not 100% sure about something let
someone who is more knowledgeable reply. There have been several posts
in this thread that gave misleading and/or confusing information that
could easily have been avoided.


hth,

Doug

-- 

This .signature sanitized for your protection

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