Re: [ HEADS UP ] Ports unstable for the next 10 days
On 28/03/2010 15:38, Ion-Mihai Tetcu wrote:
We do _NOT_ recommend updating ports until this commits are all done,
and the problems are fixed, except if you want to help testing / fixing.
A small fix for graphics/php5-gd. It builds without the patch, but
doesn't work without it.
diff -Nur php5-gd.orig/files/patch-ext-gd-libgd-gd_png.c
php5-gd/files/patch-ext-gd-libgd-gd_png.c
--- php5-gd.orig/files/patch-ext-gd-libgd-gd_png.c 1970-01-01
01:00:00.0 +0100
+++ php5-gd/files/patch-ext-gd-libgd-gd_png.c 2010-03-29 09:38:38.0
+0200
@@ -0,0 +1,11 @@
+--- libgd/gd_png.c.orig2010-03-29 09:33:02.0 +0200
libgd/gd_png.c 2010-03-29 09:35:15.0 +0200
+@@ -139,7 +139,7 @@
+ return NULL;
+ }
+
+- if (!png_check_sig (sig, 8)) { /* bad signature */
++ if (png_sig_cmp (sig, 0, 8) != 0) { /* bad signature */
+ return NULL;
+ }
+
___
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: [ HEADS UP ] Ports unstable for the next 10 days
2010/3/29 Garrett Cooper yanef...@gmail.com: On Sun, Mar 28, 2010 at 7:17 PM, Aristedes Maniatis a...@ish.com.au wrote: On 29/03/10 1:15 PM, Garrett Cooper wrote: portmaster -r png- Is that correct? I haven't seen that notation before (although I might just have missed it in the docs). I would have used portmaster -r graphics/png And yes, the directions are still wrong; it should be: portmaster -r 'png-*' Similarly since this was just a copy-paste of the jpeg instructions, those ones are wrong as well. Given that the PORTREVISION of all dependent ports are bumped, a simple 'portupgrade -a' or 'portmaster -a' should suffice. Or am I missing something? Rene ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts
Am 28.03.2010, 08:14 Uhr, schrieb Garrett Cooper:
Hi,
As part of taking a look at the differences in our implementation
of pkg_install(1) in order to afford an improvement over the existing
code, I've looked at various implementations of pkg_install, one being
NetBSD's evolution [1]. It's several years ahead from our's and while
I don't believe that all of the complexity is desired, there's a lot
of good lessons to be learned from this. One of which is that they
replaced the @exec and @unexec calls with string pre-install //
post-install and pre-deinstall // post-deinstall scripts. I think that
this potentially is a good step forward because it takes some of the
guts out of the +CONTENTS files and places it in [bourne shell]
scripts, which are easier to maintain and potentially understand.
I realize that some of the loss would be that one couldn't simply
specify things like %f, %D, %F, etc with @exec and @unexec, but that
seems a small price to pay for tuning everything a bit more. On the
plus side too, that means that one could use an extensive set of
shell, etc libraries that would avoid code duplication like what's
present in the +CONTENTS files. This is one of the small observations
I made after starting on work which would modify 1k python ports to
not install the byte-compiled or optimized files (side topic that we
can talk about in another thread if desired).
Thoughts?
Hi Garrett,
I'm not so sure what the advantage would be. For trivial
pre-post-(de)install tasks, why use a separate script? It's less concise
than reading everything in pkg-plist.
WRT variables, I'm not so concerned about %D %F etc, but I am concerned
about the necessity to add script boilerplate (such as snatching pre-post
or deinstall-install modes, prefix), and while I haven't thoroughly
audited the install scripts in ports, I see lots of bad shell scripts
around. These would need rigorous audits (in adverse conditions, such as
paths containing blanks and shell meta characters to unveil underquoted
parameters/variables).
Also, this effort alone isn't any help in reducing code duplication, as in
my perception the duplication is between Makefile (for port install) and
pkg-plist/pkg-install (for packages). There often is some line similar to
${SETENV} PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME}
POST-INSTALL
in the ports' Makefiles (post-install or whereever appropriate).
Also, this would need excellent documentation. RPM on Linux is similarly
flexible, but is severely underdocumented (at least RPM v3 and v4 on
openSUSE Linux are). If it does any _undocumented_ magic, I don't want it.
:)
So, before we think about it and harrass hundreds of ports maintainers,
we'd need the shell script library in place to make it a selling point for
actually using install scripts; at that point we can re-think about moving
stuff out of pkg-plist into pkg-install scripts. At the *same* time (so
that only one edit cycle is needed for affected ports - and I'd suggest a
survey to see how many, hundreds probably), we should consider making
Mk/bsd.port.mk call the install scripts automatically (needs changes to
hundreds of ports again) in pre-install, post-install and related stages.
HTH
--
Matthias 'mandree@' Andree
FreeBSD ports committer
___
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: [ HEADS UP ] Ports unstable for the next 10 days
On 28/03/2010 15:38, Ion-Mihai Tetcu wrote:
We do _NOT_ recommend updating ports until this commits are all done,
and the problems are fixed, except if you want to help testing / fixing.
Fix for graphics/evas-loader-png.
diff -Nur
evas-loader-png.orig/files/patch-src-modules-loaders-png-evas_image_load_png.c
evas-loader-png/files/patch-src-modules-loaders-png-evas_image_load_png.c
---
evas-loader-png.orig/files/patch-src-modules-loaders-png-evas_image_load_png.c
1970-01-01 01:00:00.0 +0100
+++ evas-loader-png/files/patch-src-modules-loaders-png-evas_image_load_png.c
2010-03-29 09:54:23.0 +0200
@@ -0,0 +1,11 @@
+--- src/modules/loaders/png/evas_image_load_png.c.orig 2010-03-29
09:51:19.0 +0200
src/modules/loaders/png/evas_image_load_png.c 2010-03-29
09:52:29.0 +0200
+@@ -44,7 +44,7 @@
+ fclose(f);
+ return 0;
+ }
+- if (!png_check_sig(buf, PNG_BYTES_TO_CHECK))
++ if (png_sig_cmp(buf, 0, PNG_BYTES_TO_CHECK) != 0)
+ {
+ fclose(f);
+ return 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: [ HEADS UP ] Ports unstable for the next 10 days
On 29/03/2010 09:58, Dominic Fandrey wrote:
On 28/03/2010 15:38, Ion-Mihai Tetcu wrote:
We do _NOT_ recommend updating ports until this commits are all done,
and the problems are fixed, except if you want to help testing / fixing.
Fix for graphics/evas-loader-png.
Sorry, wrong patch. This is the one:
diff -Nur
evas-loader-png.orig/files/patch-src-modules-loaders-png-evas_image_load_png.c
evas-loader-png/files/patch-src-modules-loaders-png-evas_image_load_png.c
---
evas-loader-png.orig/files/patch-src-modules-loaders-png-evas_image_load_png.c
1970-01-01 01:00:00.0 +0100
+++ evas-loader-png/files/patch-src-modules-loaders-png-evas_image_load_png.c
2010-03-29 10:01:37.0 +0200
@@ -0,0 +1,20 @@
+--- src/modules/loaders/png/evas_image_load_png.c.orig 2007-10-28
11:35:13.0 +0100
src/modules/loaders/png/evas_image_load_png.c 2010-03-29
10:01:31.0 +0200
+@@ -44,7 +44,7 @@
+ fclose(f);
+ return 0;
+ }
+- if (!png_check_sig(buf, PNG_BYTES_TO_CHECK))
++ if (png_sig_cmp(buf, 0, PNG_BYTES_TO_CHECK) != 0)
+ {
+ fclose(f);
+ return 0;
+@@ -121,7 +121,7 @@
+
+/* if we havent read the header before, set the header data */
+fread(buf, 1, PNG_BYTES_TO_CHECK, f);
+- if (!png_check_sig(buf, PNG_BYTES_TO_CHECK))
++ if (png_sig_cmp(buf, 0, PNG_BYTES_TO_CHECK) != 0)
+ {
+ fclose(f);
+ return 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: [ HEADS UP ] Ports unstable for the next 10 days
On 28/03/2010 15:38, Ion-Mihai Tetcu wrote:
We do _NOT_ recommend updating ports until this commits are all done,
and the problems are fixed, except if you want to help testing / fixing.
The already committed graphics/imlib2 patch does not work,
i.e. it compiles, but png doesn't work, with this one it does:
diff -Nur imlib2.orig/files/patch-loader_png.c imlib2/files/patch-loader_png.c
--- imlib2.orig/files/patch-loader_png.c2010-03-29 10:12:43.0
+0200
+++ imlib2/files/patch-loader_png.c 2010-03-29 10:08:41.0 +0200
@@ -5,7 +5,7 @@
/* if we haven't read the header before, set the header data */
fread(buf, 1, PNG_BYTES_TO_CHECK, f);
-if (!png_check_sig(buf, PNG_BYTES_TO_CHECK))
-+if (png_check_sig(buf, 0, PNG_BYTES_TO_CHECK))
++if (png_sig_cmp(buf, 0, PNG_BYTES_TO_CHECK) != 0)
{
fclose(f);
return 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: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts
On Mon, Mar 29, 2010 at 7:58 AM, Matthias Andree matthias.and...@gmx.de wrote:
Am 28.03.2010, 08:14 Uhr, schrieb Garrett Cooper:
Hi,
As part of taking a look at the differences in our implementation
of pkg_install(1) in order to afford an improvement over the existing
code, I've looked at various implementations of pkg_install, one being
NetBSD's evolution [1]. It's several years ahead from our's and while
I don't believe that all of the complexity is desired, there's a lot
of good lessons to be learned from this. One of which is that they
replaced the @exec and @unexec calls with string pre-install //
post-install and pre-deinstall // post-deinstall scripts. I think that
this potentially is a good step forward because it takes some of the
guts out of the +CONTENTS files and places it in [bourne shell]
scripts, which are easier to maintain and potentially understand.
I realize that some of the loss would be that one couldn't simply
specify things like %f, %D, %F, etc with @exec and @unexec, but that
seems a small price to pay for tuning everything a bit more. On the
plus side too, that means that one could use an extensive set of
shell, etc libraries that would avoid code duplication like what's
present in the +CONTENTS files. This is one of the small observations
I made after starting on work which would modify 1k python ports to
not install the byte-compiled or optimized files (side topic that we
can talk about in another thread if desired).
Thoughts?
Hi Garrett,
I'm not so sure what the advantage would be. For trivial
pre-post-(de)install tasks, why use a separate script? It's less concise
than reading everything in pkg-plist.
WRT variables, I'm not so concerned about %D %F etc, but I am concerned
about the necessity to add script boilerplate (such as snatching pre-post or
deinstall-install modes, prefix), and while I haven't thoroughly audited the
install scripts in ports, I see lots of bad shell scripts around. These
would need rigorous audits (in adverse conditions, such as paths containing
blanks and shell meta characters to unveil underquoted
parameters/variables).
Also, this effort alone isn't any help in reducing code duplication, as in
my perception the duplication is between Makefile (for port install) and
pkg-plist/pkg-install (for packages). There often is some line similar to
${SETENV} PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME}
POST-INSTALL
in the ports' Makefiles (post-install or whereever appropriate).
Also, this would need excellent documentation. RPM on Linux is similarly
flexible, but is severely underdocumented (at least RPM v3 and v4 on
openSUSE Linux are). If it does any _undocumented_ magic, I don't want it.
:)
So, before we think about it and harrass hundreds of ports maintainers, we'd
need the shell script library in place to make it a selling point for
actually using install scripts; at that point we can re-think about moving
stuff out of pkg-plist into pkg-install scripts. At the *same* time (so that
only one edit cycle is needed for affected ports - and I'd suggest a survey
to see how many, hundreds probably), we should consider making
Mk/bsd.port.mk call the install scripts automatically (needs changes to
hundreds of ports again) in pre-install, post-install and related stages.
I mentioned getting rid of those pesky @*exec lines a few years ago,
but this was met by quite a lot of objection.
I still think it would be a good change, assuming that we provide
equivalent (or better) features:
- Configuration files should be marked and automatically dealt with by
the infrastructure, not by esoteric commands.
- Subroutines for shell scripts should be provided along with
pkg_install, or be installed by a third party port (users/groups
creation comes to mind).
- Scripts should be automatically picked up as you mentioned. We're
trying to shove most targets in pkg-install, but it probably would be
best to split it (preinstall, postinstall, predeinstall,
postdeinstall). Good thing is, this doesn't require any change in
pkg_install since it's already supported.
One of the added bonus is that some code that appears both in Makefile
and pkg-plist will only be in preinstall/postinstall scripts.
--
Florent Thoumie
f...@freebsd.org
FreeBSD Committer
___
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: [ HEADS UP ] Ports unstable for the next 10 days
On Mon, 29 Mar 2010 10:15:23 +0200 Dominic Fandrey kamik...@bsdforen.de wrote: On 28/03/2010 15:38, Ion-Mihai Tetcu wrote: We do _NOT_ recommend updating ports until this commits are all done, and the problems are fixed, except if you want to help testing / fixing. The already committed graphics/imlib2 patch does not work, i.e. it compiles, but png doesn't work, with this one it does: [ .. ] Committed, thanks. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [ HEADS UP ] Ports unstable for the next 10 days
On 29/03/10 7:04 PM, Doug Barton wrote: portmaster -r graphics/png That won't work, the man page clearly says that it has to be a port directory or glob pattern from /var/db/pkg. The glob pattern bit of that was (unfortunately) broken up till version 2.20, which I just committed. I'm confused. The manual actually says: [-R] -r name/glob of port in /var/db/pkg When I try your suggestion I get this: # portmaster -r png- === No valid installed port, or port directory given === Try portmaster --help And this doesn't work either: # portmaster -r graphics/png === No valid installed port, or port directory given === Try portmaster --help So, as you say the pkg pattern is broken, but also 'port directory' doesn't work either unlike your suggestions above. It would be nice for both pkg and directory patterns to be more consistently available, but in the meantime readers of UPDATING are going to be confused. Ari Maniatis -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts
On Mon, Mar 29, 2010 at 2:10 AM, Florent Thoumie f...@xbsd.org wrote:
On Mon, Mar 29, 2010 at 7:58 AM, Matthias Andree matthias.and...@gmx.de
wrote:
Am 28.03.2010, 08:14 Uhr, schrieb Garrett Cooper:
Hi,
As part of taking a look at the differences in our implementation
of pkg_install(1) in order to afford an improvement over the existing
code, I've looked at various implementations of pkg_install, one being
NetBSD's evolution [1]. It's several years ahead from our's and while
I don't believe that all of the complexity is desired, there's a lot
of good lessons to be learned from this. One of which is that they
replaced the @exec and @unexec calls with string pre-install //
post-install and pre-deinstall // post-deinstall scripts. I think that
this potentially is a good step forward because it takes some of the
guts out of the +CONTENTS files and places it in [bourne shell]
scripts, which are easier to maintain and potentially understand.
I realize that some of the loss would be that one couldn't simply
specify things like %f, %D, %F, etc with @exec and @unexec, but that
seems a small price to pay for tuning everything a bit more. On the
plus side too, that means that one could use an extensive set of
shell, etc libraries that would avoid code duplication like what's
present in the +CONTENTS files. This is one of the small observations
I made after starting on work which would modify 1k python ports to
not install the byte-compiled or optimized files (side topic that we
can talk about in another thread if desired).
Thoughts?
Hi Garrett,
I'm not so sure what the advantage would be. For trivial
pre-post-(de)install tasks, why use a separate script? It's less concise
than reading everything in pkg-plist.
Let's put it this way. Once I determined that there was some
precompiled crud that needed to be removed in order to eliminate bugs
in python packages, that was a lofty goal that I intended to complete
~2 months ago.
Things happened, I got busy, then got back to it 2 weekends ago.
Now, I'm not miwi@ by any means, so modifying ports does require
proper motivation to complete, but let's put it this way... after
modifying 40 ports I said to myself `this is stupid.. I could reduce
the amount of useless typing by automating this crud through a script
library once and call it from the pkg_*install script, respectively,
without having to go through the error prone exercise of hand-editing
1000-some plists' -- because certain `package categories' have common
logic that can be applied to them when they're installed and removed.
WRT variables, I'm not so concerned about %D %F etc, but I am concerned
about the necessity to add script boilerplate (such as snatching pre-post or
deinstall-install modes, prefix), and while I haven't thoroughly audited the
install scripts in ports, I see lots of bad shell scripts around. These
would need rigorous audits (in adverse conditions, such as paths containing
blanks and shell meta characters to unveil underquoted
parameters/variables).
It's really no better passing in these values in +CONTENTS [// *plist]
form because a lot of this stuff is fed through to vsystem eventually
[a pkg_install home-grown variadic version of system(3)], which means
that all bets are off then, minus the initial @cwd stuff (but that's
fine because it's handled from within pkg_install anyhow.
Also, this effort alone isn't any help in reducing code duplication, as in
my perception the duplication is between Makefile (for port install) and
pkg-plist/pkg-install (for packages). There often is some line similar to
${SETENV} PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME}
POST-INSTALL
in the ports' Makefiles (post-install or whereever appropriate).
This doesn't make sense to be honest... *sigh*. There's already a
well-established format in pkg_install that should be leveraged
instead of reinventing the wheel for ports...
Also, this would need excellent documentation. RPM on Linux is similarly
flexible, but is severely underdocumented (at least RPM v3 and v4 on
openSUSE Linux are). If it does any _undocumented_ magic, I don't want it.
:)
So, before we think about it and harrass hundreds of ports maintainers, we'd
need the shell script library in place to make it a selling point for
actually using install scripts; at that point we can re-think about moving
stuff out of pkg-plist into pkg-install scripts. At the *same* time (so that
only one edit cycle is needed for affected ports - and I'd suggest a survey
to see how many, hundreds probably), we should consider making
Mk/bsd.port.mk call the install scripts automatically (needs changes to
hundreds of ports again) in pre-install, post-install and related stages.
No need; pkg_add and pkg_delete already do this and do it fairly well,
and pkg_install should be called from ports anyhow because it is the
package maintenance tool...
I mentioned getting rid of those pesky @*exec lines a few
Re: [ HEADS UP ] Ports unstable for the next 10 days
On 29/03/2010 11:27, Ion-Mihai Tetcu wrote: On Mon, 29 Mar 2010 10:15:23 +0200 Dominic Fandrey kamik...@bsdforen.de wrote: On 28/03/2010 15:38, Ion-Mihai Tetcu wrote: We do _NOT_ recommend updating ports until this commits are all done, and the problems are fixed, except if you want to help testing / fixing. The already committed graphics/imlib2 patch does not work, i.e. it compiles, but png doesn't work, with this one it does: [ .. ] Committed, thanks. Someone committed the broken code again. :( ___ 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
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/145164[maintainer] lang/petite-chez: update from 7.4d to 8.0 f ports/145163error: cannot portupgrade palm/pilot-link o ports/145154New port: devel/luafilesystem A library to access dire o ports/145149maintainer-update: security/scamp o ports/145146[PATCH] update print/hplip3 to 3.10.2 o ports/145144[NEW PORT] databases/xtrabackup: OpenSource version of o ports/145143new port: science/p5-PerlMol and dependencies o ports/145142new port: devel/p5-HOP-Lexer o ports/145141new port: devel/p5-HOP-Stream o ports/145140new port: devel/p5-Config-Yaml o ports/145135new port: textproc/p5-Spreadsheet-ReadSXC o ports/145134new port: textproc/p5-Spreadsheet-Read o ports/145133new port: textproc/p5-Spreadsheet-ReadSXC o ports/145132new port: textproc/p5-libxml-enno o ports/145131new port: www/p5-CGI-Application-Plugin-Config-YAML o ports/145130new port: www/p5-CGI-Application-Plugin-JSON o ports/145129new port: www/p5-CGI-EncryptForm o ports/145127[MAINTAINER] www/xpi-mozex: update to 1.9.12 o ports/145125[PATCH] update kdesvn-kde4: 1.4.1 - 1.5.2 o ports/145113[NEW PORT] net/sslh: A ssl/ssh multiplexer o ports/145107[patch] net/csync2 improvements o ports/145099[UPDATE] devel/ioncube - new version 3.3.12_1 (added I f ports/145094[patch][repocopy] audio/linux-nerodigitalaudio: update o ports/145089[new port] multimedia/umph o ports/145088new port: devel/buildapp o ports/145083[update] games/simutrans: version 102.2.2 f ports/145080[patch] update net-mgmt/snmptt to 1.3 f ports/145077[PATCH] upgrade multimedia/clive to version 2.2.10 o ports/145076I could not build devel/pwlib o ports/145075New port: databases/beansdb: Yet anonther distributed o ports/145072Update Port: irc/irssi-fish to v.1.00.RC5 o ports/145053audio/swami Segmentation fault o ports/145050Update ports emulator/sdlmame : Update to v0.137 and r o ports/145017New port: databases/dm-validations. o ports/145015net-im/prosody rc.d script doesn't stop the server whe o ports/145007audio/ario port build fine with gcc42, so GCC= 4.4+ is o ports/145002databases/postgresql-client : libpgport.a is missing a o ports/144999New port: devel/gitg (GTK git frontend) o ports/144993databases/postgresql-odbc: contents of numeric fields o ports/144989irc/inspircd will not compile if gnutls module is sele o ports/144988[NEW PORT] net/monast: A monitoring and an operator pa o ports/144983[maintainer] databases/phpmyadmin -- mcrypt module sho o ports/144979new port net-im/komclean o ports/144977[PATCH] audio/solfege-nosound: update to 3.15.8 o ports/144973New port: devel/p5-App-Ack grep on steriods f ports/144964x11-wm/echinus out-of-date o ports/144939New port databases/xtrabackup OpenSource version of In o ports/144923make devel/netbsd-pkgsrc-mk-files install files to dif o ports/144910[new port] java/hgeclipse Mercurial VCS plugin for the o ports/144906german/BBBike: update to 3.17 o ports/144904[PATCH] www/free-sa-devel: update to 2.0.0b3 f ports/144897[UPDATE] Update mail/dovecot to 1.2.11 o ports/144885[NEW PORT] devel/p5-TryCatch: First class try catch se f ports/144884[PATCH] www/davical - update to 0.9.8.4 o ports/144878www/tomcat55 uid is hardcoded to 80 o ports/144876[patch] net-mgmt/nfsen won't work with rrdtool 1.4.2 ( o ports/144862port update www/sbox-dtc to v1.10 f ports/144857[patch] audio/abraca: update to 0.4.3 f ports/144850[PATCH] databases/rrdtool: fix 'make deinstall' when N o ports/144849[new port] java/eclipse-eclemma code coverage for ecli o ports/144846New port: games/jfsw - JonoF's Shadow Warrior f ports/144845[patch] lang/guile: Fails to build on recent 9-CURREN f ports/144833print/hplip3: configure failed f ports/144832[PATCH] net-mgmt/bsnmp-regex - Add option to use PCRE o ports/144831[UPDATE] net-mgmt/mbrowse to 0.4.0 o ports/144812
Re: cvs commit: ports/print/panda/files patch-configure
The Restless Daemon identified a linker error while trying to build: panda-0.5.4_4 maintained by po...@freebsd.org Makefile ident: $FreeBSD: ports/print/panda/Makefile,v 1.29 2010/03/28 06:42:45 dinoex Exp $ Excerpt from http://QAT.TecNik93.com/logs/8-STABLE-NPD/panda-0.5.4_4.log : libtool: compile: cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/local/include/db41 -I/usr/local/include -O2 -pipe -fno-strict-aliasing -DHAVE_LIBPNG -DHAVE_LIBTIFF -DHAVE_LIBJPEG -MT view.lo -MD -MP -MF .deps/view.Tpo -c view.c -o view.o /dev/null 21 if /bin/sh /usr/local/bin/libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/local/include/db41 -I/usr/local/include -O2 -pipe -fno-strict-aliasing -DHAVE_LIBPNG -DHAVE_LIBTIFF -DHAVE_LIBJPEG -MT xref.lo -MD -MP -MF .deps/xref.Tpo \ -c -o xref.lo `test -f 'xref.c' || echo './'`xref.c; \ then mv -f .deps/xref.Tpo .deps/xref.Plo; \ else rm -f .deps/xref.Tpo; exit 1; \ fi libtool: compile: cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/local/include/db41 -I/usr/local/include -O2 -pipe -fno-strict-aliasing -DHAVE_LIBPNG -DHAVE_LIBTIFF -DHAVE_LIBJPEG -MT xref.lo -MD -MP -MF .deps/xref.Tpo -c xref.c -fPIC -DPIC -o .libs/xref.o libtool: compile: cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/local/include/db41 -I/usr/local/include -O2 -pipe -fno-strict-aliasing -DHAVE_LIBPNG -DHAVE_LIBTIFF -DHAVE_LIBJPEG -MT xref.lo -MD -MP -MF .deps/xref.Tpo -c xref.c -o xref.o /dev/null 21 /bin/sh /usr/local/bin/libtool --mode=link cc -O2 -pipe -fno-strict-aliasing -DHAVE_LIBPNG -DHAVE_LIBTIFF -DHAVE_LIBJPEG -L/usr/local/lib -L/usr/local/lib -pthread -lpng -ltiff -ljpeg -ldb41 -o libpanda.la -rpath /usr/local/lib annotate.lo curves.lo database.lo date.lo font.lo fontmetrics.lo info.lo memory.lo panda.lo trailer.lo error.lo images.lo internal.lo md5c.lo objects.lo template.lo text.lo utility.lo view.lo xref.lo -lm libtool: link: cc -shared .libs/annotate.o .libs/curves.o .libs/database.o .libs/date.o .libs/font.o .libs/fontmetrics.o .libs/info.o .libs/memory.o .libs/panda.o .libs/trailer.o .libs/error.o .libs/images.o .libs/internal.o .libs/md5c.o .libs/objects.o .libs/template.o .libs/text.o .libs/utility.o .libs/view.o .libs/xref.o -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib -L/usr/local/lib -pthread -lpng /usr/local/lib/libtiff.so -ljbig -lz /usr/local/lib/libjpeg.so -ldb41 -lm -pthread -pthread -pthread -pthread -Wl,-soname -Wl,libpanda.so.0 -o .libs/libpanda.so.0 libtool: link: (cd .libs rm -f libpanda.so ln -s libpanda.so.0 libpanda.so) libtool: link: (cd .libs rm -f libpanda.so ln -s libpanda.so.0 libpanda.so) libtool: link: ar cru .libs/libpanda.a annotate.o curves.o database.o date.o font.o fontmetrics.o info.o memory.o panda.o trailer.o error.o images.o internal.o md5c.o objects.o template.o text.o utility.o view.o xref.o libtool: link: ranlib .libs/libpanda.a libtool: link: ( cd .libs rm -f libpanda.la ln -s ../libpanda.la libpanda.la ) gmake[2]: Leaving directory `/work/a/ports/print/panda/work/panda-0.5.4' Making all in panda gmake[2]: Entering directory `/work/a/ports/print/panda/work/panda-0.5.4/panda' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/work/a/ports/print/panda/work/panda-0.5.4/panda' Making all in examples gmake[2]: Entering directory `/work/a/ports/print/panda/work/panda-0.5.4/examples' if cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/local/include/db41 -I/usr/local/include -O2 -pipe -fno-strict-aliasing -DHAVE_LIBPNG -DHAVE_LIBTIFF -DHAVE_LIBJPEG -MT main.o -MD -MP -MF .deps/main.Tpo \ -c -o main.o `test -f 'main.c' || echo './'`main.c; \ then mv -f .deps/main.Tpo .deps/main.Po; \ else rm -f .deps/main.Tpo; exit 1; \ fi /bin/sh /usr/local/bin/libtool --mode=link cc -O2 -pipe -fno-strict-aliasing -DHAVE_LIBPNG -DHAVE_LIBTIFF -DHAVE_LIBJPEG -L/usr/local/lib -L/usr/local/lib -pthread -lpng -ltiff -ljpeg -ldb41 -o pandademo main.o ../libpanda.la -L.. -lm libtool: link: cc -O2 -pipe -fno-strict-aliasing -DHAVE_LIBPNG -DHAVE_LIBTIFF -DHAVE_LIBJPEG -pthread -o .libs/pandademo main.o -L/usr/local/lib ../.libs/libpanda.so -lpng /usr/local/lib/libtiff.so -ljbig -lz /usr/local/lib/libjpeg.so -ldb41 -L/work/a/ports/print/panda/work/panda-0.5.4 -lm -pthread -Wl,-rpath -Wl,/usr/local/lib ../.libs/libpanda.so: undefined reference to `png_check_sig' gmake[2]: *** [pandademo] Error 1 gmake[2]: Leaving directory `/work/a/ports/print/panda/work/panda-0.5.4/examples' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/work/a/ports/print/panda/work/panda-0.5.4' gmake: *** [all] Error 2 *** Error code 1 Stop in /a/ports/print/panda. build of /usr/ports/print/panda ended at Mon Mar 29 11:09:53 UTC 2010 PortsMon page for the port: http://portsmon.freebsd.org/portoverview.py?category=printportname=panda The build which triggered this BotMail was done
Now OK (Re: cvs commit: ports/print/panda/files patch-images.c)
print/panda, which was previously failing is OK after this commit. Thanks for fixing it! A description of the testing process can be found here: http://T32.TecNik93.com/FreeBSD/QA-Tindy/ Thanks for your work on making FreeBSD better, -- QAT - your friendly neighborhood Daemon, preparing a heck of an error trapping system: - HMC and EOI? - Halt, Melt and Catch fire or Execute Operator Immediately. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts
Garrett Cooper wrote on 2010-03-29:
WRT variables, I'm not so concerned about %D %F etc, but I am concerned
about the necessity to add script boilerplate (such as snatching
pre-post or
deinstall-install modes, prefix), and while I haven't thoroughly
audited the
install scripts in ports, I see lots of bad shell scripts around. These
would need rigorous audits (in adverse conditions, such as paths
containing
blanks and shell meta characters to unveil underquoted
parameters/variables).
It's really no better passing in these values in +CONTENTS [// *plist]
form because a lot of this stuff is fed through to vsystem eventually
[a pkg_install home-grown variadic version of system(3)], which means
that all bets are off then, minus the initial @cwd stuff (but that's
fine because it's handled from within pkg_install anyhow.
OK.
Also, this effort alone isn't any help in reducing code duplication,
as in
my perception the duplication is between Makefile (for port install)
and
pkg-plist/pkg-install (for packages). There often is some line similar
to
${SETENV} PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME}
POST-INSTALL
in the ports' Makefiles (post-install or whereever appropriate).
This doesn't make sense to be honest... *sigh*. There's already a
well-established format in pkg_install that should be leveraged
instead of reinventing the wheel for ports...
Well, basically what the line above (in a port's post-install target) does
is to run the installed PKGINSTALL script to do its job.
I've only never understood why a port maintainer has to this explicitly,
when Mk/bsd.port.mk could as well handle it.
It appears to me that we are in violent agreement on this one.
No need; pkg_add and pkg_delete already do this and do it fairly well,
and pkg_install should be called from ports anyhow because it is the
package maintenance tool...
I'm not sure I understand your proposal. How do we create a package to
pkg_install? Currently that's make install, make package (ok, the
latter implies the former), which adds a few +... files (+CONTENTS and
thereabouts) and then runs pkg_create, right?
Exactly. pkg_create does properly document this functionality, but
unfortunately it's really underused in the ports infrastructure and
instead all of this stuff is jammed into the +CONTENTS [/*plist]. This
is what should be avoided because we've just made the plists into a
veritable 7-11 for all of the pkgs needs instead of using duplicated
functionality.
I have no objections, I just want to (a) understand the issue, and (b)
make sure we have proper and strong (not to say compelling) arguments in
favor of your proposal, and (c) avoid that new crutches would have to be
invented.
I was also hoping to converge into a more sensical model like
NetBSD has created over the past 4 years -- and this is one of the
gaps that I think we should cross in trying to make this possible. The
overall goal is to make a logically sound change that would reduce
maintenance for everyone in the ports community.
That's the second time the reference to NetBSD has appeared, would you
like to add any pointers to highlights of the NetBSD system?
(It's been a while since I've used pkgsrc if that's what you're implying,
and only on Linux :))
--
Matthias Andree
___
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: Removal of RC_SUBR and RC_SUBR_SUFFIX
Doug Barton do...@freebsd.org wrote:
As should be obvious by now I'm following through on my previously
stated plans to remove the no longer necessary %%RC_SUBR%% and
%%RC_SUBR_SUFFIX%% from the ports tree.
Does it still make sense to use
rcvar=`set_rcvar`
as recommended by rc.subr(8) or should we just use
rcvar=${name}_enable
as shown in the Porter's Handbook example?
--
Christian naddy Weisgerber na...@mips.inka.de
___
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
Newer autoconf (2.63+)?
We only have autoconf 2.13 and 2.62 in the tree. Upstream authors are increasingly moving towards and _requiring_ newer versions (2.63, 2.64, 2.65), and if you have to run autoconf, that is a problem. Are there any plans to provide a newer autoconf version? -- Christian naddy Weisgerber na...@mips.inka.de ___ 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: stable ports?
On 29 March 2010, at 08:57, Ivan Voras wrote: In some cases the burdens are obvious - the maintainer(s) would need to e.g. maintain three versions of the ports - a random example would be e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future (CURRENT/9.x) branch. I am a bit concerned about your concept of maintain, being able to build a port successfully, does not necessarily mean it will work properly. For example, qpopper (which I maintain) has an issue where one feature does not work properly on 64 bit machines where it works fine on 32 bit machines. In addition, there are a number of other machine types that are currently not heavily used but might become so in the future. Thats a lot of different combinations of hardware and OSs to keep running for the maintainers. ___ 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
Silent distfiles conflict between graphics/xface.el and mail/x-face-e21.
Hello! Could please someone with emacs knowledge (preferably ports commiter) look into issue http://www.freebsd.org/cgi/query-pr.cgi?pr=141839 Both ports refer distfiles with the same name but of different sizes (and checksums). It looks like one port is a subset of another, but I am not familiar with emacs to say for sure. Both maintainers, yoichi@ and ume@ haven't responded to private mails yet. Thanks, Alexey. ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On 03/29/10 02:27, Aristedes Maniatis wrote: On 29/03/10 7:04 PM, Doug Barton wrote: portmaster -r graphics/png That won't work, the man page clearly says that it has to be a port directory or glob pattern from /var/db/pkg. The glob pattern bit of that was (unfortunately) broken up till version 2.20, which I just committed. I'm confused. The manual actually says: [-R] -r name/glob of port in /var/db/pkg When I try your suggestion I get this: # portmaster -r png- === No valid installed port, or port directory given === Try portmaster --help Are you using portmaster version 2.20? -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: [ HEADS UP ] Ports unstable for the next 10 days
On 03/29/10 02:53, Garrett Cooper wrote: Besides, when I read `glob' I don't think `regular expression'. A glob is a simplified extension of regular expressions, I wasn't going for a rigorous definition here. :) However, simplified is the correct idea. The previous method I described works, and works well: portmaster -r 'png-*' Right, that will work, but the * isn't necessary. Portmaster will strip it internally in any case. Not sure why graphics/png doesn't work though; hrrm... The -r option is only relevant to an installed port. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: [ HEADS UP ] Ports unstable for the next 10 days
Hi,
sysutils/tracker-client fails in configure, fix to port's Makefile:
--- sysutils/tracker-client/Makefile.orig 2010-03-29 20:59:36.0
+0200
+++ sysutils/tracker-client/Makefile2010-03-29 21:01:42.0 +0200
@@ -46,7 +46,9 @@
INSTALLS_ICONS=yes
USE_AUTOTOOLS= libtool:22
CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include \
- LDFLAGS=-L${LOCALBASE}/lib -L${LOCALBASE}/lib/tracker
${PTHREAD_LIBS}
+ LDFLAGS=-L${LOCALBASE}/lib -L${LOCALBASE}/lib/tracker
${PTHREAD_LIBS} \
+ LIBPNG_CFLAGS=-I${LOCALBASE}/include \
+ LIBPNG_LDFLAGS=-L${LOCALBASE}/lib LIBPNG_LIBS=png
CONFIGURE_ARGS=--enable-video-extractor=gstreamer \
--enable-file-monitoring=fam \
--with-session-bus-services-dir=${LOCALBASE}/share/dbus-1/services \
And cad/brlcad will need some work, but that might be larger...
Regards,
Christoph
--
Spare Space
___
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
Be careful with fdopendir() on RELENG_7
There is a silly bug in RELENG_7 up to and including RELENG_7_3: fdopendir(3) is available in libc, but the prototype is missing from dirent.h. This can have unexpected consequences. A configure script can notice that fdopendir() is available, but due to the missing prototype, the function will be typed as the default int fdopendir(); This is bad. fdopendir() returns a pointer and unless correctly prototyped, the return value will be truncated from 64 to 32 bits on LP64 platforms. So if you notice that something picks up the fdopendir() function you need to either disable it for 702102 to 703100 (inclusive) or make sure that the correct prototype DIR *fdopendir(int); is wedged in somehow. This isn't a hypothetical concern. When I initially tried gtar 1.23 on 7.3/amd64, it left a trail of coredumps because of this. -- Christian naddy Weisgerber na...@mips.inka.de ___ 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
Old ports bugs analyzis
I work on creating system for system and ports autobuilder with custom
settings for my FreeBSD machines. I know about many programs, which do
same, but I don't like strange depends, which are not controlled by
OPTIONS and some another
I've analyse ports tree and want to say about.
There're lot problems with ports to create per-port PRs
manually.Common types of problems are listed here:
0) Main part of problems in tons of ports, which has hidden options
(WITH WITHOUT checking), but not using OPTIONS for them.
1) There many libraries added with BUILDRUN dependencies, not as LIB-DEPENDS.
2) Some ports has only BUILD depends to libraries, but links them dynamicly.
3) All(?) samba33 slaves define dependency as samba33, and make
warning me about master target redefinition when do something on them.
4) many ports define dependencies as
${.CURDIR}/../../category/dep-port-name
5) And some adds trailing slash.
I want fix these problems, but I have no much time to fix several
thousands of ports. This work (include PR sending) needs about is 1-2
month per 8-10 hours a day.
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but enough version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX, see
py program for comments about types.
___
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: Be careful with fdopendir() on RELENG_7
On Mon, Mar 29, 2010 at 6:07 PM, Xin LI delp...@gmail.com wrote: On Mon, Mar 29, 2010 at 5:45 PM, Garrett Cooper yanef...@gmail.com wrote: [...] This isn't a hypothetical concern. When I initially tried gtar 1.23 on 7.3/amd64, it left a trail of coredumps because of this. Is there a bug outstanding for this? This has been fixed in RELENG_7 before 7.3-RELEASE but re@ considered it too late so the change didn't make it into the final release. No, there is no outstanding bug report as I am aware. Hmm... is it possible to release note it after the fact (or at least release note all major / outstanding items discovered shortly after the release, like the accidental zfs bootloader breakage)? Thanks, -Garrett ___ 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: Be careful with fdopendir() on RELENG_7
Perhaps as an errata? On Mar 29, 2010 7:42 PM, Garrett Cooper yanef...@gmail.com wrote: On Mon, Mar 29, 2010 at 6:07 PM, Xin LI delp...@gmail.com wrote: On Mon, Mar 29, 2010 at 5:45 PM... Hmm... is it possible to release note it after the fact (or at least release note all major / outstanding items discovered shortly after the release, like the accidental zfs bootloader breakage)? Thanks, -Garrett ___ 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: Be careful with fdopendir() on RELENG_7
On Mar 29, 2010, at 8:18 PM, Xin LI delp...@gmail.com wrote: Perhaps as an errata? On Mar 29, 2010 7:42 PM, Garrett Cooper yanef...@gmail.com wrote: On Mon, Mar 29, 2010 at 6:07 PM, Xin LI delp...@gmail.com wrote: On Mon, Mar 29, 2010 at 5:45 PM... Hmm... is it possible to release note it after the fact (or at least release note all major / outstanding items discovered shortly after the release, like the accidental zfs bootloader breakage)? Sounds good. Just want to avoid unnecessary bug reports ;).. -Garrett ___ 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
