p5-HTML-Tree -- missing dependency

[Ronald F. Guilmette]

Greetings,

I have some old code I'm trying to get running again.  It uses the
Perl module HTML::TreeBuilder (aka www/p5-HTML-Tree).

I did the following:

# pkg install p5-HTML-Tree

which completed with no problems, but now it appears that my installed
version of HTML::TreeBuilder craps out at:

/usr/local/lib/perl5/site_perl/HTML/TreeBuilder.pm line 59.

Looking at that source line, I see the following:

use HTML::Entities ();

I have looked in my ports tree to see if an appropriate port/pkg might
be available to satisfy this dependency, but all I am finding is these
things, none of which appear to fit the bill:

textproc/p5-HTML-Entities-ImodePictogram
textproc/p5-HTML-Entities-Interpolate
textproc/p5-HTML-Entities-Numbered
textproc/p5-HTML-HTML5-Entities
textproc/p5-MathML-Entities
textproc/p5-XML-DoubleEncodedEntities
textproc/p5-XML-Entities

Shouldn't the installation of a particular pre-built package such as
the p5-HTML-Tree force all of its dependencies to also be automagically
installed?

How do I fix this problem?

The descr file associated with the textproc/p5-HTML-HTML5-Entities package
says:

   HTML::HTML5::Entities is a pure Perl, drop-in replacement for HTML::Entities,
   providing the character entities defined in HTML5.

So should I just install that and then manually exit the source line
quoted above so that it says instead:

use HTML::HTML5::Entities ();

?


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

Re: Post-install messages

[Ronald F. Guilmette]

In message <5707fd13.2060...@gmx.de>, olli hauer  wrote:

>Try the command `pkg info -aD | less' or for a single package `pkg info -D $pa
>ckagename'

Thank you.  That seems to do the trick nicely.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Post-install messages

[Ronald F. Guilmette]

I am bringing up a new 10.3-RELEASE system from scratch.

While doing so, I unfortunately rushed ahead and installed
several packages I knew I needed using the "pkg install"
command, but I neglected to look carefully at all of the
helpful post-install messages for each package.  Most of
these post-install messages appear to be merely informative,
however some of these appear to be REALLY critical, e.g. the
ones you get after "pkg install bash".

Is there a way for me to go back now and see again all of the
post-install messages for all of the packages that I have
already installed, so that I can make sure that I've done
everything that should be done to properly install all these?

I am hoping that there is some way for me to see all these
messages again *without* having to force re-install all of the
relevant packages.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Deriving base port/package names

[Ronald F. Guilmette]

In message <5707553c.40...@quip.cz>, Miroslav Lachman <000.f...@quip.cz> wrote:

>If you have the index stripped to
>
>yorick-2.2.04_1
>
>This will do the trick
>sed 's/-[0-9a-z.,_+]*$//g' master-index.txt


Thank you.  Your response made me realize that there's an even simpler
solution...

sed 's/-[^\-]*$//'

That seems to do the trick!
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Deriving base port/package names

[Ronald F. Guilmette]

Given a list of all current FreeBSD ports/package, such as a (plain text
version) the list found here:

   https://www.freebsd.org/ports/master-index.html

and assuming that all text past the ' -- ' has already been deleted
from each line, what would be a proper sort of sed command to extract
_just_ the port/package names, without the version numbers attached?

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

Re: Firefox chokes up for several seconds... frequently

[Ronald F. Guilmette]

In message <20140604195803.gj2...@home.opsec.eu>, 
Kurt Jaeger  wrote:

>Hi!
>
>> > I spoke too soon.
>> >
>> > The problem is back again.
>> >
>> > As a friend of mine used to say "Problems that go away by themselves
>> > come back by themselves".
>[...]
>> Try changing "gfx.xrender.enabled" from True to False in about:config.  
>> This solved a similar problem with scaled images for me a couple years ago.
>
>I have seen the same problem (freezes for several seconds)
>and changed this config.

OK, I changed it.  Now I guess I'll see what happens.

>My firefox process currently has 3.6 GB RAM with 3.1 GB RSS (!)

Jesus!  Yes!  Mine is showing up (under top) as follows:

  PID USERNAME  THR PRI NICE   SIZERES STATE   C   TIME   WCPU COMMAND
58591 rfg47  520  2811M  2328M uwait   2 690:23 44.19% firefox

Jesus!  2.8 GIGABYTES !?!?!?!

No wonder the thing runs like a pig.  Probably half of it is swapped out
at any given time.

What the hell could it possibly be using so much memory for?  Is it trying
to cache every blessed last bit of crap it has received??

>That was much better in the past. I had firefox running for several
>month with heavy browsing. Now I need to restart it every 1-2 weeks.

Have you mentioned this to anybody?  I mean like, you know, anbody who
is involved with Firefox development?

>Hmm, one thing: I had gnash-0.8.10_10 installed. Deleted it now.

I don't have any gnash\* anything installed.
___
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"

A simple ports question

[Ronald F. Guilmette]

Functionally, what is the difference between:

   pkg_delete Y

and:

   cd /usr/ports/X/Y; make deinstall

?


P.S.  Yes, yes.  I know.  I am _supposed_ to be only using pkgng,
but if you are able to do so, please answer my question anyway.
___
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: Firefox chokes up for several seconds... frequently

[Ronald F. Guilmette]

In message <51901.1401770...@server1.tristatelogic.com>, I wrote:

>
>I wrote:
>
>> Since I last updated my ports a couple of weeks ago, the problem
>> has gotten DRAMATICALLY worse.  Now Firefox is choking up frequently,
>> and for perhaps 10-20 second each time, on virutally every web site
>> that I visit.
>
>NEVERMIND!
>
>I manually rebuilt and re-installed the nspluginwrapper and now
>everything with Firefox seems to magically be working A-OK again.

I spoke too soon.

The problem is back again.

As a friend of mine used to say "Problems that go away by themselves
come back by themselves".

I am still desperately seeking assistance to fix this problem.  I have
done everything I can to follow the Handbook instructions to the letter
and Firefox is still choking up on the vast majority of web sites.
(Apparently, almost every site on the Interwebs these days has a s**t
load of embedded flash crap on it, you know, to make it look fancy
schmancy.  I think this is absurdly stupid, but what do I know?)
___
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: Firefox chokes up for several seconds... frequently

[Ronald F. Guilmette]

In message <20140603042442.ge...@lena.kiev>, 
l...@lena.kiev.ua wrote:

> From: "Ronald F. Guilmette" 
>> In section 7.2.1.2. (Firefox and Adobe?? Flash?? Plugin) of
>> the above Handbook page, Step #3 says:
>> 
>> # ln -s /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so \
>>   /usr/local/lib/browser_plugins/
>
>Apparently obsolete.

OK.  I shall file a PR on against this part of the Handbook then.

___
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: Firefox chokes up for several seconds... frequently

[Ronald F. Guilmette]

I wrote:

> Since I last updated my ports a couple of weeks ago, the problem
> has gotten DRAMATICALLY worse.  Now Firefox is choking up frequently,
> and for perhaps 10-20 second each time, on virutally every web site
> that I visit.

NEVERMIND!

I manually rebuilt and re-installed the nspluginwrapper and now
everything with Firefox seems to magically be working A-OK again.
(I really do wish I knew why THAT would have fixed the problems
that I saw, but I guess that I actually don't care that much, as
long as everything is working again.)


Now... if I could only get flash working, at all, with either flavor
of Opera (native or Linux version), I would be a happy camper.
___
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"

Firefox chokes up for several seconds... frequently

[Ronald F. Guilmette]

Firefox has, for me 9and on FreeBSD) always exhibited some amount
of quirky behavior... occasionally freezing for several second or
more, for no apparently good reason, during which time, clicking
on *anything* within any of the open firefox windows simply produces
no response whatsoever.

Since I last updated my ports a couple of weeks ago, the problem
has gotten DRAMATICALLY worse.  Now Firefox is choking up frequently,
and for perhaps 10-20 second each time, on virutally every web site
that I visit.

This is slowly driving me insane.

I suspect that this may perhaps have something to do with my attempt
to update the flash plugin, and related things like the associated
wrapper.

Can anyone (please) help to to unsnarl this mess?

To begin with, here are some things that seem to be present on my
system at the present time, and I do believe there is something
that just isn't right here:


% cd /usr/local/lib
% find . -name libflashplayer.so | xargs ls -l
lrwxr-xr-x  1 root  wheel60 Feb 19  2013 
./browser_plugins/libflashplayer.so -> 
/usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so
-r--r--r--  1 root  wheel  17422820 May 16 08:50 
./browser_plugins/linux-f10-flashplugin/libflashplayer.so
lrwxr-xr-x  1 root  wheel49 May 16 08:50 
./browser_plugins/symlinks/linux-firefox/libflashplayer.so -> 
/usr/local/lib/browser_plugins//libflashplayer.so
lrwxr-xr-x  1 root  wheel49 May 16 08:50 
./browser_plugins/symlinks/linux-opera-devel/libflashplayer.so -> 
/usr/local/lib/browser_plugins//libflashplayer.so
lrwxr-xr-x  1 root  wheel49 May 16 08:50 
./browser_plugins/symlinks/linux-opera/libflashplayer.so -> 
/usr/local/lib/browser_plugins//libflashplayer.so
lrwxr-xr-x  1 root  wheel49 May 16 08:50 
./browser_plugins/symlinks/linux-seamonkey/libflashplayer.so -> 
/usr/local/lib/browser_plugins//libflashplayer.so


To begin with, my system does not seem to have any such
directory as /usr/local/lib/npapi/ even though this handbook
page make clear reference to such a thing, as does one of the
symlinks mentioned above:

 http://www.freebsd.org/doc/handbook/desktop-browsers.html

So what is the story, please?  Should I indeed have a directory called
/usr/local/lib/npapi/ on my system?  If so, how did I manage to install
all of this stuff *without* such a directory having been created, you
know, as part of the install process?  Do the rest of you have such a
directory on YOUR systems?  If so, what does it contain, exactly?

In section 7.2.1.2. (Firefox and Adobe® Flash® Plugin) of
the above Handbook page, Step #3 says:

# ln -s /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so \
  /usr/local/lib/browser_plugins/

This clearly indicates to me that the file libflashplayer.so is really
*supposed* to be located in the /usr/local/lib/npapi/linux-f10-flashplugin/
directory, and that the libflashplayer.so that is contained within the
/usr/local/lib/browser_plugins/ directory should really only be a symlink
to that.  Is that correct?  If so, I will make it so, but I am still
utterly baffled by how my system came to be like it is, with this file
actually having been installed in what appears to be the Wrong Place.

If anybody can explain to me how that happened, I sure would appreciate
it.

Anyway, in the xterm window where I've started Firefrox I have noticed
that during those times when it appears to be choked up, I am getting
errors like these:

