Re: Discover stored options different from port defaults/defines

[Randy Pratt]

On Sun, 30 Mar 2014 17:13:15 -0400
"John W. O'Brien"  wrote:

> Hello ports@,
> 
> In the bad old days before poudriere and various improvements to
> OptionsNG came to town, when I was using portmaster* to handle upgrades,
> I cobbled together a configuration management practice that involved
> using rsync and git to store /var/db/ports in a repository. The usual
> workflow looked roughly like this:
> 
> svn up /usr/ports
> portmaster -dga
> # handle changes to OPTIONS_DEFINE and its brethren here
> rsync -rpt --del --exclude distfiles /var/db/ports/ /path/to/repo
> cd /path/to/repo
> git commit -a -m "Store options that changed"
> 
> A downside of this approach is that it couldn't distinguish between
> options I care about ("Always do this" and "Never do this") and options
> I don't care about ("Do what the maintainer thinks is best"). The only
> upstream changes that would bubble to the surface of their own accord
> were NEW_OPTIONS when OPTIONS_DEFINE changed.
> 
> When I switched from portmaster to poudriere+pkgng, I migrated
> /var/db/ports to /usr/local/etc/poudriere.d/$jail-$ports-$set-options
> and that worked OK for a little while. However, this compounded the old
> problem in that now even NEW_OPTIONS would arrive silently.
> 
> The first part of my solution to these problems is to store only the
> options that I know I care about. That is, I know I need to find out
> where a stored option disagrees with the default.
> 
> I couldn't figure out how to use the stock tools to peel apart currently
> stored options from current default options, so I wrote a
> ``nondefaultconfig`` target for Mk/bsd.port.mk (see attached), set all
> the common options (DOCS, IPv6, etc) explicitly in /etc/make.conf using
> OPTIONS_SET/OPTIONS_UNSET, and ran the new target against all of my
> installed ports, replacing a subtree full of options files with a
> single, quite modest make.conf. To make this more generally-useful, it
> would need to behave more like NEW_OPTIONS.
> 
>cd /usr/ports
>pkg info -aoq | sort | xargs -n1 make nondefaultconfig -C \
> >> /usr/local/etc/poudriere.d/$jail-make.conf
>rm -fr /usr/local/etc/poudriere.d/$jail-$ports-$set-options
> 
> At this point, any option not configured by $jail-make.conf will be
> allowed to vary according to the whims of the maintainer. The next part
> of the problem that I would like to solve is learning about options that
> I don't yet know I care about (OPTIONS_DEFINE gains a member), and
> secondarily to learn when an option is past caring (OPTIONS_DEFINE loses
> a member that I used to care about), so that I can update
> $jail-make.conf in an orderly fashion.
> 
> I welcome any comments on my approach so far, or suggestions about how I
> might proceed.

I found this posting useful to find OPTIONS:

http://docs.freebsd.org/cgi/mid.cgi?CAOjFWZ45ACYnaByYxxrGoyqTOeS7_EDV6MwoH98-GtDe-F3Yug

The mailing list archives seem to be missing for the past month PR187557
so here an excerpt from my notes:

> On 3/4/2014 9:40 AM, Thierry Thomas wrote:
> from within a port's directory,
>
> make showconfig
>
> will show you the current options set and
>
> make __MAKE_CONF=/dev/null PORT_DBDIR=/var/empty showconfig
>
> will show you the defaults.

See make(1)'s -C option for specifying ports pathname.

It shouldn't take too much to write a small script and find
the diff in the output for each command.

HTH,

Randy
  


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

Re: Portmaster/Poudriere/Pkgng

[Randy Pratt]

On Tue, 18 Feb 2014 07:22:11 +
Matthew Seaman  wrote:

> On 18/02/2014 02:34, Randy Pratt wrote:
> > I have been attempting to get portmaster to use my local repository
> > but get a message "Package installation support cannot be used with
> > pkgng yet, it will be disabled".
> 
> This is a known limitation of the portmaster / pkg combination.  Patches
> welcome -- however, there is a significant hurdle in that portmaster
> would have to rebuild its repository each time it added a package to it,
> and that would make things horribly slow.

The message was what finally prompted me to ask on the list after
about a week of trying various configurations and searching many
documents.   I didn't see the message at first because it scrolls
off the screen as portmaster started building from source.  The
https://fossil.etoilebsd.net/poudriere/doc/trunk/doc/portmaster.wiki
makes it look easy to use portmaster.

> Most people find that the pkg+poudriere combination is sufficient on its
> own, without needing to add portmaster to the mix.  If you need to add a
> new package, add it to the list of packages for your poudriere instance
> to build and then run a poudriere bulk to add it and any dependencies to
> your repo.  You can then 'pkg install' it in the usual way.

Agreed.  Its probably the best in the long run if you need more
frequent updates than is provided by the FreeBSD package builds,
need to update multiple machines using different OPTIONS, or
want to build packages in a pristine environment before installing
them to running systems.  

Congrats to those who worked to make this happen.  It'll be interesting
to watch as future features emerge.

My next project is to actually *use* the packages I've built for
updating a running system.  Even though my last portmaster update was
2 days ago, my "pkg upgrade" shows over 200 packages to be updated.
It seems as if pkg does a more thorough checking than a simple
version comparison.

Thanks for taking the time to respond.

Randy
  

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

Re: Portmaster/Poudriere/Pkgng

[Randy Pratt]

On Tue, 18 Feb 2014 04:09:39 +0100
"A.J. 'Fonz' van Werven"  wrote:

> Randy Pratt wrote:
> 
> > PS - It would be nice to find an audio file on how to pronounce
> >  poudriere ;-)  I don't remember much from French I studied
> >  50 years ago.
> 
> Not that I'm a native speaker, but I'd say the following comes close:
> "poo dree air".
> 
> Note 1: the ee is short (or *very* short, even), but if I wrote dre one
> might wrongly think it's pronounced "dray" instead.
> 
> Note 2: the e at the end of Poudriere is silent, but that doesn't
> necessarily stop people from tacking on an "uh" anyway ;-)
> 
> AvW

Thanks!  That does help and gets me close enough for reading purposes.

Much appreciated,

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

Portmaster/Poudriere/Pkgng

[Randy Pratt]

I have poudriere functional with a set of ports which can be installed
using pkg commands via a local webserver.  That part all seems to be
functional.  All ports are up-to-date as of 2/16.

I have been attempting to get portmaster to use my local repository
but get a message "Package installation support cannot be used with
pkgng yet, it will be disabled".

I've tried setting PACKAGESITE in portmaster but it pollutes the
environment of pkg commands used by portmaster and generates the
message "pkg: PACKAGESITE in pkg.conf is deprecated. Please create a
repository configuration file". I do have a repository configuration
file and it does work with pkg.

I've read man pages, handbook, wikis, forums, mailing list archives
and googled but cannot seem to get portmaster to work with my repo.
The man pages are good but the rest of the online documents and
references seem to be outdated.

I'd appreciate any pointers to get portmaster playing nicely with my
local repository so I could use a command like "portmaster -P -a"
after doing any UPDATING chores.

Thanks for any input,

Randy

PS - It would be nice to find an audio file on how to pronounce
 poudriere ;-)  I don't remember much from French I studied
 50 years 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: Update for graphics/libopenraw failed

[Randy Pratt]

On Thu, 13 Feb 2014 19:22:25 -0800 (PST)
Robert English  wrote:

> Had a similar problem on my 8.4-Release system. After looking at the 
> "config.log" file, figured out it was looking for 
> "libboost_unit_test_framework_gcc42.so" so I made a soft link in the 
> "usr/local/lib" directory with that name pointing to the 
> "libboost_unit_test_framework.so.1.55.0" file. Libopenraw compiled fine after 
> that.
> 
> Putting this on the server in case someone else has this problem also.
> 
> 
> Bob
> 
> On Feb 10, Randy Pratt wrote:
> >The system is an 8.4-STABLE/i386.
> >
> >Excerpt from the entire http://myfreebsd.homeunix.net/libopenraw-0.0.8_5.log 
> >:
> >
> >checking boost/test/unit_test.hpp presence... yes
> >checking for boost/test/unit_test.hpp... yes
> >checking for the Boost unit_test_framework library... no
> >configure: error: Could not find the flags to link with Boost 
> >unit_test_framework
> >===>  Script "configure" failed unexpectedly.
> >-

I've not used it in some time but libmap.conf comes to mind as the
tool I have used instead of making symlinks for libraries.

I took a different approach.  I found the dependency chain:

  graphics/gimp --> graphics/gegl --> graphics/libopenraw

Gimp was the only port that used libopenraw and I don't use gimp for 
manipulating camera images.

My temporary work around was to remove the OPTION for openraw in
graphics/gegl.  It was necessary to rebuild gegl and gimp to satisfy
pkg_libchk.  Now the trick will be to remember that I did this if
I happened to need to use camera RAW images at some point.

Thanks,

Randy
___
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: can't build gimp-help-en due to missing Sourceforge file

[Randy Pratt]

On Tue, 11 Feb 2014 09:06:43 -0500
Robert Huff  wrote:

