Re: libpng.so.6 missing
Michael Scheidell scheid...@freebsd.org wrote .. On 6/11/12 1:44 AM, Waitman Gobble wrote: Hi, I was reading the handbook about burning DVD's and thought I would check out K3b as recommended... so I attempted to install from ports. After an hour or so of the make script building a whole bunch of stuff my patience wore out, and I bailed. ports tree csup this morning. Now it seems many things that were working great will no longer load, it's missing libpng.so.6 # SciTE Shared object libpng.so.6 not found, required by libpangocairo-1.0.so.0 # qtcreator Shared object libpng.so.6 not found, required by libQtGui.so.4 # xxxterm Shared object libpng.so.6 not found, required by libwebkitgtk-1.0.so.0 etc, etc. and so on. Anyhow, i am not sure which package 'libpng.so.6' comes from.. anyone have a tip or a pointer? something is still looking for an old version of png (libpng.so.6), the new version of png uses lib: libpng.so.15. Did you rebuild all packages from source? quick 'cheat' would be to restore libpng.so.6 to compat library from your backup, or another system. -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ 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 Thank you for your reply. I did not rebuild all ports from source. This system was previously on a low power machine and I used pre-compiled packages as much as possible, because of the system requirements to build from source. I'll pull the libpng.so.6 and see if that fixes it. -- Waitman Gobble San Jose California USA ___ 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: libpng.so.6 missing
On Sun, Jun 10, 2012 at 10:52 PM, Michael Scheidell scheid...@freebsd.org wrote: On 6/11/12 1:44 AM, Waitman Gobble wrote: Hi, I was reading the handbook about burning DVD's and thought I would check out K3b as recommended... so I attempted to install from ports. After an hour or so of the make script building a whole bunch of stuff my patience wore out, and I bailed. ports tree csup this morning. Now it seems many things that were working great will no longer load, it's missing libpng.so.6 # SciTE Shared object libpng.so.6 not found, required by libpangocairo-1.0.so.0 # qtcreator Shared object libpng.so.6 not found, required by libQtGui.so.4 # xxxterm Shared object libpng.so.6 not found, required by libwebkitgtk-1.0.so.0 etc, etc. and so on. Anyhow, i am not sure which package 'libpng.so.6' comes from.. anyone have a tip or a pointer? something is still looking for an old version of png (libpng.so.6), the new version of png uses lib: libpng.so.15. Did you rebuild all packages from source? quick 'cheat' would be to restore libpng.so.6 to compat library from your backup, or another system. Install sysutils/bsdadminscripts and 'pkg_chklib -o | grep libpng | sort'. This will provide a list of ports that need to be re-installed so that they will be linked to the new libpng. As pkg_chklib reports on every file that references the old libpng, you may see ports listed several times, once for every executable or shareable that references libpng.so.6. This will really fix the problem. Pulling in a copy of libpng.so.6 might make things work, but may fail if more than one version of libpng is linked to different shareables or executables. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: libpng.so.6 missing
On 6/11/12 2:10 AM, Waitman Gobble wrote: I did not rebuild all ports from source. This system was previously on a low power machine and I used pre-compiled packages as much as possible, looks like one (or more) of the packages still references libpng.so.6. if using portmaster, next time, use -w (preserves old libraries) -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports need a uniq identifier, do you have any suggestion?
On 10 June 2012 21:30, Baptiste Daroussin b...@freebsd.org wrote:
Hi all,
In the ports tree we lack a unique identifier, while we could live without it
until now, it is more than needed for 2 upcoming features: pkgng and stage
directory support.
unique means something that will always be the same what ever the options are
and what ever the runtime they use are. But also means unique in term of in
the
whole ports no other package will share its identifier.
currently the only equivalent of this in the ports tree is the origin of a
package, which will no more be unique with the upcoming sub package support
(coming along with stage directory) aka 1 origin to produce n package.
Perhaps we could introduce UNIQUE_ORIGIN which is
${ORIGIN}_${SUBPACKAGE} or something of the sort?
--
Eitan Adler
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port unmaintained since 2005? drop it? misc/gpt*
On 6/11/12, Michael Scheidell scheid...@freebsd.org wrote: On 6/10/12 11:14 PM, b. f. wrote: The distribution files are at: ftp://ftp.ncsa.uiuc.edu/aces/gpt/releases and the homepage is: http://grid.ncsa.illinois.edu/gpt/ (And Globus is at: http://www.globus.org/toolkit/) Time to determine this: 1 min. b. glad to know you are volunteering to maintain these ports. I will resurrect globus from the archives (where it has been since 2008, see /usr/ports/MOVED), which email address do you want in the MAINTAINER= line? Heh, not so fast. I've got other things to do first. I was just pointing out that it is not so hard to correct some of the stale information, and it is useful to do this as a pointer to those who may wish to more actively maintain the port later, even if it is moved to the attic in a few months. I should add that globus comes with a bundled version of gpt, and I think the Debian port is based upon this -- it's at 3.6.x. Also, that brooks@, who was involved in adding this port and other related software, could probably tell you more about grid software. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports need a uniq identifier, do you have any suggestion?
On 11/06/2012 05:30, Baptiste Daroussin wrote: In the ports tree we lack a unique identifier, while we could live without it until now, it is more than needed for 2 upcoming features: pkgng and stage directory support. unique means something that will always be the same what ever the options are and what ever the runtime they use are. But also means unique in term of in the whole ports no other package will share its identifier. currently the only equivalent of this in the ports tree is the origin of a package, which will no more be unique with the upcoming sub package support (coming along with stage directory) aka 1 origin to produce n package. UNIQUENAME and LATEST_LINK fails in that area because they both can change according to the runtime: py27- for example which will become py30- if you change the default python. LATEST_LINK by default also append the PKGNAMEPREFIX which some ports can be really creative with. should we introduce something new, should we fix one of the above? do you have any suggestion? I was looking at this. You'ld think from the name that UNIQUENAME is the appropriate variable here. Yet by my calculations there are 1439 ports using non-unique UNIQUENAME variables. Fixing that seems like common sense to me: why call it unique if it isn't? UNIQUENAME importance being because the default location for a port's OPTIONSFILE is derived from it, and non-uniqueness can lead to ports fighting over control of that file? Which is bad when unintentional, but can be useful for some related ports to share the same options settings. Does pkgng really need LATEST_LINK at all? As far as I recall, that only exists so that the user can say: # pkg_add -r firefox without having to look up the version number of the firefox port. But pkg(1) pretty much already lets you do that, maybe with the aid of '-x' or '-X' options. Come the pkgng revolution, LATEST_LINK should be one of the first against the wall. I don't see the problem with port prefixes changing UNIQUENAME. Isn't py27-foo conceptually a different port to py30-foo ? Yes, they are built from the same port ORIGIN, but you already intend dropping the one-to-one correspondence between port ORIGINS and packages with the introduction of sub-ports. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: libpng.so.6 missing
Kevin Oberman kob6...@gmail.com wrote .. On Sun, Jun 10, 2012 at 10:52 PM, Michael Scheidell scheid...@freebsd.org wrote: On 6/11/12 1:44 AM, Waitman Gobble wrote: Hi, I was reading the handbook about burning DVD's and thought I would check out K3b as recommended... so I attempted to install from ports. After an hour or so of the make script building a whole bunch of stuff my patience wore out, and I bailed. ports tree csup this morning. Now it seems many things that were working great will no longer load, it's missing libpng.so.6 # SciTE Shared object libpng.so.6 not found, required by libpangocairo-1.0.so.0 # qtcreator Shared object libpng.so.6 not found, required by libQtGui.so.4 # xxxterm Shared object libpng.so.6 not found, required by libwebkitgtk-1.0.so.0 etc, etc. and so on. Anyhow, i am not sure which package 'libpng.so.6' comes from.. anyone have a tip or a pointer? something is still looking for an old version of png (libpng.so.6), the new version of png uses lib: libpng.so.15. Did you rebuild all packages from source? quick 'cheat' would be to restore libpng.so.6 to compat library from your backup, or another system. Install sysutils/bsdadminscripts and 'pkg_chklib -o | grep libpng | sort'. This will provide a list of ports that need to be re-installed so that they will be linked to the new libpng. As pkg_chklib reports on every file that references the old libpng, you may see ports listed several times, once for every executable or shareable that references libpng.so.6. This will really fix the problem. Pulling in a copy of libpng.so.6 might make things work, but may fail if more than one version of libpng is linked to different shareables or executables. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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 Thank you, I appreciate the information. I will add 'replace-packages' in my package-update script. -- Waitman Gobble San Jose California USA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports need a uniq identifier, do you have any suggestion?
On Sun, Jun 10, 2012 at 11:23:46PM -0700, Eitan Adler wrote:
On 10 June 2012 21:30, Baptiste Daroussin b...@freebsd.org wrote:
Hi all,
In the ports tree we lack a unique identifier, while we could live without
it
until now, it is more than needed for 2 upcoming features: pkgng and stage
directory support.
unique means something that will always be the same what ever the options
are
and what ever the runtime they use are. But also means unique in term of in
the
whole ports no other package will share its identifier.
currently the only equivalent of this in the ports tree is the origin of a
package, which will no more be unique with the upcoming sub package support
(coming along with stage directory) aka 1 origin to produce n package.
Perhaps we could introduce UNIQUE_ORIGIN which is
${ORIGIN}_${SUBPACKAGE} or something of the sort?
I thought about this one, but while here we should think about package move
which keeps being the same package, in that case origin will change, and the
uniquename will change which is no good for binary world.
regards,
Bapt
pgpkJVLX5hp6L.pgp
Description: PGP signature
Re: ports need a uniq identifier, do you have any suggestion?
On Mon, Jun 11, 2012 at 07:36:15AM +0100, Matthew Seaman wrote: On 11/06/2012 05:30, Baptiste Daroussin wrote: In the ports tree we lack a unique identifier, while we could live without it until now, it is more than needed for 2 upcoming features: pkgng and stage directory support. unique means something that will always be the same what ever the options are and what ever the runtime they use are. But also means unique in term of in the whole ports no other package will share its identifier. currently the only equivalent of this in the ports tree is the origin of a package, which will no more be unique with the upcoming sub package support (coming along with stage directory) aka 1 origin to produce n package. UNIQUENAME and LATEST_LINK fails in that area because they both can change according to the runtime: py27- for example which will become py30- if you change the default python. LATEST_LINK by default also append the PKGNAMEPREFIX which some ports can be really creative with. should we introduce something new, should we fix one of the above? do you have any suggestion? I was looking at this. You'ld think from the name that UNIQUENAME is the appropriate variable here. Yet by my calculations there are 1439 ports using non-unique UNIQUENAME variables. Fixing that seems like common sense to me: why call it unique if it isn't? UNIQUENAME importance being because the default location for a port's OPTIONSFILE is derived from it, and non-uniqueness can lead to ports fighting over control of that file? Which is bad when unintentional, but can be useful for some related ports to share the same options settings. Well this is the right thing to do but looking at bsd.port.mk and the changes needed I get bored and gave up :( Does pkgng really need LATEST_LINK at all? As far as I recall, that only exists so that the user can say: Well no pkgng doesn't need it at all except for pkg itself for the bootstrap :) # pkg_add -r firefox without having to look up the version number of the firefox port. But pkg(1) pretty much already lets you do that, maybe with the aid of '-x' or '-X' options. Come the pkgng revolution, LATEST_LINK should be one of the first against the wall. I don't see the problem with port prefixes changing UNIQUENAME. Isn't py27-foo conceptually a different port to py30-foo ? Yes, they are built from the same port ORIGIN, but you already intend dropping the one-to-one correspondence between port ORIGINS and packages with the introduction of sub-ports. Maybe they are different packages, but they have the same options, and from pkgng we should be able to detect it as the same package just a different runtime which is what they are. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW pgp7mSItOhMk0.pgp Description: PGP signature
Current unassigned ports problem reports
(Note: an HTML version of this report is available at
http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .)
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker Resp. Description
o ports/168946[PATCH] lang/php5-extensions Avoid optionsNG breakage
o ports/168945[patch update take-maint] update devel/soapui 3.5 - 4
o ports/168943[patch] [maintainer] unbreak port databases/libudbc
o ports/168941[ERROR] cannot upgrade graphics/ImageMagick to version
o ports/168940[ERROR] cannot upgrade misc/ossp-uuid to version 1.6.2
o ports/168937[MAINTAINER] emulators/dynagen: fix RUN_DEPENDS
o ports/168936[bsd.pkgng.mk / bsd.options.mk] Fix portmgr options (D
f ports/168935www/firefox-remote shares PORTNAME with www/firefox
o ports/168934update textproc/dikt to 2j
o ports/168933update net/gnu-dico to 2.2
o ports/168932[NEW PORT] net-mgmt/phpipam: PHPIPAM: PHP IP Address M
o ports/168926Second '59.xxx' out of range 0..59 at security/snort-r
o ports/168914[maintainer update] math/ess 12.04-02 - 12.04-04 + CO
o ports/168906Update port mail/assp to 1.9.3.6 and update new to new
o ports/168905[NEW PORT] devel/rebar: A build-tool for Erlang that f
f ports/168892[PATCH] benchmarks/polygraph: Update to 4.3.2 - Unmark
o ports/168861devel/tkcvs: tkdiff no longer runs correctly
f ports/168841x11/slim fails to authorize (through kereros) if built
o ports/168832New port: sysutils/bsdinfo a freebsd version of 'arche
f ports/168824[PATCH] astro/gpstk: fix conflict lib links
o ports/168809[new port] net-im/spectrum: Jabber/XMPP transport/gate
f ports/168661devel/boost-libs fails on make package because of miss
f ports/168648[PATCH] editors/mg: Don't hard code CC in Makefile
o ports/168627[NEW PORT] net/bibtexconv port
f ports/168611conflict: cad/brlcad: Port shares files with other por
o ports/168576[MAINTAINER] sysutils/watchmen: update to 0.07
f ports/168559Updated lang/clojure to version 1.4.0
f ports/168523[PATCH] sysutils/smartmontools smartd can't see ada(4)
o ports/168515New port: devel/elasticsearch A search engine in Java
o ports/168486[PATCH] www/sams, warnings strftime() [function.strft
f ports/168484[patch] update www/cntlm to version 0.92.2
o ports/168483Maintainer Update: lang/squeak version up to 4.4.7-238
o ports/168466[PATCH] www/sams, web-interface, needs GetHostnameSam.
o ports/168452New Port: comms/qtel EchoLink Client and SvrLink audio
f ports/168444Segfault in devel/gdb version 7.4.1
f ports/168407[patch] lang/gauche: update to 0.9.3.2, unbreak
o ports/168404[NEW PORT] databases/dev-sqlite3: This is a developmen
o ports/168385every port has vulnerabilities in case of locale probl
o ports/168366port www/lynx Move lynx conf files form ${LOCALBASE}/e
o ports/168334New port: security/kpcli - Command line interface to K
o ports/168321fix japanese/kon2-16dot
f ports/168319graphics/qiviewer: Not displaying image jpeg
o ports/168191sysutils/ezjail + freebsd9 -stable -- dont work
o ports/168177[NEW PORT] games/asteroids3d: First-person shooter blo
f ports/168161[PATCH] sysutils/conky: update to 1.9.0
f ports/168160ports-mgmt/jailaudit doesn't return a non-0 exit code
o ports/168141faild to install lang/ezm3
f ports/168139install net/quagga is failed
s ports/167955[update] graphics/tinyows: Fix dependency to postgis
f ports/167950databases/memcachedb does not work on 10-CURRENT
o ports/167943[PATCH] fix warnings when compiling benchmarks/iozone
f ports/167910[MAINTAINER] databases/mariadb-scripts: add missing de
f ports/167824mail/dovecot: double checks for build options
f ports/167691security/heimdal: problem compiling kerberos/heimdal
o ports/167591security/openssh-portable looks for ecdsa key but none
o ports/167554security/openssh-portable has some drawbacks
f ports/167090sysutils/ezjail: Invalid command line option in ezjail
o ports/167042New port: net-p2p/tahoe-lafs
f ports/167031security/heimdal ignore environment after process call
f ports/166987net/nss_ldap: ports/152982 causes nss_ldap to not func
o ports/166826New port: misc/libphidget The driver
Current problem reports assigned to po...@freebsd.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o ports/168328 ports [REPOCOPY] devel/codeblocks -- devel/codeblocks-devel 1 problem total. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports need a uniq identifier, do you have any suggestion?
On 11/06/2012 11:32, Baptiste Daroussin wrote: UNIQUENAME importance being because the default location for a port's OPTIONSFILE is derived from it, and non-uniqueness can lead to ports fighting over control of that file? Which is bad when unintentional, but can be useful for some related ports to share the same options settings. Well this is the right thing to do but looking at bsd.port.mk and the changes needed I get bored and gave up :( I haven't looked at what would be necessary to fix UNIQUENAME collisions in any great detail, but I think a number are due to setting PORTNAME to something basically incorrect. Does pkgng really need LATEST_LINK at all? As far as I recall, that only exists so that the user can say: Well no pkgng doesn't need it at all except for pkg itself for the bootstrap :) Hmmm... so there just has to be pkg.txz at some predictable URL(s) on the FBSD mirrors? That doesn't sound like enough to justify keeping LATEST_LINK related bits in the ports tree. I don't see the problem with port prefixes changing UNIQUENAME. Isn't py27-foo conceptually a different port to py30-foo ? Yes, they are built from the same port ORIGIN, but you already intend dropping the one-to-one correspondence between port ORIGINS and packages with the introduction of sub-ports. Maybe they are different packages, but they have the same options, and from pkgng we should be able to detect it as the same package just a different runtime which is what they are. I think I see. You're thinking of packages that install the same files, but maybe in a different location (eg. SITE_PERL) or that register run-time dependencies on a number of different possible providers. Couldn't that boil down to having several alternate .MANIFEST files in the pkg? Plus some sort of final-location-independent way of naming the files to be installed by the package? On the matter of having alternate RUN_DEPENDS to be set at install time? I've wanted to do something like that with databases/phpmyadmin for ages. Most of the optional dependencies there are autodetected by the PHP code at run-time, so it should be possible to just ask the user which of them they want to have during pkg installation. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: ports need a uniq identifier, do you have any suggestion?
On Mon, Jun 11, 2012 at 12:34:16PM +0100, Matthew Seaman wrote:
On 11/06/2012 11:32, Baptiste Daroussin wrote:
UNIQUENAME importance being because the default location for a port's
OPTIONSFILE is derived from it, and non-uniqueness can lead to ports
fighting over control of that file? Which is bad when unintentional,
but can be useful for some related ports to share the same options
settings.
Well this is the right thing to do but looking at bsd.port.mk and the
changes
needed I get bored and gave up :(
I haven't looked at what would be necessary to fix UNIQUENAME collisions
in any great detail, but I think a number are due to setting PORTNAME to
something basically incorrect.
In fact there are 3 majors guilty:
- bsd.python.mk
- bsd.ruby.mk
- bsd.apache.mk
why because they recommand their user to set PKGNAMEPREFIX to
${BLA_PKGNAMEPREFIX} so that their prefix can be set from bsd.port.mk
Which mean that until the said bsd.$guilty.mk is included UNIQUENAME name is set
to ${PKGNAMEPREFIX}${PORTNAME} with PKGNAMEPREFIX being expanded to nothing
and once bsd.$guilty.mk is included ${PKGNAMEPREFIX} expands to something and so
UNIQUENAME is changed. (btw also break the options framework (old and new) with
the ports because OPTIONSFILE is created using the ${UNIQUENAME}
second problem is that uniquename can potentially be shared between ports for
example nginx and nginx-devel and in general all the -devel ports
Does pkgng really need LATEST_LINK at all? As far as I recall, that
only exists so that the user can say:
Well no pkgng doesn't need it at all except for pkg itself for the
bootstrap :)
Hmmm... so there just has to be pkg.txz at some predictable URL(s) on
the FBSD mirrors? That doesn't sound like enough to justify keeping
LATEST_LINK related bits in the ports tree.
Once pkg_install is gone then LATEST_LINK can go away
I think I see. You're thinking of packages that install the same files,
but maybe in a different location (eg. SITE_PERL) or that register
run-time dependencies on a number of different possible providers.
Couldn't that boil down to having several alternate .MANIFEST files in
the pkg? Plus some sort of final-location-independent way of naming the
files to be installed by the package?
On the matter of having alternate RUN_DEPENDS to be set at install time?
I've wanted to do something like that with databases/phpmyadmin for
ages. Most of the optional dependencies there are autodetected by the
PHP code at run-time, so it should be possible to just ask the user
which of them they want to have during pkg installation.
That is over complicated imho, and I don't like much the interactive installers,
most of people would want to automated the whole installing process.
regards,
Bapt
pgpJJzV8oR0gm.pgp
Description: PGP signature
Re: ports need a uniq identifier, do you have any suggestion?
Baptiste Daroussin wrote:
Perhaps we could introduce UNIQUE_ORIGIN which is
${ORIGIN}_${SUBPACKAGE} or something of the sort?
I thought about this one, but while here we should think about package move
which keeps being the same package, in that case origin will change, and the
uniquename will change which is no good for binary world.
Does pkgng handle MOVED during upgrades? If so, ${ORIGIN}_${SUBPACKAGE}
will work fine, if not -- then it should; relying on unique name not to
change is fragile.
For example when audio/polypaudio was renamed to audio/pulseaudio, it
would be unreasonable to keep it's unique name as polyaudio.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports need a uniq identifier, do you have any suggestion?
On 11-6-2012 12:32, Baptiste Daroussin wrote: On Mon, Jun 11, 2012 at 07:36:15AM +0100, Matthew Seaman wrote: On 11/06/2012 05:30, Baptiste Daroussin wrote: In the ports tree we lack a unique identifier, while we could live without it until now, it is more than needed for 2 upcoming features: pkgng and stage directory support. unique means something that will always be the same what ever the options are and what ever the runtime they use are. But also means unique in term of in the whole ports no other package will share its identifier. currently the only equivalent of this in the ports tree is the origin of a package, which will no more be unique with the upcoming sub package support (coming along with stage directory) aka 1 origin to produce n package. UNIQUENAME and LATEST_LINK fails in that area because they both can change according to the runtime: py27- for example which will become py30- if you change the default python. LATEST_LINK by default also append the PKGNAMEPREFIX which some ports can be really creative with. should we introduce something new, should we fix one of the above? do you have any suggestion? UNIQUENAME is a clear name. Abusing it should simply not happen and this is a case of badly chosen defaults. This is a variable that should not have a default as it's too expensive to check whether the chosen default lives up to the standard (being ports-tree wide unique), unless you make this a UUID, which is probably not desirable from an operator/transparency perspective to have a hierarchy like: /var/db/ports/---/options. Ideally, a port maintainer should assign a uniquename and be responsible for it. In turn, bsd.port.mk should throw a fit if UNIQUENAME is not set rather then providing a guess that works most of the time. I was looking at this. You'ld think from the name that UNIQUENAME is the appropriate variable here. Yet by my calculations there are 1439 ports using non-unique UNIQUENAME variables. Fixing that seems like common sense to me: why call it unique if it isn't? UNIQUENAME importance being because the default location for a port's OPTIONSFILE is derived from it, and non-uniqueness can lead to ports fighting over control of that file? Which is bad when unintentional, but can be useful for some related ports to share the same options settings. If you want to share an options file, you should share the OPTIONSFILE. Knowing what UNIQUENAME is used for should not be a vehicle to using it as in the future it can be used for more things or be disconnected from the functionality you were using it for. Maybe they are different packages, but they have the same options, and from pkgng we should be able to detect it as the same package just a different runtime which is what they are. Not if they install in version-specific site-packages. Then they really are different packages, since the packing list will be different after expansion of variables. If you count that as same package, then definitions are getting real fuzzy and I'm not sure how well that's going to play out in the long run. The degradation of UNIQUENAME is an excellent example of how things clearly named end up being not what they are. And finally there's the case where extra stuff gets patched or installed based on the interpreter version. Good example is various perl ports where functionality from a CPAN module has been integrated into the perl port itself. So, older modules installed with older versions have (one or more) extra dependencies. On the plus side, these ports don't change UNIQUENAME, but that is just an implementation issue. I don't know of any python ports that change dependencies based on interpreter version, but I wouldn't be surprised if there are some. All this only enforces my view that we should standardize versioned ports and I've started working on it. bsd.databases.mk will be the victim of my first iteration. -- Mel ___ 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: OPTIONSng and OPTIONS_SINGLE, OPTIONS_MULTI
On 11-6-2012 7:49, Matthew Seaman wrote:
Surely it is more sensible to say that OPTIONS_SINGLE is strictly
'choose one from these options.' Then you can implement 'zero or one of
these options' by:
OPTIONS_SINGLE= EXAMPLE
OPTIONS_SINGLE_EXAMPLE= FOO BAR BAZ BLURFL NONE_OF_THE_ABOVE
I like this approach and it would be nice if you can have a standard
none option, rendered in the dialog consistently none with text
none of the above, but translated to ${GROUPNAME}_NONE for the port
and optionsfile. The group should be indented so one sees what of the
above applies to.
So the definition would look like:
OPTIONS_NONEORONE= EXAMPLE
OPTIONS_NONEORONE_EXAMPLE= BLONDE BRUNETTE
And the port's test would be:
.if ${OPTIONS:MEXAMPLE_NONE}
# yay, no work for me
.else
# crap which one he pick
.endif
--
Mel
___
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
portupgrade omniORB
Hello. It looks like I cannot portupgrade omniORB. Solution is to deinstall and reinstall, but I thought I'd report this. bye av. ... --- Uninstallation of omniORB-4.1.6 ended at: Mon, 11 Jun 2012 14:55:47 +0200 (consumed 00:00:12) --- Installation of devel/omniORB started at: Mon, 11 Jun 2012 14:55:47 +0200 --- Installing the new version via the port === Installing for omniORB-4.1.6 === omniORB-4.1.6 depends on file: /usr/local/bin/python2.7 - found === omniORB-4.1.6 depends on executable: pkg-config - found === Generating temporary packing list making install in ./src... gmake[1]: Entering directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src' making install in src/tool... gmake[2]: Entering directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src/tool' making install in src/tool/omkdepend... gmake[3]: Entering directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src/tool/omkdepend' + /usr/bin/install -c -o root -g wheel -m 0755 omkdepend /usr/local/bin gmake[3]: Leaving directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src/tool/omkdepend' making install in src/tool/omniidl... gmake[3]: Entering directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src/tool/omniidl' making install in src/tool/omniidl/cxx... gmake[4]: Entering directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src/tool/omniidl/cxx' making install in src/tool/omniidl/cxx/cccp... gmake[5]: Entering directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src/tool/omniidl/cxx/cccp' + /usr/bin/install -c -o root -g wheel -m 0755 omnicpp /usr/local/bin gmake[5]: Leaving directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src/tool/omniidl/cxx/cccp' gmake[4]: *** No rule to make target `/usr/local/include/omniORB4/CORBA_sysdep.h', needed by `y.tab.o'. Stop. gmake[4]: Leaving directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src/tool/omniidl/cxx' gmake[3]: *** [install] Error 2 gmake[3]: Leaving directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src/tool/omniidl' gmake[2]: *** [install] Error 2 gmake[2]: Leaving directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src/tool' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/usr/local/local/storage/tmp/usr/ports/devel/omniORB/work/omniORB-4.1.6/src' gmake: *** [install] Error 2 *** Error code 2 Stop in /usr/ports/devel/omniORB. *** Error code 1 Stop in /usr/ports/devel/omniORB. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20120611-27468-1wab2uj-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=omniORB-4.1.6 UPGRADE_PORT_VER=4.1.6 make -DFORCE_PKG_REGISTER reinstall --- Restoring the old version --- Removing old package' ** Fix the installation problem and try again. --- Installation of devel/omniORB ended at: Mon, 11 Jun 2012 14:55:53 +0200 (consumed 00:00:05) --- Reinstallation of devel/omniORB ended at: Mon, 11 Jun 2012 14:55:53 +0200 (consumed 00:05:49) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports need a uniq identifier, do you have any suggestion?
On Mon, Jun 11, 2012 at 03:31:30PM +0300, Vitaly Magerya wrote:
Baptiste Daroussin wrote:
Perhaps we could introduce UNIQUE_ORIGIN which is
${ORIGIN}_${SUBPACKAGE} or something of the sort?
I thought about this one, but while here we should think about package move
which keeps being the same package, in that case origin will change, and the
uniquename will change which is no good for binary world.
Does pkgng handle MOVED during upgrades? If so, ${ORIGIN}_${SUBPACKAGE}
will work fine, if not -- then it should; relying on unique name not to
change is fragile.
pkgng doesn't handle MOVED yet and having a unique identifier for for package
would simplify 90% of the move cases.
Plus ${ORIGIN}_${SUBPACKAGE} is fragile because you can have a port which is:
lang/mylang with a subpackage bla which will give lang/mylang_bla
and a port lang/mylang_bla with no subpackage which will give lang/mylang_bla
regards,
Bapt
pgpky7yDpR7JH.pgp
Description: PGP signature
Re: ports need a uniq identifier, do you have any suggestion?
On 11/06/2012 12:55, Baptiste Daroussin wrote:
why because they recommand their user to set PKGNAMEPREFIX to
${BLA_PKGNAMEPREFIX} so that their prefix can be set from bsd.port.mk
Which mean that until the said bsd.$guilty.mk is included UNIQUENAME name is
set
to ${PKGNAMEPREFIX}${PORTNAME} with PKGNAMEPREFIX being expanded to nothing
and once bsd.$guilty.mk is included ${PKGNAMEPREFIX} expands to something and
so
UNIQUENAME is changed. (btw also break the options framework (old and new)
with
the ports because OPTIONSFILE is created using the ${UNIQUENAME}
A light dawns. Yes. The value of $OPTIONSFILE cannot depend on
anything that happens in the port after bsd.port.options.mk is .include'd.
How about this (untested):
% cvs diff
cvs diff: Diffing .
Index: bsd.options.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.options.mk,v
retrieving revision 1.13
diff -u -r1.13 bsd.options.mk
--- bsd.options.mk 6 Jun 2012 11:47:29 - 1.13
+++ bsd.options.mk 11 Jun 2012 13:03:47 -
@@ -8,8 +8,6 @@
# global ones and ending with the ones decided by the maintainer.
# Options global to the entire ports tree
-OPTIONSFILE?= ${PORT_DBDIR}/${UNIQUENAME}/options
-
#ALL_OPTIONS= DOCS \
# NLS
Index: bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.727
diff -u -r1.727 bsd.port.mk
--- bsd.port.mk 8 Jun 2012 19:52:39 - 1.727
+++ bsd.port.mk 11 Jun 2012 13:06:35 -
@@ -1268,6 +1268,10 @@
UNIQUENAME?= ${PKGNAMEPREFIX}${PORTNAME}
.endif
+.if !defined(OPTIONSFILE)
+OPTIONSFILE:= ${PORT_DBDIR}/${UNIQUENAME}/options
+.endif
+
.endif
DOS2UNIX_REGEX?= .*
So OPTIONSFILE is at least independent of any changes to PKGNAMEPREFIX
made by bsd.$guilty.mk?
Port maintainers wishing to override the default OPTIONSFILE setting
should obviously do that before the inclusion of bsd.port.options.mk
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Re: ports need a uniq identifier, do you have any suggestion?
On Mon, Jun 11, 2012 at 02:17:21PM +0100, Matthew Seaman wrote:
On 11/06/2012 12:55, Baptiste Daroussin wrote:
why because they recommand their user to set PKGNAMEPREFIX to
${BLA_PKGNAMEPREFIX} so that their prefix can be set from bsd.port.mk
Which mean that until the said bsd.$guilty.mk is included UNIQUENAME name
is set
to ${PKGNAMEPREFIX}${PORTNAME} with PKGNAMEPREFIX being expanded to nothing
and once bsd.$guilty.mk is included ${PKGNAMEPREFIX} expands to something
and so
UNIQUENAME is changed. (btw also break the options framework (old and new)
with
the ports because OPTIONSFILE is created using the ${UNIQUENAME}
A light dawns. Yes. The value of $OPTIONSFILE cannot depend on
anything that happens in the port after bsd.port.options.mk is .include'd.
How about this (untested):
I tried what you did :) but it doesn't work
because
On first pass (before bsd.port.options.mk:
PORTNAME is test
UNIQUENAME is ${PKGNAMEPREFIX}${PORTNAME}
and PKGNAMEPREFIX is for example ${PYTHON_PKGNAMEPREFIX}
and ${PYTHON_PKGNAMEPREFIX} is empty.
which means after
BLA:= ${UNIQUENAME}
Only the first level is expanded and so:
BLA is now ${PYTHON_PKGNAMEPREFIX}test
if use in first pass then it becomes test
when used after bsd.port.pre.mk
PYTHON_PKGNAMEPREFIX become py27-
and so BLA is py27-
The joy of make(1)
% cvs diff
cvs diff: Diffing .
Index: bsd.options.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.options.mk,v
retrieving revision 1.13
diff -u -r1.13 bsd.options.mk
--- bsd.options.mk6 Jun 2012 11:47:29 - 1.13
+++ bsd.options.mk11 Jun 2012 13:03:47 -
@@ -8,8 +8,6 @@
# global ones and ending with the ones decided by the maintainer.
# Options global to the entire ports tree
-OPTIONSFILE?=${PORT_DBDIR}/${UNIQUENAME}/options
-
#ALL_OPTIONS=DOCS \
#NLS
Index: bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.727
diff -u -r1.727 bsd.port.mk
--- bsd.port.mk 8 Jun 2012 19:52:39 - 1.727
+++ bsd.port.mk 11 Jun 2012 13:06:35 -
@@ -1268,6 +1268,10 @@
UNIQUENAME?= ${PKGNAMEPREFIX}${PORTNAME}
.endif
+.if !defined(OPTIONSFILE)
+OPTIONSFILE:=${PORT_DBDIR}/${UNIQUENAME}/options
+.endif
+
.endif
DOS2UNIX_REGEX?= .*
So OPTIONSFILE is at least independent of any changes to PKGNAMEPREFIX
made by bsd.$guilty.mk?
Port maintainers wishing to override the default OPTIONSFILE setting
should obviously do that before the inclusion of bsd.port.options.mk
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
pgpVgBektxz0Z.pgp
Description: PGP signature
Re: NOPORTDOCS and NOPORTEXAMPLES
On Mon, Jun 11, 2012 at 08:00:53AM -0600, Warren Block wrote:
On Mon, 11 Jun 2012, Baptiste Daroussin wrote:
On Sun, Jun 10, 2012 at 06:05:49PM -0600, Warren Block wrote:
On Sun, 10 Jun 2012, Jason Helfman wrote:
So references to NOPORTDOCS should be replaced with references to
PORT_OPTIONS:MDOCS now? Why that but not NOPORTEXAMPLES?
You can use PORT_OPTIONS:MEXAMPLES for this case.
I believe I did this recently in www/flot
But only after bsd.port.options.mk is included. Here's what I was
trying to do:
.if ${PORT_OPTIONS:MDOCS}
OPTIONS_DEFINE+=REFDOCS
REFDOCS_DESC= Install the reference documents
OPTIONS_DEFAULT+= REFDOCS
.endif
.if ${PORT_OPTIONS:MEXAMPLES}
OPTIONS_DEFINE+=EXAMPLES
EXAMPLES_DESC= Install the example code
OPTIONS_DEFAULT+= EXAMPLES
.endif
.include bsd.port.options.mk
Why not simply that way:
OPTIONS_DEFINE= ... DOCS EXAMPLES
DOCS_DESC= Install the reference documents
And done.
Condtion an EXAMPLES on EXAMPLES options doesn't make sense to me.
by default DOCS and EXAMPLES are on expect if the user set NOPORTDOCS,
NOPORTEXAMPLES or OPTIONS_UNSET= DOCS EXAMPLES
The logic has probably gotten twisted around, and it's been long enough
since I did this that I don't recall the situation. I think it was just
to prevent the options screen from appearing if NOPORTDOCS and
NOPORTEXAMPLES were set.
I don't see a way to do that without using the old versions of those
variables. The new ones have not been set until after
bsd.port.options.mk is included, and by then the dialog has been shown.
Do not put OPTIONS_DEFINE and you won't get a dialog UI but still can test
PORT_OPTIONS:MEXAMPLES and PORT_OPTIONS:MDOCS
regards,
Bapt
pgp9FhE6dEj0R.pgp
Description: PGP signature
Re: NOPORTDOCS and NOPORTEXAMPLES
On Mon, 11 Jun 2012, Baptiste Daroussin wrote: The logic has probably gotten twisted around, and it's been long enough since I did this that I don't recall the situation. I think it was just to prevent the options screen from appearing if NOPORTDOCS and NOPORTEXAMPLES were set. I don't see a way to do that without using the old versions of those variables. The new ones have not been set until after bsd.port.options.mk is included, and by then the dialog has been shown. Do not put OPTIONS_DEFINE and you won't get a dialog UI but still can test PORT_OPTIONS:MEXAMPLES and PORT_OPTIONS:MDOCS The original: .if !defined(NOPORTDOCS) OPTIONS+= REFDOCS Install the reference documents on .endif .if !defined(NOPORTEXAMPLES) OPTIONS+= EXAMPLES Install the example code on .endif .include bsd.port.options.mk So if the user has set NOPORTDOCS in make.conf, that option does not appear in the dialog. Likewise with NOPORTEXAMPLES, and if both are set, the dialog does not appear at all. If either docs or examples are allowed, the user gets the chance to turn them off for this port. ___ 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: libpng.so.6 missing
On Sun, 10 Jun 2012, Waitman Gobble wrote: Hi, I was reading the handbook about burning DVD's and thought I would check out K3b as recommended... so I attempted to install from ports. After an hour or so of the make script building a whole bunch of stuff my patience wore out, and I bailed. ports tree csup this morning. Now it seems many things that were working great will no longer load, it's missing libpng.so.6 # SciTE Shared object libpng.so.6 not found, required by libpangocairo-1.0.so.0 Always, yes, always read /usr/ports/UPDATING before updating ports. And if you've update the ports tree but not updated installed applications from it, do that first. 20120531: AFFECTS: users of graphics/png AUTHOR: din...@freebsd.org The PNG library has been updated to version 1.5.10. Please rebuild all ports that depend on it. If you use portmaster: portmaster -r png- If you use portupgrade: portupgrade -fr graphics/png___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/textproc/stardict3
Hi, for me it doesn't build with clang nor with gcc. clang++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -Wall -D_THREAD_SAFE -D_REENTRANT -DORBIT2=1 -I/usr/local/include/gtk-2.0 -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/pango-1.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libpng15 -I/usr/local/include/drm -I/usr/local/include/libgnomeui-2.0 -I/usr/local/include/libart-2.0 -I/usr/local/include/gconf/2 -I/usr/local/include/gnome-keyring-1 -I/usr/local/include/libgnome-2.0 -I/usr/local/include/libbonoboui-2.0 -I/usr/local/include/libgnomecanvas-2.0 -I/usr/local/include/gnome-vfs-2.0 -I/usr/local/lib/gnome-vfs-2.0/include -I/usr/local/include/orbit-2.0 -I/usr/local/include/libbonobo-2.0 -I/usr/local/include/bonobo-activation-2.0 -I/usr/local/include/libxml2 -I/usr/local/include/gail-1.0-I.. -I.. -I../src -I../src/lib -I../../lib/src -I/usr/local/include -O2 -pipe -fno-strict-aliasing -MT t_lookupdata.o -MD -MP -MF .deps/t_lookupdata.Tpo -c -o t_lookupdata.o t_lookupdata.cpp t_lookupdata.cpp:41:30: error: variable length array of non-POD element type 'std::vectorgchar *' std::vectorgchar * reslist[dictmask.size()]; ^ 1 error generated. gmake[2]: *** [t_lookupdata.o] Error 1 gmake[2]: Leaving directory `/tmp/usr/ports/textproc/stardict3/work/stardict-3.0.3/dict/tests' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/tmp/usr/ports/textproc/stardict3/work/stardict-3.0.3/dict' gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/textproc/stardict3. *** Error code 1 Stop in /usr/ports/textproc/stardict3. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20120611-5671-f1rp3x env UPGRADE_TOOL=portupgrade UPGRADE_PORT=stardict-3.0.3 UPGRADE_PORT_VER=3.0.3 make ** Fix the problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! textproc/stardict3 (stardict-3.0.3) (unknown build error) zsh: exit 1 sudo portupgrade -f stardict-3.0.3 With gcc it crushes in the same line. My system is 9-stable. I built stardict with GNOME support. Png and other ports had already upgraded at the moment of built. Is it problem only mine? On Sun, 2012-06-10 at 10:47 +0200, Matthias Apitz wrote: El día Tuesday, November 22, 2011 a las 05:37:03PM +, Max Brazhnikov escribió: On Fri, 18 Nov 2011 13:54:04 +0100, Matthias Apitz wrote: Hello, The port (ports tree from CVS) ports/textproc/stardict3 ports/textproc/stardict3 PORTVERSION=3.0.3 MAINTAINER= m...@freebsd.org installs fine on 10-CURRENT, but the application just crahes or runs into a CPU loop; if it runs into CPU loop there is a core file of 'troff', i.e. it seems that it started for some man page reason the troff(1) and after this it loops; Stardict has plugin for displaying man pages. ... I could go back to 3.0.3 and provide more details of the crash, but I can't debug or solve this on my own. Or should I file a bug report? backtrace would be nice to have. Hi Max, I've installed another fresh 10-CURRENT (r235646, ports from CVS as of May 19) and luckily it crashes again reproduceable; a bt of gdb looks like this: $ gdb /usr/local/bin/stardict stardict.core ... #0 0x2966868b in thr_kill () from /lib/libc.so.7 [New Thread 29c07e00 (LWP 100375/stardict)] [New Thread 29c03300 (LWP 100369/stardict)] [New Thread 29c03080 (LWP 100203/stardict)] (gdb) bt #0 0x2966868b in thr_kill () from /lib/libc.so.7 #1 0x295ffed6 in pthread_sigmask () from /lib/libthr.so.3 #2 0x296005ab in raise () from /lib/libthr.so.3 #3 0x2971ddea in abort () from /lib/libc.so.7 #4 0x291bb6ec in g_assertion_message () from /usr/local/lib/libglib-2.0.so.0 #5 0x291bbd4d in g_assertion_message_expr () from /usr/local/lib/libglib-2.0.so.0 #6 0x08118a6b in HttpClient::on_connected () #7 0x0805a232 in ?? () #8 0x0805e63a in ?? () #9 0x080b8e69 in std::operator+char, std::char_traitschar, std::allocatorchar () #10 0x080b8eab in std::operator+char, std::char_traitschar, std::allocatorchar () #11 0x28965591 in gtk_marshal_BOOLEAN__VOID () from /usr/local/lib/libgtk-x11-2.0.so.0 #12 0x2911bea3 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #13 0x29133992 in g_signal_handlers_block_matched () from /usr/local/lib/libgobject-2.0.so.0 #14 0x291359f0 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #15 0x29135c70 in g_signal_emit_by_name () from /usr/local/lib/libgobject-2.0.so.0 #16 0x289ce2f2 in gtk_target_list_unref () from /usr/local/lib/libgtk-x11-2.0.so.0 #17 0x289ce6a5 in gtk_target_list_unref () from /usr/local/lib/libgtk-x11-2.0.so.0 #18 0x289671c4 in
Re: NOPORTDOCS and NOPORTEXAMPLES
On Mon, Jun 11, 2012 at 08:17:08AM -0600, Warren Block wrote: On Mon, 11 Jun 2012, Baptiste Daroussin wrote: The logic has probably gotten twisted around, and it's been long enough since I did this that I don't recall the situation. I think it was just to prevent the options screen from appearing if NOPORTDOCS and NOPORTEXAMPLES were set. I don't see a way to do that without using the old versions of those variables. The new ones have not been set until after bsd.port.options.mk is included, and by then the dialog has been shown. Do not put OPTIONS_DEFINE and you won't get a dialog UI but still can test PORT_OPTIONS:MEXAMPLES and PORT_OPTIONS:MDOCS The original: .if !defined(NOPORTDOCS) OPTIONS+= REFDOCS Install the reference documents on .endif .if !defined(NOPORTEXAMPLES) OPTIONS+= EXAMPLES Install the example code on .endif .include bsd.port.options.mk So if the user has set NOPORTDOCS in make.conf, that option does not appear in the dialog. Likewise with NOPORTEXAMPLES, and if both are set, the dialog does not appear at all. If either docs or examples are allowed, the user gets the chance to turn them off for this port. While I understand it is not consistent and doesn't make much sense. It had sense at the time of the old framework because the old framework wasn't consistent, ie: NOPORTDOCS in make.conf had no effect on the default dialog. But now it is consistent NOPORTDOCS disable DOCS by default. but maybe the use want to set it on for that particular package. regards, Bapt pgpKITBKCU8ad.pgp Description: PGP signature
Re: ports need a uniq identifier, do you have any suggestion?
On Mon, Jun 11, 2012 at 02:17:21PM +0100, Matthew Seaman wrote:
On 11/06/2012 12:55, Baptiste Daroussin wrote:
why because they recommand their user to set PKGNAMEPREFIX to
${BLA_PKGNAMEPREFIX} so that their prefix can be set from bsd.port.mk
Which mean that until the said bsd.$guilty.mk is included UNIQUENAME name
is set
to ${PKGNAMEPREFIX}${PORTNAME} with PKGNAMEPREFIX being expanded to nothing
and once bsd.$guilty.mk is included ${PKGNAMEPREFIX} expands to something
and so
UNIQUENAME is changed. (btw also break the options framework (old and new)
with
the ports because OPTIONSFILE is created using the ${UNIQUENAME}
A light dawns. Yes. The value of $OPTIONSFILE cannot depend on
anything that happens in the port after bsd.port.options.mk is .include'd.
How about this (untested):
% cvs diff
cvs diff: Diffing .
Index: bsd.options.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.options.mk,v
retrieving revision 1.13
diff -u -r1.13 bsd.options.mk
--- bsd.options.mk6 Jun 2012 11:47:29 - 1.13
+++ bsd.options.mk11 Jun 2012 13:03:47 -
@@ -8,8 +8,6 @@
# global ones and ending with the ones decided by the maintainer.
# Options global to the entire ports tree
-OPTIONSFILE?=${PORT_DBDIR}/${UNIQUENAME}/options
-
#ALL_OPTIONS=DOCS \
#NLS
Index: bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.727
diff -u -r1.727 bsd.port.mk
--- bsd.port.mk 8 Jun 2012 19:52:39 - 1.727
+++ bsd.port.mk 11 Jun 2012 13:06:35 -
@@ -1268,6 +1268,10 @@
UNIQUENAME?= ${PKGNAMEPREFIX}${PORTNAME}
.endif
+.if !defined(OPTIONSFILE)
+OPTIONSFILE:=${PORT_DBDIR}/${UNIQUENAME}/options
+.endif
+
.endif
DOS2UNIX_REGEX?= .*
So OPTIONSFILE is at least independent of any changes to PKGNAMEPREFIX
made by bsd.$guilty.mk?
Port maintainers wishing to override the default OPTIONSFILE setting
should obviously do that before the inclusion of bsd.port.options.mk
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
This patch does the trick, I'm now running a script with that patch on to
discovers all the uniquename names which are not really uniq
regards,
Bapt
pgp9sq3hX90Pw.pgp
Description: PGP signature
Re: ports need a uniq identifier, do you have any suggestion?
On Mon, Jun 11, 2012 at 05:36:14PM +0200, Baptiste Daroussin wrote:
On Mon, Jun 11, 2012 at 02:17:21PM +0100, Matthew Seaman wrote:
On 11/06/2012 12:55, Baptiste Daroussin wrote:
why because they recommand their user to set PKGNAMEPREFIX to
${BLA_PKGNAMEPREFIX} so that their prefix can be set from bsd.port.mk
Which mean that until the said bsd.$guilty.mk is included UNIQUENAME name
is set
to ${PKGNAMEPREFIX}${PORTNAME} with PKGNAMEPREFIX being expanded to
nothing
and once bsd.$guilty.mk is included ${PKGNAMEPREFIX} expands to something
and so
UNIQUENAME is changed. (btw also break the options framework (old and
new) with
the ports because OPTIONSFILE is created using the ${UNIQUENAME}
A light dawns. Yes. The value of $OPTIONSFILE cannot depend on
anything that happens in the port after bsd.port.options.mk is .include'd.
How about this (untested):
% cvs diff
cvs diff: Diffing .
Index: bsd.options.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.options.mk,v
retrieving revision 1.13
diff -u -r1.13 bsd.options.mk
--- bsd.options.mk 6 Jun 2012 11:47:29 - 1.13
+++ bsd.options.mk 11 Jun 2012 13:03:47 -
@@ -8,8 +8,6 @@
# global ones and ending with the ones decided by the maintainer.
# Options global to the entire ports tree
-OPTIONSFILE?= ${PORT_DBDIR}/${UNIQUENAME}/options
-
#ALL_OPTIONS= DOCS \
# NLS
Index: bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.727
diff -u -r1.727 bsd.port.mk
--- bsd.port.mk 8 Jun 2012 19:52:39 - 1.727
+++ bsd.port.mk 11 Jun 2012 13:06:35 -
@@ -1268,6 +1268,10 @@
UNIQUENAME?= ${PKGNAMEPREFIX}${PORTNAME}
.endif
+.if !defined(OPTIONSFILE)
+OPTIONSFILE:= ${PORT_DBDIR}/${UNIQUENAME}/options
+.endif
+
.endif
DOS2UNIX_REGEX?= .*
So OPTIONSFILE is at least independent of any changes to PKGNAMEPREFIX
made by bsd.$guilty.mk?
Port maintainers wishing to override the default OPTIONSFILE setting
should obviously do that before the inclusion of bsd.port.options.mk
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
This patch does the trick, I'm now running a script with that patch on to
discovers all the uniquename names which are not really uniq
regards,
Bapt
Here is the patch :) http://people.freebsd.org/~bapt/realuniq.diff
pgp56GGJIm9Di.pgp
Description: PGP signature
Re: ports need a uniq identifier, do you have any suggestion?
On 11/06/2012 16:37, Baptiste Daroussin wrote: This patch does the trick, I'm now running a script with that patch on to discovers all the uniquename names which are not really uniq regards, Bapt Here is the patch :) http://people.freebsd.org/~bapt/realuniq.diff Aren't you going to initialise PKGUNIQUENAMESUFFIX anywhere? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: libpng.so.6 missing
Warren Block wbl...@wonkity.com wrote .. On Sun, 10 Jun 2012, Waitman Gobble wrote: Hi, I was reading the handbook about burning DVD's and thought I would check out K3b as recommended... so I attempted to install from ports. After an hour or so of the make script building a whole bunch of stuff my patience wore out, and I bailed. ports tree csup this morning. Now it seems many things that were working great will no longer load, it's missing libpng.so.6 # SciTE Shared object libpng.so.6 not found, required by libpangocairo-1.0.so.0 Always, yes, always read /usr/ports/UPDATING before updating ports. And if you've update the ports tree but not updated installed applications from it, do that first. 20120531: AFFECTS: users of graphics/png AUTHOR: din...@freebsd.org The PNG library has been updated to version 1.5.10. Please rebuild all ports that depend on it. If you use portmaster: portmaster -r png- If you use portupgrade: portupgrade -fr graphics/png Thanks for the info, I appreciate it. -- Waitman Gobble San Jose California USA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports need a uniq identifier, do you have any suggestion?
On Mon, Jun 11, 2012 at 04:48:58PM +0100, Matthew Seaman wrote:
On 11/06/2012 16:37, Baptiste Daroussin wrote:
This patch does the trick, I'm now running a script with that patch on to
discovers all the uniquename names which are not really uniq
regards,
Bapt
Here is the patch :) http://people.freebsd.org/~bapt/realuniq.diff
Aren't you going to initialise PKGUNIQUENAMESUFFIX anywhere?
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
No need except ports willing to have a custom PKGNAMEPREFIX but still wanted to
have a custom prefix anyway.
like
PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
PKGUNIQUEPREFIX=py-
which is not mandatory but can help avoiding UNIQUENAME collision
regards,
Bapt
pgpAUHmnEVSEv.pgp
Description: PGP signature
graphics/graphviz
On r236740M amd64, building graphics/graphiviz: In file included from gv_php_init.c:14: /usr/local/include/php/main/php.h:298: warning: function declaration isn't a prototype /usr/local/bin/swig1.3 -c++ -php5 -o gv_php.cpp ./gv.i CXXlibgv_php_la-gv_php.lo gv_php.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gv_php.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake[4]: *** [libgv_php_la-gv_php.lo] Error 1 gmake[4]: Leaving directory `/usr/ports/graphics/graphviz/work/graphviz-2.28.0/tclpkg/gv' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/graphics/graphviz/work/graphviz-2.28.0/tclpkg/gv' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/graphviz/work/graphviz-2.28.0/tclpkg' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/graphics/graphviz/work/graphviz-2.28.0' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/graphics/graphviz. *** [build] Error code 1 Stop in /usr/ports/graphics/graphviz. # make showconfig === The following configuration options are available for graphviz-2.28.0_1: ICONV=on: Build with ICONV support XPM=on: Build with XPM support DIGCOLA=on: DIGCOLA features in neato layout engine IPSEPCOLA=on: IPSEPCOLA features in neato layout engine NLS=on: Build with gettext support TK=off: Build with TK support PANGOCAIRO=off: build with pangocairo support RSVG=off: build with rsvg library GTK=off: build with gtk plugin GDK_PIXBUF=off: build with gdk pixbuf support GNOMEUI=off: build with libgnomeui support SMYRNA=off: SMYRNA large graph viewer (GTK is required) GVEDIT=off: gvedit (qt is required) MING=off: Build with ming plugin DEVIL=off: Build with devil plugin GHOSTSCRIPT=off: Build with ghostscript plugin PERL=on: Perl bindings (swig) PHP=on: PHP bindings (swig) PYTHON=on: Python bindings (swig) RUBY=on: Ruby bindings (swig) LUA=on: Lua bindings (swig) TCL=on: TCL bindings (swig) GUILE=on: Guile bindings (swig) === Use 'make config' to modify these settings # With the default config (no swig), port builds fine. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports need a uniq identifier, do you have any suggestion?
On 11/06/2012 17:05, Baptiste Daroussin wrote:
On Mon, Jun 11, 2012 at 04:48:58PM +0100, Matthew Seaman wrote:
On 11/06/2012 16:37, Baptiste Daroussin wrote:
This patch does the trick, I'm now running a script with that patch on to
discovers all the uniquename names which are not really uniq
regards,
Bapt
Here is the patch :) http://people.freebsd.org/~bapt/realuniq.diff
Aren't you going to initialise PKGUNIQUENAMESUFFIX anywhere?
No need except ports willing to have a custom PKGNAMEPREFIX but still wanted
to
have a custom prefix anyway.
like
PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}
PKGUNIQUEPREFIX= py-
which is not mandatory but can help avoiding UNIQUENAME collision
Not PREFIX --- SUFFIX. You have:
UNIQUENAME?=${PKGUNIQUENAMEPREFIX}${PORTNAME}${PKGUNIQUENAMESUFFIX}
^^
or is this part of some cunning plan to do with sub-ports?
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Re: portupgrade omniORB
11.06.2012 17:10, Andrea Venturoli wrote: Hello. It looks like I cannot portupgrade omniORB. Solution is to deinstall and reinstall, but I thought I'd report this. Thanks. I'll take a look. ___ 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: Documenting 'make config' options
On Sat, 9 Jun 2012, Warren Block wrote:
That's a nice idea, how do you make it work with dialog?
No idea, this is still the design phase. :) Actually, a message I now
can't find suggested that dialog may be able to do it unchanged.
Followup:
dialog --item-help \
--checklist Contrived options description example 21 70 15 \
ABC Enable ABC encapsulation of convoluted insoluble... on \
variations when the complementary quantum reversal feature is undesirable \
DOCS Build and install documentation on \
XYZ Enabling XYZ sets compiler go-fast stripes, defeats ..., off \
all safeguards, and begins a wholesale, awesome, breathtaking data mangling \
NLS Native Language Support via gettext utilities on
Here is a patch to do it.
To use, apply patch. Pick a port and edit the option descriptions to be
longer than 49 characters. Then run 'make config'.
Notes:
This patch only does descriptions for the plain options right now.
Changes to the multi and single options would be the same thing. (Not
done because I'm hoping someone better at make(1) will have cleaner
methods.)
There's a cosmetic problem. The last description line at the bottom of
the screen remains after dialog exits. I have not found a way to clear
it in dialog.--- bsd.port.mk.orig2012-06-11 08:53:43.0 -0600
+++ bsd.port.mk 2012-06-11 12:50:08.0 -0600
@@ -6017,11 +6017,14 @@
.if !target(pre-config)
pre-config:
_COMPLETE_OPTIONS_LIST:= ${ALL_OPTIONS}
+VIS_WIDTH= 49
.for opt in ${ALL_OPTIONS}
+${opt}_FIRST!= ${ECHO} ${${opt}_DESC:Q} | ${AWK} -F=\004 '{ ORS=; print
substr($$0,1,${VIS_WIDTH}); if (length($1)${VIS_WIDTH}){print +} }'
+${opt}_REST!= ${ECHO} ${${opt}_DESC:Q} | ${AWK} -F=\004 '{ print
substr($$0,${VIS_WIDTH}+1) }'
. if empty(PORT_OPTIONS:M${opt})
-DEFOPTIONS+= ${opt} ${${opt}_DESC:Q} off
+DEFOPTIONS+= ${opt} ${${opt}_FIRST:Q} off ${${opt}_REST:Q}
. else
-DEFOPTIONS+= ${opt} ${${opt}_DESC:Q} on
+DEFOPTIONS+= ${opt} ${${opt}_FIRST:Q} on ${${opt}_REST:Q}
. endif
.endfor
.for multi in ${OPTIONS_MULTI}
@@ -6069,7 +6072,7 @@
.endif
@TMPOPTIONSFILE=$$(mktemp -t portoptions); \
trap ${RM} -f $${TMPOPTIONSFILE}; exit 1 1 2 3 5 10 13 15; \
- ${DIALOG} --checklist Options for ${PKGNAME:C/-([^-]+)$/ \1/} 21 70
15 ${DEFOPTIONS} 2 $${TMPOPTIONSFILE} || { \
+ ${DIALOG} --item-help --checklist Options for ${PKGNAME:C/-([^-]+)$/
\1/} 21 70 15 ${DEFOPTIONS} 2 $${TMPOPTIONSFILE} || { \
${RM} -f $${TMPOPTIONSFILE}; \
${ECHO_MSG} === Options unchanged; \
exit 0; \
___
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: Documenting 'make config' options
On Mon, 11 Jun 2012, Warren Block wrote: Here is a patch to do it. To use, apply patch. Pick a port and edit the option descriptions to be longer than 49 characters. Then run 'make config'. Notes: This patch only does descriptions for the plain options right now. Changes to the multi and single options would be the same thing. (Not done because I'm hoping someone better at make(1) will have cleaner methods.) There's a cosmetic problem. The last description line at the bottom of the screen remains after dialog exits. I have not found a way to clear it in dialog. And another note: VIS_WIDTH is set to 49 because that is the size available for a description on a standard 80x24 terminal (less one column for a + indicator). But it can be dynamically determined with dialog --print-maxsize. ___ 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: Documenting 'make config' options
On 6/11/2012 2:03 PM, Warren Block wrote: On Sat, 9 Jun 2012, Warren Block wrote: That's a nice idea, how do you make it work with dialog? No idea, this is still the design phase. :) Actually, a message I now can't find suggested that dialog may be able to do it unchanged. Followup: dialog --item-help \ --checklist Contrived options description example 21 70 15 \ ABC Enable ABC encapsulation of convoluted insoluble... on \ variations when the complementary quantum reversal feature is undesirable \ DOCS Build and install documentation on \ XYZ Enabling XYZ sets compiler go-fast stripes, defeats ..., off \ all safeguards, and begins a wholesale, awesome, breathtaking data mangling \ NLS Native Language Support via gettext utilities on Here is a patch to do it. To use, apply patch. Pick a port and edit the option descriptions to be longer than 49 characters. Then run 'make config'. Notes: This patch only does descriptions for the plain options right now. Changes to the multi and single options would be the same thing. (Not done because I'm hoping someone better at make(1) will have cleaner methods.) There's a cosmetic problem. The last description line at the bottom of the screen remains after dialog exits. I have not found a way to clear it in dialog. Cool idea. FYI --item-help is not supported on 8.3 and earlier so a OSVERSION check is probably needed. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: OPTIONS framework unwell? Additional ports installed unexpectedly
On 02/06/2012 19:55, Baptiste Daroussin wrote: On Sat, Jun 02, 2012 at 01:57:58PM +1000, John Marshall wrote: I just had a whole bunch of ports install unexpectedly. portmaster -D -r png-1.4.11 One of the ports that pulled in for rebuilding was graphics/php5-gd. That's fair enough, and it is depended on by lang/php5-extensions, so that got pulled in too. That's fine, but then php5-extensions pulled in all of the other default extensions to *install* - all of the ones a have deselected in my config. === Done updating ports that depend on png-1.4.11 === The following actions were performed: Upgrade of png-1.4.11 to png-1.5.10 Upgrade of gd-2.0.35_7,1 to gd-2.0.35_8,1 Upgrade of p5-GD-2.46 to p5-GD-2.46_1 Installation of archivers/php5-phar (php5-phar-5.4.3) Installation of databases/php5-pdo_sqlite (php5-pdo_sqlite-5.4.3) Installation of databases/php5-sqlite3 (php5-sqlite3-5.4.3) Installation of devel/php5-json (php5-json-5.4.3) Installation of devel/php5-tokenizer (php5-tokenizer-5.4.3) Re-installation of php5-gd-5.4.3 Installation of security/php5-filter (php5-filter-5.4.3) Installation of sysutils/php5-posix (php5-posix-5.4.3) Installation of textproc/php5-simplexml (php5-simplexml-5.4.3) Installation of textproc/php5-xmlreader (php5-xmlreader-5.4.3) Installation of textproc/php5-xmlwriter (php5-xmlwriter-5.4.3) Re-installation of php5-extensions-1.7 Upgrade of rrdtool-1.2.30_1 to rrdtool-1.2.30_2 Upgrade of webalizer-geoip-2.23.5 to webalizer-geoip-2.23.5_1 So, what happened? Those extensions OPTIONS are all disabled in my config. (details were shown in OP) Thanks for reporting, apparently there might be a bug in the code that regenerate the WITH_/WITHOUT_ stuff needed by the old options stuff. I got frustrated with this and changed lang/php5-extensions/Makefile to use the new options. That avoids the problem and works for me. See: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168946 -- John Marshall signature.asc Description: OpenPGP digital signature
graphics/libfpx: use of bsd.lib.mk and warnings
[Cc-ing mailing list just in case it is useful for other port maintainers] Mikhail, I see that graphics/libfpx uses a custom FreeBSD-specific makefile which makes use of bsd.lib.mk and sets WARNS to 3. I think that this is an unsustainable approach. First, the external libraries are not under our control and may adhere to some different policy with respect to warnings. Second, different compilers (gccXY, clang) may be used to compile ports and they may produce new warnings-come-errors. Right now, this is an issue for me with gcc46 as a ports compiler. I think that the best solution here is NO_WERROR. What do you and other port guys think about this? -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
graphics/djview4: QMAKESPEC override?
Writing to both a formal maintainer and a more realistic maintainer.
graphics/djview4 Makefile has this:
.if defined(CXX) ${CXX:M*icc}
QMAKESPEC?= freebsd-icc
.else
QMAKESPEC?=freebsd-g++
.endif
This snippet is before bsd.port.pre.mk inclusion. Thus, it overrides the logic
for QMAKESPEC selection in bsd.qt.mk for no apparent good reason.
Removing it doesn't break anything and fixes compilation with gcc46 too.
P.S. Does anyone actually uses icc on FreeBSD to build ports? I doubt that
very much.
--
Andriy Gapon
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
On Sat, 9 Jun 2012, Doug Barton wrote: In an ideal world, we would have separate packages for the runtime libs and the build tools so that packages could be more portable, but I would imagine that would be a lot of work. I looked into that last year and found that the FreeBSD ports infrastructure was not exactly helpful. Ideally I would want something like gcc46-runtime and gcc46-java and gcc46 itself, where -runtime is a hard dependency for gcc46 and -java optional. Short of building lang/gcc46 a couple of times via slave ports and packaging different aspects by virtue of different slave ports, or having gcc46 also include the contents of gcc46-runtime, the introduction of a gcc46-DONT-USE-JUST-USED-FOR-SUBPACKAGES dummy port was the only idea I came up with. None of the three approaches really convinced me. On Sun, 10 Jun 2012, Baptiste Daroussin wrote: Yes that would be a lot of but it is the way we are doing. the upcoming stagedir will open the door to easy package splitting and then allow easily to split gcc into something like gcc-libs and gcc package or something like that. Lovely. Looking forward to that! (Chris also indicated he had an idea, let's see. Whatever works. ;-) Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pkg_version -vIL= outputs several succeeds index entries.
{The author of this post has been Chad Perrin approved}
I just ran portsnap followed by pkg_version -vIL= and received this
output. Somehow this just doesn't look kosher.
bn-freebsd-doc-20120506succeeds index (index has 39016)
da-freebsd-doc-20120506succeeds index (index has 39016)
de-freebsd-doc-20120506succeeds index (index has 39016)
el-freebsd-doc-20120506succeeds index (index has 39016)
en-freebsd-doc-20120506succeeds index (index has 39016)
es-freebsd-doc-20120506succeeds index (index has 39016)
fr-freebsd-doc-20120506succeeds index (index has 39016)
hu-freebsd-doc-20120506succeeds index (index has 39016)
it-freebsd-doc-20120506succeeds index (index has 39016)
ja-freebsd-doc-20120506succeeds index (index has 39016)
mn-freebsd-doc-20120506succeeds index (index has 39016)
nl-freebsd-doc-20120506succeeds index (index has 39016)
pl-freebsd-doc-20120506succeeds index (index has 39016)
pt-freebsd-doc-20120506succeeds index (index has 39016)
ru-freebsd-doc-20120506succeeds index (index has 39016)
sr-freebsd-doc-20120506succeeds index (index has 39016)
tr-freebsd-doc-20120506succeeds index (index has 39016)
zh_cn-freebsd-doc-20120506 succeeds index (index has 39016)
zh_tw-freebsd-doc-20120506 succeeds index (index has 39016)
--
Jerry ♔
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port unmaintained since 2005? drop it? misc/gpt*
On Mon, Jun 11, 2012 at 2:33 AM, b. f. bf1...@googlemail.com wrote: On 6/11/12, Michael Scheidell scheid...@freebsd.org wrote: On 6/10/12 11:14 PM, b. f. wrote: The distribution files are at: ftp://ftp.ncsa.uiuc.edu/aces/gpt/releases and the homepage is: http://grid.ncsa.illinois.edu/gpt/ (And Globus is at: http://www.globus.org/toolkit/ ) Time to determine this: 1 min. b. glad to know you are volunteering to maintain these ports. I will resurrect globus from the archives (where it has been since 2008, see /usr/ports/MOVED), which email address do you want in the MAINTAINER= line? Heh, not so fast. I've got other things to do first. I was just pointing out that it is not so hard to correct some of the stale information, and it is useful to do this as a pointer to those who may wish to more actively maintain the port later, even if it is moved to the attic in a few months. I should add that globus comes with a bundled version of gpt, and I think the Debian port is based upon this -- it's at 3.6.x. Also, that brooks@, who was involved in adding this port and other related software, could probably tell you more about grid software. Well, there may be some users coming out of the woodwork for this port. I noticed the following vulnerability alert today: CVE-2012-3292 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3292 ___ 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: UID/GID_OFFSET (Was: Re: WITH_GCC)
On Fri, 25 May 2012, Mel Flynn wrote:
On 20-5-2012 14:06, Chris Rees wrote:
Usually. Sometimes it's (ab)used to include the relevant bsd.*.mk
file without adding dependencies (WANT_GNOME), but normally that's
what WANT_ is used for.
Definitely add a warning that if you want to use a WANT_ variable you
should also check the relevant Mk/ files to check for syntax.
What's also not consistent is the use of:
USE_FOO=42+
which is shorthand for:
USE_FOO=yes
WANT_FOO_VER= 42+
Anyway, since Warren is on the job, on one of my travels through pmk, I
turned a corner and met these totally awesome user settable variables:
UID_OFFSET
GID_OFFSET
No docs on them in pmk itself or share/examples/etc/make.conf. What they
do is add the specified number to the UID and GID that a port defines by
using /usr/ports/{UIDS,GIDS}. This is extremely useful if you are using
multiple jails on one machine and don't want the uid's to clash (shared
memory for example).
It's also useful, if you have different providers for uid/gid
information through the use of NSS modules. Knowing that ports won't
ever get into your module range makes you sleep better.
Example in /etc/make.conf
UID_OFFSET= 2
GID_OFFSET= ${UID_OFFSET} # best to keep them equal
Installing for example postgresql, will now use uid/gid 20070 instead of 70.
Okay, I've finally cleared some room to work on this; sorry about the
delay.
My main question is where to add these descriptions. Should they go in
existing sections where possible? Or are we talking about a new
section, and if so, where? At the end of the Dependencies section?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port unmaintained since 2005? drop it? misc/gpt*
On Mon, Jun 11, 2012 at 01:45:40AM -0400, Michael Scheidell wrote: On 6/11/12 4:31 AM, per...@pluto.rain.com wrote: Dunno what (if anything) they are currently good for, but it seems that, at a minimum, the PORTVERSION and/or MASTER_SITES -- and the pkg-descr -- need to be updated. They still don't build. And, they still aren't need by anything in ports tree (again, globus was deleted from ports tree in 2008) anyone want to maintain them? I'll tag your name on the ports for you. As the person who originally ported and committed them, I say they should be taken out and shot. They were unmaintainable from the start without a significant number of users to drive the upstream to stop making bad decisions. -- Brooks pgpwlwIKa9BIq.pgp Description: PGP signature
Re: libpng.so.6 missing
Kevin Oberman kob6...@gmail.com wrote .. On Sun, Jun 10, 2012 at 10:52 PM, Michael Scheidell scheid...@freebsd.org wrote: On 6/11/12 1:44 AM, Waitman Gobble wrote: Hi, I was reading the handbook about burning DVD's and thought I would check out K3b as recommended... so I attempted to install from ports. After an hour or so of the make script building a whole bunch of stuff my patience wore out, and I bailed. ports tree csup this morning. Now it seems many things that were working great will no longer load, it's missing libpng.so.6 # SciTE Shared object libpng.so.6 not found, required by libpangocairo-1.0.so.0 # qtcreator Shared object libpng.so.6 not found, required by libQtGui.so.4 # xxxterm Shared object libpng.so.6 not found, required by libwebkitgtk-1.0.so.0 etc, etc. and so on. Anyhow, i am not sure which package 'libpng.so.6' comes from.. anyone have a tip or a pointer? something is still looking for an old version of png (libpng.so.6), the new version of png uses lib: libpng.so.15. Did you rebuild all packages from source? quick 'cheat' would be to restore libpng.so.6 to compat library from your backup, or another system. Install sysutils/bsdadminscripts and 'pkg_chklib -o | grep libpng | sort'. This will provide a list of ports that need to be re-installed so that they will be linked to the new libpng. As pkg_chklib reports on every file that references the old libpng, you may see ports listed several times, once for every executable or shareable that references libpng.so.6. This will really fix the problem. Pulling in a copy of libpng.so.6 might make things work, but may fail if more than one version of libpng is linked to different shareables or executables. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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 Again, thanks for the info. It seems that the script may be pkg_libchk instead of pkg_chklib (?) please confirm. I ran pkg_libchk and it looks like a whole boatload of packages need to be replaced, so I decided to skip to the chase and give the update script a 'replace' option.. it checks the package version available in the packages directory on the freebsd site with what's installed, if there's a newer version it downloads it and does the MD5 check, creates an update.sh script to replace (the update script doesn't actually do any udpating!) Anyhow, with 'replace' it will either replace the existing or use the newer if available. I've been using this script to update the system and it works pretty good for me, except when I veer off path and get into ports like with my libpng issue. :) Anyhow, hopefully this will fix it, I'll try it later tonight. Gotta run. -- Waitman Gobble San Jose California USA ___ 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: libpng.so.6 missing
On Mon, 11 Jun 2012, Waitman Gobble wrote: I ran pkg_libchk and it looks like a whole boatload of packages need to be replaced, so I decided to skip to the chase and give the update script a 'replace' option.. it checks the package version available in the packages directory on the freebsd site with what's installed, if there's a newer version it downloads it and does the MD5 check, creates an update.sh script to replace (the update script doesn't actually do any udpating!) Anyhow, with 'replace' it will either replace the existing or use the newer if available. I've been using this script to update the system and it works pretty good for me, except when I veer off path and get into ports like with my libpng issue. :) There is a pkg_upgrade command in the bsdadminscripts, too. However, pkgng will change all that soon. ___ 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: libpng.so.6 missing
Warren Block wbl...@wonkity.com wrote .. On Mon, 11 Jun 2012, Waitman Gobble wrote: I ran pkg_libchk and it looks like a whole boatload of packages need to be replaced, so I decided to skip to the chase and give the update script a 'replace' option.. it checks the package version available in the packages directory on the freebsd site with what's installed, if there's a newer version it downloads it and does the MD5 check, creates an update.sh script to replace (the update script doesn't actually do any udpating!) Anyhow, with 'replace' it will either replace the existing or use the newer if available. I've been using this script to update the system and it works pretty good for me, except when I veer off path and get into ports like with my libpng issue. :) There is a pkg_upgrade command in the bsdadminscripts, too. However, pkgng will change all that soon. Thanks, I tried pkgng a few months ago and it didn't seem to do updates... but I recall many updates on the mail list so I'm sure it's much different now, and works much better. I'll definitely check it out. My update script fixed all problems with libpng, I ran pkg_libchk to verify. I'm glad to know about pkg_libchk, that's a great way to see if there are issues. My system is now working properly, yay. It's really simple, it just looks at what is installed and compares to what's available on freebsd.org, and that's about it. The script does not care about dependencies or what's in ports, etc, which I suppose could be a bad thing. But I've had luck. In my mind the dependencies are already on the system and as long as it's not a major version change there are likely to be no issues. But I've found that (for example) deleting the 2.x pkgs and installing 3.x can cause problems. I am not 100% sure I actually needed to 'reinstall' the packages - b/c it seems like it would essentially pull the same files with same dependencies i think.. Anyhow, I will take a look at the pkg_upgrade script, it would be good to have better automation, as I still have to go through the list of updates and manually mark the ones I don't want to mess with. For example, docbook.. it seems xfce (i think) pulls in like 5 different versions, so the update script gets confused about that. Thanks for the help. -- Waitman Gobble San Jose California USA ___ 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: libpng.so.6 missing
On Mon, Jun 11, 2012 at 10:07:22PM -0700, Waitman Gobble wrote: Warren Block wbl...@wonkity.com wrote .. On Mon, 11 Jun 2012, Waitman Gobble wrote: I ran pkg_libchk and it looks like a whole boatload of packages need to be replaced, so I decided to skip to the chase and give the update script a 'replace' option.. it checks the package version available in the packages directory on the freebsd site with what's installed, if there's a newer version it downloads it and does the MD5 check, creates an update.sh script to replace (the update script doesn't actually do any udpating!) Anyhow, with 'replace' it will either replace the existing or use the newer if available. I've been using this script to update the system and it works pretty good for me, except when I veer off path and get into ports like with my libpng issue. :) There is a pkg_upgrade command in the bsdadminscripts, too. However, pkgng will change all that soon. Thanks, I tried pkgng a few months ago and it didn't seem to do updates... but I recall many updates on the mail list so I'm sure it's much different now, and works much better. I'll definitely check it out. It does, but you need a working repository for it. pgp4qAIwWWtGS.pgp Description: PGP signature