(process:33557): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
*** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client 
connection
NOTE: child process received `Goodbye', closing down


I Think that the one about the unsupported locale has always been
generated, ad infinitum, by Firefox, and that this is just another
bug that nobody actually wants to fix.  But the error relating to
NSPlugin Wrapper seems to be new, and I guess this is being caused by
the fact that my libflashplayer.so is in the Wrong Place.


Humm... Well, I created the following (previously non-existant) directories:

/usr/local/lib/npapi/
/usr/local/lib/npapi/linux-f10-flashplugin/

and I moved my libflashplayer.so file to the latter directory.  Then,
I found that I needed to re-run this command from the handbook:

   nspluginwrapper -v -a -i

in order to get *something* to show up in my ~/.mozilla/plugins/
directory.  (Now that contains a file npwrapper.libflashplayer.so.)

so after all of the above, I ran firefox.  It *did* come up, but in
the xterm window where it was started, I got these errors immediately:

(process:34140): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size 
== 0' failed
LoadPlugin: failed to initialize shared library 
/usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so 
[/usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so: unsupported file 
layout]

My guess is that the "GLib-CRITICAL" error is, contrary, to its ominous
soun

Two questions about Firefox

[Ronald F. Guilmette]

1)  Is anybody planning to work on this problem?

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

2)  How has it been possible to fix other problems in the FreeBSD port of
Firefox if nobody is even able to run the thing when it has been
built with debugging enabled?

(May I safely infer that _nobody_ is _ever_ working to fix any bugs
found in Firefox on FreeBSD?  The fact that the thing cannot even be
run with debugging enabled would seem to lead one to that conclusion.)
___
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: multimedia/ffmpeg: pkg_add: leave_playpen: can't chdir back to ''

[Ronald F. Guilmette]

In message 
Kevin Oberman  wrote:

>On Thu, May 22, 2014 at 1:44 PM, Ronald F. Guilmette
>wrote:
>...
>> share/doc/ffmpeg/swscale.txt: Could not unlink
>> share/doc/ffmpeg/tablegen.txt: Could not unlink
>> share/doc/ffmpeg/viterbi.txt: Could not unlink
>> tar: Error exit delayed from previous errors.
>> pkg_add: leave_playpen: can't chdir back to ''
>> *** [install-package] Error code 2
>>
>> Stop in /usr/ports/multimedia/ffmpeg.
>> *** [install] Error code 1
>>
>> Stop in /usr/ports/multimedia/ffmpeg.
>>
>
>The list of "Could not unlink" messages smell like some sort of permissions
>problem.

Nevermind.

Apparently, there was a _file_... please note... a _file_ (not a directory)
on my system with the name /usr/local/share/doc/ffmpeg and this was
apparently causing all the problems.

I removed it and now the install completes without error.

I myseld never intentionally created that file, and I feel that it must
have been a left-over of some kind of some prior install of ffmpeg...
perhaps from long ago.

The file itself was apparently a text file, 7 bytes long, containing only
the following text:

0.7.15

I say again that I personally have no recollection of *ever* having
intentionally created any such file.

I humbly suggest that install scripts should avoid making assumptions
about the presence of absence of some particular type of thing within
the file system unless the scripts in question have themselves made all
necessary arrangements beforehand to create said filesystem objects
(and using "rm -f" where necessary, in order to reliably clear the way
for any such creations).
___
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"

multimedia/ffmpeg: pkg_add: leave_playpen: can't chdir back to ''

[Ronald F. Guilmette]

I built the latest multimedia/ffmpeg and now it won't install, due
to the error(s) shown below.

Is there a known fix for this?

P.S.  Apparently this error:

  pkg_add: leave_playpen: can't chdir back to ''

has been publically discussed since at least January, 2012.  In all that
time, why hasn't anybody fixed it?

=
# make install
===>  Installing for ffmpeg-2.1.1_3,1
===>   ffmpeg-2.1.1_3,1 depends on shared library: libfontconfig.so - found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libfreetype.so - found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libgnutls.so - found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libopencv_imgproc.so - found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libschroedinger-1.0.so - 
found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libtheora.so - found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libva.so - found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libvorbisenc.so - found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libvpx.so - found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libx264.so - found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libxvidcore.so - found
===>   ffmpeg-2.1.1_3,1 depends on shared library: libiconv.so.3 - found
===>  Checking if multimedia/ffmpeg already installed
share/doc/ffmpeg/APIchanges: Could not unlink
share/doc/ffmpeg/CREDITS: Could not unlink
share/doc/ffmpeg/Changelog: Could not unlink
share/doc/ffmpeg/INSTALL: Could not unlink
share/doc/ffmpeg/LICENSE: Could not unlink
share/doc/ffmpeg/MAINTAINERS: Could not unlink
share/doc/ffmpeg/README: Could not unlink
share/doc/ffmpeg/RELEASE_NOTES: Could not unlink
share/doc/ffmpeg/avutil.txt: Could not unlink
share/doc/ffmpeg/build_system.txt: Could not unlink
share/doc/ffmpeg/developer.html: Could not unlink
share/doc/ffmpeg/errno.txt: Could not unlink
share/doc/ffmpeg/faq.html: Could not unlink
share/doc/ffmpeg/fate.html: Could not unlink
share/doc/ffmpeg/fate.txt: Could not unlink
share/doc/ffmpeg/ffmpeg-all.html: Could not unlink
share/doc/ffmpeg/ffmpeg-bitstream-filters.html: Could not unlink
share/doc/ffmpeg/ffmpeg-codecs.html: Could not unlink
share/doc/ffmpeg/ffmpeg-devices.html: Could not unlink
share/doc/ffmpeg/ffmpeg-filters.html: Could not unlink
share/doc/ffmpeg/ffmpeg-formats.html: Could not unlink
share/doc/ffmpeg/ffmpeg-protocols.html: Could not unlink
share/doc/ffmpeg/ffmpeg-resampler.html: Could not unlink
share/doc/ffmpeg/ffmpeg-scaler.html: Could not unlink
share/doc/ffmpeg/ffmpeg-utils.html: Could not unlink
share/doc/ffmpeg/ffmpeg.html: Could not unlink
share/doc/ffmpeg/ffmpeg.txt: Could not unlink
share/doc/ffmpeg/ffprobe-all.html: Could not unlink
share/doc/ffmpeg/ffprobe.html: Could not unlink
share/doc/ffmpeg/ffserver-all.html: Could not unlink
share/doc/ffmpeg/ffserver.html: Could not unlink
share/doc/ffmpeg/filter_design.txt: Could not unlink
share/doc/ffmpeg/general.html: Could not unlink
share/doc/ffmpeg/git-howto.html: Could not unlink
share/doc/ffmpeg/git-howto.txt: Could not unlink
share/doc/ffmpeg/issue_tracker.txt: Could not unlink
share/doc/ffmpeg/libavcodec.html: Could not unlink
share/doc/ffmpeg/libavdevice.html: Could not unlink
share/doc/ffmpeg/libavfilter.html: Could not unlink
share/doc/ffmpeg/libavformat.html: Could not unlink
share/doc/ffmpeg/libavutil.html: Could not unlink
share/doc/ffmpeg/libswresample.html: Could not unlink
share/doc/ffmpeg/libswscale.html: Could not unlink
share/doc/ffmpeg/mips.txt: Could not unlink
share/doc/ffmpeg/multithreading.txt: Could not unlink
share/doc/ffmpeg/nut.html: Could not unlink
share/doc/ffmpeg/optimization.txt: Could not unlink
share/doc/ffmpeg/platform.html: Could not unlink
share/doc/ffmpeg/rate_distortion.txt: Could not unlink
share/doc/ffmpeg/snow.txt: Could not unlink
share/doc/ffmpeg/soc.txt: Could not unlink
share/doc/ffmpeg/swresample.txt: Could not unlink
share/doc/ffmpeg/swscale.txt: Could not unlink
share/doc/ffmpeg/tablegen.txt: Could not unlink
share/doc/ffmpeg/viterbi.txt: Could not unlink
tar: Error exit delayed from previous errors.
pkg_add: leave_playpen: can't chdir back to ''
*** [install-package] Error code 2

Stop in /usr/ports/multimedia/ffmpeg.
*** [install] Error code 1

Stop in /usr/ports/multimedia/ffmpeg.

___
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"

PORT META: Installed files conflict between ports

[Ronald F. Guilmette]

I just submitted the following PR:

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

I was a bit flabberghasted to believe that such file conflicts between
ports was even possible.  Seeing that it is possible prompted me to
write the attached small Perl script, which can quickly find all such
cases among a set of installed ports on a given system.

To use this simple script, place it somewhere on your path and name
it "pccheck" (Port Conflict Check).  Then do the following:

cd /var/db/pkg
pccheck *

That will tell you if any of your installed ports have installed any
files which any other of your installed ports also believe that they
also have installed.

When I ran it on my system, I got this, which is worrying, to say the
least:

mplayer2-2.0.20130428_4: Conflict -- file=/usr/local/bin/mplayer  
pkg=mplayer-1.1.r20140418
mplayer2-2.0.20130428_4: Conflict -- file=/usr/local/man/man1/mplayer.1.gz  
pkg=mplayer-1.1.r20140418
samba36-nmblookup-3.6.23: Conflict -- file=/usr/local/bin/nmblookup  
pkg=samba36-3.6.23
samba36-nmblookup-3.6.23: Conflict -- file=/usr/local/man/man1/nmblookup.1.gz  
pkg=samba36-3.6.23
samba36-nmblookup-3.6.23: Conflict -- file=/usr/local/man/man5/smb.conf.5.gz  
pkg=samba36-3.6.23

How does this sort of problem even creep in (to the ports tree)?  Is
there nothing in place which prevents it from arising?


#!/usr/bin/perl -w

use strict;

my $origin;
my %installed_files;

foreach my $arg (@ARGV) {
  next unless (-d "$arg");
  open (IFILE, "<$arg/+CONTENTS") || die "$arg: Open failed\n";
  while (my $line = ) {
chop $line;
if ($line =~ m/^\@/) {
  if ($line =~ m/^\@conflicts /) {
#print STDERR ("$arg: $line\n");
# do nothing
  } elsif ($line =~ m/^\@cwd /) {
$origin = $';
  } else {
# do nothing
  }
} else {
  next if ($line =~ m/^\+[A-Z]/);
  die "$arg: Origin not defined\n" unless (defined ($origin));
  my $fullpath = "$origin/$line";
#  print "$fullpath\n";
  if (exists ($installed_files{$fullpath})) {
print STDERR ("$arg: Conflict -- file=$fullpath  
pkg=$installed_files{$fullpath}\n");
  } else {
$installed_files{$fullpath} = $arg;
  }
}
  }
  close (IFILE);
}
___
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"

Need help getting docbook mess unsnarled

[Ronald F. Guilmette]

I rarely update my installed ports.  I do it only every few months.

Unfortunately, when I tried to do it a few days ago (using "portupgrade -a")
I neglected to read over the last several thousand lines of the UPDATING
file, in particular this entry:


20140219:
  AFFECTS: users of textproc/docbook*
  AUTHOR: m...@freebsd.org

  The textproc/docbook-* ports have been consolidated into two ports
  textproc/docbook-sgml and textproc/docbook-xml.

  Before upgrading you should force the removal of the existing ports, they
  will conflict with the new ones.
  
  pkg users can run:

pkg delete -f docbook-xml\* docbook-sk\* docbook\[2345\]\?\?-\* docbook-4\*

  the other users can run:

pkg_delete -f docbook-xml\* docbook-sk\* docbook\[2345\]\?\?-\* docbook-4\*


So, um, naturally, a whole bunch of my port updates failed, whereupon
I went and read the UPDATING file and found the note quoted above.

Upon seeing this I did as suggested, albeit after having already tried
to update everything:

pkg_delete -f docbook-xml\* docbook-sk\* docbook\[2345\]\?\?-\* docbook-4\*

Now it seems that my installed ports are still all messed up, and I seem
to have two different version of the docbook port installed.  (See below.)

What must I do in order to untangle all this?  I've tried removing
some of the packages mentioned below, but pkg_delete won't let me
because they have other things dependent upon them.  Do I have to
delete each and every one of those installed ports too, then delete
the ``bad'' (obsolete) docbbook-* things, and then just manually
reinstall all of the dependent ports?

Another question:  If one had... at some prior point in time... installed
some package `X', and if one subsequently then did a "portinstall X",
would that be an OK thing to do?

I'm worried/paranoid about doing this because I am aware of the fact
that when one is manually building & installing ports, particularly
ones that have previously been installed, then one is supposed to do
"make deinstall" and then "make reinstall".  Obviously, there is some
magic that is associated with these specific make targets... in particular
"make reinstall"...  and I don't know if that required magic is or is
not incorporated into portinstall.  So I'm worried about using portinstall
for anything that was every previously installed.  Will anything get
messed up if I do?

P.S.  Yes, yes.  I know.  I'm supposed to be using pkgng.  I haven't
had the time yet to familiarize myself with that.  I still have until
September to convert myself, right?


% pkg_info docbook\*

Information for docbook-1.5:

Comment:
Meta-port for the different versions of the DocBook DTD


Required by:
brasero-2.32.1_6
docbook-xsl-1.76.1_2
evince-2.32.0_11
gimp-app-2.8.10_2,1
gimp-gutenprint-5.2.8
gnome-desktop-2.32.1_5
gnome-doc-utils-0.20.10_2
gnome-mount-0.8_12
gthumb-2.14.1_8
gtk-doc-1.18_1
gvfs-1.12.3_2
nautilus-2.32.2.1_6
policykit-gnome-0.9.2_7
py27-gimp-2.8.10_1
rarian-0.8.1_1
xmlto-0.0.26_1
yelp-2.30.2_7


Description:
A meta-port for the DocBook DTD.  This port depends upon the docbook-*
ports, to ensure that they are installed correctly.

WWW: http://www.oasis-open.org/docbook/



Information for docbook-5.0_1:

Comment:
DocBook 5.0, designed for technical documentation


Required by:
brasero-2.32.1_6
docbook-1.5
docbook-xsl-1.76.1_2
evince-2.32.0_11
gimp-app-2.8.10_2,1
gimp-gutenprint-5.2.8
gnome-desktop-2.32.1_5
gnome-doc-utils-0.20.10_2
gnome-mount-0.8_12
gthumb-2.14.1_8
gtk-doc-1.18_1
gvfs-1.12.3_2
nautilus-2.32.2.1_6
policykit-gnome-0.9.2_7
py27-gimp-2.8.10_1
rarian-0.8.1_1
xmlto-0.0.26_1
yelp-2.30.2_7


Description:
DocBook is a general purpose XML schema particularly well suited to books and
papers about computer hardware and software (though it is by no means limited
to these applications).

The Version 5.0 release is a complete rewrite of DocBook in RELAX NG.
The intent of this rewrite is to produce a schema that is true to the spirit
of DocBook while simultaneously removing inconsistencies that have arisen as
a natural consequence of DocBook's long, slow evolution. The Technical
Committee has taken this opportunity to simplify a number of content models
and tighten constraints where RELAX NG makes that possible.

The Technical Committee provides the DocBook 5.0 schema in other schema
languages, including W3C XML Schema and an XML DTD, but the RELAX NG Schema
is now the normative schema.

WWW: http://www.docbook.org/specs/docbook-5.0-spec-cd-04.html



Information for docbook-sgml-4.5_1:

Comment:
DocBook SGML DTD


Required by:
brasero-2.32.1_6
docbook-1.5
docbook-xsl-1.76.1_2
evince-2.32.0_11
gimp-app-2.8.10_2,1
gimp-gutenprint-5.2.8
gnome-desktop-2.32.1_5
gnome-doc-utils-0.20.10_2
gnome-mount-0.8_12
gthumb-2.14.1_8
gtk-doc-1.18_1
gvfs-1.12.

Re: firefox-29.0,1 -- dumps core

[Ronald F. Guilmette]

Please allow me to clarify two things:

1)  The exact set of build options that are needed in order to reproduce
the crash I have reported are as follows:

DBUS (enabled by default)
GIO (enabled by default)
GSTREAMER (enabled by default)
ALSA (enabled by default)

DEBUG

Apparently enabling or disabling the LOGGING option makes no difference
at all.  The crash will arise (when broswing around on, e.g. www.newegg.com)
as long as the DEBUG build-time option is enabled.

2)  When built with DEBUG, Firefox is quite a bit more verbose than when
it is built without that option.  In particular, some text messages that
Firefox writes to its stderr channel just before it segfaults appear to
provide some indication of the reason why it elects to do so:

...
XRE_main+0x0058 [/usr/local/lib/firefox/libxul.so +0x03348aa7]
_start+0x0825 [/usr/local/bin/firefox +0x4935]
_start+0x0c20 [/usr/local/bin/firefox +0x4d30]
_start+0x008e [/usr/local/bin/firefox +0x419e]
UNKNOWN 0x800696000
[79233] ###!!! ABORT: Should be tracking any image we're going to use!: 
'mImageTracked', file 
/usr/ports/www/firefox/work/mozilla-release/layout/style/nsStyleStruct.h, line 
208
Hit MOZ_CRASH() at 
/usr/ports/www/firefox/work/mozilla-release/memory/mozalloc/mozalloc_abort.cpp:30


Can anybody who knows their way around the Firefox code look into this
further?

I myself am not at all familiar with the code base of Firefox.
___
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"

smplayer dependency on mplayer1

[Ronald F. Guilmette]

Looking at the Makefile for multimedia/smplayer it appears to me
that smplayer is dependent upon the 1.x version of mplayer being
installed, however there exists what I would guess is a later
and better version of mplayer called multimedia/mplayer2 in the
ports tree.

So why is smplayer dependent upon an oldre (and now obsolete?)
version of mplayer?
___
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: firefox-29.0,1 -- dumps core

[Ronald F. Guilmette]

In message 
Kevin Oberman  wrote:

>No problems with www.newegg.com. Works fine for me.

Two questions:

1)  Are you running on an AMD platform?

2)  When you ran your test, did you first rebuild & reinstall Firefox with
these two build options enabled?

DEBUG   -- Build with debugging support
LOGGING -- Additional log messages

(I built mine with these options, and I do believe that it may indeed
make a world of difference as to whether or not you will experience
the crashes in firefox that I have described.)

___
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: firefox-29.0,1 -- dumps core

[Ronald F. Guilmette]

It just did it again.

Apparently there is something that firefox-29.0,1 does not like about
something at www.newegg.com.  (A pity, since this is a very popular site.)

Stack traceback looks about the same as before

Core was generated by `firefox'.
Program terminated with signal 11, Segmentation fault.
#0  0x00080125024c in thr_kill () from /lib/libc.so.7
(gdb) where
#0  0x00080125024c in thr_kill () from /lib/libc.so.7
#1  0x000804d5abc2 in nsProfileLock::FatalSignalHandler (signo=11, 
info=0x7fff9e40, context=0x7fff9ad0)
at 
/usr/ports/www/firefox/work/mozilla-release/profile/dirserviceprovider/src/nsProfileLock.cpp:180
#2  0x000805454852 in AsmJSFaultHandler (signum=11, info=0x7fff9e40, 
context=0x7fff9ad0)
at 
/usr/ports/www/firefox/work/mozilla-release/js/src/jit/AsmJSSignalHandlers.cpp:964
#3  0x000800fdd46e in ?? () from /lib/libthr.so.3
#4  0x000800fdd5fc in ?? () from /lib/libthr.so.3
#5  0x7043 in ?? ()
#6  0x000800fdd520 in ?? () from /lib/libthr.so.3
#7  0x in ?? ()
(gdb) 
___
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"

firefox-29.0,1 -- dumps core

[Ronald F. Guilmette]

I recently built & installed firefox-29.0,1 with debugging information.

That was just a day or so ago.

It has already dumped core twice.

Here is some info from the most recent one:

...
Core was generated by `firefox'.
Program terminated with signal 11, Segmentation fault.
#0  0x00080125024c in thr_kill () from /lib/libc.so.7
(gdb) where
#0  0x00080125024c in thr_kill () from /lib/libc.so.7
#1  0x000804d5abc2 in nsProfileLock::FatalSignalHandler (signo=11, 
info=0x7fff9e40, context=0x7fff9ad0)
at 
/usr/ports/www/firefox/work/mozilla-release/profile/dirserviceprovider/src/nsProfileLock.cpp:180
#2  0x000805454852 in AsmJSFaultHandler (signum=11, info=0x7fff9e40, 
context=0x7fff9ad0)
at 
/usr/ports/www/firefox/work/mozilla-release/js/src/jit/AsmJSSignalHandlers.cpp:964
#3  0x000800fdd46e in ?? () from /lib/libthr.so.3
#4  0x000800fdd5fc in ?? () from /lib/libthr.so.3
#5  0x7043 in ?? ()
#6  0x000800fdd520 in ?? () from /lib/libthr.so.3
#7  0x in ?? ()
(gdb) 