> 
>   [I sent mail to the maintainer (cc'ed: here) but had no
> respeonse.  And there's nothing about it in UPDATING.  So ...]
> 
> 
>   While attempting to update to the latest version I get:
> 
> Copying images (en) ... 1605
> *** Making html for en ... 
> I/O error : Attempt to load network entity 
> http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl
> warning: failed to load external entity 
> "http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl";
> compilation error: file stylesheets/plainhtml.xsl line 10 element import
> xsl:import : unable to load 
> http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl
> gmake[1]: *** [html/en/index.html] Error 5
> 
>   Is there something I've failed to update, or even install?
>   What's up, and how does it get fixed?

I also ran into this a week ago and not heard anything back from the maintainer.

I unchecked the OPTION for the Gimp Help manual for now so that I could
finish my update.  Now all I have to do is remember to change it back at the
appropriate time.  For the time being, I'll use the online manual (if needed).

Randy

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

Update for graphics/libopenraw failed

[Randy Pratt]

The system is an 8.4-STABLE/i386.

Excerpt from the entire http://myfreebsd.homeunix.net/libopenraw-0.0.8_5.log :

checking boost/test/unit_test.hpp presence... yes
checking for boost/test/unit_test.hpp... yes
checking for the Boost unit_test_framework library... no
configure: error: Could not find the flags to link with Boost 
unit_test_framework
===>  Script "configure" failed unexpectedly.
-

The libs seem to be there and were were updated:
/usr/local/lib/libboost_unit_test_framework.a
/usr/local/lib/libboost_unit_test_framework.so -> 
libboost_unit_test_framework.so.1.55.0
/usr/local/lib/libboost_unit_test_framework.so.1.55.0
/usr/local/lib/libboost_unit_test_framework.so.5 -> 
libboost_unit_test_framework.so.1.55.0

The entire update log URL is:
http://myfreebsd.homeunix.net/updates/ports/ports-2014.02.09.0606.log

Output of /usr/local/sbin/pkg-static info -g -Ea :
http://myfreebsd.homeunix.net/pkg-info-02.09.txt

I can provide any additional information if needed and do any testing
required.  Any pointers or suggestions to resolve this would be greatly
appreciated.

I've noticed that Firefox won't start due to the interrupted update.  I've
decided that once things get resolved that I'll be using poudriere to
build packages for updating so that I can be reasonably sure that updates
will succeed.

Thanks,

Randy
___
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-Ports-Announce] Time to bid farewell to the old pkg_ tools

[Randy Pratt]

On Wed, 5 Feb 2014 23:26:18 -0800
Kevin Oberman  wrote:

> On Wed, Feb 5, 2014 at 10:45 PM, Matthew Seaman <
> m.sea...@infracaninophile.co.uk> wrote:
> 
> > On 05/02/2014 23:57, Kevin Oberman wrote:
> > > 1. The ports/packages system is not total crap. In fact, at the time jkh
> > > started it, it was far superior to any tool available.
> >
> > When I first encountered the ports, way back in 1998 or so, I was
> > completely mind-blown that something so fantastic could exist.  Yes, it
> > was revolutionary at the time and right where FreeBSD should be --
> > leading the rest of the world with great innovations.
>
> > However, things have changed in the last 16 years. Development of the
> > ports as a global concept has been resting on its laurels a bit, and the
> > rest of the world has caught up, and indeed overtaken.   Partly that was
> > due to the mindset of seeing binary packages as a second-class thing;
> > partly due to the old pkg_tools not providing the scope to implement
> > innovative features; partly due to pkg_tools being part of the FreeBSD
> > base, so impossible to update over reasonable timescales due to the
> > requirement to support older RELEASE branches.
> >
> > pkg(8) addresses those problems, and I hope will do so for at least the
> > next decade.
> >
> > > 5. The introduction of pkgng could have really been handled better and
> > that
> > > probably increased the negative feelings about it. It was also a bit
> > before
> > > it was really ready. It still lacks a few features I feel are quite
> > > important, but they were also missing from the old system.
> >
> > I don't think it's possible to make a change of this magnitude without
> > upsetting anyone.  We have been getting a lot of feedack on the lines of
> > 'Wow! This is great.  When can we have feature XYZ?'  to which we
> > frequently have to reply that XYZ can't be implemented without breaking
> > compatibility with pkg_tools.  Like sub-packages.
> >
> > I'd be interested to hear what features you think are missing.  We will
> > implement anything (eventually...) that there is demand for and that is
> > technically feasible, and that fits with the overall concept of what we
> > think a packaging system should do.  There's a number of ideas in the
> > github issue list already (usually tagged with 'longterm' or 'thinking')
> > and we are happy for people to add to that, or to discuss ideas -- the
> > freebsd-pkg@ list is a good place for that.
> >
> >
> One BIG one that I know is being worked is the capability to mix packages
> and ports effectively.  If you use poudriere, you can roll your own
> packages with custom options and maintain things pretty reasonably, but for
> a single system (or two), this is a bit of overkill. As things stand,  this
> is a real pain to use customized ports and packages from the standard
> FreeBSD distributions. I'm waiting with great excitement for this to
> appear, though I have no idea if it is near or far.
> -- 
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkober...@gmail.com
> 

My experience with mixing ports and packages dates back to 2.2.5 and
the disasters it created.  Most of the problems were created by the
ports tree and package builds not being syncronized.  I switched to
ports exclusively and have not had those problems again.  If a
mechanism existed to svn update a ports tree to the revision level of
the package build I would probably try to use packages for most
and limit building to those ports for which non-default OPTIONS were
employed.  For me, this is the feature that has always been missing.

I recently switched to pkgng and while there is a learning curve I
think it is more versatile and efficient than its predecessor.
Thanks to all who are working to make things better.

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

Re: CFT for cairo 1.12 and 8.x survey

[Randy Pratt]

On Mon, 06 Jan 2014 17:28:58 +0100
Koop Mast  wrote:

> Greetings!
> 
> This is a weird call for testers.
> 
> First off before the real CFT. We are interested if people are still 
> using 8.x for there desktop. Is there a specific reason for not updating 
> to 9.x or 10.x?
> 
> So in our quest for push Xorg on FreeBSD further, we are looking for 
> people to test cairo 1.12 primarily with the old Xorg stack. We know 
> that the graphics with the 2.7.1 intel driver are horribly broken (lots 
> of artifacts) so people don't need to test that, but what is the state 
> of the other xorg video drivers with cairo 1.12? If problems arise after 
> the update, a screenshot and details about installed ports and your 
> hardware should be enough. But if your using the intel driver with old 
> xorg please chime in too, this will give us a beter idea about the user 
> base.

I'm using 8.4-STABLE on a box which has the on-board intel graphics
and uses the xorg-7.7 / xf86-video-intel-2.7.1_6 driver.  It seems to
work reasonably for a fluxbox desktop although I do see occasional
artifacts.  I never expect much from on-board video.

The information at http://bsdstats.org/bt/releases.html might be helpful
since it shows quite a few 8.x users.  I was a little surprised that
the intel driver usage was among the higher numbers (512) for drivers
being reported ( http://bsdstats.org/ports.php?category=93 ).

I'm dragging my feet on updating to 10.x because of the large block of
time needed to rebuild everything or to do a new install.  There's
still some time left before EOL of 8.x ( June 30, 2015 ) so I suspect
that there will be others that are slow to update.  It was only the EOL
of 6.x that pushed me to 8.x.  I tend to live on the trailing-edge ;-)

Randy



___
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: about the Berkeley DB 4 "cleanup"

[Randy Pratt]

On Mon, 16 Dec 2013 07:51:54 -0500
Robert Huff  wrote:

> 
>   [Ref: ports/UPDATING 20131214]
> 
>   I am an indirect user of BDB (currently ver 4.3); "pkg version
> -r" reports
> 
>   redland-1.0.16
>   ruby19-bdb43-0.6.6_1
>   webalizer-geoip-2.23.8
>   php5-5.4.21
>   xmms-1.2.11_20
>   libreoffice-4.0.6_1
>   gramps-3.3.0_2
>   docproj-2.0_1
>   librcc-0.2.12
>   apr-1.4.8.1.5.3
>   apache24-2.4.6_1
>   subversion-1.8.5
>   py27-bsddb-2.7.6_3
>   portupgrade-2.4.11.3,2
> 
> 
>   as being dependant, and I suspect the list will be longer with
> each passing day.
>   While I appreciate the work done to move the universe along,
> the upgrade instructions included (by reference) are partially past
> my understanding and _way_ beyond my comfort zone.  (And I suspect
> I'm not alone.)
>   So: what explodes if I simply set "WITH_BDB_VER=5", shutdown my
> services, and rebuild?
>   Alternately: does someone whose comfort zone this is well
> within) have a script that will take care of things?

I've got a similar list of dependencies but only subversion and
apr actually use BDB.  The rest seem to be dependencies on apr.

I went a step further and set "WITH_BDB_VER=5" in /etc/make.conf and
proceeded to update.  At the end, I still had db42-4.2.52_5.  I
suspect it was because that neither apr or subversion needed updated.

I'm not sure if I should switch the origin of BDB for involved ports,
do forced rebuild of a few ports or if doing a recursive update is
needed.  Some additional direction would be much appreciated.

My eyes glazed over trying to read the Wiki link to updating since
I don't know database vocabulary so you're not alone ;-)

Randy




___
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: Get ports tree of the current pkgng repository

[Randy Pratt]

On Fri, 17 Aug 2012 06:25:36 +0300
Kimmo Paasiala  wrote:

> On Thu, Aug 16, 2012 at 10:56 PM, Michael Schnell  wrote:
> > Hi,
> > I don't know if this came up already, but not as far as I know. So, I
> > was thinking it would be nice to add a mechanism to pkgng, which enables
> > the user to get the ports tree corresponding to the current repository.
> >
> > At least I've the problem that I really like the idea of the pkgng
> > system, but I need a few custom build packages. For instance rawtherapee
> > is not working for me with OpenMP, so I have to disable it to get it
> > working, or I made some patches for openbox, which of course then needs
> > to be compiled. In order to get not in conflict with a more recent
> > ports tree the exact version of the repository build would be nice.
> >
> > At the moment I can think of two ways to implement it. The easiest way
> > would be to add the ports tree as a packages into the repository. A more
> > complicated thing is to add a mechanism to portsnap synchronised with
> > the pkgng system to direct fetch it, or at least a revision number of
> > the current repo, so you can check it out of the subversion.
> >
> > How do you guys feel about this?
> >
> >
> > Greetings
> > Michael
> >
> 
> Why not just include the SVN revision of the ports tree that was used
> to create the packages in the package metadata?

I asked this same question about syncronizing the ports tree with CVS
a long time ago.  At the time it seemed that manual tweaking was done
to get the packages built so there was no actual tree that matched
the package repository.  I hope this is no longer the case since mixing
ports and packages is likely to cause some mismatch eventually if there
is no syncronization.

I quit using packages because of this over ten years ago.  I'd like to
see a way to easily be able to mix building ports and using packages
without problems.

Randy
___
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: installed ports dependency tree?

[Randy Pratt]

On Sun, 1 Feb 2009 22:48:37 -0500
Robert Huff  wrote:

>   Suppose I have installed ports A..Z.  Some of these are
> standakone; some depend on others on the list; others depend on
> installed ports not on the list.
>   Is there a port that will produce a unified and ordered
> dependency list, such that upgrading/reinstalling in that order will
> avoid multiple rebuilds?  I though portupgrade could to this, but
> apparently not.

Portupgrade installs several pkg_* tools [1].  The pkg_glob and
pkg_sort tools might be what you're looking for.  Here's an
example:

  pkg_glob [package names] | pkg_sort

This produces a list for update order.  The man pages are quite
helpful for the pkg_* tools.

HTH,

Randy


[1]  Run "pkg_info -L portupgrade-\*" to see the complete packing
 list for portupgrade.
___
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: php5-5.2.7 commit mail missing from cvs-ports list

[Randy Pratt]

On Sun, 07 Dec 2008 18:46:03 -0500
Joseph Gelinas <[EMAIL PROTECTED]> wrote:

> Randy Pratt wrote:
> > I follow the cvs-ports mailing list and noticed that the
> > recent commit for php5-5.2.7 never showed up on the
> > list:
> > 
> >   http://docs.freebsd.org/mail/current/cvs-ports.html
> > 
> > The cvsweb shows the commit as expected.
> > 
> > I also checked the cvs-all mailing list but the php update
> > is not listed there either.
> > 
> > Any ideas as to why its missing?  Its not a big thing but I've
> > come to rely on the cvs-ports list for commits that affect my
> > installed ports.
> > 
> > Randy
> 
> It is not missing. You may not have noticed it because the subject 
> starts with MOVED etc.
> 
> http://docs.FreeBSD.org/cgi/mid.cgi?200812071154.mB7Bsa5o058919

Doh! ;-)  I didn't catch the truncation in the summary list.

I'll have to pay closer attention in the future.

My apologies for the noise.  I'll go back to my corner now.

Randy



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

php5-5.2.7 commit mail missing from cvs-ports list

[Randy Pratt]

I follow the cvs-ports mailing list and noticed that the
recent commit for php5-5.2.7 never showed up on the
list:

  http://docs.freebsd.org/mail/current/cvs-ports.html

The cvsweb shows the commit as expected.

I also checked the cvs-all mailing list but the php update
is not listed there either.

Any ideas as to why its missing?  Its not a big thing but I've
come to rely on the cvs-ports list for commits that affect my
installed ports.

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

Re: x11-wm/fluxbox fluxbox-generate_menu lists all available programs.

[Randy Pratt]

On Mon, 22 Sep 2008 14:16:35 -0500
"Jeremy Messenger" <[EMAIL PROTECTED]> wrote:

> I agree for 'which' is best thing to do. Not all shells (csh, see in  
> builtin(1)) have 'hash' stuff. I have bring all of hash -> which stuff  
>  from 1.0.0, so let me know patches work for you.
> 
> http://people.freebsd.org/~mezz/diff/patch-util%3a%3afluxbox-generate_menu.in
> http://people.freebsd.org/~mezz/diff/patch-util_fbsetbg
> 
> Put those files in x11-wm/fluxbox/files/ and reinstall fluxbox.

The patch-util_fbsetbg fixed the inability to set backgrounds.  I had
almost forgotten about this minor problem.

The fluxbox-generate_menu.in patch results in an improved function
but I recommend users backup their ~/.fluxbox in case it does
something odd (I have a highly customized menu).

Thanks again for fluxbox patches ;-)

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

Re: Stop in /usr/ports/sysutils/php5-posix.

[Randy Pratt]

On Thu, 04 Sep 2008 17:38:52 +0200
Miroslav Lachman <[EMAIL PROTECTED]> wrote:

> Morgan Wesström wrote:
> > Portaudit has complained for a few days about vulnerabilities in 
> > sysutils/php5-posix but there seems to be no update yet. When I now try 
> > to recompile all my ports with portmaster it stops with an error when it 
> > reaches this port.
> > 
> > ===>  php5-posix-5.2.6_1 has known vulnerabilities:
> > => php -- input validation error in posix_access function.
> >Reference: 
> > 
> >  
> > 
> > => Please update your ports tree and try again.
> > *** Error code 1
> > 
> > 
> > How do I continue? Is there anyway I can force portmaster to skip this 
> > port and continue where it left off or do I have to deinstall it and 
> > recompile everything all over again?
>
> You can recompile / install vulnerable applications by giving portmaster 
>option: -m "DISABLE_VULNERABILITIES=yes".
> !!You are using it at your own risk!!

I also use this option for all of my port updating.  I figure that
updating to a newer version "probably" won't make the security
any worse if I've already got a vulnerable application.

> If you don't need php5-posix, it is better to deinstall it and uncheck 
> from php5-extensions (with `make config` in /usr/ports/lang/php5-extensions)

Actually, I think a fix was just committed:

  http://docs.freebsd.org/cgi/mid.cgi?200809041355.m84DtBLn072467

So give it a little time for propagation, then re-csup and try it
again.  

HTH,

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

Re: Core dump using csup to update ports tree

[Randy Pratt]

On Sat, 12 Jul 2008 15:21:09 -0400
Boris Kochergin <[EMAIL PROTECTED]> wrote:

> Randy Pratt wrote:
> > On Sat, 12 Jul 2008 10:23:07 -0700
> > "Garrett Cooper" <[EMAIL PROTECTED]> wrote:
> >
> >   
> >> On Sat, Jul 12, 2008 at 7:47 AM, Randy Pratt <[EMAIL PROTECTED]> wrote:
> >> 
> >>> On Sat, 12 Jul 2008 07:26:36 -0700
> >>> Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> >>>
> >>>   
> >>>> On Sat, Jul 12, 2008 at 10:00:25AM -0400, Randy Pratt wrote:
> >>>> 
> >>>>> Later, I retried cvsup5.us.freebsd.org and was not able to duplicate
> >>>>> the core dump.  I do have the core dump if its of any use:
> >>>>>
> >>>>>   http://myfreebsd.homeunix.net/csup.core
> >>>>>   
> >>>> Can you provide a backtrace with this core?
> >>>>
> >>>> $ gdb /usr/bin/csup csup.core
> >>>> ...
> >>>> (gdb) bt full
> >>>> 
> >>> # gdb /usr/bin/csup csup.core
> >>> GNU gdb 6.1.1 [FreeBSD]
> >>> Copyright 2004 Free Software Foundation, Inc.
> >>> GDB is free software, covered by the GNU General Public License, and
> >>> you are welcome to change it and/or distribute copies of it under
> >>> certain conditions. Type "show copying" to see the conditions.
> >>> There is absolutely no warranty for GDB.  Type "show warranty" for
> >>> details. This GDB was configured as "i386-marcel-freebsd"...(no
> >>> debugging symbols found)... Core was generated by `csup'.
> >>> Program terminated with signal 11, Segmentation fault.
> >>> Reading symbols from /lib/libcrypto.so.4...(no debugging symbols
> >>> found)...done. Loaded symbols for /lib/libcrypto.so.4
> >>> Reading symbols from /lib/libz.so.3...(no debugging symbols
> >>> found)...done. Loaded symbols for /lib/libz.so.3
> >>> Reading symbols from /lib/libpthread.so.2...(no debugging symbols
> >>> found)...done. Loaded symbols for /lib/libpthread.so.2
> >>> Reading symbols from /lib/libc.so.6...(no debugging symbols
> >>> found)...done. Loaded symbols for /lib/libc.so.6
> >>> Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
> >>> found)...done. Loaded symbols for /libexec/ld-elf.so.1
> >>> #0  0x281b3677 in pthread_testcancel () from /lib/libpthread.so.2
> >>> [New Thread 0x8066600 (LWP 100197)]
> >>> [New Thread 0x8066000 (runnable)]
> >>> [New LWP 100198]
> >>> (gdb) bt full
> >>> #0  0x281b3677 in pthread_testcancel () from /lib/libpthread.so.2
> >>> No symbol table info available.
> >>> #1  0x281abaaa in pthread_mutexattr_init () from /lib/libpthread.so.2
> >>> No symbol table info available.
> >>> #2  0x2808d450 in ?? ()
> >>> No symbol table info available.
> >>> (gdb) q
> >>> #
> >>>
> >>> Thanks for the interest and response,
> >>>
> >>> Best regards,
> >>>
> >>> Randy
> >>>   
> >> Randy,
> >>   Did you build csup yourself or did it come prepackaged with the
> >> base system? If the former, please recompiling csup with CFLAGS=-g (as
> >> well as your current CFLAGS) and then repost your results.
> >>   Also, please provide your CFLAGS (and any other compile flag
> >> variables) as a sidenote.
> >> 
> >
> > Its the csup built with the base system.  The only thing of
> > consequence in /etc/make.conf is:
> >
> >   CFLAGS= -O -pipe
> >   NO_PROFILE=true# Avoid compiling profiled libraries
> >
> > I can see where the additional debugging symbols might be useful
> > *if* it happens again.  I can't reproduce it on demand.
> >
> > How would I rebuild the base csup to use the -g or would it be
> > better to switch to the ports csup version and do it there?
> >
> > Thanks,
> >
> > Randy
> >   
> You can change your CFLAGS in /etc/make.conf to "-g -pipe", cd into 
> /usr/src/usr.bin/csup, "make", and "make install".

Thanks!  I preceeded the rebuild with a make clean.  Perhaps I can
provide a more useful backtrace when/if it happens again.

Randy


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

Re: Core dump using csup to update ports tree

[Randy Pratt]

On Sat, 12 Jul 2008 10:23:07 -0700
"Garrett Cooper" <[EMAIL PROTECTED]> wrote:

> On Sat, Jul 12, 2008 at 7:47 AM, Randy Pratt <[EMAIL PROTECTED]> wrote:
> > On Sat, 12 Jul 2008 07:26:36 -0700
> > Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> >
> >> On Sat, Jul 12, 2008 at 10:00:25AM -0400, Randy Pratt wrote:
> >> > Later, I retried cvsup5.us.freebsd.org and was not able to duplicate
> >> > the core dump.  I do have the core dump if its of any use:
> >> >
> >> >   http://myfreebsd.homeunix.net/csup.core
> >>
> >> Can you provide a backtrace with this core?
> >>
> >> $ gdb /usr/bin/csup csup.core
> >> ...
> >> (gdb) bt full
> >
> > # gdb /usr/bin/csup csup.core
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and
> > you are welcome to change it and/or distribute copies of it under
> > certain conditions. Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details. This GDB was configured as "i386-marcel-freebsd"...(no
> > debugging symbols found)... Core was generated by `csup'.
> > Program terminated with signal 11, Segmentation fault.
> > Reading symbols from /lib/libcrypto.so.4...(no debugging symbols
> > found)...done. Loaded symbols for /lib/libcrypto.so.4
> > Reading symbols from /lib/libz.so.3...(no debugging symbols
> > found)...done. Loaded symbols for /lib/libz.so.3
> > Reading symbols from /lib/libpthread.so.2...(no debugging symbols
> > found)...done. Loaded symbols for /lib/libpthread.so.2
> > Reading symbols from /lib/libc.so.6...(no debugging symbols
> > found)...done. Loaded symbols for /lib/libc.so.6
> > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
> > found)...done. Loaded symbols for /libexec/ld-elf.so.1
> > #0  0x281b3677 in pthread_testcancel () from /lib/libpthread.so.2
> > [New Thread 0x8066600 (LWP 100197)]
> > [New Thread 0x8066000 (runnable)]
> > [New LWP 100198]
> > (gdb) bt full
> > #0  0x281b3677 in pthread_testcancel () from /lib/libpthread.so.2
> > No symbol table info available.
> > #1  0x281abaaa in pthread_mutexattr_init () from /lib/libpthread.so.2
> > No symbol table info available.
> > #2  0x2808d450 in ?? ()
> > No symbol table info available.
> > (gdb) q
> > #
> >
> > Thanks for the interest and response,
> >
> > Best regards,
> >
> > Randy
> 
> Randy,
>   Did you build csup yourself or did it come prepackaged with the
> base system? If the former, please recompiling csup with CFLAGS=-g (as
> well as your current CFLAGS) and then repost your results.
>   Also, please provide your CFLAGS (and any other compile flag
> variables) as a sidenote.

Its the csup built with the base system.  The only thing of
consequence in /etc/make.conf is:

  CFLAGS= -O -pipe
  NO_PROFILE=true# Avoid compiling profiled libraries

I can see where the additional debugging symbols might be useful
*if* it happens again.  I can't reproduce it on demand.

How would I rebuild the base csup to use the -g or would it be
better to switch to the ports csup version and do it there?

Thanks,

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

Re: Core dump using csup to update ports tree

[Randy Pratt]

On Sat, 12 Jul 2008 07:26:36 -0700
Jeremy Chadwick <[EMAIL PROTECTED]> wrote:

> On Sat, Jul 12, 2008 at 10:00:25AM -0400, Randy Pratt wrote:
> > Later, I retried cvsup5.us.freebsd.org and was not able to duplicate
> > the core dump.  I do have the core dump if its of any use:
> > 
> >   http://myfreebsd.homeunix.net/csup.core
> 
> Can you provide a backtrace with this core?
> 
> $ gdb /usr/bin/csup csup.core
> ...
> (gdb) bt full