So, um, should I file a PR, or what?


P.S.  Do any of the chaps who work on the FreeBSD port of Firefox ever
themselves try to build it and then run it with debugging info enabled?
___
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: Upgrading Perl... Somebody just shoot me and put me out of my misery!

[Ronald F. Guilmette]

In message <845a2e7e540e58efd7f05...@atuin.in.mat.cc>, 
Mathieu Arnold  wrote:

>rfg wrote:
>| Why would _anything_ that is in any way dependent upon the Perl
>| interpreter need to be rebuilt?  In this switch to threads=on, has the
>| language itself changed?  And if not, shouldn't the change to
>| multi-threading capability within the interpreter be utterly transparent
>| to (and a non-event for) any and all pre-existing Perl code?
>| 
>| Obviously, there's something that I'm missing, but I have no idea what it
>| might be.
>
>Because, hum, quite a few things change when you enable threads, some
>headers bits change, some calls that are noop without become real call
>with, things like that.
>
>Now, it obviously is a non issue with ports that only use perl to run
>scripts, or p5- ports that are only scripts, but for ports that have XS
>files that get compiled into .so, they need to get recompiled, and the same
>goes for every bit of software that includes the interpreter.
>
>As there is no simple way to differentiate between those two categories of
>dependencies, I ask people to rebuild (or reinstall, if you're using binary
>packages) everything.

OK.  It is all clear now.  Thank you for taking the time to explain.  It
_does_ all make sense now.

>I assure you, it does not make me happy at all to have people rebuild
>everything depending on Perl every two weeks (like it feels I've been doing
>that for a few months...)

Well, I apologize if I cam off as being a bit... um... testy.  I'm actually
one of the lucky people, I guess, since I only update my ports very
infrequently... only once in every several months... so I've managed to
miss most of the excitement. :-)

(As I mentioned in my original post in this thread, it was late and I was
tired when I first posted about all this.  Please do forgive me if I seemed
at all unappreciative of your hard work, which is clearly of great value,
both to me personally and also to countless others.)

>| I'm *not* claiming that the maintainer didn't have a good reason for
>| suggesting these rebuilds.  I'm only saying that *I* personally still
>| don't have a good understanding of what the need for this is/was.
>
>As the maintainer, I hope my previous bit did explain that a bit better, if
>things are not that clear, do feel free to point them out and I'll try
>better.

No no.  You have now explained the resons for the rebuilds clearly and
admirably.  It all makes sense.

>The thing is that all those explanations can't go into UPDATING, we try to
>keep it short not to confuse people.

Yes.

I'm glad that we have these mailing lists, and their associated archives,
so that people like me with an interest in such arcana can ask and get
answers... at least from the subset of port maintainers who, like you,
are nicely responsive.

Keep up the good work!  And thanks again, for everthing.


Regards,
rfg
___
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"

After updating ports, flash plugins for Firefox & Opera have gone AWOL

[Ronald F. Guilmette]

Having gotten past all the difficulties that related to Perl, I have
finally managed to update essentially all of my installed ports.  (I
still have a small problem with the update for ffmpeg(2), but I'll
take that up later on.)

Unfortunately, after updating all my ports I find that I now have a
problem with the flash plugins for both Firefox and Opera... and I
could use some help solving these two problems.

After updating all my ports I have, among many many other things, all
of the following currently installed:

firefox-25.0_1,1
opera-12.16
linux-f10-flashplugin-11.2r202.327_1
nspluginwrapper-1.4.4_2
opera-linuxplugins-12.16

(Note:  I use both Firefox and Opera, at different times for different
purposes.)

After updating my ports, I dutifully followed the instructions here for
updating the flash support in Firefox (as I have done, many times before):

   https://www.freebsd.org/doc/handbook/desktop-browsers.html

Specifically (and only) I executed this step:

   nspluginwrapper -v -a -u

This produced the following output:

  Auto-update plugins from /usr/local/lib/browser_plugins
  Looking for plugins in /usr/local/lib/browser_plugins
  Auto-update plugins from /usr/local/lib/browser_plugins/linux-f10-flashplugin
  Looking for plugins in /usr/local/lib/browser_plugins/linux-f10-flashplugin
  Auto-update plugins from /home/rfg/.mozilla/plugins
  Looking for plugins in /home/rfg/.mozilla/plugins

Then I quit and restarted Firefox.

Unfortunately, after these steps entering "about:plugins" in the Firefox
location bar now shows that I have -no- plugins installed.  Additionally,
upon visiting (in Firefox) a web page that I believe contains flash
material, I am getting a notification that I need to install the flash
plugin.

So, my questions:

1)  What did I do wrong?

2)  How can I correct the situation and get flash working with Firefox again?

Separately and additionally, Opera also now does not seem to believe that
it has any flash pulgin installed either.  Of course, I would like to
correct this problem also.
___
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: Upgrading Perl... Somebody just shoot me and put me out of my misery!

[Ronald F. Guilmette]

In message 
Anton Afanasyev  wrote:

>On Sat, Nov 23, 2013 at 12:17 PM, Ronald F. Guilmette > wrote:
>
>>
>> OK, but please help me understand here.  What is it, exactly, that is _now_
>> being threaded, that wasn't threaded before?
>> ...
>> (Part of what is confusing about this is that I was under the impression...
>> perhaps naive... that Perl was already set up for threads support quite
>> some
>> long time ago.)
>>
>Perl _was_ set up to be threaded (although I have no idea what is actually
>threaded there), but the port option to enable it being threaded was not
>enabled by default.

(One might well ask "why not?" but we will leave that question aside for
the moment.)

>The implication is that if you compiled it with default
>options, it wasn't threaded. But now it (the option) has been changed to be
>enabled by default, and so the point of that UPDATING entry was that if you
>are running with default options, then your Perl will switch from
>non-threaded to threaded when you recompile it,

OK, that part, at least is clear.

>and you will thus need to recompile all ports that depend on Perl.

This is the part that is still utterly baffling.

Why would _anything_ that is in any way dependent upon the Perl interpreter
need to be rebuilt?  In this switch to threads=on, has the language itself
changed?  And if not, shouldn't the change to multi-threading capability
within the interpreter be utterly transparent to (and a non-event for)
any and all pre-existing Perl code?

Obviously, there's something that I'm missing, but I have no idea what it
might be.

>IF you already had this option enabled to begin with, I believe you don't
>need to recompile and reinstall anything (including Perl itself, but do
>note that the ports system will then keep thinking that Perl hasn't been
>upgraded - which isn't an issue, since the only thing changed here is the
>defaults and not any functionality, and so you can just wait to recompile
>it when something more serious changes; this is up to you though).
>
>Hope this clears it up a bit.

Well, I thank you for your attempt to help clear up the confusion, but I
do confess that the need to rebuild... or the value of rebuilding... all
of the stuff that _depends_ on Perl is still rather entirely mystifying.

I'm *not* claiming that the maintainer didn't have a good reason for
suggesting these rebuilds.  I'm only saying that *I* personally still
don't have a good understanding of what the need for this is/was.


Regards,
rfg
___
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: Graphing installed ports

[Ronald F. Guilmette]

In message , 
Michel Talon  wrote:

>The following script
>http://www.lpthe.jussieu.fr/~talon/check_pkg.py
>does the job you want plus other things,

Thank you!

>but it was written for the old package
>system (i.e. it looks under /var/db/pkg).

That's OK.  I am still using that.

>By the way i noted that as soon as you have a fair number of ports =
>installed, you get
>so many arrows in the diagram that you cannot see anything, rendering =
>the idea quite useless.

Well, that is interesting.

I have a dim recollection that there is/was s theorem in the fields of
software science to the effect that the greater the number of interconnections
(e.g. between functions) within a given program, the more likely it was to
have bugs.

I'll have to go and do some googling now and refresh my memory about that.


Regards,
rfg
___
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"

Graphing installed ports

[Ronald F. Guilmette]

Has anyone ever used a graphing tool (such as GraphViz) to create a
graph of all of the installed ports on a given system and their
dependencies?

I think that this would be interesting... and perhaps even useful...
to do, but it seems like such an obvious idea that I have to
guess that somebody else has already coded up a small script to
do this exact thing.  If so, I see no reason why I should re-invent
this wheel.

___
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: Upgrading Perl... Somebody just shoot me and put me out of my misery!

[Ronald F. Guilmette]

In message <17d096510a47c61858d55...@atuin.in.mat.cc>, 
Mathieu Arnold  wrote:

>+--On 22 novembre 2013 12:40:07 -0800 "Ronald F. Guilmette"
> wrote:
>|1) Change the option in lang/perl5.16:
>| make -C /usr/ports/lang/perl5.16 config
>| 
>| HUH??  I don't understand this at all.  What exactly is "the option" that
>| we are changing here?  And what does it matter to anything?
>
>Like it is written in the paragraph before, the default option for perl has
>changed, *if* you want to switch from non threaded to threaded, you also
>need to change your perl configuration.

OK, but please help me understand here.  What is it, exactly, that is _now_
being threaded, that wasn't threaded before?

Is it the guts of the Perl interpreter itself?

Is it the Perl programs that get interpreted by the interpreter?

(Part of what is confusing about this is that I was under the impression...
perhaps naive... that Perl was already set up for threads support quite some
long time ago.)
___
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: Upgrading Perl... Somebody just shoot me and put me out of my misery!

[Ronald F. Guilmette]

In message <0fc91d46cdc4b54132d12...@atuin.in.mat.cc>, 
Mathieu Arnold  wrote:

>+--On 22 novembre 2013 00:25:26 -0800 "Ronald F. Guilmette"
> wrote:
>|   AUTHOR: m...@freebsd.org
>
>Cough, cough, yeah, I mostly wrote that.
>
>| portupgrade -o lang/perl5.16 -f perl-5.14.\*
>
>At that time, that line was right. Now, after that, the perl packages name
>which had the same name (all named perl) and were conflicting and were
>renamed to perl5 for the default perl, that is, 5.16, and perl5.xx for the
>non default ones, that are 5.12, 5.14 and 5.18.

OK.

I probably need another cup of coffee (to awaken that last dormant set of
of brain cells) before I'll really grok the "conflict" you've just described,
but that's OK.  For the moment, at least, you've explained it well enough
and I understand it well enough to proceed, and to make progress in my
quest to upgrade my ports.

>| pkg_info says that at present I have perl5.14-5.14.4_3 installed.  So
>| excuse my french, but why the fuck didn't the command:
>| 
>|portupgrade -o lang/perl5.16 -f perl-5.14.\*
>
>Now, as you can see, your perl is not named perl-5.14 but
>perl5.14-5.14.4_3, so, you should change that line to :
>portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3

Ah!  OK.  Thank you VERY much.  I have just now begun executing the revised
command line that you kindly provided, and I'll keep my fingers crossed.
(So far things _do_ seem to be progressing nicely.)

Hummm Well, that command *did* already complete, as I was typing this
message.  And now pkg_info says that I have perl5-5.16.3_3 installed.  So
that is good.  Progress.  *However* now when I tried to execute the next
step you suggested, i.e.:

   2) Reinstall everything that depends on Perl:
portupgrade -fr perl

Once again *nothing* happened!

OK, so I scracthed my head for a bit and then tried it this way:

portupgrade -fr perl5

Now *that* *did* do something.  In fact that appears to have caused Perl
(5.16) to be rebuilt and reinstalled all over again *and* now everything
in the universe that depended, directly or indirectly on that appears to
also be in the process of rebuilding... which is good, I suppose.

Now, one last little thing...

The note in the UPDATING file dated 20131120 gives essentially the same
instructions as the one dated 20131023, *however* it also contains this:

   1) Change the option in lang/perl5.16:
make -C /usr/ports/lang/perl5.16 config

HUH??  I don't understand this at all.  What exactly is "the option" that we
are changing here?  And what does it matter to anything?

It would be Nice if this were entierly less opaque.


Regards,
rfg
___
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 build failure -- security/hydra

[Ronald F. Guilmette]

In message <20131014184048.27851...@bsd64.grem.de>, you wrote:

>On Mon, 14 Oct 2013 20:13:51 +0400
>Ruslan Makhmatkhanov  wrote:
>
>> Ronald F. Guilmette wrote on 06.10.2013 01:34:
>> >
>> >> make -V FETCH_CMD
>> >
>> > Results:
>> >
>> > /usr/bin/fetch -AFpr
>> >
>> >> on your system? What FreeBSD version you are using?
>> >
>> > FreeBSD segfault.tristatelogic.com 9.1-RELEASE FreeBSD 9.1-RELEASE
>> > #0 r243825: Tue Dec  4 09:23:10 UTC 2012
>> > r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>> 
>> Yes, I now see the issue. If I understand correctly /usr/bin/fetch
>> got SSL support since FreeBSD 9.2, so is why it isn't work to you.
>>
>
>Fetch had basic SSL support for many years, what changed is that in
>10-CURRENT and 9-STABLE proper checking of certificates has been
>implemented, which is disabled for the ports system though (since it's
>using checksums and size checks anyway). So this is not the problem.


So I am the only person for whom the fetch of the tarball for
security/hydra has failed?
___
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 build failure -- security/hydra

[Ronald F. Guilmette]

In message <525c183f.7010...@yandex.ru>, you wrote:

>Ronald F. Guilmette wrote on 06.10.2013 01:34:
>>
>>> make -V FETCH_CMD
>>
>> Results:
>>
>> /usr/bin/fetch -AFpr
>>
>>> on your system? What FreeBSD version you are using?
>>
>> FreeBSD segfault.tristatelogic.com 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r24382
>5: Tue Dec  4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/
>src/sys/GENERIC  amd64
>
>Yes, I now see the issue. If I understand correctly /usr/bin/fetch got 
>SSL support since FreeBSD 9.2, so is why it isn't work to you.

Thank you for the follow-up.

I know that there is always a rational explanation for everything, but
it is nice to have someone independently confirm that fact from time to
time.

>>> PS. Yes, packetstorm has different distifile at the moment.
>>
>> No no.  As I said, *all* of the mirrors appear to have the tarball that is
>> 681552 bytes long, and only just the thc.org copy fo teh tarball has the
>> size 681784.
>
>Packetstorm just updated the distfile on their mirrors, so now all 
>should work.

OK.  Good.

Once again, thank youf or the follow-up.


Regards,
rfg
___
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"

Messages while (re)installing portupgrade

[Ronald F. Guilmette]

Because I just switched from ruby1.8 to ruby1.9 I've had to
rebuild and reinstall my ports-mgmt/portupgrade port.  That all
went well, but I got some messages at the end of the re-install
process that I've never noticed before, and they are all rather
befuddling to me:

--
  Fill ALT_PKGDEP section in pkgtools.conf file for portupgrade to be
  aware of alternative dependencies you use.
  E.g.
  ALT_PKGDEP = {
# Use the -nox11 port when another port depends on category/portexample
'category/portexample' => 'category/portexample-nox11',
  }

  Note also, portupgrade knows nothing about how to handle ports with
  different suffixes (E.g. -nox11). So you should explicitly define
  variables (E.g. WITHOUT_X11=yes) for the ports in /etc/make.conf or
  pkgtools.conf (MAKE_ARGS section) files.
--

I have no idea what any of the above means.  Should I be at all concerned?

Where exactly is this alleged "pkgtools.conf" file.  I looked in /etc.
It ain't there.  I've never even heard of it until today.

I grok the general idea that there may be a file someplace (called
"pkgtools.conf") wherein one may explicitly override various otherwise
hardwired inter-port dependencies, but what has that got to do with
me?

I _do_ use X, so none of the rest of this stuff seems the least bit
relevant to anything I am doing.  Am I perhaps mistaken?
___
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 mplayer port update?

[Ronald F. Guilmette]

In message 
, you wrote:

>On 8 October 2013 02:10, Ronald F. Guilmette  wrote:
>
>> Could someone (anyone) explain to me why the FreeBSD port of mplayer
>> has not been updated at all since March 8th of this year?
>
>Yes.
>That is because I am preparing roughly 2 major updates per year,
>preferably shortly after a FreeBSD release. The other changes to the
>port are to maintain compatibility and fix whatever problems users may
>have.
>
>To pre-empt the inevitable question: Yes, there will be a new version
>before the end of October.
>Do you miss a specific feature in the current port or why do you press
>for an update?


The answer to your question is just this:

On very rare occasions, I come upon a video that does not seem to
play correctly (using mplayer).  When this happens, it may be the fault
of the video itself, or perhaps of mplayer.  If I knew that my mplayer
had been updated recently, then I would tend more to suspect the video
file of being corrupted.

And also, of course, even when videos play "correctly" I do often wonder
whether or not I am getting the full benefits of my hardware.
___
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 mplayer port update?

[Ronald F. Guilmette]

Could someone (anyone) explain to me why the FreeBSD port of mplayer
has not been updated at all since March 8th of this year?

That seems like an awfully long time to go without any update.

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

Re: Port build failure -- security/hydra

[Ronald F. Guilmette]

In message <524fd88e.5030...@yandex.ru>, you wrote:

>
>As I already said, I can't reproduce this problem even with updated url:
>root@smeshariki4:/usr/ports/security/hydra # make fetch
>===>  License AGPLv3 accepted by the user
>===>  Found saved configuration for hydra-7.5
>===>   hydra-7.5 depends on file: /usr/local/sbin/pkg - found
>=> hydra-7.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>=> Attempting to fetch https://www.thc.org/releases/hydra-7.5.tar.gz
>hydra-7.5.tar.gz  100% of  665 kB  128 kBps 
>00m06s
>===> Fetching all distfiles required by hydra-7.5 for building
>
>What output this command produce on your system?
>
>cd /usr/ports/security/hydra
>make distclean
>make fetch

OK, I id all three steps above, and here are the results which are the
same as what I have already reported:

===>  License AGPLv3 accepted by the user
===>  Found saved configuration for hydra-7.5
=> hydra-7.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch http://freeworld.thc.org/releases/hydra-7.5.tar.gz
fetch: http://freeworld.thc.org/releases/hydra-7.5.tar.gz: Moved Permanently
=> Attempting to fetch 
http://dl.packetstormsecurity.net/groups/thc/hydra-7.5.tar.gz
fetch: http://dl.packetstormsecurity.net/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch 
http://packetstorm.codar.com.br/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.codar.com.br/groups/thc/hydra-7.5.tar.gz: No address 
record
=> Attempting to fetch 
http://packetstorm.igor.onlinedirect.bg/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.igor.onlinedirect.bg/groups/thc/hydra-7.5.tar.gz: 
size mismatch: expected 681784, actual 681552
=> Attempting to fetch 
http://packetstorm.interhost.co.il/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.interhost.co.il/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch http://packetstorm.foofus.com/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.foofus.com/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch 
http://packetstorm.tacticalflex.com/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.tacticalflex.com/groups/thc/hydra-7.5.tar.gz: Not 
Found
=> Attempting to fetch 
http://packetstorm.unixteacher.org/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.unixteacher.org/groups/thc/hydra-7.5.tar.gz: No 
address record
=> Attempting to fetch 
http://packetstorm.wowhacker.com/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.wowhacker.com/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch 
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/hydra-7.5.tar.gz
fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/hydra-7.5.tar.gz: File 
unavailable (e.g., file not found, no access)
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/ports/distfiles/ and try again.
*** [do-fetch] Error code 1

Stop in /usr/ports/security/hydra.


>What's the output of
>cd /usr/ports/security/hydra
>make -V FETCH_CMD

Results:

/usr/bin/fetch -AFpr

>on your system? What FreeBSD version you are using?

FreeBSD segfault.tristatelogic.com 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: 
Tue Dec  4 09:23:10 UTC 2012 
r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

>PS. Yes, packetstorm has different distifile at the moment.

No no.  As I said, *all* of the mirrors appear to have the tarball that is
681552 bytes long, and only just the thc.org copy fo teh tarball has the
size 681784.

___
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 build failure -- security/hydra

[Ronald F. Guilmette]

Oh geeezzz!  Things are even more screwed up with the hydra port
that I thought!

I mentioned in my prior e-mail that the size of the hydra-7.5.tar.gz
file being reported by essentially all of the mirrors that are coded
into the current hydra port is in fact 681552... *not* 681784 bytes,
which is apparently what the port is expecting and demanding.

However it appears that there is *one* and *only one* source for
the hydra-7.5.tar.gz distribution file where the size of the file
*is* in fact 681784 bytes, and that is:

   https://www.thc.org/releases/hydra-7.5.tar.gz

but this is the site that apparently has its SSL certificates screwed up!

G!  How worrisome is it to be fetching a piece of "security"
software from a site that can't even manage to get its own SSL certs
set up or maintained properly??

How worrisome is it to be doing that when *every* other copy of the
relevant source tarball *everywhere* else on the net has a different
size??

OK, so being curious, I got *both* one of the 681552 sized copies
of this file and also one of the 681784 sized copies, and I unpacked
them both and ran "diff -rc2".  The results are attached below.
Clearly, the bizzare and unexpected size differences are *not* due
to any any sneeky corruption of the source tarball.  However it is
equally apparent that _somebody_ has been fiddling with the contents
of the source tarball *without* bothering to change the version number
on that.

(I don't generally believe in castration as a punishment for crimes
against humanity, but I make an exception in such cases, because there
is no excuse for this kind of shoddy workmanship.  Even if the only
change is a single comma, different versions need different numbers.)

So, um, will the real hydra-7.5.tar.gz file please stand up?



diff -rc2 tmp0/hydra-7.5/LICENSE tmp1/hydra-7.5/LICENSE
*** tmp0/hydra-7.5/LICENSE  2013-08-02 04:35:56.0 -0700
--- tmp1/hydra-7.5/LICENSE  2013-08-06 07:42:44.0 -0700
***
*** 1,2 
--- 1,7 
+ [see the end of the file for the special exception for linking with OpenSSL
+  - debian people need this]
+ 
+ 
+ 
  GNU AFFERO GENERAL PUBLIC LICENSE
 Version 3, 19 November 2007
***
*** 660,661 
--- 665,683 
  For more information on this, and how to apply and follow the GNU AGPL, see
  .
+ 
+ 
+ Special Exception
+ 
+  * In addition, as a special exception, the copyright holders give
+  * permission to link the code of portions of this program with the
+  * OpenSSL library under certain conditions as described in each
+  * individual source file, and distribute linked combinations
+  * including the two.
+  * You must obey the GNU Affero General Public License in all respects
+  * for all of the code used other than OpenSSL.  If you modify
+  * file(s) with this exception, you may extend this exception to your
+  * version of the file(s), but you are not obligated to do so.  If you
+  * do not wish to do so, delete this exception statement from your
+  * version.  If you delete this exception statement from all source
+  * files in the program, then also delete it here.
+ 
diff -rc2 tmp0/hydra-7.5/hydra.1 tmp1/hydra-7.5/hydra.1
*** tmp0/hydra-7.5/hydra.1  2013-08-02 04:35:56.0 -0700
--- tmp1/hydra-7.5/hydra.1  2013-08-06 00:27:33.0 -0700
***
*** 94,98 
  defines the max wait time in seconds for responses (default: 32)
  .TP
! .B \-w TIME
  defines a wait time between each connection a task performs. This usually
  only makes sense if a low task number is used, .e.g \-t 1
--- 94,98 
  defines the max wait time in seconds for responses (default: 32)
  .TP
! .B \-W TIME
  defines a wait time between each connection a task performs. This usually
  only makes sense if a low task number is used, .e.g \-t 1
Files tmp0/hydra-7.5.tar.gz and tmp1/hydra-7.5.tar.gz differ
___
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 build failure -- security/hydra

[Ronald F. Guilmette]

In message <524f179d.8030...@yandex.ru>, 
Ruslan Makhmatkhanov  wrote:

>Ronald F. Guilmette wrote on 04.10.2013 23:11:
>> At the end of my effort to do "portupgrade -a", I got this:
>>
>>  ! security/hydra (hydra-7.4.2)  (fetch error)
>>
>> Apparently, the source tarball for the current hydra port seems to be
>> nowhere to be found.  How come?  Shouldn't there _always_ be at least one
>> copy of the source tarball, somewhere on one or another of the FreeBSD
>> distribution servers, for each and every port in the ports tree?
>
>I can't reproduce this problem, it's fetching fine to me:
>
>root@smeshariki4:/usr/ports/security/hydra # make distclean
>===>  Cleaning for hydra-7.5
>===>  Deleting distfiles for hydra-7.5
>root@smeshariki4:/usr/ports/security/hydra # make fetch
>===>  License AGPLv3 accepted by the user
>===>  Found saved configuration for hydra-7.5
>===>   hydra-7.5 depends on file: /usr/local/sbin/pkg - found
>=> hydra-7.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>=> Attempting to fetch http://freeworld.thc.org/releases/hydra-7.5.tar.gz
>hydra-7.5.tar.gz  100% of  665 kB  348 kBps 
>00m02s
>===> Fetching all distfiles required by hydra-7.5 for building
>
>But I updated the download url to avoid redirect in r329365. Please 
>update your ports tree and try again.
>
>PS. Packetstorm seems changed the way they handle downloads. Will check 
>later how to deal with it.


OK, first question:  What the devil is "r329365" ?

Anyway, I did what you suggested.  I just now re-did this step:

   portsnap fetch update

and then I tried again:

  portupgrade security/hydra

but I am _still_ getting the exact same error.  From where I am sitting,
the hydra-7.5.tar.gz file is *not* available from freeworld.thc.org, and
indeed I am wondering how you managed to get it from there.  From where I
am sitting, even trying to fetch it from there using wget indicates that
there is a "Moved Permanently" HTTP error encountered when trying to
fetch the file from this URL, which is currently coded into the port:

   http://freeworld.thc.org/releases/hydra-7.5.tar.gz

How are you not seeing this "Moved Permanently" HTTP error??

Anyway, if I try to fetch the file from the above URL using wget, even
after being redirected (automagically) to the new URL, there is still a
very evident problem... the real source site (www.thc.org) has its
security certs screwed up:

==
% wget 'http://freeworld.thc.org/releases/hydra-7.5.tar.gz'
--2013-10-04 12:38:31--  http://freeworld.thc.org/releases/hydra-7.5.tar.gz
Resolving freeworld.thc.org (freeworld.thc.org)... 199.58.210.16
Connecting to freeworld.thc.org (freeworld.thc.org)|199.58.210.16|:80... 
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.thc.org/releases/hydra-7.5.tar.gz [following]
--2013-10-04 12:38:31--  https://www.thc.org/releases/hydra-7.5.tar.gz
Resolving www.thc.org (www.thc.org)... 199.58.210.16
Connecting to www.thc.org (www.thc.org)|199.58.210.16|:443... connected.
ERROR: cannot verify www.thc.org's certificate, issued by ‘/C=US/O=GeoTrust, 
Inc./CN=RapidSSL CA’:
  Unable to locally verify the issuer's authority.