# gdb /usr/bin/csup csup.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions. Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details. This GDB was configured as "i386-marcel-freebsd"...(no
debugging symbols found)... Core was generated by `csup'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypto.so.4...(no debugging symbols
found)...done. Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/libz.so.3...(no debugging symbols
found)...done. Loaded symbols for /lib/libz.so.3
Reading symbols from /lib/libpthread.so.2...(no debugging symbols
found)...done. Loaded symbols for /lib/libpthread.so.2
Reading symbols from /lib/libc.so.6...(no debugging symbols
found)...done. Loaded symbols for /lib/libc.so.6
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
found)...done. Loaded symbols for /libexec/ld-elf.so.1
#0  0x281b3677 in pthread_testcancel () from /lib/libpthread.so.2
[New Thread 0x8066600 (LWP 100197)]
[New Thread 0x8066000 (runnable)]
[New LWP 100198]
(gdb) bt full
#0  0x281b3677 in pthread_testcancel () from /lib/libpthread.so.2
No symbol table info available.
#1  0x281abaaa in pthread_mutexattr_init () from /lib/libpthread.so.2
No symbol table info available.
#2  0x2808d450 in ?? ()
No symbol table info available.
(gdb) q
#

Thanks for the interest and response,

Best regards,

Randy

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

Core dump using csup to update ports tree

[Randy Pratt]

6.3-STABLE FreeBSD 6.3-STABLE #0: Sat Apr 19 07:46:18 EDT 2008

>From my logfile:

===>>> Previous CVS checkout date: Fri Jul 11 08:46:00 UTC 2008
===>>> CVS Server: cvsup5.us.freebsd.org
===>>> Ports tree update start: 07/12/2008 06:00
Parsing supfile "/root/supfiles/ports-supfile"
Connecting to cvsup5.us.freebsd.org
Connected to 208.83.20.14
Server software version: SNAP_16_1h
Negotiating file attribute support
Exchanging collection information
Establishing multiplexed-mode data connection
Running
Receiver: Connection reset by peer
Will retry at 06:05:52
Retrying
Connected to 208.83.20.14
Server software version: SNAP_16_1h
Negotiating file attribute support
Exchanging collection information
Segmentation fault (core dumped)

I switched to cvsup2.us.freebsd.org and csup updated my tree without
a problem.  I've not updated the base since April and had no problems
prior to today.

Later, I retried cvsup5.us.freebsd.org and was not able to duplicate
the core dump.  I do have the core dump if its of any use:

  http://myfreebsd.homeunix.net/csup.core

I've been reading some of the thread regarding a core dump with
cvsup but the only thing I see in common is that both involve the
server-side of updating. It may, of course, be a red herring.

Since I can't seem to duplicate the core dump on demand, it would
seem that its very subtle.  I can't force a "Connection reset by
peer" so I'm not sure if that's relevant or not.  Those resets
were not happening during my duplication efforts.

I can't think of anything to pursue at this point other than to
continue as usual and watch for a repeat.

Randy


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

Re: Interaction between port OPTIONS and /usr/bin/tee

[Randy Pratt]

On Fri, 29 Feb 2008 10:09:25 -0500
Wesley Shields <[EMAIL PROTECTED]> wrote:
> You never mention which version of FreeBSD you are using.  My money is
> on ncurses changes, though it's hard to tell until we know what you are
> using.
> 
> I can see similar behavior on a current box from a few days ago.  My
> guess is this won't happen on 6.2-RELEASE?

My bad.. I should have mentioned it:

FreeBSD kt.weeeble.com 6.3-STABLE FreeBSD 6.3-STABLE #0: Thu Feb 14
16:02:22 EST 2008

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

Interaction between port OPTIONS and /usr/bin/tee

[Randy Pratt]

I run a script to update ports which uses /usr/bin/tee to do some
logging of the process.  This has worked for a very long time (years)
but sometime in the past week(s) or so something has changed when
an OPTIONS screen displays and "tee" is being employed.

I cannot use TAB to get to the OK button.  The TAB key cause the
cursor to go to the next word to the right.  The UP/DOWN arrows
are also misbehaving.  I'm sure this is hard to visualize but a
short script shows the new(?) behavior:

===
#!/bin/sh
logfile="~/test_interaction.log"
cd /usr/ports/multimedia/mplayer
make config | tee /dev/tty >> ${logfile}
===

Once you see the resulting action, just ctrl-c to exit and leave
the OPTIONS settings unchanged.  You may need to issue a "reset"
command to restore the xterm to normal colors.

Any port that uses the OPTIONS framework can be substituted and
produce the same results.

I thought perhaps it was a recent change to xterm behavior but I
portdowngraded to xterm-228 and the behavior was the same.  The
last time it appeared to work correctly was on 2-16-2008 when the
"Options for sox 14.0.1" screen was displayed.  I last
updated sources on 2-18-2008 if that has any bearing on it.  

I understand that logging the output of an OPTIONS selection 
produces a bizzare log entry but its not been a problem in the
past when it was just another part of the port update process.

Anyone have any ideas what's happening here?  I don't think I'm
misapplying the use of "tee".

Thanks,

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

Re: Portmaster and added dependencies

[Randy Pratt]

On Sat, 23 Feb 2008 16:26:53 -0500
Wesley Shields <[EMAIL PROTECTED]> wrote:

> On Sat, Feb 23, 2008 at 03:59:11PM -0500, Randy Pratt wrote:
> > I've been using portmaster for a couple of weeks and like what I've
> > seen.  However, I'm a bit confused on how dependencies changes are to
> > be handled.  Here's a scenario:
> > 
> > Events:
> > 
> > 2008.02.17 01:50:08 UTC  devel/p5-ExtUtils-CBuilder: update to 0.22
> > 
> > 2008.02.17 11:00:00 UTC  update ports and devel/p5-ExtUtils-CBuilder
> >  was updated 
> > 
> > 2008.02.19 05:33:50 UTC  devel/p5-ExtUtils-CBuilder: Add missing deps
> >  ports/120802 (textproc/p5-Text-ParseWords was
> >  added as a build/run dependency)
> 
> Snipped the rest because I think this could have all been avoided by
> bumping PORTREVISION when the dependency to p5-Text-ParseWords was
> added.  Ideally the dependency information should have been recorded
> with the update to 0.22 (like is in ports/120802).  I'm CC'ing leeym@
> who made the last commit.

It would have been far easier that way of course but this isn't the
first time a dependency change has been made to some port without
bumping PORTREVISION and probably won't be the last.  This situation
only existed for a couple of days and affected only those who updated
during the interim.

What I'm really looking for is the portmaster equivalent of
portupgrade's "pkgdb -L" to look for lost dependencies so I can
check all the installed ports dependency chains.

Thanks,

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

Portmaster and added dependencies

[Randy Pratt]

I've been using portmaster for a couple of weeks and like what I've
seen.  However, I'm a bit confused on how dependencies changes are to
be handled.  Here's a scenario:

Events:

2008.02.17 01:50:08 UTC  devel/p5-ExtUtils-CBuilder: update to 0.22

2008.02.17 11:00:00 UTC  update ports and devel/p5-ExtUtils-CBuilder
 was updated 

2008.02.19 05:33:50 UTC  devel/p5-ExtUtils-CBuilder: Add missing deps
 ports/120802 (textproc/p5-Text-ParseWords was
 added as a build/run dependency)

I have been running the command in my daily port updates:

  portmaster -d -w -m DISABLE_VULNERABILITIES=yes -a

but it never picked up the added dependency since it is already up
to date.  The man page seems to indicate that the dependency check
will be skipped if the port is up-to-date.  Running:

  portmaster --check-depends

didn't seem do do anything (because all ports were up-to-date?).

I decided to just update p5-ExtUtils-CBuilder-0.22 and it did
catch the added dependency of p5-Text-ParseWords.  Checking what
depends on p5-Text-ParseWords:

  # pkg_info -R p5-Text-ParseWords-\*
  Information for p5-Text-ParseWords-3.1:

  Required by:
  p5-ExtUtils-CBuilder-0.22

On this system I have 3 ports which depend on p5-ExtUtils-CBuilder:

  # pkg_info -R p5-ExtUtils-CBuilder-0.22
  Information for p5-ExtUtils-CBuilder-0.22:

  Required by:
  p5-ExtUtils-ParseXS-2.19
  p5-Module-Build-0.28.08
  txt2html-2.50

Finally, I just did a recursive update of p5-ExtUtils-CBuilder:

  portmaster -r p5-ExtUtils-CBuilder-0.22

and that gave me what I expected to see:

  # pkg_info -R p5-Text-ParseWords-\*
  Information for p5-Text-ParseWords-3.1:

  Required by:
  p5-ExtUtils-CBuilder-0.22
  p5-ExtUtils-ParseXS-2.19
  p5-Module-Build-0.28.08
  txt2html-2.50

I got to where I think I should be but obviously, I'm not doing
exactly the right thing for the portmaster command to always pick
up these added and/or removed dependencies.  I tried to use the
'-t' but it didn't seem to make any difference.

I've reread the man page but I still don't seem to see what I
need to do so that I don't have to chase down these little things.
Suggestions?

Thanks,

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

Re: portupgrade-devel: 2 feature requests

[Randy Pratt]

On Thu, 14 Feb 2008 11:46:10 -0500
"Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> How hard would it be to add the following to portupgrade-devel:
> 
> 1. Progress report for -a builds (i.e. after and/or at the start of a 
> port build it says how many ports are left to be processed)

I think this information exists while a port is being updated:

  ps -auxww | grep "ruby"

You will probably get several lines of processes but one of which
will say something like [10/25] indicating that its working on
the tenth one of 25 total.  This may only exist in later versions
of portupgrade.

Its possible to create your own database of port build times by
creating a list of ports to be updated and running it thru
pkg_sort so that they are in correct dependency order, then
using /usr/bin/time you can build each port individually and record
each port's build time (seconds) in some flat file, for ex:

  devel/glib20|140.85
  devel/gmake|45.16
  devel/gnome-vfs|289.34
  devel/gnomevfs2|338.94
  devel/libIDL|50.06
  devel/libbonobo|162.98
  devel/libglade2|81.53

It would be more accurate than any build times from someone else
since it would be based on your machine's environment.

I went all the way and used Xdialog to display a progress bar and
other such frills.

In the end, I stopped bothering since it added needless complexity to
the process and it still took however long it takes to finish.

Randy




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

Re: qiv quits with Gdk-ERROR on FreeBSD 6.3

[Randy Pratt]

On Fri, 25 Jan 2008 07:56:25 -0500
Randy Pratt <[EMAIL PROTECTED]> wrote:

> On Fri, 25 Jan 2008 03:19:17 +0100
> Martin Tournoij <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, Jan 24, 2008 at 08:19:26PM -0500, Randy Pratt wrote:
> > > On Thu, 24 Jan 2008 23:38:59 +0100
> > > Boris Hollas <[EMAIL PROTECTED]> wrote:
> > > 
> > > > I invoked qiv (quick image viewer) on an image file and got the 
> > > > following message:
> > > > 
> > > > Gdk-ERROR **: BadMatch (invalid parameter attributes)
> > > >   serial 115 error_code 8 request_code 2 minor_code 0
> > > > 
> > > > I installed qiv-2.0_2 from package on FreeBSD 6.3.
> > > > 
> > > > On 6.1, I've used qiv without any problems.
> > > 
> > > I switched to using a qiv development version (2.1) and this problem 
> > > doesn't seem to exist there.
> > 
> > Update to 2.1pre12:
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=119958
> > 
> > Please report if this version works for you.
> 
> I made a clean install using the patch in PR119958.  It displays
> images but it gives the following messages when run from the
> command line:
> 
> $ qiv *.png
> IMLIB ERROR: SHM can't get SHM Identifier for Shared Pixmap Wrapper
>  Falling back on Shared XImages
> IMLIB ERROR: SHM can't get SHM Identifier for Shared XImage
>  Falling back on XImages

I did a little more investigating and the above error only seems
to happen for interlaced images, for example:

  freebsd-bikeshed.png: PNG image data, 3336 x 3666, 8-bit colormap,
  interlaced

I put this image at:

  http://myfreebsd.homeunix.net/freebsd-bikeshed.png

Converting the image to non-interlaced does not produce the imlib
error.

This same imlib error message exists in the qiv-2.0_2 version so its
not new.

The PR-119958 version works and is an improvement over the one in
the tree.

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

Re: qiv quits with Gdk-ERROR on FreeBSD 6.3

[Randy Pratt]

On Fri, 25 Jan 2008 03:19:17 +0100
Martin Tournoij <[EMAIL PROTECTED]> wrote:

> On Thu, Jan 24, 2008 at 08:19:26PM -0500, Randy Pratt wrote:
> > On Thu, 24 Jan 2008 23:38:59 +0100
> > Boris Hollas <[EMAIL PROTECTED]> wrote:
> > 
> > > I invoked qiv (quick image viewer) on an image file and got the following 
> > > message:
> > > 
> > > Gdk-ERROR **: BadMatch (invalid parameter attributes)
> > >   serial 115 error_code 8 request_code 2 minor_code 0
> > > 
> > > I installed qiv-2.0_2 from package on FreeBSD 6.3.
> > > 
> > > On 6.1, I've used qiv without any problems.
> > 
> > I switched to using a qiv development version (2.1) and this problem 
> > doesn't seem to exist there.
> 
> Update to 2.1pre12:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=119958
> 
> Please report if this version works for you.

I made a clean install using the patch in PR119958.  It displays
images but it gives the following messages when run from the
command line:

$ qiv *.png
IMLIB ERROR: SHM can't get SHM Identifier for Shared Pixmap Wrapper
 Falling back on Shared XImages
IMLIB ERROR: SHM can't get SHM Identifier for Shared XImage
 Falling back on XImages

I have both imlib-1.9.15_5 and imlib2-20070223_1,1 installed and
the configure found:

 qiv-2.1pre12 depends on shared library: Imlib.5 - found

# pkg_which /usr/local/lib/libImlib.so.5
imlib-1.9.15_5

If more information or testing is needed, just ask.

Thanks,

Randy

(FreeBSD 6.3-PRERELEASE #0: Tue Jan 15 10:33:13 EST 2008)
-- 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: qiv quits with Gdk-ERROR on FreeBSD 6.3

[Randy Pratt]

On Thu, 24 Jan 2008 23:38:59 +0100
Boris Hollas <[EMAIL PROTECTED]> wrote:

> I invoked qiv (quick image viewer) on an image file and got the following 
> message:
> 
> Gdk-ERROR **: BadMatch (invalid parameter attributes)
>   serial 115 error_code 8 request_code 2 minor_code 0
> 
> I installed qiv-2.0_2 from package on FreeBSD 6.3.
> 
> On 6.1, I've used qiv without any problems.

I got the same thing when using that version of qiv.  Try setting
your environment with: 

XLIB_SKIP_ARGB_VISUALS=1

See the Handbook section on "Shells" if you need some hints on
setting the environment with your particular shell:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/shells.html

I switched to using a qiv development version (2.1) and this problem 
doesn't seem to exist there.

HTH,

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

Re: Xorg initial resolution broken

[Randy Pratt]

On Sun, 14 Oct 2007 08:10:25 +0100
Mark Knight <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>, "[LoN]Kamikaze"
> <[EMAIL PROTECTED]> writes
> >Mark Knight wrote:
> >> Just restarted X after various Xorg updates.  Now the server seems to be
> >> completely ignoring the "Modes" line in the config file's Screen/Display
> >> section and picking its own initial resolution.
> >>
> >> No problem switching to the desired resolution later on when logged in.
> >>
> >> Config and log files here:
> >>
> >>   http://www.knigma.org.uk/scratch/resolution.txt
> >>
> >> This configuration has worked for years so I'm sure it's down to the
> >> Xorg update.  Any ideas please?
> >>
> >> Cheers,
> >
> >Set PreferredMode and check for the Virtual screen size in the log, you might
> >have to increase that to.
> 
> Thanks for the tips.
> 
> Setting PreferredMode caused the X server to lockup during start-up
> before switching out of text mode and requiring kill -9, until I removed
> my HorizSync and VertRefresh lines.
> 
> Tried with X -configure afresh and achieved the same effect.
> 
> With DDC and without HorizSync and VertRefresh lines PreferredMode is
> working but I'm having to use a lower refresh and I've lost the highest
> resolution my monitor displays.
> 
> So for me the choice seems to be:
> 
>   - stick with my old config and sort out resolution when I log in
> 
>   - accept lower refresh (75Hz) and lower max resolution (rarely used it
> anyway), and use PreferredMode

I'm having the same default resolution (1280x1024) problem using the
updated xf86-video-mga-1.9.100 driver and additionally am unable to
switch modes using the ctrl-alt-keypad +/- keys (Option "Dont Zoom"
_is_ disabled).

I reverted to the xf86-video-mga-1.4.7 driver and the desktop is
my normal 1024x768 resolution and the mode switch keys work.  Alas,
as my eyes age, the higher resolutions are unreadable.

Are you perhaps using the xf86-video-mga driver?  If so, reverting
to the older version may be another temporary workaround.

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

Re: ImageMagick

[Randy Pratt]

On Thu, 27 Sep 2007 17:39:31 +0200
Christopher Illies <[EMAIL PROTECTED]> wrote:

> On Thu, Sep 27, 2007 at 09:34:58AM -0400, Randy Pratt wrote:
> > On Thu, 27 Sep 2007 14:44:21 +0200
> > Christopher Illies <[EMAIL PROTECTED]> wrote:
> > 
> > > On Thu, Sep 27, 2007 at 11:21:02AM +0200, Johan Hendriks wrote:
> > > > I can not update Image Magick on all of my machines.
> > > > This is on 6.2 and 6.1
> > > >  
> > > > it errors out with the following error:
> > > [...]
> > > 
> > > I had the same error. Now I switched SVG format support on and it
> > > passes the tests.
> > 
> > I tried turning on the SVG format and it still fails.  Could you
> > show the output of your "make showconfig" for ImageMagick?
> > 
> > Mine is:
> >  X11=on "X11 support"
> >  IMAGEMAGICK_TESTS=on "Run bundled self-tests after build"
> >  IMAGEMAGICK_PERL=on "Perl support"
> >  IMAGEMAGICK_MODULES=off "Modules support (broken)"
> >  IMAGEMAGICK_BZLIB=on "Bzlib support"
> >  IMAGEMAGICK_16BIT_PIXEL=on "16bit pixel support"
> >  IMAGEMAGICK_LCMS=on "LCMS support"
> >  IMAGEMAGICK_TTF=on "Freetype support"
> >  IMAGEMAGICK_FONTCONFIG=on "Fontconfig support"
> >  IMAGEMAGICK_JPEG=on "JPG format support"
> >  IMAGEMAGICK_PNG=on "PNG format support"
> >  IMAGEMAGICK_TIFF=on "TIFF format support"
> >  IMAGEMAGICK_FPX=on "FPX format support"
> >  IMAGEMAGICK_JBIG=on "JBIG format support"
> >  IMAGEMAGICK_JPEG2000=on "JPEG2000 format support"
> >  IMAGEMAGICK_DOT=off "GraphViz dot graphs support"
> >  IMAGEMAGICK_WMF=off "WMF format support"
> >  IMAGEMAGICK_SVG=on "SVG format support"
> >  IMAGEMAGICK_PDF=on "PDF format support"
> >  IMAGEMAGICK_MPEG2=on "MPEG2 format support"
> >  IMAGEMAGICK_GSLIB=off "libgs (Postscript SHLIB) support"
> > 
> > There has been a PR 116682 filed and a thread started on: 
> > 
> > http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=9782
> > 
> > The developers can't reproduce the failure we're seeing.
> > 
> > Thanks,
> > 
> > Randy
> > -- 
> 
> Here it is:
> $ make showconfig
> ===> The following configuration options are available for
> ImageMagick-6.3.5.10:
>  X11=on "X11 support"
>  IMAGEMAGICK_TESTS=on "Run bundled self-tests after build"
>  IMAGEMAGICK_PERL=off "Perl support"
>  IMAGEMAGICK_MODULES=off "Modules support (broken)"
>  IMAGEMAGICK_BZLIB=on "Bzlib support"
>  IMAGEMAGICK_16BIT_PIXEL=on "16bit pixel support"
>  IMAGEMAGICK_LCMS=on "LCMS support"
>  IMAGEMAGICK_TTF=on "Freetype support"
>  IMAGEMAGICK_FONTCONFIG=on "Fontconfig support"
>  IMAGEMAGICK_JPEG=on "JPG format support"
>  IMAGEMAGICK_PNG=on "PNG format support"
>  IMAGEMAGICK_TIFF=on "TIFF format support"
>  IMAGEMAGICK_FPX=on "FPX format support"
>  IMAGEMAGICK_JBIG=on "JBIG format support"
>  IMAGEMAGICK_JPEG2000=on "JPEG2000 format support"
>  IMAGEMAGICK_DOT=off "GraphViz dot graphs support"
>  IMAGEMAGICK_WMF=off "WMF format support"
>  IMAGEMAGICK_SVG=on "SVG format support"
>  IMAGEMAGICK_PDF=on "PDF format support"
>  IMAGEMAGICK_MPEG2=on "MPEG2 format support"
>  IMAGEMAGICK_GSLIB=off "libgs (Postscript SHLIB) support"
> ===> Use 'make config' to modify these settings
> $
> 
> And as I see now, I also turned off Perl support. Probably that did
> it. Sorry about the confusion.

I turned off IMAGEMAGICK_PERL and it does complete with or without
IMAGEMAGICK_SVG support and IMAGEMAGICK_TESTS on.  I'm not sure how
this affects the port or its capabilities.  It may help someone track
down the cause. Its beyond my meager abilities bit I'm willing to do
testing.

Thanks for the clarification,

Randy



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

Re: ImageMagick

[Randy Pratt]

On Thu, 27 Sep 2007 14:44:21 +0200
Christopher Illies <[EMAIL PROTECTED]> wrote:

> On Thu, Sep 27, 2007 at 11:21:02AM +0200, Johan Hendriks wrote:
> > I can not update Image Magick on all of my machines.
> > This is on 6.2 and 6.1
> >  
> > it errors out with the following error:
> [...]
> 
> I had the same error. Now I switched SVG format support on and it
> passes the tests.

I tried turning on the SVG format and it still fails.  Could you
show the output of your "make showconfig" for ImageMagick?

Mine is:
 X11=on "X11 support"
 IMAGEMAGICK_TESTS=on "Run bundled self-tests after build"
 IMAGEMAGICK_PERL=on "Perl support"
 IMAGEMAGICK_MODULES=off "Modules support (broken)"
 IMAGEMAGICK_BZLIB=on "Bzlib support"
 IMAGEMAGICK_16BIT_PIXEL=on "16bit pixel support"
 IMAGEMAGICK_LCMS=on "LCMS support"
 IMAGEMAGICK_TTF=on "Freetype support"
 IMAGEMAGICK_FONTCONFIG=on "Fontconfig support"
 IMAGEMAGICK_JPEG=on "JPG format support"
 IMAGEMAGICK_PNG=on "PNG format support"
 IMAGEMAGICK_TIFF=on "TIFF format support"
 IMAGEMAGICK_FPX=on "FPX format support"
 IMAGEMAGICK_JBIG=on "JBIG format support"
 IMAGEMAGICK_JPEG2000=on "JPEG2000 format support"
 IMAGEMAGICK_DOT=off "GraphViz dot graphs support"
 IMAGEMAGICK_WMF=off "WMF format support"
 IMAGEMAGICK_SVG=on "SVG format support"
 IMAGEMAGICK_PDF=on "PDF format support"
 IMAGEMAGICK_MPEG2=on "MPEG2 format support"
 IMAGEMAGICK_GSLIB=off "libgs (Postscript SHLIB) support"

There has been a PR 116682 filed and a thread started on: 

http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=9782

The developers can't reproduce the failure we're seeing.

Thanks,

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

Re: pkgdb -L issues *following xorg-7.3 update*

[Randy Pratt]

On Fri, 14 Sep 2007 21:55:52 -0400
Rob Clark <[EMAIL PROTECTED]> wrote:

> Running: FreeBSD 6.2-STABLE #0: Thu Aug  2 03:23:18 EDT 2007
> 
> Following the 20070913 xorg-7.3 update and using
> portupgrade-devel, pkgdb -L gave the following:
> 
> # pkgdb -L
> [Updating the pkgdb  in /var/db/pkg ... -
> 838 packages found (-0 +1) . done] Look for lost
> dependencies: HVSC-Update-2.8.3: ok
> /bin/sh:Argument list too long
> can't convert nil into String
> ImageMagick-6.3.3.5_1: #

I saw the same message until I updated ports again this morning.
It appears to have been fixed although I can't point to the cause
or what fixed it.  I realize this isn't real useful other than
to suggest refreshing your ports tree and updating again.

HTH,

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

Re: Problems with +CONTENTS being messed up by pkg_delete -f

[Randy Pratt]

On Wed, 18 Jul 2007 15:56:49 -0500 (CDT)
Stephen Montgomery-Smith <[EMAIL PROTECTED]> wrote:

> 
> If you "pkg_delete -f" a package and then install the port again (but 
> after it has been bumped up a version), then the +CONTENTS of ports that 
> require the original port will be incorrect.  This apparently messes up 
> programs like portmanager.  There is a sense in which one should never do 
> "pkg_delete -f" and expect /var/db/pkg to keep its integrety - on the 
> other hand this is exactly what "make deinstall" does.
> 
> My feeling is that the integrety of /var/db/pkg should be maintained 
> across a "make deinstall" and subsequent "make install" of a bumped 
> version of the port.
> 
> This is my suggestion.  When a "pkg_delete -f" is executed, it looks 
> through +REQUIRED_BY of the port it is going to delete, and modifies the 
> +CONTENTS file of each of them, replacing lines like
> @pkgdep xineramaproto-1.1.2
> @comment DEPORIGIN:x11/xineramaproto
> 
> to maybe something like
> @comment DELDEPORIGIN:x11/xineramaproto
> 
> ("deleted dependency origin").  A subsequent "make install" of 
> x11/xineramaproto should look through the +CONTENTS of all entries in
> /var/db/pkg and change these lines to something like
> 
> @pkgdep xineramaproto-1.1.3
> @comment DEPORIGIN:x11/xineramaproto
> 
> A further benefit of this approach is that one could also accurately 
> reconstruct the +REQUIRED_BY of the port just reinstalled - right now this 
> is left empty and thus inaccurate.
> 
> What do you guys think?  I know I could write the code for this quite 
> quickly, but I want some feedback before I work on it.

I've not read this thread in detail but I think "pkgdb -L" could be
of use in this situation.  It will check and restore lost dependencies
against the ports tree.  It has worked for me on several occasions.

As far as package set creation for distribution on my systems, I use
the "pkg_create -b" instead of "make package".  I have only used "make
package" to check a port that is being created for local use (as per
Porters Handbook).

Just ignore me if I've misunderstood the thread ;-)

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

Re: Portupgrade omitting dependencies?

[Randy Pratt]

On Mon, 26 Feb 2007 17:15:18 +0300
Sergey Matveychuk <[EMAIL PROTECTED]> wrote:

> I think it should be fixed in 2.2.5 version.

Yes, it certainly seems so.  It may be a bit premature without
further testing but it works as I have come to expect portupgrade
to work.  

Just after I updated this morning for the latest portupgrade-devel
version, there was a version update for mplayer.

This time, mplayer was updated to a new version and there were no
entries left as "DELETED" in any /var/db/pkg/*/+CONTENTS file.

I did as you suggested with pkgtools.conf:

  ALT_PKGDEP = {
'print/ghostscript-afpl' => 'print/ghostscript-gnu',
'www/apache13' => 'www/apache13-modssl',
  }

In order to clear the "DELETED" entries I had to first do a

  portupgrade -fo print/ghostscript-afpl ghostscript-gnu

to update all the dependencies to the ghostscript-afpl version
then followed that with a:

  portupgrade -o print/ghostscript-gnu ghostscript-afpl

to restore things to the original ghostscript-gnu version.

It would have probably been okay to just leave them at the newer
ghostscript-afpl.  I saw talk on cvs-all list about perhaps 
making that the default version of ghostscript but that's up to
those that take care of that.

I'll continue using portupgrade-devel to shake out anything else
since I do ports update almost daily.

Thanks so much for doing all this (and knowing ruby ;-).

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

Re: Portupgrade omitting dependencies?

[Randy Pratt]

On Mon, 26 Feb 2007 12:25:05 +0300
Sergey Matveychuk <[EMAIL PROTECTED]> wrote:

> Randy Pratt wrote:
> >> Unfortunately I can't reproduce it.
> >> Can you show an output of the command please: cd
> >> /usr/ports/multimedia/kino; make package-depends-list
> > 
> > (doesn't this ignore any entries in pkgtools.conf?  I don't have
> > any in this case)
> > 
> [...]
> > mplayer-0.99.10_4 /usr/ports/multimedia/mplayer multimedia/mplayer
> 
> So pkgdb -F should not remove mplayer as dependency. And an interesting
> thing now is when you got it removed?
>
> > I'm not sure which part that you couldn't reproduce but these
> > 'DELETED' dependencies seem to only occur when updating from
> > an old version to a new version.  This doesn't happen for all
> > ports being updated to a new version, just some.
> 
> I've tried to install multimedia/kino and pkgdb -F. It does not remove
> mplayer for me.

The problem can only be reproduced when a port is being updated to
a newer version.  In this instance, kino would have to have been
installed before mplayer was updated to a newer version.  More
examples of the problem from yesterday's update are at the end.

> > 
> > I have already "repaired" the /var/db/pkg/*/+CONTENTS by forcing
> > updates of ports whose dependencies were marked as "DELETED";
> > however, the "DELETED" ghostscript-afpl entries still remain.
> > 
> > I realize this kind of thing is hard to reproduce since it probably
> > depends on a lot of things that are constantly moving targets.
> 
> I hope I found all issues and will release a new version today. It will
> fix ghostscript and relate issues but you will need to add the ports in
> ALT_PKGDEP section in pkgtools.conf just like this:
> 
> ALT_PKGDEP = {
>   'print/ghostscript-afpl' => 'print/ghostscript-gnu',
>   'www/apache13' => 'www/apache13-modssl',
> }

I'll give this a try today.  I had cvsupped but noticed that there
were some additional patches committed so I'll get those before
continuing.  Additionally, I'll have to wait for a few ports to
be version updated before I do any testing of the new 
portupgrade-devel.

Randy
===
Ports updated 2007.02.25.2001:

libmpcdec-1.2.2 <  needs updating (port has 1.2.5) 
nspr-4.6.4  <  needs updating (port has 4.6.5) 
p5-GSSAPI-0.23  <  needs updating (port has 0.24) 
pciids-20070123 <  needs updating (port has 20070225) 
rar-3.70b1_1,1  <  needs updating (port has 3.70b1_2,1) 
speex-1.2.b1,1  <  needs updating (port has 1.2.b1_1,1) 


After updating these were the entries from /var/db/pkg/*/+CONTENTS:

ImageMagick-6.3.2.0_1/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
ImageMagick-6.3.2.0_1/+CONTENTS:@comment 
DELETED:DEPORIGIN:print/ghostscript-afpl
apsfilter-7.2.8/+CONTENTS:@comment DELETED:pkgdep rar-3.70b1_2,1
apsfilter-7.2.8/+CONTENTS:@comment DELETED:DEPORIGIN:archivers/rar
apsfilter-7.2.8/+CONTENTS:@comment DELETED:pkgdep speex-1.2.b1_1,1
apsfilter-7.2.8/+CONTENTS:@comment DELETED:DEPORIGIN:audio/speex
avidemux2-2.3.0/+CONTENTS:@comment DELETED:pkgdep nspr-4.6.5
avidemux2-2.3.0/+CONTENTS:@comment DELETED:DEPORIGIN:devel/nspr
dvdauthor-0.6.11_1/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
dvdauthor-0.6.11_1/+CONTENTS:@comment DELETED:DEPORIGIN:print/ghostscript-afpl
dvdstyler-1.5.b5_1,2/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
dvdstyler-1.5.b5_1,2/+CONTENTS:@comment DELETED:DEPORIGIN:print/ghostscript-afpl
firefox-2.0.0.2,1/+CONTENTS:@comment DELETED:pkgdep nspr-4.6.5
firefox-2.0.0.2,1/+CONTENTS:@comment DELETED:DEPORIGIN:devel/nspr
gimp-2.2.13_2,1/+CONTENTS:@comment DELETED:pkgdep pciids-20070225
gimp-2.2.13_2,1/+CONTENTS:@comment DELETED:DEPORIGIN:misc/pciids
gmencoder-0.1.0_7/+CONTENTS:@comment DELETED:pkgdep pciids-20070225
gmencoder-0.1.0_7/+CONTENTS:@comment DELETED:DEPORIGIN:misc/pciids
gnome-vfs-2.16.3/+CONTENTS:@comment DELETED:pkgdep pciids-20070225
gnome-vfs-2.16.3/+CONTENTS:@comment DELETED:DEPORIGIN:misc/pciids
gxine-0.5.11/+CONTENTS:@comment DELETED:pkgdep pciids-20070225
gxine-0.5.11/+CONTENTS:@comment DELETED:DEPORIGIN:misc/pciids
gxine-0.5.11/+CONTENTS:@comment DELETED:pkgdep nspr-4.6.5
gxine-0.5.11/+CONTENTS:@comment DELETED:DEPORIGIN:devel/nspr
gxine-0.5.11/+CONTENTS:@comment DELETED:pkgdep speex-1.2.b1_1,1
gxine-0.5.11/+CONTENTS:@comment DELETED:DEPORIGIN:audio/speex
gxine-0.5.11/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
gxine-0.5.11/+CONTENTS:@comment DELETED:DEPORIGIN:print/ghostscript-afpl
hal-0.5.8.20070210/+CONTENTS:@comment DELETED:pkgdep p

Re: Portupgrade omitting dependencies?

[Randy Pratt]

On Sun, 25 Feb 2007 21:51:48 +0300
Sergey Matveychuk <[EMAIL PROTECTED]> wrote:

> Sergey Matveychuk wrote:
> >> # grep mplayer /var/db/pkg/kino-0.9.5/*
> >> /var/db/pkg/kino-0.9.5/+CONTENTS:@pkgdep mplayer-skins-1.1.2_6
> >> /var/db/pkg/kino-0.9.5/+CONTENTS:@comment 
> >> DEPORIGIN:multimedia/mplayer-skins
> >> /var/db/pkg/kino-0.9.5/+CONTENTS:@comment DELETED:pkgdep mplayer-0.99.10_4
> >> /var/db/pkg/kino-0.9.5/+CONTENTS:@comment 
> >> DELETED:DEPORIGIN:multimedia/mplayer
> >>
> >> This doesn't seem to be correct since it keeps mplayer-skins and removes
> >> mplayer.  Likewise for gmencoder:
> > 
> > It's mysterious for me. I'll try reproduce the situation.
> > 
> 
> Unfortunately I can't reproduce it.
> Can you show an output of the command please: cd
> /usr/ports/multimedia/kino; make package-depends-list

(doesn't this ignore any entries in pkgtools.conf?  I don't have
any in this case)

libdv-0.104_3 /usr/ports/multimedia/libdv multimedia/libdv
jpeg-6b_4 /usr/ports/graphics/jpeg graphics/jpeg
popt-1.7_2 /usr/ports/devel/popt devel/popt
gettext-0.14.5_2 /usr/ports/devel/gettext devel/gettext
libiconv-1.9.2_2 /usr/ports/converters/libiconv converters/libiconv
sdl-1.2.11,2 /usr/ports/devel/sdl12 devel/sdl12
aalib-1.4.r5_2 /usr/ports/graphics/aalib graphics/aalib
xorg-libraries-6.9.0_1 /usr/ports/x11/xorg-libraries x11/xorg-libraries
libdrm-2.0.2 /usr/ports/graphics/libdrm graphics/libdrm
freetype2-2.2.1_1 /usr/ports/print/freetype2 print/freetype2
pkg-config-0.21 /usr/ports/devel/pkg-config devel/pkg-config
fontconfig-2.3.2_6,1 /usr/ports/x11-fonts/fontconfig
x11-fonts/fontconfig expat-2.0.0_1 /usr/ports/textproc/expat2
textproc/expat2 svgalib-1.4.3_5 /usr/ports/graphics/svgalib
graphics/svgalib esound-0.2.36_1 /usr/ports/audio/esound audio/esound
libaudiofile-0.2.6 /usr/ports/audio/libaudiofile audio/libaudiofile
glib-1.2.10_12 /usr/ports/devel/glib12 devel/glib12
gtk-1.2.10_17 /usr/ports/x11-toolkits/gtk12 x11-toolkits/gtk12
perl-5.8.8 /usr/ports/lang/perl5.8 lang/perl5.8
ffmpeg-devel-0.4.9.c.2006032300_4 /usr/ports/multimedia/ffmpeg-devel
multimedia/ffmpeg-devel faac-1.25 /usr/ports/audio/faac audio/faac
mpeg4ip-libmp4v2-1.5.0.1 /usr/ports/multimedia/mpeg4ip-libmp4v2
multimedia/mpeg4ip-libmp4v2 faad2-2.5,1 /usr/ports/audio/faad audio/faad
lame-3.97_1 /usr/ports/audio/lame audio/lame
libogg-1.1.3,3 /usr/ports/audio/libogg audio/libogg
libtheora-1.0.a7 /usr/ports/multimedia/libtheora multimedia/libtheora
libvorbis-1.1.2,3 /usr/ports/audio/libvorbis audio/libvorbis
x264-0.0.20061030 /usr/ports/multimedia/x264 multimedia/x264
gpac-libgpac-0.4.2.r2,1 /usr/ports/multimedia/gpac-libgpac
multimedia/gpac-libgpac atk-1.12.4 /usr/ports/accessibility/atk
accessibility/atk glib-2.12.9 /usr/ports/devel/glib20 devel/glib20
gtk-2.10.9_1 /usr/ports/x11-toolkits/gtk20 x11-toolkits/gtk20
png-1.2.14 /usr/ports/graphics/png graphics/png
tiff-3.8.2_1 /usr/ports/graphics/tiff graphics/tiff
cups-base-1.2.8 /usr/ports/print/cups-base print/cups-base
gnutls-1.6.1_1 /usr/ports/security/gnutls security/gnutls
libgcrypt-1.2.4 /usr/ports/security/libgcrypt security/libgcrypt
libgpg-error-1.4 /usr/ports/security/libgpg-error security/libgpg-error
pango-1.14.10 /usr/ports/x11-toolkits/pango x11-toolkits/pango
cairo-1.2.6_1 /usr/ports/graphics/cairo graphics/cairo
libXft-2.1.7_1 /usr/ports/x11-fonts/libXft x11-fonts/libXft
xorg-fonts-truetype-6.9.0 /usr/ports/x11-fonts/xorg-fonts-truetype
x11-fonts/xorg-fonts-truetype
xorg-fonts-encodings-6.9.0_1 /usr/ports/x11-fonts/xorg-fonts-encodings
x11-fonts/xorg-fonts-encodings
bitstream-vera-1.10_2 /usr/ports/x11-fonts/bitstream-vera
x11-fonts/bitstream-vera
shared-mime-info-0.20 /usr/ports/misc/shared-mime-info
misc/shared-mime-info libxml2-2.6.27 /usr/ports/textproc/libxml2
textproc/libxml2
hicolor-icon-theme-0.9_2 /usr/ports/misc/hicolor-icon-theme
misc/hicolor-icon-theme imlib2-20060926_2,1 /usr/ports/graphics/imlib2
graphics/imlib2 libungif-4.1.4_2 /usr/ports/graphics/libungif
graphics/libungif libid3tag-0.15.1b /usr/ports/audio/libid3tag
audio/libid3tag xvid-1.1.2,1 /usr/ports/multimedia/xvid multimedia/xvid
ImageMagick-6.3.2.0_1 /usr/ports/graphics/ImageMagick
graphics/ImageMagick libfpx-1.2.0.12 /usr/ports/graphics/libfpx
graphics/libfpx jbigkit-1.6 /usr/ports/graphics/jbigkit
graphics/jbigkit jasper-1.900.1 /usr/ports/graphics/jasper
graphics/jasper lcms-1.16_1,1 /usr/ports/graphics/lcms graphics/lcms
libltdl-1.5.22_1 /usr/ports/devel/libltdl15 devel/libltdl15
mpeg2codec-1.2_1 /usr/ports/multimedia/mpeg2codec multimedia/mpeg2codec
ghostscript-afpl-8.54,1 /usr/ports/print/ghostscript-afpl
print/ghostscript-afpl gsfonts-8.11_2 /usr/ports/print/gsfonts
print/gsfonts libsamplerate-0.1.2_2 /usr/ports/audio/libsamplerate
audio/libsamplerate libsndfile-1.0.17 /usr/ports/audio/libsndfile
audio/libsndfile flac-1.1.2_1 /usr/ports/audio/flac audio/flac
fftw3-3.1.2 /usr/ports/math/fftw3 math/fftw3
libglade2-2.6.0_2 /usr/ports/devel/libglade2 devel/libglade2
xmlcatmgr-2.2 /usr/ports/textproc/xml

Re: Portupgrade omitting dependencies?

[Randy Pratt]

On Fri, 23 Feb 2007 19:36:19 +0300
Sergey Matveychuk <[EMAIL PROTECTED]> wrote:

> Sergey Matveychuk wrote:
> > Randy Pratt wrote:
> >> There seems to be some problem in the way that portupgrade handles
> >> dependencies in updating a port to a new version.  In quite a few
> >> cases, portupgrade does not restore all dependencies that were
> >> originally listed in the +REQUIRED_BY file.  I'll use the "netpbm"
> > 
> > Well, I have an idea about this I should check.
> > 
> 
> Sorry I did not answer for a long time. I have no time for portupgrade
> till today. I've found the big and fix it in portupgrade-devel (version
> 2.2.4). It would be great if you test it (anyone who want are welcome).

No problem.  I really do understand that Real Life (tm) exists and
there are other things than computers.

> You can follow the steps to upgrade:
> 
> portupgrade -fo ports-mgmt/portupgrade-devel portupgrade
> pkgdb -L (it fixes lost dependencies. you could want to backup your
> /var/db/pkg to compare afterwards)
> pkgdb -F

Before starting, I had no DELETED comments in /var/db/pkg/*/+CONTENTS.
After following the above steps, I checked for DELETED comments:

ImageMagick-6.3.2.0_1/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
ImageMagick-6.3.2.0_1/+CONTENTS:@comment 
DELETED:DEPORIGIN:print/ghostscript-afpl
dvdauthor-0.6.11_1/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
dvdauthor-0.6.11_1/+CONTENTS:@comment DELETED:DEPORIGIN:print/ghostscript-afpl
dvdstyler-1.5.b5_1,2/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
dvdstyler-1.5.b5_1,2/+CONTENTS:@comment DELETED:DEPORIGIN:print/ghostscript-afpl
gxine-0.5.11/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
gxine-0.5.11/+CONTENTS:@comment DELETED:DEPORIGIN:print/ghostscript-afpl
html2ps-letter-1.0.b5,1/+CONTENTS:@comment DELETED:pkgdep 
ghostscript-afpl-8.54,1
html2ps-letter-1.0.b5,1/+CONTENTS:@comment 
DELETED:DEPORIGIN:print/ghostscript-afpl
kino-0.9.5/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
kino-0.9.5/+CONTENTS:@comment DELETED:DEPORIGIN:print/ghostscript-afpl
libxine-1.1.4_1/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
libxine-1.1.4_1/+CONTENTS:@comment DELETED:DEPORIGIN:print/ghostscript-afpl
transcode-1.0.2_5/+CONTENTS:@comment DELETED:pkgdep ghostscript-afpl-8.54,1
transcode-1.0.2_5/+CONTENTS:@comment DELETED:DEPORIGIN:print/ghostscript-afpl

I have no idea where the references to ghostscript-afpl come from
since I have only ghostscript-gnu installed.

The "portversion -vL=" show the following needed updated:

intltool-0.35.4 <  needs updating (port has 0.35.5) 
libxine-1.1.4_1 <  needs updating (port has 1.1.4_2) 
mplayer-0.99.10_3   <  needs updating (port has 0.99.10_4) 
rar-3.70b1,1<  needs updating (port has 3.70b1_1,1) 
speex-1.0.5_1,1 <  needs updating (port has 1.2.b1,1) 
vorbis-tools-1.1.1_2,3  <  needs updating (port has 1.1.1_3,3) 

What really happened  during the update was:
--->  Upgrading 'speex-1.0.5_1,1' to 'speex-1.2.b1,1' (audio/speex)
--->  Upgrading 'rar-3.70b1,1' to 'rar-3.70b1_1,1' (archivers/rar)
--->  Upgrading 'intltool-0.35.4' to 'intltool-0.35.5' (textproc/intltool)
--->  Upgrading 'vorbis-tools-1.1.1_2,3' to 'vorbis-tools-1.1.1_3,3' 
(audio/vorbis-tools)
--->  Upgrading 'firefox-2.0.0.1_1,1' to 'firefox-2.0.0.2,1' (www/firefox)
--->  Upgrading 'mplayer-0.99.10_3' to 'mplayer-0.99.10_4' (multimedia/mplayer)
--->  Upgrading 'libxine-1.1.4_1' to 'libxine-1.1.4_2' (multimedia/libxine)

It seems that portversion missed the need to update firefox.

After running portupgrade -a, I again checked for any additional
DELETED entries (omitting the previously mentioned ghostscript-afpl
entries for clairty):

# grep DELETED /var/db/pkg/*/+CONTENTS | grep -v ghostscript
/var/db/pkg/gmencoder-0.1.0_7/+CONTENTS:@comment DELETED:pkgdep intltool-0.35.5
/var/db/pkg/gmencoder-0.1.0_7/+CONTENTS:@comment 
DELETED:DEPORIGIN:textproc/intltool
/var/db/pkg/gmencoder-0.1.0_7/+CONTENTS:@comment DELETED:pkgdep 
mplayer-0.99.10_4
/var/db/pkg/gmencoder-0.1.0_7/+CONTENTS:@comment 
DELETED:DEPORIGIN:multimedia/mplayer
/var/db/pkg/kino-0.9.5/+CONTENTS:@comment DELETED:pkgdep mplayer-0.99.10_4
/var/db/pkg/kino-0.9.5/+CONTENTS:@comment DELETED:DEPORIGIN:multimedia/mplayer
/var/db/pkg/libbonoboui-2.16.0/+CONTENTS:@comment DELETED:pkgdep intltool-0.35.5
/var/db/pkg/libbonoboui-2.16.0/+CONTENTS:@comment 
DELETED:DEPORIGIN:textproc/intltool
/var/db/pkg/libgnome-2.16.0/+CONTENTS:@comment DELETED:pkgdep intltool-0.35.5
/var/db/pkg/libgnome-2.16.0/+CONTENTS:@comment 
DELETED:DEPORIGIN:textproc/intltool
/var/db/pkg/libgnomeui-2.16.1/+CONTE

Portupgrade omitting dependencies?

[Randy Pratt]

There seems to be some problem in the way that portupgrade handles
dependencies in updating a port to a new version.  In quite a few
cases, portupgrade does not restore all dependencies that were
originally listed in the +REQUIRED_BY file.  I'll use the "netpbm"
as an example:

Before updating netpbm, the ports that depended on it were listed
as:
  # cat /var/db/pkg/netpbm-10.26.38/+REQUIRED_BY 
  apsfilter-7.2.8
  docproj-1.17
  dvdstyler-1.5.b5_1,2
  gocr-0.43
  tgif-nls-4.1.45
  transfig-3.2.4_1
  xfig-3.2.4_4

This is an excerpt from my netpbm update log showing that it is
not 'seeing' all of the dependencies originally listed in the
respective /var/db/pkg/*/+REQUIRED_BY file:

  pkg_delete: package 'netpbm-10.26.38' is required by these other
  packages and may not be deinstalled (but I'll delete it anyway):
  docproj-1.17
  dvdstyler-1.5.b5_1,2
  gocr-0.43
  tgif-nls-4.1.45
  transfig-3.2.4_1

After updating netpbm, the ports that depend on it have not been
restored (note that it reflects the dependency list shown during
portupgrade):

  # cat /var/db/pkg/netpbm-10.26.39/+REQUIRED_BY 
  docproj-1.17
  dvdstyler-1.5.b5_1,2
  gocr-0.43
  tgif-nls-4.1.45
  transfig-3.2.4_1

Additionally the ports requiring netpbm still show them as being
marked as "DELETED" by portupgrade after all the updating has
finished:

  # grep "DELETED" /var/db/pkg/*/+CONTENTS
  apsfilter-7.2.8/+CONTENTS:@comment DELETED:pkgdep netpbm-10.26.39
  apsfilter-7.2.8/+CONTENTS:@comment DELETED:DEPORIGIN:graphics/netpbm
  xfig-3.2.4_4/+CONTENTS:@comment DELETED:pkgdep netpbm-10.26.39
  xfig-3.2.4_4/+CONTENTS:@comment DELETED:DEPORIGIN:graphics/netpbm

It seems that this could cause problems if I needed to update
netpbm and all the ports that depend on it.  It would surely miss
apsfilter and xfig in this case.

I'm curious if anyone else is seeing these leftover DELETED notations.
They can be checked with the simple grep as shown above.  I've
went so far as to removing the ports tree and cvsupping a new one
as well as removing portupgrade and reinstalling.  The maintainer
for portupgrade indicated that he's not seen this problem.

I've been seeing this for at least 4-5 weeks and see the same
problems on all four of my local machines (all i386 running
6.2-STABLE).

I'd appreciate anyone confirming that they are also seeing this kind
of problem as I can't find anything local.  As I understand it,
there should be nothing marked as "DELETED" after portupgrade.  The
absense/presence can be determined with:

  grep "DELETED" /var/db/pkg/*/+CONTENTS

Thanks,

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

Portupgrade and /var/db/pkg/*/+CONTENTS

[Randy Pratt]

I've spent many hours in the past week or so trying to understand
what I'm seeing.  In the interest of brevity I've tried to omit
non-relevant detail but this still ends up longer than I would like.

It seems that portupgrade is "deleting" dependencies during the update
process.  This is happening for many ports and I only chose the recent
upgrading 'curl-7.15.5_1' to 'curl-7.16.0' (ftp/curl) to demonstrate
what I'm observing.

As a reference I pulled these excerpts from a backup of my
previous /var/db/pkg/* for ports that depended on ftp/curl:

  apsfilter-7.2.8/+CONTENTS:@pkgdep curl-7.15.5_1
  apsfilter-7.2.8/+CONTENTS:@comment DEPORIGIN:ftp/curl
  curl-7.15.5_1/+CONTENTS:@name curl-7.15.5_1
  curl-7.15.5_1/+CONTENTS:@comment ORIGIN:ftp/curl
  gnupg-1.4.6_1/+CONTENTS:@pkgdep curl-7.15.5_1
  gnupg-1.4.6_1/+CONTENTS:@comment DEPORIGIN:ftp/curl
  gnupg-devel-1.9.22_1/+CONTENTS:@pkgdep curl-7.15.5_1
  gnupg-devel-1.9.22_1/+CONTENTS:@comment DEPORIGIN:ftp/curl
  streamtuner-0.99.99_5/+CONTENTS:@pkgdep curl-7.15.5_1
  streamtuner-0.99.99_5/+CONTENTS:@comment DEPORIGIN:ftp/curl
  sylpheed-2.2.10/+CONTENTS:@pkgdep curl-7.15.5_1
  sylpheed-2.2.10/+CONTENTS:@comment DEPORIGIN:ftp/curl
  vorbis-tools-1.1.1_1,3/+CONTENTS:@pkgdep curl-7.15.5_1
  vorbis-tools-1.1.1_1,3/+CONTENTS:@comment DEPORIGIN:ftp/curl
  wmweather-2.4.3/+CONTENTS:@pkgdep curl-7.15.5_1
  wmweather-2.4.3/+CONTENTS:@comment DEPORIGIN:ftp/curl

This is from my log of the updating of ftp/curl:

  pkg_delete: package 'curl-7.15.5_1' is required by these other
  packages and may not be deinstalled (but I'll delete it anyway):
  gnupg-1.4.6_1
  streamtuner-0.99.99_5
  vorbis-tools-1.1.1_1,3
  wmweather-2.4.3

I noted that print/apsfilter, security/gnupg-devel and mail/sylpheed2
were missing.  Checking /var/db/pkg does indeed show that their
dependency on ftp/curl has been removed.  This happens at the time
that the 'but I'll delete it anyway' step occurs.

  $ grep DELETED /var/db/pkg/*/+CONTENTS
  /var/db/pkg/apsfilter-7.2.8/+CONTENTS:@comment DELETED:pkgdep curl-7.16.0 
  /var/db/pkg/apsfilter-7.2.8/+CONTENTS:@commentDELETED:DEPORIGIN:ftp/curl
  /var/db/pkg/gnupg-devel-1.9.22_1/+CONTENTS:@comment DELETED:pkgdep 
curl-7.16.0 
  /var/db/pkg/gnupg-devel-1.9.22_1/+CONTENTS:@comment DELETED:DEPORIGIN:ftp/curl
  /var/db/pkg/sylpheed-2.2.10/+CONTENTS:@comment DELETED:pkgdep curl-7.16.0 
  /var/db/pkg/sylpheed-2.2.10/+CONTENTS:@comment DELETED:DEPORIGIN:ftp/curl

That is also reflected in checking for ports that now depend on
ftp/curl:

  pkg_info -R curl-\*
  Information for curl-7.16.0:

  Required by:
  gnupg-1.4.6_2
  streamtuner-0.99.99_6
  vorbis-tools-1.1.1_2,3
  wmweather-2.4.3_1

I decided to force an update of the ports which had dependencies on
ftp/curl deleted:

  portupgrade -f apsfilter-7.2.8 gnupg-devel-1.9.22_1 sylpheed-2.2.10

All of the dependencies on ftp/curl were restored:

  pkg_info -R curl-\*
  Information for curl-7.16.0:

  Required by:
  apsfilter-7.2.8
  gnupg-1.4.6_2
  gnupg-devel-1.9.22_1
  streamtuner-0.99.99_6
  sylpheed-2.2.10
  vorbis-tools-1.1.1_2,3
  wmweather-2.4.3_1

I was then curious what would happen if I forced a portupgrade of
ftp/curl.  I thought it might remove the dependencies again but it
did not.  They all remained this time.

Why did a portupgrade to a new version remove dependencies when a
forced update of the same version did not?  I'm probably not
understanding the role of the "DELETED" notation in +CONTENTS .

I decided to take a look at how dependences were noted in the
ports tree with 'make'.  I double checked for anything out of the
ordinary in etc/make.conf:

  CFLAGS= -O -pipe
  PERL_VER=5.8.8
  PERL_VERSION=5.8.8

This is the relevant portion of /usr/local/etc/pkgtools.conf for
MAKE_ARGS since these have impact on portupgrade dependencies:

  'print/apsfilter' => 'BATCH=yes APSFILTER_ALL=yes PAPERSIZE=letter',

Each of the dependencies being deleted were checked with various
incantations to display dependencies:

cd /usr/ports/print/sylpheed
  make build-depends-list: returns nothing for curl.
  make pretty-print-build-depends-list: returns nothing for curl.
  make run-depends-list: returns nothing for curl.
  make pretty-print-run-depends-list: includes curl-7.16.0
  make all-depends-list: includes /usr/ports/ftp/curl

cd /usr/ports/security/gnupg-devel
  make build-depends-list: returns nothing for curl
  make pretty-print-build-depends-list: returns nothing for curl.
  make run-depends-list:  returns nothing for curl.
  make pretty-print-run-depends-list: includes curl-7.16.0
  make all-depends-list: includes /usr/ports/ftp/curl

cd /usr/ports/print/apsfilter
  make BATCH=yes APSFILTER_ALL=yes PAPERSIZE=letter build-depends-list:
returns nothing.
  make BATCH=yes APSFILTER_ALL=yes PAPERSIZE=letter 
pretty-print-run-depends-list:
returns nothing.
  make BATCH=yes APSFILTER_ALL=yes PAPERSIZE=letter run-depends-list:
returns nothing for curl.
  make BATCH=yes APSFILTER_ALL=yes P

editors/xemacs-21.4.20 - package build failure - missing .elc files

[Randy Pratt]

I just updated ports and tried to build a package for xemacs-21.4.20
but apparently there are missing files, an incorrect packing list or
some option that is not turned on.  I'm not building it with any
options other than the defaults.

This is a 6.2-PRERELEASE box and ports were cvsupped just a couple of
hours ago.

Any help in resolving this would be appreciated.  I can do any testing
or provide more information if it would be helpful!

Thanks,

Randy

The details:
=
The port builds and installs but building a package with
"pkg_create -R -b xemacs-21.4.20" fails at:

tar: lib/xemacs-21.4.20/lisp/mule/arabic.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/canna-leim.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/chinese.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/custom-load.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/cyrillic.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/english.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/ethiopic.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/european.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/greek.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/hebrew.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/japanese.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/kinsoku.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/korean.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/latin.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/misc-lang.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/mule-category.elc: Cannot stat: No such file 
or directory
tar: lib/xemacs-21.4.20/lisp/mule/mule-ccl.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/mule-charset.elc: Cannot stat: No such file 
or directory
tar: lib/xemacs-21.4.20/lisp/mule/mule-cmds.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/mule-coding.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/mule-help.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/mule-init.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/mule-misc.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/mule-tty-init.elc: Cannot stat: No such file 
or directory
tar: lib/xemacs-21.4.20/lisp/mule/mule-x-init.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/thai-xtis-chars.elc: Cannot stat: No such 
file or directory
tar: lib/xemacs-21.4.20/lisp/mule/thai-xtis.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/viet-chars.elc: Cannot stat: No such file or 
directory
tar: lib/xemacs-21.4.20/lisp/mule/vietnamese.elc: Cannot stat: No such file or 
directory
pkg_create: make_dist: tar command failed with code 256
-- 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Restarting services

[Randy Pratt]

On Mon, 25 Sep 2006 10:35:15 +0200
Erwin Van de Velde <[EMAIL PROTECTED]> wrote:

> Dear all,
> 
> Almost every port containing a service stops the service before updating but 
> does not restart it afterwards. I was wondering how difficult it can be to 
> restart the updated service after installing the files? In my opinion, it 
> would be less error-prone than hoping for the administrator to remember 
> restarting all updated services...
> While this depends on every port maintainer, a general guideline about this 
> would help and encourage maintainers to do this.

I took a look at /usr/local/etc/pkgtools.conf and it may be possible
to do what you want from there.  I noticed pre-defined functions like:

  #  cmd_start_rc(origin_or_pkgname)
  #Returns a command line string that starts the services of the
  #given package, if any. (Yields "start" for each enabled rc
  #script)

  #  cmd_restart_rc(origin_or_pkgname)
  #Returns a command line string that restarts the services of the
  #given package, if any. (Yields "stop", sleeps for 3 seconds, then
  #yields "start" for each enabled rc script)

There is also a provision for running commands "AFTERINSTALL".

However, I have not used these so there may be some aspects of it
that I'm overlooking but its probably worth consideration.

Randy


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

Re: Skipping certain ports, no upgrade of installed packages ...

[Randy Pratt]

On Sun, 13 Aug 2006 16:35:11 +0200
"[LoN]Kamikaze" <[EMAIL PROTECTED]> wrote:

> 
> Randy Pratt wrote:
> > On Sun, 13 Aug 2006 13:33:19 +0200
> > Rene Ladan <[EMAIL PROTECTED]> wrote:
> > 
> >> Kiffin Gish schreef:
> >>> On Sun, 2006-08-13 at 13:08 +0200, [LoN]Kamikaze wrote:
> >>>> Kiffin Gish wrote:
> >>>>> How can prevent a given package from being reinstalled during the next
> >>>>> portupgrade when I want to delete permanently?
> >>>>>
> >>>>> An example is the Galeon browser. Since it also appears in the
> >>>>> gnome2-fifth-toe makefile t will automatically be rebuilt.
> >>>>>
> >>>>> 2nd question: how can I just keep a given version without having it
> >>>>> upgraded?
> >>>>>
> >>>>> Thanks alot in advance.
> >>>>>
> >>>> .if ${.CURDIR:M/usr/ports/category/port}
> >>>> IGNORE=  not wanted
> >>>> .endif
> >>>>
> >>>> This will keep the ports system from building them. But you will have to
> >>>> edit dependant ports Makefiles. I'm doing that for arts and have to edit
> >>>> the kdelibs Makefile every time kdelibs gets updated.
> >>> The only problem with that approach is that every time I run cvsup the
> >>> modified makefiles are overwritten.
> >>>
> >>> Can also just delete the dependencies line containing galeon for
> >>> example, but overwritten by next cvsup.
> >>>
> >> You can also try portsnap, which only overwrites ports which have been
> >> changed by a commit.
> > 
> > I'm not sure that is true for portsnap under all conditions.  From
> > the portsnap man page:
> > 
> >   extract   Extract a ports tree, replacing existing files and
> > directories.  NOTE: This will remove anything occupying
> > the location where files or directories are being
> > extracted; in particular, any changes made locally to
> > ports tree (for example, adding new patches) will be
> > silently obliterated.
> > 
> 
> You forget that extract is only called for the first time portsnap is used.
> Afterwards you use 'portsnap fetch update', which has the desired behaviour.

Actually, I didn't forget.  I was pointing out that portsnap will
remove any local patches/modifications in an existing ports tree when
extract is used.  I think we both agree on this.

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

Re: Skipping certain ports, no upgrade of installed packages ...

[Randy Pratt]

On Sun, 13 Aug 2006 13:33:19 +0200
Rene Ladan <[EMAIL PROTECTED]> wrote:

> Kiffin Gish schreef:
> > On Sun, 2006-08-13 at 13:08 +0200, [LoN]Kamikaze wrote:
> >> Kiffin Gish wrote:
> >>> How can prevent a given package from being reinstalled during the next
> >>> portupgrade when I want to delete permanently?
> >>>
> >>> An example is the Galeon browser. Since it also appears in the
> >>> gnome2-fifth-toe makefile t will automatically be rebuilt.
> >>>
> >>> 2nd question: how can I just keep a given version without having it
> >>> upgraded?
> >>>
> >>> Thanks alot in advance.
> >>>
> >> .if ${.CURDIR:M/usr/ports/category/port}
> >> IGNORE=not wanted
> >> .endif
> >>
> >> This will keep the ports system from building them. But you will have to
> >> edit dependant ports Makefiles. I'm doing that for arts and have to edit
> >> the kdelibs Makefile every time kdelibs gets updated.
> > 
> > The only problem with that approach is that every time I run cvsup the
> > modified makefiles are overwritten.
> > 
> > Can also just delete the dependencies line containing galeon for
> > example, but overwritten by next cvsup.
> > 
> You can also try portsnap, which only overwrites ports which have been
> changed by a commit.

I'm not sure that is true for portsnap under all conditions.  From
the portsnap man page:

  extract   Extract a ports tree, replacing existing files and
directories.  NOTE: This will remove anything occupying
the location where files or directories are being
extracted; in particular, any changes made locally to
ports tree (for example, adding new patches) will be
silently obliterated.

The conventional tool, portupgrade, uses /usr/local/etc/pkgtools.conf
to HOLD a package (not upgrade).  The pkgtools.conf.sample file is
well annotated and has many other available options.

Take a look at that and see if it will do the job.

HTH,

Randy


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

Re: Ruby vulnerability?

[Randy Pratt]

On Sun, 30 Jul 2006 17:47:33 +0200
Frank Steinborn <[EMAIL PROTECTED]> wrote:

> Shaun Amott wrote:
> > On Fri, Jul 28, 2006 at 03:03:43PM +1000, Joel Hatton wrote:
> > > 
> > > FYI, Red Hat released an advisory today about a vulnerability in Ruby. So
> > > far it doesn't appear in the VuXML, but am I correct in presuming it will
> > > soon?
> > > 
> > 
> > I've added it; thanks for the report.
> 
> Hmm, i saw the flaw with "portaudit -Fda" yesterday, however - today
> my ruby isn't shown as vulnerable anymore. Why?

I show it as a vulnerability here.  It could be that you may have
gotten your last update from a server that hasn't caught up yet.

Try running it again and see if that helps.

Randy

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

Re: Anyone still using x11-wm/fluxbox?

[Randy Pratt]

On Mon, 3 Jul 2006 19:18:26 -0400
Randy Pratt <[EMAIL PROTECTED]> wrote:

> On Mon, 03 Jul 2006 13:42:20 -0500
> "Jeremy Messenger" <[EMAIL PROTECTED]> wrote:
> 
> > Hello folks,
> > 
> > Fluxbox is now at 1.0rc2, so it is near ready to move from fluxbox-devel  
> > to fluxbox. I am wondering if there is any users that still are using  
> > x11-wm/fluxbox (0.1.14)? If yes, then I am happy to move from fluxbox to  
> > something like fluxbox-old (got any better name?) but I will not maintain  
> > it as I shall drop it to [EMAIL PROTECTED] If I get no reply until  
> > Fluxbox released at 1.0 then the 0.1.14 version will be gone for good.
> 
> I'm using the older fluxbox and also know of a few others who are 
> also dragging their feet.  I've actually had my attention elsewhere
> and wasn't following the fluxbox-devel but I'll give it a whirl on a
> test box in the next few days.  I doubt I'd request that the old
> version remain in the tree in any event since I'd keep it along with a
> few other local ports if I really wanted to stick with the old version.
> 
> Thanks for the notice though so I can start paying attention :-)

Just a follow-up to my previous comments.

I switched to the fluxbox-devel-1.0rc2_1 version yesterday and have
not seen any problems.  I left my old ~/.fluxbox directory and
configs and there didn't seem to be any problems.  No reason that
I can see to keep the old version around.

Randy


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

Re: Anyone still using x11-wm/fluxbox?

[Randy Pratt]

On Mon, 03 Jul 2006 13:42:20 -0500
"Jeremy Messenger" <[EMAIL PROTECTED]> wrote:

> Hello folks,
> 
> Fluxbox is now at 1.0rc2, so it is near ready to move from fluxbox-devel  
> to fluxbox. I am wondering if there is any users that still are using  
> x11-wm/fluxbox (0.1.14)? If yes, then I am happy to move from fluxbox to  
> something like fluxbox-old (got any better name?) but I will not maintain  
> it as I shall drop it to [EMAIL PROTECTED] If I get no reply until  
> Fluxbox released at 1.0 then the 0.1.14 version will be gone for good.

I'm using the older fluxbox and also know of a few others who are 
also dragging their feet.  I've actually had my attention elsewhere
and wasn't following the fluxbox-devel but I'll give it a whirl on a
test box in the next few days.  I doubt I'd request that the old
version remain in the tree in any event since I'd keep it along with a
few other local ports if I really wanted to stick with the old version.

Thanks for the notice though so I can start paying attention :-)

Randy


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