To connect to www.thc.org insecurely, use `--no-check-certificate'.
==

OK, yes, I can bypass this, if necessary, using --no-check-certificate,
but I am telling you that the port, the way it sits now is *BROKEN*.

Furthermore, for all of the other possible sources where the file could
be gotten from, apparently the port believes that the size of the file
should be 681784, but that is *wrong* and the size of the file on _all_
the mirrors is actually 681552, so all attempts by the port to grab the
sources from any & all of the other mirrors is failing also.

Could you be kind and fix both problems, please?


==
--->  Upgrading 'hydra-7.4.2' to 'hydra-7.5' (security/hydra)
--->  Building '/usr/ports/security/hydra'
===>  Cleaning for hydra-7.5
===>  License AGPLv3 accepted by the user
===>  Found saved configuration for hydra-7.5
=> hydra-7.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch http://freeworld.thc.org/releases/hydra-7.5.tar.gz
fetch: http://freeworld.thc.org/releases/hydra-7.5.tar.gz: Moved Permanently
=> Attempting to fetch 
http://dl.packetstormsecurity.net/groups/thc/hydra-7.5.tar.gz
fetch: http://dl.packetstormsecurity.net/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting 

Port build failure -- graphics/clutter-gtk

[Ronald F. Guilmette]

At the end of my recent attempt to do "portupgrade -a" I got this error:

! graphics/clutter-gtk (clutter-gtk-0.10.8_2)   (unknown build error)

Aapparently, clutter-gtk configures OK, but then compiling it generates
a whole boat load of compile time errors.  I tried the Makefile fix
suggested here:

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

but that did not help in the slightest.  According to a suggestion made
within the build error messages, I also tried setting MAKE_JOBS_UNSAFE
to "yes" in the environment (and also on the make command line) and those
actions didn't materially help the situation either.  Logs of the build
failures, both before and after this step, are attached.

Help resolving this problem would be appreciated.


P.S.  I just checked, and there is no mention whatsoever of clutter-gtk
AT ALL in the UPDATING file.  But clearly, *something* is broken.


logs:

root@segfault:/usr/ports/graphics/clutter-gtk # make
===> Fetching all distfiles required by clutter-gtk-0.10.8_3 for building
===>  Extracting for clutter-gtk-0.10.8_3
=> SHA256 Checksum OK for clutter-gtk-0.10.8.tar.bz2.
===>  Patching for clutter-gtk-0.10.8_3
===>   clutter-gtk-0.10.8_3 depends on package: libtool>=2.4 - found
===>  Applying FreeBSD patches for clutter-gtk-0.10.8_3
===>   clutter-gtk-0.10.8_3 depends on executable: gmake - found
===>   clutter-gtk-0.10.8_3 depends on executable: pkgconf - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/glproto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/glproto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/dri2proto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: /usr/local/libdata/pkgconfig/xp.pc 
- found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/x11.pc - found
===>   clutter-gtk-0.10.8_3 depends on package: libtool>=2.4 - found
===>   clutter-gtk-0.10.8_3 depends on file: /usr/local/bin/intltool-extract - 
found
===>   clutter-gtk-0.10.8_3 depends on shared library: libGL.so - found
===>   clutter-gtk-0.10.8_3 depends on shared library: clutter-glx-1.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: intl - found
===>   clutter-gtk-0.10.8_3 depends on shared library: atk-1.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: glib-2.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: pcre - found
===>   clutter-gtk-0.10.8_3 depends on shared library: gtk-x11-2.0.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: pango-1.0 - found
===>  Configuring for clutter-gtk-0.10.8_3
configure: WARNING: unrecognized options: --with-gconf-source
configure: loading site script /usr/ports/Templates/config.site
checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p
checking for gawk... (cached) /usr/bin/awk
checking whether gmake sets $(MAKE)... yes
checking for style of include used by gmake... GNU
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking dependency style of cc... gcc3
checking whether cc understands -c and -o together... yes
checking how to run the C preprocessor... cpp
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for ANSI C header files... (cached) yes
checking build system type... amd64-portbld-freebsd9.1
checking host system type... amd64-portbld-freebsd9.1
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for fgrep... (cached) /usr/bin/fgrep
checking for ld used by cc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... (cached) 262144
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... no
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from cc object... ok
checking for sys/types.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for s

Port build failure -- security/hydra

[Ronald F. Guilmette]

At the end of my effort to do "portupgrade -a", I got this:

! security/hydra (hydra-7.4.2)  (fetch error)

Apparently, the source tarball for the current hydra port seems to be
nowhere to be found.  How come?  Shouldn't there _always_ be at least one
copy of the source tarball, somewhere on one or another of the FreeBSD
distribution servers, for each and every port in the ports tree?


===
# cd /usr/ports/security/hydra
# make
===>  License AGPLv3 accepted by the user
===>  Found saved configuration for hydra-7.5
=> hydra-7.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch http://freeworld.thc.org/releases/hydra-7.5.tar.gz
fetch: http://freeworld.thc.org/releases/hydra-7.5.tar.gz: Moved Permanently
=> Attempting to fetch 
http://dl.packetstormsecurity.net/groups/thc/hydra-7.5.tar.gz
fetch: http://dl.packetstormsecurity.net/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch 
http://packetstorm.codar.com.br/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.codar.com.br/groups/thc/hydra-7.5.tar.gz: No address 
record
=> Attempting to fetch 
http://packetstorm.igor.onlinedirect.bg/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.igor.onlinedirect.bg/groups/thc/hydra-7.5.tar.gz: 
size mismatch: expected 681784, actual 681552
=> Attempting to fetch 
http://packetstorm.interhost.co.il/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.interhost.co.il/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch http://packetstorm.foofus.com/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.foofus.com/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch 
http://packetstorm.tacticalflex.com/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.tacticalflex.com/groups/thc/hydra-7.5.tar.gz: Not 
Found
=> Attempting to fetch 
http://packetstorm.unixteacher.org/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.unixteacher.org/groups/thc/hydra-7.5.tar.gz: No 
address record
=> Attempting to fetch 
http://packetstorm.wowhacker.com/groups/thc/hydra-7.5.tar.gz
fetch: http://packetstorm.wowhacker.com/groups/thc/hydra-7.5.tar.gz: size 
mismatch: expected 681784, actual 681552
=> Attempting to fetch 
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/hydra-7.5.tar.gz
fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/hydra-7.5.tar.gz: File 
unavailable (e.g., file not found, no access)
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/ports/distfiles/ and try again.
*** [do-fetch] Error code 1

Stop in /usr/ports/security/hydra.
*** [build] Error code 1

Stop in /usr/ports/security/hydra.

___
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: multimedia/libbluray -- IGNORE... Why?

[Ronald F. Guilmette]

In message <20131004113101.GB42900@oldfaithful.bebik.local>, you wrote:

>Hi,
>
>I Made a check in the SVN and libbluray was never
>marked IGNORE, at least BROKEN for some java reasons.

Well, I'm just showing you what "portupgrade -a" reported...

- multimedia/libbluray (marked as IGNORE)

>Are you sure isn't a dependencie problem ?

No, but I have no reason whatsoever to believe that is.

>Which version are you trying to install ?

Here is the info from the relevant Makefile:

PORTNAME=   libbluray
PORTVERSION=0.3.0
PORTEPOCH=  1

___
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"

multimedia/libbluray -- IGNORE... Why?

[Ronald F. Guilmette]

Why is the multimedia/libbluray port marked as IGNORE in the current ports
tree?

More to the point, why didn't whoever marked it as IGNORE have the simple
courtesy to put at least some explanitory note about the marking of this
port (as IGNORE) into the UPDATING file?
___
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"

Port build failures -- graphics/clutter-gtk & security/hydra

[Ronald F. Guilmette]

I've been updating all of my ports, which I confess I have not done
for some long time now, and I've managed to work past most of the
easy build problems, but I'm still stuck with two things that just
refuse to build, based on what's in the current ports tree:

! security/hydra (hydra-7.4.2)  (fetch error)
! graphics/clutter-gtk (clutter-gtk-0.10.8_2)   (unknown build error)

The source tarball for the current hydra port seems to be nowhere to be
found.  How come?  Shouldn't there ALWAYS be at least one copy of the
source tarball for _every_ port on one of the FreeBSD distribution servers??

In the case of clutter-gtk, it configures OK, but then compiling generates
a whole boat load of compile time errors.  I tried the Makefile fix
suggested here:

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

but that did not help in the slightest.  According to a suggestion made
within the build error messages, I also tried setting MAKE_JOBS_UNSAFE
to "yes" in the environment (and also on the make command line) and those
actions didn't materially help the situation either.  Logs of the build
failures, both before and after this step, are attached.

Does anybody test this stuff, you know, before it goes into the ports
tree?


P.S.  I just checked, and there is no mention whatsoever of clutter-gtk
AT ALL in the UPDATING file.
Script started on Fri Oct  4 03:51:54 2013

root@segfault:/usr/ports/graphics/clutter-gtk # make
===> Fetching all distfiles required by clutter-gtk-0.10.8_3 for building
===>  Extracting for clutter-gtk-0.10.8_3
=> SHA256 Checksum OK for clutter-gtk-0.10.8.tar.bz2.
===>  Patching for clutter-gtk-0.10.8_3
===>   clutter-gtk-0.10.8_3 depends on package: libtool>=2.4 - found
===>  Applying FreeBSD patches for clutter-gtk-0.10.8_3
===>   clutter-gtk-0.10.8_3 depends on executable: gmake - found
===>   clutter-gtk-0.10.8_3 depends on executable: pkgconf - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/glproto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/glproto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/dri2proto.pc - found
===>   clutter-gtk-0.10.8_3 depends on file: /usr/local/libdata/pkgconfig/xp.pc 
- found
===>   clutter-gtk-0.10.8_3 depends on file: 
/usr/local/libdata/pkgconfig/x11.pc - found
===>   clutter-gtk-0.10.8_3 depends on package: libtool>=2.4 - found
===>   clutter-gtk-0.10.8_3 depends on file: /usr/local/bin/intltool-extract - 
found
===>   clutter-gtk-0.10.8_3 depends on shared library: libGL.so - found
===>   clutter-gtk-0.10.8_3 depends on shared library: clutter-glx-1.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: intl - found
===>   clutter-gtk-0.10.8_3 depends on shared library: atk-1.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: glib-2.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: pcre - found
===>   clutter-gtk-0.10.8_3 depends on shared library: gtk-x11-2.0.0 - found
===>   clutter-gtk-0.10.8_3 depends on shared library: pango-1.0 - found
===>  Configuring for clutter-gtk-0.10.8_3
configure: WARNING: unrecognized options: --with-gconf-source
configure: loading site script /usr/ports/Templates/config.site
checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p
checking for gawk... (cached) /usr/bin/awk
checking whether gmake sets $(MAKE)... yes
checking for style of include used by gmake... GNU
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking dependency style of cc... gcc3
checking whether cc understands -c and -o together... yes
checking how to run the C preprocessor... cpp
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for ANSI C header files... (cached) yes
checking build system type... amd64-portbld-freebsd9.1
checking host system type... amd64-portbld-freebsd9.1
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for fgrep... (cached) /usr/bin/fgrep
checking for ld used by cc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... (cached) 262144
checking whether the shell understands some XSI constructs... yes
checking whether the shell understa

The Original VI ?

[Ronald F. Guilmette]

I've just been fiddling with some unicode/utf-8 stuff, and managed
to figure out how to get both xterm and more (aka less) to properly
deal with utf-8 characters.  It then occured to me that it might be
nice if I could cut and paste utf-8 stuff into vi, which is the text
editor that I happen to use.

After a quick bit of googling I found this:

  
http://newsgroups.derkeiler.com/Archive/Comp/comp.editors/2011-03/msg00010.html

Apparently, it is correct that FreeBSD distributes nvi as vi (and as
far as I can tell, that _does not_ currently support utf-8), but I
sort-of thought that maybe this "original" vi, now with unicode support,
had at least made it into the ports tree, but I can't seem to find it there.

Am I wrong?  Is it in there?  If so, where please?
___
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"

x11-toolkits/py-tkinter ... seriously broken

[Ronald F. Guilmette]

What the hey?

# make
=> Python-2.7.3.tar.xz is not in /usr/ports/lang/python27/distinfo.
=> Either /usr/ports/lang/python27/distinfo is out of date, or
=> Python-2.7.3.tar.xz is spelled incorrectly.
*** [do-fetch] Error code 1

Stop in /usr/ports/x11-toolkits/py-tkinter.


The message is correct, my /usr/ports/lang/python27/distinfo file
looks like this:

SHA256 (python/Python-2.7.5.tar.xz) = 
f33c4cab167dc69e10962e1cebf1c0768e2d0e8575648130c20e6bda84551db1
SIZE (python/Python-2.7.5.tar.xz) = 10252148

So what the hell is wrong  How am I supposed to fix this?  I need to
build x11-toolkits/py-tkinter !

Help?  Please?


P.S. I just now tried to fix this by re-running:

 portsnap fetch update

That made no difference at all.

Does anybody maintain this?

___
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: WANTED: Tool to verify installed package/port consistancy

[Ronald F. Guilmette]

Well, I have looked a bit more at some of the files that posted about
just a short while ago.  It turns out that pretty much all of the
remaining anomolies (i.e. MD5 mismatches) in package-related or port-
related files on my system can be attributed to either (a) some person
or else (b) some thing (e.g. some other package or port install script)
coming along _after_ a given port/package has been initially installed
and then diddling one or more of the relevant files.  It is easy to
understand how or why this might happen, e.g. in cases involving
various configuration files that may have meaning to more than one
port or package.

So anyway, I revised my pkg_sanity script so that it will compare the
date/time stamps of files against the date/time stamps of the corresponding
+CONTENTS files (and report anomolies found) before it even bothers
trying to check the MD5 checksums.  Obviously, if some given file has
been diddled since the date/time when its MD5 checksum was originally
computed for inclusion in the relevant +CONTENTS file, then it is almost
an absolute certainty that it's new/current MD5 checksum is _not_ going
to match its old one, as contained in the relevant +CONTENTS file.

Running my revised version of the script yields this output:

pkg_sanity: gettext-0.18.1.1: Newer than +CONTENTS file: 
/usr/local/lib/charset.alias
pkg_sanity: linux_base-f10-10_5: Newer than +CONTENTS file: 
/compat/linux/etc/ld.so.cache
pkg_sanity: linux_base-f10-10_5: Newer than +CONTENTS file: 
/compat/linux/var/cache/ldconfig/aux-cache
pkg_sanity: p5-XML-SAX-0.99: 
/usr/local/lib/perl5/site_perl/5.14.2/XML/SAX/ParserDetails.ini: File failed 
MD5 checksum
pkg_sanity: p5-XML-SAX-0.99: 
/usr/local/lib/perl5/site_perl/5.14.2/XML/SAX/ParserDetails.ini: 
15bfbb02aa79670b148f21dfbac64843 versus cf8c5cb8a7b6cf7a8db7c53f1ba27148

(Oh!  And by the way, this date/time stamp pre-check is one that "pkg_info -g"
_should_ really be doing also, but isn't.  I'll be filing a PR on that.)

So it is clear that, sometime after install installation, somebody or
some thing came along and diddled the charset.alias, ld.so.cache, and
aux-cache files, and that thus, it is perfectly understandable that
these files no longer match their original install-time MD5 checksums.
These cases are therefore probably not worth worrying about. (I don't
ever remember having edited any of these three files, so it must have
been some other script doing it, as a side-effect of something else I
had done since I installed the relevant ports.)

This leaves me with one and only one anomoly, i.e. the ParserDetails.ini
file.  But even in that case I feel quite sure that somebody or something
has intentionally diddled it, some time since it was originally installed,
but whoever or whatever that is, they must have foolishly and mistakenly
gone out of their way to preserve the original modification date/time
stamp for that file.  If I can ever figure out who or what did that,
I shall chastize them appropriately with the nearest available instrument
of torture.

Hummm... Here's a hint.  My current ParserDetails.ini file is shown below.
On a different FreeBSD 9.1 system that I have here, this same file is
present also, but is shorter (9 lines rather than 15) and contains only
the first two sections, rather than four, as seen here.

=
[XML::SAX::PurePerl]
http://xml.org/sax/features/namespaces = 1

[XML::SAX::Expat]
http://xml.org/sax/features/namespaces = 1
http://xml.org/sax/features/external-general-entities = 1
http://xml.org/sax/features/external-parameter-entities = 1

[XML::LibXML::SAX::Parser]
http://xml.org/sax/features/namespaces = 1

[XML::LibXML::SAX]
http://xml.org/sax/features/namespaces = 1


=
___
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: WANTED: Tool to verify installed package/port consistancy

[Ronald F. Guilmette]

So, as I have now learned (and just as the post by CyberLeo Kitsana had
suggested) if one wishes to write a script to do the rough equivalent
of what "pkg_info -g" does, then one has to be mindful of the fact that
for those specific MD5 checksums contained in the various +CONTENTS
files within the /var/db/pkg directory where the relevant installed
file happend to be a symlink, you must not calculate the MD5 checksum
on the file the symlink points to, but rather on the contents of the
symlink itself, as obtained by running "readlink -n".

Making that small adjustment to my script, re-installing my many missing
CONTENTS files from a backup I had, and running my little pkg_sanity
script as root (in order to avoid a few annoying permissions problems)
it seems that my system is now mostly back to a state of good health.
However there sill remain a handful of puzzling results:

pkg_sanity: gettext-0.18.1.1: /usr/local/lib/charset.alias: File failed MD5 
checksum
pkg_sanity: gettext-0.18.1.1: /usr/local/lib/charset.alias: 
4d9c898966e87b62589a1c44dc8297f6 versus fe5bae66620b10c76971d99932b18846
pkg_sanity: linux_base-f10-10_5: /compat/linux/etc/ld.so.cache: File failed MD5 
checksum
pkg_sanity: linux_base-f10-10_5: /compat/linux/etc/ld.so.cache: 
6f66c7adc696059c6dfdf04c4ff3adb8 versus dfe04fabc88d1fd3e40b14a7f47acd8e
pkg_sanity: linux_base-f10-10_5: /compat/linux/var/cache/ldconfig/aux-cache: 
File failed MD5 checksum
pkg_sanity: linux_base-f10-10_5: /compat/linux/var/cache/ldconfig/aux-cache: 
3d561b01a69ad4357c92de3a5032d52b versus f8be26f0de9b1736b4b9837f07b550d7
pkg_sanity: p5-XML-SAX-0.99: 
/usr/local/lib/perl5/site_perl/5.14.2/XML/SAX/ParserDetails.ini: File failed 
MD5 checksum
pkg_sanity: p5-XML-SAX-0.99: 
/usr/local/lib/perl5/site_perl/5.14.2/XML/SAX/ParserDetails.ini: 
15bfbb02aa79670b148f21dfbac64843 versus cf8c5cb8a7b6cf7a8db7c53f1ba27148

I've checked and "pkg_info -g" also reports MD5 checksum mismatches
on the four files mentioned above.

If other folks could run the following command and let me know
what results you see on your system, I would really appreciate
it.  thanks.

   pkg_info -g 'gettext*' 'linux_base*' 'p5-XML-SAX*'


Regards,
rfg


P.S.  Oh lord!  Now pkg_version is issuing a different kind of complaint
about four of my installed packages...

pkg_version: icon-naming-utils-0.8.90 does not appear to be a valid package!
pkg_version: p5-Net-HTTP-6.06 does not appear to be a valid package!
pkg_version: p5-XML-Simple-2.20 does not appear to be a valid package!
pkg_version: p5-libwww-6.05 does not appear to be a valid package!

Now I feel compelled to figure out the cause of this problem too.

Just when I thought that I was out they keep pulling me back in!!!
Ar
___
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: WANTED: Tool to verify installed package/port consistancy

[Ronald F. Guilmette]

In message <518e1a51.3020...@cyberleo.net>, you wrote:

>On 05/10/2013 03:04 PM, Ronald F. Guilmette wrote:
>
>> pkg_sanity: ImageMagick-6.8.0.7_1: +CONTENTS file does not exist -- skipped
>> pkg_sanity: ORBit2-2.14.19: /usr/local/lib/libORBit-2.so: File failed MD5 
>> checksum
>> pkg_sanity: ORBit2-2.14.19: /usr/local/lib/libORBit-imodule-2.so: File 
>> failed MD5 checksum
>> pkg_sanity: ORBit2-2.14.19: /usr/local/lib/libORBitCosNaming-2.so: File 
>> failed MD5 checksum
>> pkg_sanity: OpenEXR-1.7.1: /usr/local/lib/libIlmImf.so: File failed MD5 
>> checksum
>> pkg_sanity: aalib-1.4.r5_6: /usr/local/lib/libaa.so: File failed MD5 checksum
>
>
>Are these mismatches symlinks?

Some are.

>If so, are you checking the contents of
>the symlink (with, for instance, stat(1) or readlink(1)), or the
>contents of the file to which the symlink is referring?

The latter.

(I would have had to have done something special in order to compute the
md5 fo teh symlink itself, and I did not do so.  I have just now checked,
and my script is indeed getting the md5 of the files to which the various
symlinks refer.)


It is clear to me now that "pkg_info -g" is either skipping certain files
that are listed in the relevant +CONTENTS files or else it is computing the
MD5 checksums in an odd way.  I do not think that the latter possibility is
at all likely.

I will be looking at this more deeply as time permits.


Regards,
rfg
___
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: Tool to verify installed package/port consistancy

[Ronald F. Guilmette]

b.f. bf1783 at googlemail.com wrote:

>Yes, of course, this is a basic package management feature:
>pkg_info(1) with the "-g" flag.
>(The analogous part of the newer pkgng is described in pkg-check(8)
>from ports-mgmt/pkg.)

Thank you.  I did not know about the -g option.

I have just now run that for all of my installed packages, and rather
inexplicably, it seems to have found almost no MD5 checksum mismatches.
(See output below.)  It found only 5 such MD5 mismatches, two of which
I know are due to my own local fiddling (/usr/local/libexec/psif-text
and /usr/local/libexec/psif-ps).  In contrast, the little script that
I whipped up yesterday to do that same thing found over 1,000 MD5
checmsum mismatches.

I suppose that I'll have to try to get to the bottom of this.  The
script that I wrote to do this is so simple, I can't imagine that it
has a bug that causes just a small subset of the files checked to
come up as having bad MD5 checksums.  But anything is possible, I
suppose.


Regards,
rfg





% pkg_info -g '*'
pkg_info: the package info for package 'ImageMagick-6.8.0.7_1' is corrupt
Information for ORBit2-2.14.19:

Mismatched Checksums:

Information for OpenEXR-1.7.1:

Mismatched Checksums:

Information for aalib-1.4.r5_6:

Mismatched Checksums:

pkg_info: the package info for package 'abiword-2.8.4_3' is corrupt
Information for alsa-lib-1.0.26:

Mismatched Checksums:

Information for alsa-plugins-1.0.26:

Mismatched Checksums:

Information for apache22-2.2.24:

Mismatched Checksums:

Information for appres-1.0.3:

Mismatched Checksums:

Information for apr-1.4.6.1.4.1_3:

Mismatched Checksums:

pkg_info: the package info for package 'arts-1.5.10_8,1' is corrupt
Information for asciidoc-8.6.8_1:

Mismatched Checksums:

Information for aspell-0.60.6.1_2:

Mismatched Checksums:

Information for at-spi2-core-2.6.3:

Mismatched Checksums:

Information for atk-2.6.0:

Mismatched Checksums:

Information for autoconf-2.13.000227_6:

Mismatched Checksums:

Information for autoconf-2.69:

Mismatched Checksums:

Information for autoconf-wrapper-20101119:

Mismatched Checksums:

Information for automake-1.12.6:

Mismatched Checksums:

Information for automake-1.4.6_6:

Mismatched Checksums:

Information for automake-wrapper-20101119:

Mismatched Checksums:

Information for avahi-app-0.6.29_3:

Mismatched Checksums:

Information for babl-0.1.10:

Mismatched Checksums:

Information for bash-4.2.42:

Mismatched Checksums:

Information for bdftopcf-1.0.4:

Mismatched Checksums:

Information for bigreqsproto-1.1.1:

Mismatched Checksums:

Information for bind99-9.9.2.1:

Mismatched Checksums:
pkg_info: /usr/local/etc/rndc.key doesn't exist

Information for binutils-2.23.1:

Mismatched Checksums:

Information for bison-2.7,1:

Mismatched Checksums:

Information for bitmap-1.0.6:

Mismatched Checksums:

Information for bitstream-vera-1.10_5:

Mismatched Checksums:

Information for boehm-gc-7.1:

Mismatched Checksums:

Information for boost-jam-1.52.0_1:

Mismatched Checksums:

Information for boost-libs-1.52.0_1:

Mismatched Checksums:

pkg_info: the package info for package 'brasero-2.32.1_5' is corrupt
Information for ca_root_nss-3.14.3:

Mismatched Checksums:

Information for cabextract-1.4:

Mismatched Checksums:

Information for cairo-1.10.2_5,2:

Mismatched Checksums:

Information for cantarell-fonts-0.0.12:

Mismatched Checksums:

Information for cdparanoia-3.9.8_9:

Mismatched Checksums:

Information for cdrdao-1.2.3_4:

Mismatched Checksums:

Information for cdrtools-3.00_2:

Mismatched Checksums:

Information for celt-0.11.3_1:

Mismatched Checksums:

pkg_info: the package info for package 'clutter-1.4.0_1' is corrupt
pkg_info: the package info for package 'clutter-gtk-0.10.8_2' is corrupt
Information for cmake-2.8.9:

Mismatched Checksums:

Information for cmake-modules-2.8.9:

Mismatched Checksums:

Information for compositeproto-0.4.2:

Mismatched Checksums:

Information for consolekit-0.4.3:

Mismatched Checksums:

Information for cpdup-1.17_2:

Mismatched Checksums:

Information for cups-client-1.5.4_1:

Mismatched Checksums:

Information for cups-image-1.5.4_1:

Mismatched Checksums:

Information for curl-7.24.0_2:

Mismatched Checksums:

Information for cyrus-sasl-2.1.26_2:

Mismatched Checksums:

Information for damageproto-1.2.1:

Mismatched Checksums:

Information for db41-4.1.25_4:

Mismatched Checksums:

Information for db42-4.2.52_5:

Mismatched Checksums:

Information for db47-4.7.25.4:

Mismatched Checksums:

Information for dbus-1.6.8:

Mismatched Checksums:
pkg_info: /usr/local/libexec/dbus-daemon-launch-helper doesn't exist

Information for dbus-glib-0.100.1:

Mismatched Checksums:

Information for dconf-0.12.1_1:

Mismatched Checksums:

Information for dejavu-2.33:

Mismatched Checksums:

Information for desktop-file-utils-0.18:

Mismatched Checksums:

Information for dialog4ports-0.1.3:

Mismatched Checksums:

Informa

WANTED: Tool to verify installed package/port consistancy

[Ronald F. Guilmette]

The subject line pretty much says it all.

As I explained here the other day, numerous of my installed ports
have semi-mysteriously had their corresponding +CONTENTS files
just disappear.  I do have a backup of my /var partition, from which
I could, in theory, fetch replacements for the specific +CONTENTS
files that went missing, but I know of no way to be able to check
those backed-up +CONTENTS files to make sure that they are at all
consistant with what I actually have installed in the way of ports/
packages on this system at the present time.

Looking at the +CONTENTS files that were not "disappeared" and that
are still present on the system in question, it is abundantly clear
that each of these contains two valuable things relative to the
installed package/port that it corresponds to, i.e.:

1)  A list of all of the installed files corresponding to the
specific port/package in question, and

 2) For each installed file that is part of the package/port in
question, an MD5 checksum value corresponding to that specific
installed file.

I searched within the /usr/ports/ports-mgmt directory, to see if there
might be any tools there that could be applied to a given +CONTENTS file
(or to all of them) to simply verify the presence and (MD5 checksum)
validity of each file of a given installed port/package, but the only
things whose pkg-descr files make them seem like they might be relevant
(i.e. pchecker & portlint) turn out to be tools meant for utterly
different purposes. :-(

Having found nothing useful, I stareted to write a small script of my own
to simply chcek that all files of an installed package/port exist, and that
they have the "right" MD5 checksums, but then I paused halfway through
when I realized that i am probably just re-inventing the wheel here.

It occurs to me that *something*, i.e. some tool(s) within the FreeBSD
panoply, *must* already be reading and/or otherwise making use of those
MD5 checksums within the +CONTENTS files.  Otherwise, why would they even
be there?  So my question really comes down to this: What pre-existing
software tools are available that can and do check the MD5 checksums, as
given the the +CONTENTS file(s), of various files associated with some
given installed port or package?

It is inconceivable to me that there no already existing tool within
FreeBSD that is already doing this exact job.


Regards,
rfg
___
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"

Missing +CONTENTS syndrome: Selectively restoring +CONTENTS files

[Ronald F. Guilmette]

A couple of three weeks ago or so, I experienced an unfortunate series
of three or four system crashes, all of which I ultimately found to
be attributable to CPU automatic over-temp shutdowns, where the reason
for the overheating turned out to be something really rather stupid.
Some cables inside the system's case had been obstructing the rotation
of the CPU fan.  That problem has long since been effectively resolved,
and the system in question is functioning entirely normally again.

An unfortunate side-effect of the crashes however... one of which I
believe to have occured during a "portupgrade -a" operation... is that
numerous of my /var/db/pkg/*/+CONTENTS files appear to have gone
walkabout, for no apparently good reason.  The first manifestation
of this problem that I noticed was a series of messages of the following
general form when I ran pkg_version:

   pkg_version: the package info for package '-N.N.N' is corrupt

(It appears that out of a total of 643 installed ports, only 59 of them
are currenty suffering from this missing +CONTENTS syndrome.)

Since I first noticed this problem/issue, I have taken pains to utterly
avoid making any changes or updates to any of my ports.  (I am frankly
worried that if I did so, I might make matter worse than they already
are.)

Now I am finally making time to try to clean up this mess.  With the
help of Google, I have found various suggestions for how to cope,
specifically, with the problem of missing +CONTENTS file(s).  (I am
apparently not the first person to have experienced this issue.)  I am
now trying to decide the best course of action, and would be happy for
some advice.

In the following posting:

  http://lists.freebsd.org/pipermail/freebsd-ports/2007-May/041552.html

it was suggested to simply do "portinstall -i" (with the environment
variable FORCE_PKG_REGISTER pre-set to "yes") for each of the affected
packages.

In this posting:

   http://lists.freebsd.org/pipermail/freebsd-questions/2003-May/006301.html

it was suggested instead to cd to the directory for each port in turn,
and then do "make install FORCE_PKG_REGISTER=YES".

Elsewhere, I saw it suggested that _prior_ to such steps, it would be
appropriate (and perhaps even necessary) to "rm -fr" the relevant
/var/db/pkg port directory, before attempting any kind of re-install
of any one of the affected/afflicted ports.  I sincerely would like to
know if others think that this is good advice, or not.

More importantly than any of the forgoing hoever, I need to mention that
I fortunately _do_ have a complete intact backup of my entire /var
partition which was saved a mere two or three weeks prior to the set of
system crashes that precipitated these ports problems.  Given that I am
in the habit of upgrading my existing ports and/or installing new ports
only very sporadically, I do suspect that most or perhaps even all of
the various +CONTENTS files within that /var backup could perhaps simply
be copied from the backup to their corresponding locations within my
/var/db/pkg directory, and that this would be an entirely fast and
appropriate way to correct these issues for most or all of the affected
ports.

The question I have, of course, is the obvious one:  Is there any
definitive way for me to tell whether or not, for any given individual
port, I can simply restore the corresponding +CONTENTS file from the
(slightly stale) backup?

I'm worried that simply restoring these 59 +CONTENTS files from my backup
may be inappropriate, and may cause me yet more headaches, because it is
possible that for some of the affected ports, I _did_ successfully update
those to newer versions, sometime between the time that I made that backup
of /var and the time of my heat-induced system crashes, and the corresponding
magical disappearance of these 59 distinct +CONTENTS files.  If there were
a way to tell which of my backup +CONTENTS files were still valid and
usable, and which ones weren't, then that would be most helpful to know.

Any and all comments and/or guidance appreciated.


Regards,
rfg


P.S.  It is, of course, more than passing strange that any system crash,
even in the middle of a "portupgrade -a" operation, would selectively
cause a large set of _just_ various +CONTENTS files to utterly disappear,
and others who have also experienced this missing +CONTENTS syndrome have
also made this same comment.  I do suspect that somewhere someone has a
pretty good idea of the mechanism by which such havoc might arise, and
I can only hope that whoever that is, he or she is considering changes
that might perhaps make port upgrading just a tiny bit more fault tolerant.
(If a new +CONTENTS file for some port is going to be generated and
installed, it would perhaps be a kindness to rename the existing +CONTENTS
file to, say, +CONTENTS.old, and to leave it in its directory, removing
it either never or only at such time as its new replacement is considered
finished and complete.  This would seem to be, as they say, not

Re: pkg_version: the package info for package '...' is corrupt

[Ronald F. Guilmette]

Ok, first, my apologies to Leslie Jensen about the e-mail bounce.  It is
nothing personal, believe me.  I just have a personal policy of locally
blacklisting any and all domains that send me spam.  (Apparently, at one
time or another, I received some spam from bjare.net.)  I believe that
if _everybody_... or even just 10% of everybody... did as I do, then
ISPs would finally take seriously their spam outflow problems.  (Most
of them don't at present, and that explains why there is so much spam.)

Now, as regards to "pkg_version" versus "pkg version" I have never even
seen the latter, so I don't know a damn thing about that.  Furthermore,
although there does appear to be an executable named /usr/sbin/pkg
present on my system, whatever the heck it is, it does not seem to have
any associated man page. :-(

So anyway, I have never used it, I don't know what it even does, and I
would still not know how to use it, even if you held a gun to my head.

Regarding Julien Laffaye comment(s) relating to "pkgng", I have also
never even heard of that before now.  What is it and where do I get it?
And if it is so wonderful... and if what I am using is considered "old"...
then why isn't this new "pkgng" thing the default in/on 9.1-RELEASE?
(I also apparently have no man page for anything called "pkgng" on my
system.)

Anyway, athough I do thank both Leslie Jensen and Julien Laffaye for
their comments and attempts to help, I still am in DIRE need of an answer
to my original question.  I have, apparently, over 50 of my installed
ports that pkg_version is now telling me are in some *unspecified way*
"corrupt" and I still need (and am desperately begging for) someone to
tell me how to resolve that problem, exactly.

As I have said, I _do_ have a recent full system backup, but that doesn't
help me unless and until someone tells me which file or files from that,
exactly, I should be restoring in order to eliminate this problem.

Could someone kindly do that, please?


Regards,
rfg


P.S.  I do most seriously wonder if whoever engineered the FreeBSD ports
system ever realized how dramatically UNhelpful a message like the following
actually is:

pkg_version: the package info for package 'evince-2.32.0_9' is corrupt

I do not intend to offend anyone, but to be frank, this is the kind of a
message I would expect out of a Windows system, i.e. a message that some-
thing is broken, but providing -zero- details regarding what exactly is
broken, where it is located, or, most importantly, how to begin to fix the
problem.

When I am using Windows, I _expect_ to be treated like a luser... i.e.
one who cannot be trusted with too much information.

When I am using any kind of *NIX system however, I tend to expect the exact
opposite, and am rather unhappy when critical information is hidden from
me.
___
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"

pkg_version: the package info for package '...' is corrupt

[Ronald F. Guilmette]

[[ I asked about this problem on the -questions list a couple of days
   ago, but didn't get any relevant replies, so I'm trying again here
   on the -ports list.  Apologies if you see this twice.  ]]

A couple of days ago my system just simply decided to power itself off
(twice) whilst I was in the middle of doing "portupgrade -a".

I have since learned that the unscheduled and unexpected power offs
were due to a CPU cooling problem.  I believe that I have that problem
in hand now.

Separately however, and probably as result of the sudden power offs,
when I run pkg_version now I am getting many messages relating to
various of my installed packages, all having the following general
form:

   pkg_version: the package info for package 'PKG' is corrupt

where `PKG' is the name of some package or another that I have installed.

I have at least 6 such messages for different packages I have installed...
and probably more.

I googled around a bit and did not find any good explanation for the
above error or, more importantly, what to do about it.

I gather however that my package data base has become corrupted.

OK, so how does one rebuild that from scratch?

Please don't tell me that I have to reinstall every bleedin' port from
scratch!


Regards,
rfg


P.S.  Oh!  And by the way, I just happen to have made a full system backup
quite recently.  Do I just simply need to get the entire contents of
/var/db/pkg/ from that backup, and then do "rm -fr /var/db/pkg" and then
copy my backup copy of /var/db/pkg to the real /var/db/pkg ?

Will that fix the problem?
___
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: graphviz -- can't fetch

[Ronald F. Guilmette]

In message <44mwu3rqxn@lowell-desk.lan>, you wrote:

>I suspect that it's tied to the package building cluster problems. I'm
>not sure who to ask directly, so a PR is the right approach.

For the enlightment of those not in the know (which includes myself)
please do elaborate.  What am "the package building cluster problems" ?
___
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: graphviz -- can't fetch

[Ronald F. Guilmette]

>FWIW, I have fetched the distfile repeatedly over the  past three days on a
>variety of systems with no problems at all. Slow at between 600 and 800
>kBps with my very well connected work system at the high end and my home
>system at the low end. I am also getting it from www.graphviz.org.
>
>Sounds like some sort of network issue at your location, though it could
>also have been a transitive error at the source that most people, including
>myself) never happened to hit.


It was indeed a transient DNS eror... *not* originating on my end.

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

___
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: graphviz -- can't fetch

[Ronald F. Guilmette]

In message <44k3p8pa1t@lowell-desk.lan>, 
Lowell Gilbert  wrote:

>"Ronald F. Guilmette"  writes:
>
>> What gives?  Where is the missing .gz file?
>>
>>
>> % portupgrade graphics/graphviz
>> ...
>> ===>  Found saved configuration for graphviz-2.30.1
>> => graphviz-2.30.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>> => Attempting to fetch http://www.graphviz.org/pub/graphviz/ARCHIVE/graphviz
>-2.30.1.tar.gz
>> fetch: http://www.graphviz.org/pub/graphviz/ARCHIVE/graphviz-2.30.1.tar.gz: 
>Moved Temporarily
>> => Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/gra
>phviz-2.30.1.tar.gz
>> fetch:
>> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/graphviz-2.30.1.tar.gz:
>> File unavailable (e.g., file not found, no access)
>> => Couldn't fetch it - please try to retrieve this
>> => port manually into /usr/ports/distfiles/ and try again.
>> *** [do-fetch] Error code 1
>>
>> Stop in /usr/ports/graphics/graphviz.
>> *** [build] Error code 1
>>
>> Stop in /usr/ports/graphics/graphviz.
>> ** Command failed [exit code 1]: /usr/bin/script -qa
>> /tmp/portupgrade20130314-39851-1llt20w-0 env UPGRADE_TOOL=portupgrade
>> UPGRADE_PORT=graphviz-2.30.0 UPGRADE_PORT_VER=2.30.0 make
>> ** Fix the problem and try again.
>> ** Listing the failed packages (-:ignored / *:skipped / !:failed)
>> ! graphics/graphviz (graphviz-2.30.0)   (fetch error)
>
>Try the first mastersite again; I just fetched from there.

By "the first master site" I assume you mean by the first URL, i.e.:

  http://www.graphviz.org/pub/graphviz/ARCHIVE/graphviz-2.30.1.tar.gz

Well, I just did try that and I am still getting the same result.  In fact,
it appears to me that the entire web site of "www.graphviz.org" is most
seriously and entirely baroque I mean busted, kaput, blewie, snafued,
hosed in a major way.

Please look for yourself.

I've tried looking at the home page on that site and every version of the
URL for the (alleged) .gz file between the full path of the .gz file and
the home page of the web site, and all of these display as nothing but
a blank page.  I've reproduced this is both FireFox and Opera.

I think that _somebody_ has really and totally effed up that site.

But anyway, meanwhile, back here on earth, forget about THAT for a
second... How come a copy of the dist file is *also* not available
(still) from ftp.FreeBSD.org ??

I'm filing a PR.  This is really broke.

(I wouldn't even care, but graphviz is apparently a dependency of something
else I need to build.  Gr.)
___
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"

graphviz -- can't fetch

[Ronald F. Guilmette]

What gives?  Where is the missing .gz file?


% portupgrade graphics/graphviz
...
===>  Found saved configuration for graphviz-2.30.1
=> graphviz-2.30.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch 
http://www.graphviz.org/pub/graphviz/ARCHIVE/graphviz-2.30.1.tar.gz
fetch: http://www.graphviz.org/pub/graphviz/ARCHIVE/graphviz-2.30.1.tar.gz: 
Moved Temporarily
=> Attempting to fetch 
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/graphviz-2.30.1.tar.gz
fetch: 
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/graphviz-2.30.1.tar.gz: File 
unavailable (e.g., file not found, no access)
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/ports/distfiles/ and try again.
*** [do-fetch] Error code 1

Stop in /usr/ports/graphics/graphviz.
*** [build] Error code 1

Stop in /usr/ports/graphics/graphviz.
** Command failed [exit code 1]: /usr/bin/script -qa 
/tmp/portupgrade20130314-39851-1llt20w-0 env UPGRADE_TOOL=portupgrade 
UPGRADE_PORT=graphviz-2.30.0 UPGRADE_PORT_VER=2.30.0 make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! graphics/graphviz (graphviz-2.30.0)   (fetch error)

___
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: Need a little help with a dynamic linking problem

[Ronald F. Guilmette]

Sorry for my late reply... I was tied up on other projects.

A few days ago, in a galaxy not far away...
In message <20120426080649.go2...@deviant.kiev.zoral.com.ua>, 
Konstantin Belousov  wrote:

>You need to pass --export-dynamic to the linker when linking binary that
>is supposed to export its own symbols.

Yes!  Thank you Konstantin.  Using that linker option... or more accurately it's
gcc equivalent (-rdynamic) did indeed clear up the problem I was having with
gthumb's (dynamic plug-in?) extension modules not seeing the symbols in the
main exectuable.

I'm not at all sure why this option wasn't already integrated into the relevant
Makefiles (for gthumb).  I will be looking into that further.


Regards,
rfg


P.S.  If it were me, I think I would have implemented that linker option the
other way around, i.e. made the default that symbols in the main executable
_are_ externally visible by default, and then I would have provided an option
to make them non-visible, when and if that is/was ever useful.

Sigh.  Oh well.  I wasn't there at the time.  It's just water under the bridge 
now.
___
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: Need a little help with a dynamic linking problem

[Ronald F. Guilmette]

In message 
, you wrote:

>Without being able to look at the details in-depth myself, it looks like
>the shared object is looking for a symbol which the RTLD can't resolve.

That much seems self-evident.  The error message itself in effect says
precisely that.

>The symbol is defined in the gthumb application itself. Is that symbol exported
>such that shared objects can reference it?

Based on the outcome, I would have to say that this answer to that question
is also (self-evidently?) no.

But I'm really not sure, frankly, because I have never before seen an
instance of anybody trying to do something screwy like this... I mean
having a shared library that depends upon somthing (a symbol) that is
intended to be satisfied by the main executable.  Frankly, this seems
altogether screwy and bizzare to me.  Unsually, the main executable depends
on (or uses, dynamically) a number of shared libraries.  Sharded libraries
in turn typically depend on either (a) nothing at all or else (b) some
combination of other shared and/or static linking libraries.  That has
always been my own past experience anyway.  By like I said, I have been away
from the software development tools for awhile, so mabe having a dynamic
library that depends upon something in the main executable is considered
kosher now.  (Or maybe it ain't, actually, but it is nonthelwess one of
those screwy things that the current or original developer or maintainer
found out that he could get away with anyway, you know, like JUST over
on that well-known hobbist OS whose name begins with the letter "L".)

Like I say.  I don't know, cuz I'm not the developer/maintainer of this
thing.

>If the problem is still unresolved by tomorrow...

It doesn't seem to be healing on its own so far...

>I can draft up a sample and confirm my suspicions
>(that non-exported symbols won't be resolvable by dynamically-loaded shared
>objects).

Oh, I do believe that you are 100% correct about that.  This much, at least,
I _do_ remember from ancient times when I worked on the GNU software develop-
ment tools (including the linker).

In every object file... either a main executable or a shared library, there
are symbols that are externally available/visible and then there are ones
that aren't... i.e. that are local, and that the dynamic linker either never
sees or, at any rate, doesn't pay any attention to.

But my dim recollection is that you can easily tell which is which by looking
at the type letter that appears next to the symbol in the `nm' output.  For
example:

% nm gthumb | fgrep gth_viewer_page_get_type
004aaf10 T gth_viewer_page_get_type
 ^

Here, the symbol type indicator is the letter `T', meaning that this is
a ``text'' (executable/code) type of symbol.  That much I know for sure.
The part I am less clear about anymore is that I _think_ I remember that
when the type letter on the nm output is a capital letter (as in this case)
it means that the symbol in question is ``public'' and available for
linking.  (Actually, I _am_ pretty darn sure that this is indeed what CAPITAL
type letters in the nm output mean.)

The only other thing that I can't quite remember anymore is whether such
a symbol is always and necessarily available for *dynamic* linking purposes.
It might perhaps just be externally available & visible ONLY for *static*
linking purposes, in which case that might explain why I am seeing a `T'
on the nm output for the required symbol, but yet the dynamic linker
clearly can't seem to find it.


Regards,
rfg


___
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: Need a little help with a dynamic linking problem

[Ronald F. Guilmette]

In message <450d1c59-c403-463b-9c35-6af26f63d...@mac.com>, you wrote:

>On Apr 25, 2012, at 5:01 PM, Ronald F. Guilmette wrote:
>> When I try to run the gthumb binary that I built and install, I am getting
>> the following perplexing error message:
>> 
>> /libexec/ld-elf.so.1: /usr/local/hacked/lib/gthumb/extensions/libfile_viewer
>.so: Undefined symbol "gth_viewer_page_get_type"
>
>Does running "ldconfig /usr/local/hacked/lib" help?

Not here it doesn't...

root# ldconfig /usr/local/hacked/lib
ldconfig: /usr/local/hacked/lib: ignoring directory not owned by root

But anyway, why would it?  The ``missing'' symbol is defined in the file
/usr/local/hacked/bin/gthumb, as I said.
  ^^^
>What does ldd say about things?

Which things?

% ldd /usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so:
/usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so:
libm.so.5 => /lib/libm.so.5 (0x800c0)
libc.so.7 => /lib/libc.so.7 (0x800647000)

% ldd /usr/local/hacked/bin/gthumb
/usr/local/hacked/bin/gthumb:
libclutter-gtk-0.10.so.0 => /usr/local/lib/libclutter-gtk-0.10.so.0 
(0x800718000)
libclutter-glx-1.0.so.0 => /usr/local/lib/libclutter-glx-1.0.so.0 
(0x800823000)
libSM.so.6 => /usr/local/lib/libSM.so.6 (0x800a71000)
libICE.so.6 => /usr/local/lib/libICE.so.6 (0x800b79000)
libgtk-x11-2.0.so.0 => /usr/local/lib/libgtk-x11-2.0.so.0 (0x800c93000)
libgdk-x11-2.0.so.0 => /usr/local/lib/libgdk-x11-2.0.so.0 (0x8011ac000)
libatk-1.0.so.0 => /usr/local/lib/libatk-1.0.so.0 (0x80135f000)
libpangocairo-1.0.so.0 => /usr/local/lib/libpangocairo-1.0.so.0 
(0x80148)
libgdk_pixbuf-2.0.so.0 => /usr/local/lib/libgdk_pixbuf-2.0.so.0 
(0x80158d000)
libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0x8016ab000)
libpng.so.6 => /usr/local/lib/libpng.so.6 (0x801863000)
libpango-1.0.so.0 => /usr/local/lib/libpango-1.0.so.0 (0x80198d000)
libgconf-2.so.4 => /usr/local/lib/libgconf-2.so.4 (0x801ad6000)
libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x801c12000)
libz.so.5 => /lib/libz.so.5 (0x801e36000)
libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x801f4b000)
libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80204e000)
libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x80219a000)
libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x80229e000)
libintl.so.9 => /usr/local/lib/libintl.so.9 (0x802488000)
libm.so.5 => /lib/libm.so.5 (0x802591000)
libthr.so.3 => /lib/libthr.so.3 (0x8026b1000)
libc.so.7 => /lib/libc.so.7 (0x8027ca000)
libGL.so.1 => /usr/local/lib/libGL.so.1 (0x802a0c000)
libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x802b94000)
libjson-glib-1.0.so.0 => /usr/local/lib/libjson-glib-1.0.so.0 
(0x802c9e000)
libXinerama.so.1 => /usr/local/lib/libXinerama.so.1 (0x802dbb000)
libXi.so.6 => /usr/local/lib/libXi.so.6 (0x802ebd000)
libXrandr.so.2 => /usr/local/lib/libXrandr.so.2 (0x802fcc000)
libXext.so.6 => /usr/local/lib/libXext.so.6 (0x8030d4000)
libXcursor.so.1 => /usr/local/lib/libXcursor.so.1 (0x8031e6000)
libXcomposite.so.1 => /usr/local/lib/libXcomposite.so.1 (0x8032f)
libXdamage.so.1 => /usr/local/lib/libXdamage.so.1 (0x8033f3000)
libpangoft2-1.0.so.0 => /usr/local/lib/libpangoft2-1.0.so.0 
(0x8034f5000)
libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x803627000)
libpixman-1.so.9 => /usr/local/lib/libpixman-1.so.9 (0x80372d000)
libxcb-shm.so.0 => /usr/local/lib/libxcb-shm.so.0 (0x8038ac000)
libxcb-render.so.0 => /usr/local/lib/libxcb-render.so.0 (0x8039ae000)
libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x803ab6000)
libX11.so.6 => /usr/local/lib/libX11.so.6 (0x803bbf000)
libxcb.so.2 => /usr/local/lib/libxcb.so.2 (0x803df4000)
libXau.so.6 => /usr/local/lib/libXau.so.6 (0x803f0e000)
libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x804011000)
libpthread-stubs.so.0 => /usr/local/lib/libpthread-stubs.so.0 
(0x804116000)
librpcsvc.so.5 => /usr/lib/librpcsvc.so.5 (0x804217000)
libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x80432)
libfreetype.so.9 => /usr/local/lib/libfreetype.so.9 (0x804453000)
libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x8045db000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x8046ff000)
libpcre.so.0 => not found (0x0)
libpcre.so.0 => not found (0x0)
libpcre.so.0 => not found (0x0)
libpcre.so.0 => not found (0x0)
libpcre.so.0 => not found (0x0)

Need a little help with a dynamic linking problem

[Ronald F. Guilmette]

My question relates to a port that I am doing of gthumb v2.14.3 to
FreeBSD.  Because gthumb is fundamentally a gnome application, I am
cross-posting my question to both the ports and gnome mailing lists.
(My apologies if that means that some of you see this twice.)

After a modest but unexpected amount of gnashing of teeth and tearing
of hair, I have been able to get gthumb 2.14.3 built and installed on
my FreeBSD 8.2 system.  Now comes to the fun part...

I have installed the whole thing under a special (temporary) directory
that I created called /usr/local/hacked.

When I try to run the gthumb binary that I built and install, I am getting
the following perplexing error message:

/libexec/ld-elf.so.1: 
/usr/local/hacked/lib/gthumb/extensions/libfile_viewer.so: Undefined symbol 
"gth_viewer_page_get_type"


Quite obviously, I have been away from working on the GNU software development
toolchain (and its friends, like ld-elf.so) for far far too long, because I
no longer even know how this stuff is even supposed to work, i.e. when it is
(knock on wood) working correctly.  So if someone who knows this stuff can
take pity on me and pass me a clue about what I need to do to resolve the
above dynamic linking failure, I sure would appreciate it.

Some relevant background:

The main gthumb binary is installed in /usr/local/hacked/bin/gthumb and that's
what I am running when I run it.

It seems pretty obviously to me that the main gthumb executable, when executed,
is then trying to dynamically pull in various of the *.so shared library files
that got installed into /usr/local/hacked/lib/gthumb/extensions directory as
part of the nominal build+install process for gthumb.

One last important point:

I've checked, and the symbol "gth_viewer_page_get_type" _is_ in fact defined.
It is defined within the main gthumb executable itself:

% nm gthumb | fgrep gth_viewer_page_get_type
004aaf10 T gth_viewer_page_get_type

So, um, sombody please pass me a clue... How come the dynamic linker doesn't
seem to know that the symbol it is looking for was and is defined in the main
executable file that the present process originated with?  (This specific
lack of cognition on the part of the dynamic linker seems to me to be rather
reminicent of Alzheimer's.)


Regards,
rfg


P.S.  I have already tried both of the following commands prior to executing
my gthumb executable and neither of these made a bit of difference to the
outcome.  I still got the exact same dynamic linker (fatal) error in both
cases...

setenv LD_LIBRARY_PATH /usr/local/hacked/bin

setenv LD_LIBRARY_PATH /usr/local/hacked/lib/gthumb/extensions
___
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"

graphics/dri maintainer?

[Ronald F. Guilmette]

Who is allegedly maintaining the graphics/dri port at this moment in time?

I would rather like to know, because it is in serious need of updating.
(The version upon which the port was based was apparently released on
June 23, 2009, and there have been numerous new releases since then.)

I wouldn't care, except that gthumb was crashing on me (SIGSEGV) and a
stack backtrace clearly showed that the problem resides within the Mesa/DRI
library.

Of course, I asked the Mesa/DRI dudes for help and advice, and of course
they suggested that I consider using a rather more current version.
___
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"

Still failing, after all these years (was: Re: Need help disabling (re-)configure step)

[Ronald F. Guilmette]

In message <15694.1262163...@tristatelogic.com>, I wrote:

>==
>=
># cd /usr/ports/graphics/gthumb
># make
>===>   gthumb-2.10.11_1 depends on executable: gmake - found
>===>   gthumb-2.10.11_1 depends on file: /usr/local/bin/intltool-extract - fou
>nd
>===>   gthumb-2.10.11_1 depends on file: /usr/local/libdata/pkgconfig/gnome-mi
>me-data-2.0.pc - found
>===>   gthumb-2.10.11_1 depends on executable: pkg-config - found
>===>   gthumb-2.10.11_1 depends on file: /usr/local/libdata/pkgconfig/gnome-do
>c-utils.pc - found
>===>   gthumb-2.10.11_1 depends on shared library: exif.12 - found
>===>   gthumb-2.10.11_1 depends on shared library: intl - found
>===>   gthumb-2.10.11_1 depends on shared library: esd.2 - found
>===>   gthumb-2.10.11_1 depends on shared library: atk-1.0.0 - found
>===>   gthumb-2.10.11_1 depends on shared library: gconf-2.4 - found
>===>   gthumb-2.10.11_1 depends on shared library: glib-2.0.0 - found
>===>   gthumb-2.10.11_1 depends on shared library: gnomevfs-2.0 - not found
===>Verifying install for gnomevfs-2.0 in /usr/ports/devel/gnome-vfs
>===>   gnome-vfs-2.24.2 depends on executable: gmake - found
>===>   gnome-vfs-2.24.2 depends on package: libtool>=2.2 - found
>===>   gnome-vfs-2.24.2 depends on file: /usr/local/bin/intltool-extract - fou
>nd
>===>   gnome-vfs-2.24.2 depends on file: /usr/local/libdata/pkgconfig/gnome-mi
>me-data-2.0.pc - found
>===>   gnome-vfs-2.24.2 depends on executable: pkg-config - found
>===>   gnome-vfs-2.24.2 depends on shared library: hal.1 - found
>===>   gnome-vfs-2.24.2 depends on shared library: smbclient.0 - found
>===>   gnome-vfs-2.24.2 depends on shared library: avahi-client - not found
>===>Verifying install for avahi-client in /usr/ports/net/avahi-app
>===>   Returning to build of gnome-vfs-2.24.2
>Error: shared library "avahi-client" does not exist
>*** Error code 1
>
>Stop in /usr/ports/devel/gnome-vfs.
>*** Error code 1
>
>Stop in /usr/ports/devel/gnome-vfs.
>*** Error code 1
>
>Stop in /usr/ports/graphics/gthumb.
>*** Error code 1
>
>Stop in /usr/ports/graphics/gthumb.



Man!  Is this ever FRUSTRATING!  I finally managed to build & install
avahi-app (using the --disble-dbus config option) but apparently, as you
can see above, doing it that way causes the avahi-client.* library files
to NOT be installed.  (I can't say that this makes any sense at all to
me.  What good is this whole avahi thing if there are no client libraries??
And if it is utterly useless without them, then why did the implementors
even create a configure option... --disble-dbus... that causes those
libraries not to even be built or installed?  As I say, this makes no
sense at all to me.  But I actually don't want to know the answer, I just
want to work-around all of these problems and get gthumb installed.)

So I went over to the /usr/ports/devel/gnome-vfs directory and inspected
_its_ Makefile and found that I could get it to supply a --disable-avahi
option to the configure step simply by doing:

make -DWITHOUT_MDNS=1

which I then did.  But even THAT doesn't work to get gnome-vfs built &
installed, because apparently, for reasons I don't understand, the
&^%$#@ port system _still_ views avahi-app as a prerequsite of gnome-vfs
*and* for some reason it doesn't see that I already have avahi-app
installed:

% pkg_info | fgrep avahi
avahi-app-0.6.25_2  Service discovery on a local network

So what happens is that my "make -DWITHOUT_MDNS=1" (of gnome-vfs) ends up
trying to rebuild and re-install avahi-app-0.6.25_2... an effort which, of
course, fails horribly, since avahi-app-0.6.25_2 _is_ already installed on
my system.

OK, so why is the ports system not seeing that avahi-app-0.6.25_2 (needed
by gnome-vfs) is already installed?  Why does it insist on trying to
rebuild and re-install it from scratch when I'm just trying to build
gnome-vfs and when avahi-app-0.6.25_2 is already installed??  (To say that
this makes no sense to me would be an understatement.)

More to the point, how can I get the ports system to STOP trying (and failing)
to re-build and re-install a port that's already installed?


Regards,
rfg


P.S.  I can't imagine what a real newcomer to FreeBSD would think about
the OS if he had likewise set out to just build & install one simple app
and if he had run into all of the same obstacles that I've already run
into, just trying to install gthumb.


P.P.S.  What the bleep IS this whole gnome-vfs thing anyway?  Yes, I read
the package description...

   The GNOME Virtual File System allows applications and users to treat
   any number of file system concepts as a part of the local filesystem.
   With GnomeVFS, filesystems across the internet, on connected devices,
   and in multiple formats are as simple to access (and write code for)
   as any directory on the local machine.

So, uhhh... WTF?  Like NFS, Samba, AFS, and the FreeBSD Vinum Volume Manager
wer

Re: Need help disabling (re-)configure step

[Ronald F. Guilmette]

In message <3jcA1ljpZsB1WBdNgXUe/mei...@snwcwk2deghgefqjleiqreaoikg>, you wrote
:

>Ronald, good day.

And a very good day to you also sir!  Thanks for replying!

>Basically, because you're not intended to mess with the manual invocation
>of configure script.  The proper thing to do is to edit avahi-app
>port's Makefile and replace
>-
>   --with-dbus-system-socket=unix:path=/var/run/dbus/system_bus_so
>cket \
>-
>with
>-
>   --disable-dbus --disable-gdbm \
>-


YES!  That is exactly the bit of magic I was in need of!  Thank
you very much.  (I am so glad that FreeBSD is international, so that I
can get questions like this answered, even when everyone in my local
vicinity is sound asleep, like now. :-)

So now... I FINALLY (whew!) got avahi-app built and installed... albeit
one which does not use that DBus thingy.  OK swell.  So now I go on to
build gthumb and I get the crap below.  Have you got any sage suggestions
for how I should get past _this_ new problem?

If you do, I'd be much obliged.  Thanks.


===
# cd /usr/ports/graphics/gthumb
# make
===>   gthumb-2.10.11_1 depends on executable: gmake - found
===>   gthumb-2.10.11_1 depends on file: /usr/local/bin/intltool-extract - found
===>   gthumb-2.10.11_1 depends on file: 
/usr/local/libdata/pkgconfig/gnome-mime-data-2.0.pc - found
===>   gthumb-2.10.11_1 depends on executable: pkg-config - found
===>   gthumb-2.10.11_1 depends on file: 
/usr/local/libdata/pkgconfig/gnome-doc-utils.pc - found
===>   gthumb-2.10.11_1 depends on shared library: exif.12 - found
===>   gthumb-2.10.11_1 depends on shared library: intl - found
===>   gthumb-2.10.11_1 depends on shared library: esd.2 - found
===>   gthumb-2.10.11_1 depends on shared library: atk-1.0.0 - found
===>   gthumb-2.10.11_1 depends on shared library: gconf-2.4 - found
===>   gthumb-2.10.11_1 depends on shared library: glib-2.0.0 - found
===>   gthumb-2.10.11_1 depends on shared library: gnomevfs-2.0 - not found
===>Verifying install for gnomevfs-2.0 in /usr/ports/devel/gnome-vfs
===>   gnome-vfs-2.24.2 depends on executable: gmake - found
===>   gnome-vfs-2.24.2 depends on package: libtool>=2.2 - found
===>   gnome-vfs-2.24.2 depends on file: /usr/local/bin/intltool-extract - found
===>   gnome-vfs-2.24.2 depends on file: 
/usr/local/libdata/pkgconfig/gnome-mime-data-2.0.pc - found
===>   gnome-vfs-2.24.2 depends on executable: pkg-config - found
===>   gnome-vfs-2.24.2 depends on shared library: hal.1 - found
===>   gnome-vfs-2.24.2 depends on shared library: smbclient.0 - found
===>   gnome-vfs-2.24.2 depends on shared library: avahi-client - not found
===>Verifying install for avahi-client in /usr/ports/net/avahi-app
===>   Returning to build of gnome-vfs-2.24.2
Error: shared library "avahi-client" does not exist
*** Error code 1

Stop in /usr/ports/devel/gnome-vfs.
*** Error code 1

Stop in /usr/ports/devel/gnome-vfs.
*** Error code 1

Stop in /usr/ports/graphics/gthumb.
*** Error code 1

Stop in /usr/ports/graphics/gthumb.



___
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"

Need help disabling (re-)configure step

[Ronald F. Guilmette]

I've been trying for some time to ge graphics/gthumb installed on
my 7.0-RELEASE system and it just ain't workin' and it's becoming
_very_ frustrating.

Basically, gthumb requires avahi-app, which (for as yet unexplained
reasons) won't even properly go through the configure step on my
system.  (See: http://www.freebsd.org/cgi/query-pr.cgi?pr=140563.)

I've just sent off some more information to the maintainer(s) of
the avahi-app port, and I hope that, eventually, a correct fix becomes
available for this problem, but I'd really prefer not to wait
around in the hopes that (eventually?) a fix for this is forth-
coming.

So anyway, I've found that if I just take the ./configure command as
it appears in the config.log file, and edit it to remove this option:

   --with-dbus-system-socket=unix:path=/var/run/dbus/system_bus_socket

replacing that instead with:

   --disable-dbus --disable-gdbm

then I can at least get the bleepin' thing to configure properly.  (It
appers that it subsequently dies during the actual build, but let me
worry about that part.)

So anyway, the good news is that I know how to at least get this thing
to configure without dying during the execution of ./configure.

The bad news is that once I do that, if I cd back up two levels (../..)
and then just try to do "make", for some reason the ports building system
insists on re-running the configure step again, thus wiping out my
adjustments which allowed avahi-app to at least finish the pre-build
configure step.

So, could somebody please tell me how to suppress this behavior?  Why is
it the case that when I am cd'd into /usr/ports/net/avahi-app and when I
then type "make", the bleedin' thing forces a re-run of the ./configure
step, even though I have already done that manually.

A little help would be appreciated.

___
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"

WTF?? portupgrade of bind 9.5.0-P1 => 9.5.0-P2 crashes and burns

[Ronald F. Guilmette]

Seems to be the exact same problem described here (for Linux), and
in my case, also on an AMD 64 machine:

http://209.85.173.104/search?q=cache:wfV3BUpO2d4J:www.topology.org/linux/bind_bigbug.html+undefined+reference+to+DH_generate_parameters_ex+bind&hl=en&ct=clnk&cd=5&gl=us

Is it really the AMD 64 that's the problem?

OK, so what do I do now?  I still need to upgrade this puppy.


...
cc -O2 -fno-strict-aliasing -pipe -rpath=/usr/local/lib -o named  builtin.o 
client.o config.o control.o  controlconf.o interfacemgr.o  listenlist.o log.o 
logconf.o main.o notify.o  query.o server.o sortlist.o statschannel.o  
tkeyconf.o tsigconf.o update.o xfrout.o  zoneconf.o  lwaddr.o lwresd.o 
lwdclient.o lwderror.o lwdgabn.o  lwdgnba.o lwdgrbn.o lwdnoop.o lwsearch.o
unix/os.o ../../lib/lwres/liblwres.a ../../lib/dns/libdns.a  -lcrypto 
../../lib/bind9/libbind9.a  ../../lib/isccfg/libisccfg.a 
../../lib/isccc/libisccc.a ../../lib/isc/libisc.a   
../../lib/dns/libdns.a(openssldh_link.o)(.text+0x23d): In function 
`openssldh_generate':
: undefined reference to `DH_generate_parameters_ex'
../../lib/dns/libdns.a(openssldsa_link.o)(.text+0x365): In function 
`openssldsa_generate':
: undefined reference to `DSA_generate_parameters_ex'
../../lib/dns/libdns.a(opensslrsa_link.o)(.text+0x4e0): In function 
`opensslrsa_generate':
: undefined reference to `RSA_generate_key_ex'
*** Error code 1

Stop in /usr/ports/dns/bind95/work/bind-9.5.0-P2/bin/named.
*** Error code 1

Stop in /usr/ports/dns/bind95/work/bind-9.5.0-P2/bin.
*** Error code 1

Stop in /usr/ports/dns/bind95/work/bind-9.5.0-P2.
*** Error code 1

Stop in /usr/ports/dns/bind95.
*** Error code 1

Stop in /usr/ports/dns/bind95.
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.7408.0 
env UPGRADE_TOOL=portupgrade UPGRADE_PORT=bind95-base-9.5.0.1 
UPGRADE_PORT_VER=9.5.0.1 make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! dns/bind95 (bind95-base-9.5.0.1)  (linker error)
%
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"