security/openssh-portable line # 82 of rc.d/openssh generates DSA not ECDSA
As stated in the subject if [ -f /usr/local/etc/ssh/ssh_host_ecdsa_key ]; then echo You already have a Elliptic Curve DSA host key \ in /usr/local/etc/ssh/ssh_host_ecdsa_key echo Skipping protocol version 2 Elliptic Curve DSA Key Generation else /usr/local/bin/ssh-keygen -t dsa \ -f /usr/local/etc/ssh/ssh_host_ecdsa_key -N '' fi Specifically /usr/local/bin/ssh-keygen -t dsa needs to be changed to -t ecdsa to be correct. Otherwise we are just reimplementing a DSA key in a different file. -- - (2^(N-1)) pgpaSaWWSuR7X.pgp Description: PGP signature
Re: security/openssh-portable line # 82 of rc.d/openssh generates DSA not ECDSA
On Sun, Jun 24, 2012 at 01:46:20PM -0400, Robert Simmons wrote:
On Sun, Jun 24, 2012 at 1:17 PM, J. Hellenthal jhellent...@dataix.net wrote:
As stated in the subject
if [ -f /usr/local/etc/ssh/ssh_host_ecdsa_key ]; then
echo You already have a Elliptic Curve DSA host key \
in /usr/local/etc/ssh/ssh_host_ecdsa_key
echo Skipping protocol version 2 Elliptic Curve DSA Key Generation
else
/usr/local/bin/ssh-keygen -t dsa \
-f /usr/local/etc/ssh/ssh_host_ecdsa_key -N ''
fi
Specifically /usr/local/bin/ssh-keygen -t dsa needs to be changed to
-t ecdsa to be correct. Otherwise we are just reimplementing a DSA key
in a different file.
Good eye. I'm in the process of updating that port to 6.0p1. There
are quite a lot of local patches that are part of the port. At the
moment I'm muddling through what they do and whether they can be
removed or not. I didn't even notice this problem.
I've attached a pair of patches that correct this problem. Open a PR
about this, and you can attach these patches to it. I'm not the
maintainer nor do I have commit privileges, but if you open a PR, I'm
sure someone will make the change.
Yeah I have been there too. The current port 5.8 I updated to 5.9. Some
of the patches do not work but the diff I have is attached for the
functions I use out of it.
Also attached is my config for that port. But when I made it I did not
have GSSAPI turned on. That does work but just have not adjusted it.
--
- (2^(N-1))
=== The following configuration options are available for
openssh-portable-5.9.p1_2,1:
BSM=on: Enable OpenBSM Auditing
FILECONTROL=off: Enable file control patch (broken)
HPN=on: Enable HPN-SSH patch
KERBEROS=off: Enable kerberos (autodetection)
KERB_GSSAPI=off: Enable Kerberos/GSSAPI patch (req: GSSAPI)
LIBEDIT=on: Enable readline support to sftp(1)
LPK=off: Enable LDAP Public Key (LPK) patch
OPENSSH_CHROOT=on: Enable CHROOT support
OVERWRITE_BASE=off: OpenSSH overwrite base
PAM=on: Enable pam(3) support
TCP_WRAPPERS=on: Enable tcp_wrappers support
X509=off: Enable x509 certificate patch
=== Use 'make config' to modify these settings
diff -urN security/openssh-portable-5.8p2/Makefile security/openssh-portable/Makefile
--- security/openssh-portable-5.8p2/Makefile 2012-05-01 05:56:31.0 -0400
+++ security/openssh-portable/Makefile 2012-05-30 20:01:26.493449509 -0400
@@ -6,9 +6,9 @@
#
PORTNAME= openssh
-DISTVERSION= 5.8p2
-PORTREVISION= 2
-PORTEPOCH= 1
+DISTVERSION= 5.9p1
+PORTREVISION= 2
+PORTEPOCH= 1
CATEGORIES= security ipv6
MASTER_SITES= ${MASTER_SITE_OPENBSD}
MASTER_SITE_SUBDIR= OpenSSH/portable
@@ -42,7 +42,6 @@
OPTIONS= PAM Enable pam(3) supporton \
TCP_WRAPPERS Enable tcp_wrappers support on \
LIBEDIT Enable readline support to sftp(1) on \
- SUID_SSH Enable suid SSH (Recommended off) off \
BSM Enable OpenBSM Auditing off \
KERBEROS Enable kerberos (autodetection) off \
KERB_GSSAPI Enable Kerberos/GSSAPI patch (req: GSSAPI) off \
@@ -87,10 +86,6 @@
CONFIGURE_ARGS+= --with-libedit
.endif
-.if !defined(WITH_SUID_SSH)
-CONFIGURE_ARGS+= --disable-suid-ssh
-.endif
-
.if defined(WITH_BSM)
CONFIGURE_ARGS+= --with-audit=bsm
.endif
@@ -119,7 +114,7 @@
.if defined(WITH_HPN)
PATCH_SITES+= http://www.psc.edu/networking/projects/hpn-ssh/
-PATCHFILES+= ${PORTNAME}-5.8p1-hpn13v11.diff.gz
+PATCHFILES+= ${PORTNAME}-5.9p1-hpn13v12.diff.gz
PATCH_DIST_STRIP=
.endif
@@ -194,11 +189,9 @@
-e 's|%%RC_SCRIPT_NAME%%|${RC_SCRIPT_NAME}|' ${WRKSRC}/sshd.8
@${REINPLACE_CMD} -E -e 's|SSH_VERSION|TMP_SSH_VERSION|' \
-e 's|.*SSH_RELEASE.*||' ${WRKSRC}/version.h
- @${ECHO_CMD} '#define FREEBSD_PORT_VERSION FreeBSD-${PKGNAME}' \
- ${WRKSRC}/version.h
- @${ECHO_CMD} '#define SSH_VERSION TMP_SSH_VERSION SSH_PORTABLE FREEBSD_PORT_VERSION' \
+ @${ECHO_CMD} '#define SSH_VERSION TMP_SSH_VERSION SSH_PORTABLE' \
${WRKSRC}/version.h
- @${ECHO_CMD} '#define SSH_RELEASE TMP_SSH_VERSION SSH_PORTABLE FREEBSD_PORT_VERSION' \
+ @${ECHO_CMD} '#define SSH_RELEASE TMP_SSH_VERSION SSH_PORTABLE' \
${WRKSRC}/version.h
.if defined(WITH_HPN)
@${REINPLACE_CMD} -e 's|TMP_SSH_VERSION SSH_PORTABLE|TMP_SSH_VERSION SSH_PORTABLE SSH_HPN|' \
diff -urN security/openssh-portable-5.8p2/distinfo security/openssh-portable/distinfo
--- security/openssh-portable-5.8p2/distinfo 2011-10-21 12:18:56.0 -0400
+++ security/openssh-portable/distinfo 2012-05-30 19:07:47.129970365 -0400
@@ -1,8 +1,4 @@
-SHA256 (openssh-5.8p2.tar.gz) = 5c35ec7c966ce05cc4497ac59c0b54a556e55ae7368165cc8c4129694654f314
-SIZE (openssh-5.8p2.tar.gz) = 1115475
-SHA256 (openssh-5.8p1-hpn13v11.diff.gz) = 62b500d29d8889ce76c8b596eb65731d8ac3469d89d9c6eb29fec2a845159df7
-SIZE (openssh-5.8p1-hpn13v11.diff.gz) = 22993
-SHA256 (openssh-5.8p1+x509-7.0.diff.gz) = 3b578cbf69f25e630e8da52b6586a36c62c0c7ce026f95acda91c023dc47c85b
Re: security/openssh-portable line # 82 of rc.d/openssh generates DSA not ECDSA
On Sun, Jun 24, 2012 at 01:46:20PM -0400, Robert Simmons wrote: On Sun, Jun 24, 2012 at 1:17 PM, J. Hellenthal jhellent...@dataix.net wrote: As stated in the subject if [ -f /usr/local/etc/ssh/ssh_host_ecdsa_key ]; then echo You already have a Elliptic Curve DSA host key \ in /usr/local/etc/ssh/ssh_host_ecdsa_key echo Skipping protocol version 2 Elliptic Curve DSA Key Generation else /usr/local/bin/ssh-keygen -t dsa \ -f /usr/local/etc/ssh/ssh_host_ecdsa_key -N '' fi Specifically /usr/local/bin/ssh-keygen -t dsa needs to be changed to -t ecdsa to be correct. Otherwise we are just reimplementing a DSA key in a different file. Good eye. I'm in the process of updating that port to 6.0p1. There are quite a lot of local patches that are part of the port. At the moment I'm muddling through what they do and whether they can be removed or not. I didn't even notice this problem. I've attached a pair of patches that correct this problem. Open a PR about this, and you can attach these patches to it. I'm not the maintainer nor do I have commit privileges, but if you open a PR, I'm sure someone will make the change. Should have also said the changes were already committed. ___ 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 -- - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/openssh-portable line # 82 of rc.d/openssh generates DSA not ECDSA
On Sun, Jun 24, 2012 at 02:38:54PM -0400, Robert Simmons wrote: On Sun, Jun 24, 2012 at 2:24 PM, J. Hellenthal jhellent...@dataix.net wrote: On Sun, Jun 24, 2012 at 01:46:20PM -0400, Robert Simmons wrote: On Sun, Jun 24, 2012 at 1:17 PM, J. Hellenthal jhellent...@dataix.net wrote: As stated in the subject if [ -f /usr/local/etc/ssh/ssh_host_ecdsa_key ]; then echo You already have a Elliptic Curve DSA host key \ in /usr/local/etc/ssh/ssh_host_ecdsa_key echo Skipping protocol version 2 Elliptic Curve DSA Key Generation else /usr/local/bin/ssh-keygen -t dsa \ -f /usr/local/etc/ssh/ssh_host_ecdsa_key -N '' fi Specifically /usr/local/bin/ssh-keygen -t dsa needs to be changed to -t ecdsa to be correct. Otherwise we are just reimplementing a DSA key in a different file. Good eye. I'm in the process of updating that port to 6.0p1. There are quite a lot of local patches that are part of the port. At the moment I'm muddling through what they do and whether they can be removed or not. I didn't even notice this problem. I've attached a pair of patches that correct this problem. Open a PR about this, and you can attach these patches to it. I'm not the maintainer nor do I have commit privileges, but if you open a PR, I'm sure someone will make the change. Should have also said the changes were already committed. I also want to see what can be pushed upstream. I understand that the OpenBSD/OpenSSH people are touchy about outside patches, but I think they should at least accept a patch to configure so that FreeBSD's native openpty() is detected properly. Agree'd. openssh-portable team would be the ones to contact. -- - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: expiration of net/skype ?!
martinko, Hi, Ive read your post below and the following two messages on this among other messages regarding the deprecation of ports. One thing that should be noted is that once the deprecation process is done and over and the port nolonger becomes part of the tree, you are still more than able and welcome to keep the distfiles you have as well checkout just the port directory in question that you are worried about to a seperate place other than the ports tree to maintain it locally. The port may not exactly be in the snapshot tree but just because of that does not mean it will not work for you from a different location. Also note that it may actually be good practice for those that need to use those ports but are unsure of exactly what it involves to upkeep them. It could lead you to another time where you might be interested in being the maintainer for that port. On Tue, Apr 26, 2011 at 01:47:30AM +0200, martinko wrote: Hi all, So what is this deprecation and expiration of net/skype port please ?? I'm asking because I've been using it successfully for more than a year and installed it again just this weekend without any issue. And I've read in the mailing lists many others use it too. So why all that black-listing ? Should I copy the port to my home folder for future installations ? Or can I / we do something about keeping it in the ports tree ? I would surely appreciate if it could stay there. -- Regards, (jhell) Jason Hellenthal pgpEgF7qh4JeD.pgp Description: PGP signature
Re: saving a few ports from death
Adam, On Tue, Apr 26, 2011 at 10:51:39PM -0500, Adam Vande More wrote: On Tue, Apr 26, 2011 at 10:41 PM, Robert Huff roberth...@rcn.com wrote: Garance A Drosehn writes: Speaking of which, I haven't noticed the old lists of FreeBSD unmaintained ports which are currently marked broken and FreeBSD ports which are currently scheduled for deletion show up recently. I did have some mixup in my email account for a short period, so I assume I just missed an announcement on how that is handled now. I get regular e-mails for marked as broken. Last one I have is from Jan 21, prior to that it was twice monthly. Must be they were scheduled for deletion ;) last ones I received here for the two first listed subjects above were recieved January. -- Regards, (jhell) Jason Hellenthal pgpcLCljljQNW.pgp Description: PGP signature
portmaster patch, nice - renice
Hi Doug,
Not that this is much a improvement but thought youd like to be informed
of it. I usually try to refrain whenever possible from calling utilities
like nice(1) or renice(1) and let processes inherit their niceness be
inherited from the parent process. This patch does that very thing for
portmaster.
Regards,
--
J. Hellenthal
--- portmaster.orig 2011-04-12 04:05:16.0 -0400
+++ portmaster 2011-04-12 04:15:54.0 -0400
@@ -3,6 +3,7 @@
# Copyright (c) 2005-2011 Douglas Barton, All rights reserved
# Please see detailed copyright below
+renice -n 10 -p $$
trap trap_exit INT
# Initialize crucial values for the parent, and export them for the children
@@ -269,7 +270,7 @@
pm_kill () { /bin/kill $* /dev/null 2/dev/null; }
pm_make () { ( unset -v CUR_DEPS INSTALLED_LIST PM_DEPTH build_l;
unset -v MASTER_RB_LIST;
- /usr/bin/nice /usr/bin/make $PM_MAKE_ARGS $*; ); }
+ /usr/bin/make $PM_MAKE_ARGS $*; ); }
pm_make_b () { /usr/bin/make $PM_MAKE_ARGS BEFOREPORTMK=bpm $*; }
pm_mktemp () { /usr/bin/mktemp -t f-${PM_PARENT_PID}-$1 ||
fail mktemp for $1 failed; }
@@ -281,7 +282,7 @@
pm_install_s () { $PM_SU_CMD /usr/bin/install -p -o root -g wheel -m 644 $1 $2; }
pm_make_s () { ( unset -v CUR_DEPS INSTALLED_LIST PM_DEPTH build_l;
unset -v MASTER_RB_LIST;
- $PM_SU_CMD /usr/bin/nice /usr/bin/make $PM_MAKE_ARGS $*; ); }
+ $PM_SU_CMD /usr/bin/make $PM_MAKE_ARGS $*; ); }
pm_mkdir_s() { $PM_SU_CMD /bin/mkdir -p $1; }
pm_pkg_delete_s () { $PM_SU_CMD /usr/sbin/pkg_delete $*; }
pm_rm_s () { $PM_SU_CMD /bin/rm $*; }
pgpQGmf60Csd5.pgp
Description: PGP signature
Re: sysutils/zfs-stats update
Just to follow up on this... -:Keep Alive:-
On Tue, Apr 05, 2011 at 02:37:50AM -0400, jhell wrote:
Hi Martin,
Would you mind adding the following to sysutils/zfs-stats/pkg-descr as
well here, http://www.vx.sk/zfs-stats/.
{{{
zfs-stats was branched from a previous revision of the original authors
code that is still maintained at the following URL. You may be interested
in some of the improvements that were made.
http://jhell.googlecode.com/hg/base/head/scripts/zfs/arc_summary/arc_summary.pl
}}}
A shorter URL for that is: http://bit.ly/arc_summary
If not, I do not mind taking maintainership of that port and rolling out
dated revisions in the download section that would coinside with the
release of the port.
The current version that I have up now is up-to-date as of ZFSv28,
supports flags to display single pages of information and defaults to a
display of all pages as well has human readable output for all the
values + increased system memory display in the header.
As I cleaned this up quite a bit from what it used to be before I got my
hands on it for FreeBSD usage I would like to contain the differences in
the least amount of branches for the users sake. As for right now ? I do
not plan on not maintaining it and have further improvements on the way.
You can consider this a public request for maintainership.
I see a much simpler port that doesnt need to fetch a tarball in the
near future and would appreciate your support in doing so.
--
J. Hellenthal
pgpwGSSnYPynq.pgp
Description: PGP signature
Re: Can't upgrade firefox
As per the start of the build of firefox 4. * attention ** * To build Firefox with PGO support you need a running X server and build this port with an user who could access the X server! During the build a Firefox instance will start and run some test. Do not interrupt or close Firefox during this tests! * On Wed, Apr 06, 2011 at 07:14:56PM +0200, Andrea Venturoli wrote: Hello. I'm on a 8.1p2/i386. Issuing portupgrade -o www/firefox www/firefox35, compilation ends with the following: ... gmake[3]: Nothing to be done for `tools'. gmake[3]: Leaving directory `/usr/local/local/storage/alamartmp/usr/ports/www/firefox/work/mozil la-2.0/obj-i386-unknown-freebsd8.1/browser/installer' if test -d ../../dist/bin ; then touch ../../dist/bin/.purgecaches ; fi hg: not found gmake[2]: Leaving directory `/usr/local/local/storage/alamartmp/usr/ports/www/firefox/work/mozil la-2.0/obj-i386-unknown-freebsd8.1/browser/installer' gmake[1]: Leaving directory `/usr/local/local/storage/alamartmp/usr/ports/www/firefox/work/mozil la-2.0/obj-i386-unknown-freebsd8.1' OBJDIR=obj-i386-unknown-freebsd8.1 /usr/local/bin/python2.7 obj-i386-unknown-freebsd8.1/_profile /pgo/profileserver.py Traceback (most recent call last): File obj-i386-unknown-freebsd8.1/_profile/pgo/profileserver.py, line 52, in module from automation import Automation File /usr/local/local/storage/alamartmp/usr/ports/www/firefox/work/mozilla-2.0/obj-i386-unkno wn-freebsd8.1/_profile/pgo/automation.py, line 16, in module import sqlite3 File /usr/local/lib/python2.7/sqlite3/__init__.py, line 24, in module from dbapi2 import * File /usr/local/lib/python2.7/sqlite3/dbapi2.py, line 27, in module from _sqlite3 import * ImportError: /usr/local/lib/python2.7/site-packages/_sqlite3.so: Undefined symbol sqlite3_load_ extension gmake: *** [profiledbuild] Error 1 *** Error code 1 I've banged my head on this, but can't get to understand. I already tried deleting py27-sqlite, reinstalling it with 'portupgrade -Rf' and so on. Any help is appreciated. bye Thanks av. ___ 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 -- Regards, J. Hellenthal JJH48-ARIN 0x89D8547E pgpkVq9J0LFk6.pgp Description: PGP signature
Re: Updating multiple ports with portmaster
On Sat, 26 Mar 2011 12:47, dougb@ wrote: On 3/26/2011 8:22 AM, Ron (Lists) wrote: I have a questions about the use of portmaster when upgrading multiple ports and how to correctly use wildcards. For example, I have this from pkg_version: p5-Digest-SHA-5.50 needs updating (port has 5.61) p5-IO-Socket-SSL-1.38 needs updating (port has 1.39) p5-IPC-Cmd-0.68 needs updating (port has 0.70) p5-Math-BigInt-1.99 needs updating (port has 1.993) p5-Module-Build-0.3607_1 needs updating (port has 0.3624) p5-Module-CoreList-2.42 needs updating (port has 2.45) p5-Module-Load-Conditional-0.38 needs updating (port has 0.44) p5-Params-Check-0.26_1 needs updating (port has 0.28) p5-Test-Harness-3.22 needs updating (port has 3.23) p5-URI-1.56 needs updating (port has 1.58) When I was using portupgrade, I could type... portupgrade p5-* ...and it would upgrade only the ports that needed upgrading and dependancies. But if I try... portmaster p5-* === The following actions will be taken if you choose to proceed: Re-install p5-Digest-SHA1-2.13 Re-install p5-IO-Compress-2.033 Re-install p5-Compress-Raw-Bzip2-2.033 Re-install p5-Compress-Raw-Zlib-2.033 Re-install p5-HTML-Tagset-3.20 Re-install p5-HTML-Parser-3.68 Upgrade p5-Digest-SHA-5.50 to p5-Digest-SHA-5.61 Re-install p5-Mail-SpamAssassin-3.3.1_3 Re-install p5-Archive-Tar-1.76 Re-install p5-IO-Zlib-1.10_1 Re-install p5-IO-String-1.08 Re-install p5-Package-Constants-0.02 Re-install p5-Encode-Detect-1.01 Re-install p5-ExtUtils-CBuilder-0.2802_1,1 Upgrade p5-IPC-Cmd-0.68 to p5-IPC-Cmd-0.70 Re-install p5-Locale-Maketext-Simple-0.21 Upgrade p5-Module-Load-Conditional-0.38 to p5-Module-Load-Conditional-0.44 Upgrade p5-Module-CoreList-2.42 to p5-Module-CoreList-2.45 Re-install p5-Module-Load-0.18 Upgrade p5-Params-Check-0.26_1 to p5-Params-Check-0.28 Re-install p5-version-0.88 Upgrade p5-Module-Build-0.3607_1 to p5-Module-Build-0.3624 Install devel/p5-CPAN-Meta-YAML Re-install p5-ExtUtils-Install-1.54 Re-install p5-ExtUtils-ParseXS-2.22.03 Install devel/p5-Module-Metadata Install devel/p5-Perl-OSType Upgrade p5-Test-Harness-3.22 to p5-Test-Harness-3.23 Re-install p5-Net-DNS-0.66_1 Re-install p5-Net-IP-1.25_2 Re-install p5-IO-Socket-INET6-2.65 Re-install p5-Socket6-0.23 Re-install p5-Digest-HMAC-1.02 Re-install p5-Mail-Tools-2.07 Re-install p5-TimeDate-1.20,1 Re-install p5-NetAddr-IP-4.038 Upgrade p5-IO-Socket-SSL-1.38 to p5-IO-Socket-SSL-1.39 Re-install p5-Net-SSLeay-1.36 Re-install p5-libwww-5.837 Upgrade p5-URI-1.56 to p5-URI-1.58 Re-install p5-YAML-Tiny-1.44 Re-install p5-Time-HiRes-1.9721,1 Re-install p5-Locale-gettext-1.05_3 Upgrade p5-Math-BigInt-1.99 to p5-Math-BigInt-1.993 Re-install p5-ExtUtils-MakeMaker-6.56 Re-install p5-MIME-Base64-3.13 Re-install p5-YAML-0.72 Re-install p5-Error-0.17016 Re-install p5-Net-DNS-Resolver-Programmable-0.003 Re-install p5-Mail-SPF-2.007 ...it wants to upgrade and reinstall every port that I have installed that begins with p5-* Is there a way to get portmaster to behave like portupgrade did and only upgrade what needs to be upgraded? Not directly. You could mimic the behavior using the -i option with either 'portmaster -a' or 'portmaster p5-'. And to answer your likely followup question, I have no plans to add such an option. :) Hi Doug, ...Everyone else, Since were on the (-i) subject here. Do you have any plans in the near future to implement a way for end-user to change the default questioning response from [y] to [n] ? This would be extremely helpful to those users in these circumstances at what seems not that much effort to do so. [y] makes sense when using (-a) where portmaster will only be upgrading what has upgrades available. [n] makes sense when doing most anything else I can think of since its interactive but should be chosen by the user. This is speaking strictly in the sense of: === Update portname-X.Y,Z? y/n [y] And with the above list of ports I think I would rather hit [Return] 50 times than [n][Return] Thanks -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Port Spam graphics/gimpshop
I don't know about anyone else but has anyone even checked this out ?. This site is full of buy this and buy that adds, the forum is hosted on some we buy used cars website, there is tons of re-seller crap all over the place that just spells marketer looking for revenue!. And now its in ports! 1. http://gimpshop.webuyusedcars.com/forum/YaBB.pl?board=general 2. http://www.gimpshop.com/ 3. http://socialnetwork.gimpshop.com/ is 404 not found for contact Our users have made 2207 Posts within 492 Topics. The most recent post is Text Recognition (03/14/11 at 19:30:45). We have 2927 registered members. The newest member is estimatecar. Most Users ever online was 131 on 05/06/09 at 04:31:41 Most Members ever online was 9 on 04/23/09 at 08:31:42 Most Guests ever online was 131 on 05/06/09 at 04:31:41 These don't add up... -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN ___ 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 Infrastructure Changes
On Thu, 24 Mar 2011 11:38, lists@ wrote: you can then build category based directories with symlinks to the main location based on what categories My ports-mgmt/symports does something like this. It builds a full directory tree of symlinks for the secondary categories. I'm sure that something like this has been mentioned before. But I don't see what else is going to stop the categorization issue popping up all of the time. If we alphabetized the ports then there would be constant conversation about how whether or not we should categorize them. I agree with that but wouldn't it be great if there was something in place that would be extensible beyond a few thousand ports without having to think about what the contents of that directory would be ? If we stopped imposing upon the names of projects like Perl with p5- or python with py- and put them in their respective alphabetic category ? If you already knew what you were looking for and you knew the structure then their is no need to search ( cd /usr/ports/pool/A-Z/portname ). A few thoughts I had to go along with this the other day when I mentioned it in ##freebsd before it was brought up here, but laced out in a tree format where I can better visually explain it than put it in words as a rough draft. I envision the tag-files directory below as a community effort of the Wikipedia kind that would lift the effort off of the committer's backs and promote more of an open involvement as a whole to edit them. This is where I seen the use of a DVCS like Mercurial come into play because if you divide it up the tree properly into separate repo's then cloning and distribution and community involvement of those repo's becomes a benefit. A referral access system along with key access, (*). ./ports |-- COPYRIGHT |-- Changelog/ | |-- ABI | |-- DELETED | |-- DEPRECATED | |-- OBSOLETED | |-- OPTIONS | `-- UPDATING |-- Distfiles/ |-- GIDs |-- INDEX-8 |-- KNOBS |-- Mgmt/ | |-- pkg_cutleaves/ | |-- portmaster/ | |-- portupgrade/ | `-- tinderbox/ |-- Mk/ |-- Packages/ |-- Tagfiles/ | |-- categories/ | | |-- devel-all | | |-- ftp-all | | |-- www-client-all | | |-- www-server-all | | `-- www-webapp-all | |-- community/ | | `-- custom-server-tag1 | `-- installs/ | |-- desktop-install-kde4.2 | `-- lamp-install |-- Templates/ |-- Tools/ |-- UIDs `-- pool/ |-- a/ |-- b/ |-- c/ | `-- clang/ |-- d/ |-- e/ |-- f/ | `-- firefox/ |-- g/ |-- h/ |-- l/ | `-- llvm-devel/ |-- libc/ |-- libh/ |-- p/ | `-- perl5.10/ |-- t/ `-- z/ Just some cents for the mail-bank. It works as it is now, if you are happy running through every once in a while and re-categorizing things and re-judging whether something is supposed to or should be in a category then sobeit, ultimately it doesn't stop the software from working on the other end and the work is still very much appreciated either way. -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN ___ 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: /tmp/portslicense.*
On Wed, 23 Mar 2011 10:16, naddy@ wrote: I notice that empty portslicense.* files keep accumulating in /tmp. From time to time I manually delete them, but shouldn't the ports framework remove them? I haven't seen this happen once throughout the ports that I use. Can you identify the port that its originating from if it is originating from ports at all ? -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN ___ 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: sysutils/gpart: deprecated port, anyone interested?
On Thu, 17 Mar 2011 05:33, mandree@ wrote: Am 17.03.2011 07:49, schrieb Rainer Hurling: Hey Matthias, thanks for taking this up. Am 17.03.2011 01:09 (UTC+1) schrieb Matthias Andree: On Wed, Mar 16, 2011 at 08:00:17PM +0100, Rainer Hurling wrote: gpart in sysutils/gpart stands for 'guess partitions'. Its an old, but very useful tool for repairing partitions. Unfortunately it does not work on amd64. I've added two patches to make it work on amd64, bumped the expiration date and port revision (to 2), but I'm not sure if it can detect all relevant partition types yet. It detects my BSD UFS partitions, but not my Windows 7 NTFS partitions, and it would probably also need ZFS detection. I can confirm that it builds and install on amd64 again. Sure enough - I'd tested that on my amd64 Tinderbox. :) Newer partition types are not known to sysutils/gpart. For me it is a useful tools to repair (older) servers with Win2000 or something like that. In some cases it was the only tool, which was able to reconstruct destroyed partition tables. Sounds reasonable. Could you test the amd64 version on some of the disks and see if it guesses reasonable partition tables, and finds existing partitions, too? I don't trust it yet, as there has been quite a bit of C integer data type abuse in the source code when, even ten years ago, /usr/include/inttypes.h existed... although the source code isn't all bad. I've fixed more than one unsigned long instance to uint32_t but didn't have time yet to look deeper to see, for instance, if all the block structures are 2^N (for N typically 9) bytes tall. An alternative appears to be http://www.cgsecurity.org/wiki/TestDisk (GPL'd), but I haven't looked closer, but the list of supported file systems is longer and comprises newer NTFS and exFAT, but not zfs/zpool either. If someone is willing to update the port: I have an original tarball 'gpart-0.1h.tar.gz'. It would need a new home ;-) Is that tarball different from what's on sunsite and currently fetched by the port? I compared it against my old distfile and all seems fine: ls -l old/gpart-0.1h.tar.gz new/gpart-0.1h.tar.gz 52357 15 Feb 19:24:06 2001 old/gpart-0.1h.tar.gz 52357 15 Feb 19:24:06 2001 new/gpart-0.1h.tar.gz SHA256 (old/gpart-0.1h.tar.gz) = b542bceb1a778c719304dadae5dbc2a8bd7f195c06774933e7255b98cfa46ee3 SHA256 (new/gpart-0.1h.tar.gz) = b542bceb1a778c719304dadae5dbc2a8bd7f195c06774933e7255b98cfa46ee3 The updated port is still marked as deprecated. Do you plan to change this back? Thanks for the comparison. What I'd like to see happen for an un-deprecation is a united effort to contact the former maintainer about his plans and situation, and else a coordination of the changes that other distributors may have added, too, so as to create a unified effort. Basically we'd need a maintainer for the port and possibly for the upstream code, too, but I don't plan to sign up for yet another maintainership. However, I don't have strong feelings about this either way. Original author Bcc'd. Just for reference I did a distfile search for this and it came up in quite a few interesting places including fc14 that isn't really that old. Attached is the result for the search. -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN http://packages.sw.be/gpart/ http://www.clearfoundation.com/component/option,com_ionfiles/fileid,58/func,download/ http://mirror.anl.gov/pub/scientific-linux/54/i386/updates/fastbugs/ http://www.cert.org/forensics/tools/fedora/cert/14/x86_64/ http://dev.centos.org/centos/5/testing/SRPMS/ http://mirror.su.lt/openSuSE.11.3/repositories/filesystems/i586/ http://ftp.eenet.ee/gentoo-portage/sys-block/gpart/files/ http://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/ http://archive.fedoraproject.org/pub/archive/fedora/linux/core/updates/6/SRPMS/ http://oss.oracle.com/el5/SRPMS/ http://free-softwares-download.info/ftp3.tsinghua.edu.cn/mirror/fedora/core/updates/5/SRPMS http://mirrors.gigenet.com/centos/5.5/os/SRPMS/ http://mib.pianetalinux.org/2009.1/i686/MIB-free/ http://download.clarkconnect.com/community/5.0/System/RPMS/ http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/ http://ftp.twaren.net/Linux/Linpus/General_Product_Source/LL94/srpms/ http://repo.cloudlinux.com/cloudlinux/5/os/SRPMS/ http://demeter.uni-regensburg.de/SLED10SP2-x64/suse/x86_64/ http://mirror.centos.org/centos/5/os/SRPMS/ http://dox.sfr-fresh.com/index_all.html http://archive.fedoraproject.org/pub/archive/fedora/linux/core/6/source/SRPMS/ http://mib.pianetalinux.org/MIB/2010.1/32/basic/ http://fr.rpmfind.net/linux/redhat/enterprise/5Client/en/os/SRPMS/ http://download.linuxaudio.org/studiotogo/src/ http://mirror.anl.gov/pub/centos/5.5/os/SRPMS/ http://lisa.gov.pt/ftp/centos/5/os/SRPMS/ http://mirror.cv.ua/archlinux/extra/os/i686/ https://ftp7.de.netbsd.org/pub/suse-old-versions/SLES10/suse/x86_64/ http://ftp.man.poznan.pl/pub/linux/fedora/core/updates/6/i386
Re: portmaster comments
On Sun, 13 Mar 2011 20:45, dougb@ wrote:
On 3/13/2011 5:35 PM, Peter Jeremy wrote:
Hi Doug,
I'd like to raise a couple of nits with portmaster (primarily a wish
for more configurability):
1) In v3.0, you added code to nice(1) all make(1) invocations. In some
cases, the default niceness does not suit me (in particular, I'd often
prefer '0' to '10'). Would it be possible to add an option to control
the priority?
2) In v3.6, you added a find $WRKDIRPREFIX ... to the cleanup. For
various reasons, I have _lots_ of unrelated stuff under that tree and
so the find(1) takes an unacceptably long time to run. It would be
nice to restrict that search to $WRKDIRPREFIX${.CURDIR} and have an
option to disable it completely.
Neither is likely to happen. :) I may however remove 1, it didn't really
help much, if at all. As for 2, my suggestion is to have a WRKDIRPREFIX for
development stuff, and a different one for portmaster. It's pretty easy to do
with a make.conf knob searching for whether UPGRADE_TOOL is set to
This doesn't have any effect for,
/usr/ports/lang/python/Makefile:31:.if defined(USE_PORTMASTER)
Does it ?
It would be real nice if these things were somewhat in sync for their
intended use.
Ill BCC python@ for the heads up on ``UPGRADE_TOOL'' I would prefer this
personally over USE_ vars. But is this common among portupgrade and
portmaster ? If not can something be done in tree to decipher it into what
is supposed to be set to avoid confusion ?
portmaster. I have such a thing which I can send you if you really need me
to, but I'm not booted into FreeBSD right now so I don't have it close to
hand.
--
Regards,
J. Hellenthal
(0x89D8547E)
JJH48-ARIN
___
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: ZFSv28, zfs list behaviour and sysutils/freebsd-snapshot
On Mon, 14 Mar 2011 04:30, mikael.urankar@ wrote:
On Mon 14 March 2011 at 02:44:16AM -0400, J. Hellenthal wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 10 Mar 2011 08:17, mikael.urankar@ wrote:
Hi,
I'm using sysutils/freebsd-snapshot to make periodic ZFS backup snapshot
and this soft is broken since the upgrade of my pool to ZFSv28.
After some debugging it appears that zfs list behaviour has changed
with ZFSv28, and since freebsd-snapshot relies on zfs list to retrieve
the ZFS file system name from the mountpoint name the soft doesn't
work anymore.
output of zfs list on a 8.2R amd64 (ZFSv15) :
zfs list /home/murankar
NAME USED AVAIL REFER MOUNTPOINT
tank/home/murankar 1.47M 1.59T 1.47M /home/murankar
zfs list tank/home/murankar
NAME USED AVAIL REFER MOUNTPOINT
tank/home/murankar 1.47M 1.59T 1.47M /home/murankar
on a 9-Current amd64 I've got no output for zfs list /home/murankar
and a exit code of 1
the output of zfs list tank/home/murankar is correct :
NAME USED AVAIL REFER MOUNTPOINT
tank/home/murankar 6,56G 286G 6,55G /home/murankar
Looking at the output here I am hoping that this is not hand typed! the
character ',' appears in this output which might fool a script into doing
other things if it has not been avoided in the first place.
This is not hand typed and depends on the locale in use :
zfs list tank/home/murankar
NAME USED AVAIL REFER MOUNTPOINT
tank/home/murankar 6,65G 286G 6,58G /home/murankar
setenv LANG en_US.UTF8
zfs list tank/home/murankar
NAME USED AVAIL REFER MOUNTPOINT
tank/home/murankar 6.65G 286G 6.58G /home/murankar
freebsd-snapshot set LC_ALL and LANG to C
If you have upgraded that machine to 9-CURRENT and have
sysutils/zfsnap installed I would recommend deleting any snapshots
that you have before it runs the snapshot scripts. This assumes that the
snapshot script might have changed since you upgraded it and that the
snapshot names are different. Better to be on the sane side.
See UPDATING/20100929 for reference.
I've deleted all old snapshots before running the snapshot scripts, but
to not avail.
# Correct syntax:
zfs list pool/dataset1/dataset2
# Incorrect syntax: ( I hope you were hand typing that and missed... )
zfs list /dataset1/dataset2
In fact I was only doing by hand what freebsd-snapshot is doing.
See op_make() from /usr/local/sbin/snapshot (near line 285) :
# operate on filesystem
+echo XXX zfs list $fs_dir
if [ .$zfs_enabled = .yes ] (zfs list $fs_dir) /dev/null
21; then
/usr/local/sbin/snapshot make -g4 /var:test
XXX zfs list /var
Is it the normal behaviour for ZFSv28 or some kind of regression ?
No its not normal, and some sort of regression possible. Though I usually
take regression as performance issues as in speed.
Also,
pkg-descr
freebsd-snapshot is a set of convenience front-end tools to mount(8)
and mdconfig(8) for the management of UFS2 snapshots. It is
also the under-lying tool used in the periodic snapshot
scheduler periodic-snapshot(8) and the mounting/unmouning
command in the amd(8) map /usr/local/etc/amd.map.snap. It
provides the making, expiring, visiting, mounting and
unmounting of filesystem snapshots.
pkg-descr
zfSnap is simple sh script to make rolling zfs snapshots with cron. Main
advantage of zfSnap is that it's written in %100 pure /bin/sh, doesn't
require any additional software to run, and is simple to use.
zfSnap keeps all information about snapshot in snapshot name. zfs snapshot
names are in form: Time-stamp--TTL where time-stamp is date and time of
snapshot creation and TTL is Time To Live in human readable form.
Did you happen to mix the above two up ? If so then rinse and repeat.
Nope, freebsd-snapshot can handle ZFS snapshot and it uses to work fine
with ZFSv{14,15}, see the copyright notice :
FreeBSD UFS/ZFS Snapshot Management Environment, the pkg-descr file
seems outdated.
Thanks for your help.
Since this is s locale dependent script I have added the maintainer to the
CC so he can adjust it properly upstream.
A simple ( export LC_ALL=C ) to the top of the script should fix it
permanently.
--
Regards,
J. Hellenthal
(0x89D8547E)
JJH48-ARIN
___
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: net/samba-libsmbclient SAMBA_PORT= - SAMBA_PORT?=
On Sat, 12 Mar 2011 10:25, timur@ wrote:
Hi!
On Tue, Mar 1, 2011 at 6:46 AM, jhell jh...@dataix.net wrote:
Could you please change the SAMBA_PORT= directive in samba-libsmbclient to
SAMBA_PORT?= samba34 so it can be overridden by make.conf or command line ?
No, I believe it's a bad idea.
It's - is either a bad idea or a good one, there is no grey line where
belief should be playing a part. You either know or you don't.
There is probably some bad magic that will happen on a machine with samba35
installed and libsmbclient34 and I would like to stay as close as I can to
using the same version of samba that's installed and making the above
corrections would still allow for the current functionality to be kept while
allowing an override.
The flexibility in the base port definition is done to ease my life, as
a maintainer, not to easily switch between the versions.
That's great I am all for that but, this is not that much of a 'OMG
surprise' if a user decides to bump something like this for their own
purpose, 'just like yours'.
Code wise libsmbclient in 34 and 35 should be the same, as the library
isn't actively developed and stable. I don't want people to recompile
firefox, for example, cause version of Samba have been bumped again -
there is no real need for this. Another story is that it's hard to
guaranty that that between 34, 35 and 36 version the packaging list of
the port will remain the same.
I sort of agree with the example you have about firefox but again this is
a change that a user would subject them self to if they were to change it.
If they are reading the Makefile then I would hope if they are changing a
variable like this then they are willing to deal with the repercussions
from that change.
This variable is already hard-locked down to samba34 so adding such a minor
change as '?' to change how the variable operates does not seem like such
a bad idea. It affects nobody other than those that change it.
In any case would you mind adding a variable to the Makefile then ?
SAMBA_PORT =${SAMBA_LIBSMBPORT:=samba34}
Which would ultimately still allow to change it by an undocumented
SAMBA_LIBSMBPORT variable and also allow the current conditions to still
exist if the user had already defined SAMBA_PORT in their make.conf.
PS: 3.5.8 Since 7 March 2011
http://samba.org/samba/history/samba-3.5.8.html
http://www.samba.org/samba/ftp/patches/security/samba-3.5.6-CVE-2011-0719.patch
--
Regards,
J. Hellenthal
(0x89D8547E)
JJH48-ARIN
___
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: some ports doesn't build with non standard WRKDIRPREFIX
On Sat, 12 Mar 2011 16:07, subbsd@ wrote: On Sat, Mar 12, 2011 at 11:38 PM, Doug Barton do...@freebsd.org wrote: On 03/12/2011 00:37, Subbsd wrote: Hi. Ive have server with huge of RAM (32 GB) and after mounting tmpfs on /tmp try use it for more faster port building. Most of the ports work when set WRKDIRPREFIX=/tmp/ports in /etc/make.conf is magnificently. But part of ports not, for example: /usr/ports/devel/ode % make -V WRKDIRPREFIX -C/usr/ports/devel/ode /tmp/ports This is your problem right here... do-not-use-quotes-here # This is exactly whats in my make.conf for ports(7). WRKDIRPREFIX?=/usr/obj Read slower, -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN ___ 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
Expansion of -I wrong for emacs builds without fail.
stable/8 i386, Can we get this fixed please!. It does not stop compilation and build succeeds and runs as expected though were throwing non-existent options to gcc or any other compiler that's used. I noticed this a few weeks ago when I first built the port but let it be figuring it would probably be fixed by now... needless to say due to the ncurses bump not too long ago, it has brought it to my attention again. cc -c -I/usr/X11R6/include -I/usr/local/include -L/usr/local/lib -I/usr/local/include -Demacs -DHAVE_CONFIG_H -I. -I/usr/obj/usr/ports/editors/emacs/work/emacs-23.2/src -I/usr/X11R6/include -I/usr/local/include -L/usr/local/lib -I/usr/local/include -D_THREAD_SAFE -D_REENTRANT -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -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 :HERE: -I/usr/local/include/gio-1 -2.0/ -I/usr/local/include :HERE: -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/librsvg-2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/cairo -I/usr/local/include -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -O2 -pipe -fno-strict-aliasing -I/usr/local/include/freetype2 -I/usr/local/include xdisp.c :CAUSES: cc: unrecognized option '-2.0/' :CAUSES: Relevant configuration: /var/db/ports/emacs/options # This file is auto-generated by 'make config'. Incorrect spelling for ``servicable'' as a side note. :PS: # No user-servicable parts inside! :PS: # Options for emacs-23.2_4,2 _OPTIONS_READ=emacs-23.2_4,2 WITHOUT_CANNA=true WITHOUT_DBUS=true WITHOUT_GCONF=true WITH_GIF=true WITH_GTK2=true WITH_JPEG=true WITHOUT_M17N=true WITHOUT_MOTIF=true WITH_OTF=true WITH_PNG=true WITHOUT_SOUND=true WITH_SOURCES=true WITH_SVG=true WITH_TIFF=true WITHOUT_XAW=true WITHOUT_XAW3D=true WITH_SYNC_INPUT=true WITH_SCROLLBARS=true WITH_XFT=true WITH_XIM=true WITH_XPM=true -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN ® ___ 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: diablo-jdk- misses libodbcinst.so conflicts libiodbc/virtuoso
On 01/04/2011 09:37, David Southwell wrote: Hi pkg_libchk shows that diablo-jdk misses libodbcinst.so: diablo-jdk-1.6.0.07.02_12: /usr/local/diablo- jdk1.6.0/jre/lib/amd64/libJdbcOdbc.so misses libodbcinst.so Is it right that libodbcinst.so is installed by unixODBC-2.3.0_1 ? When attempting to install databases/libodbc++ (includes unixODBC) which would presumably fix this issue I receive the console report: unixODBC-2.3.0_1 conflicts with installed package(s): libiodbc-3.52.7 virtuoso-6.1.2_1 I need virtuoso on this system. How do I preceed? Replace libiodbc with unixODBC They provide the same layer that virtuoso would need for ODBC. -- Regards, jhell,v JJH48-ARIN ___ 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: RFT: deskutils/sciplore-mindmapping
On 08/31/2010 06:14, Sutra Zhou wrote: On Tue, Aug 31, 2010 at 6:44 AM, Matthias Andree mand...@freebsd.org wrote: Greetings, I have create a new port for SciPlore Mind Mapping, a mind mapper/manager with reference and PDF management (to integrate with JabRef, Mendeley, BibTeX). The port requires Java 1.6. Since this is my first Java-related port, and I haven't all the related tools installed, I'd like to request testing and feedback on the port. Please let me know if it works for you, what reference and/or PDF software you've used, or if it fails, or if you spot something I can improve before making this an official port. URL: http://home.pages.de/~mandree/freebsd/ - grab the .shar file and the GnuPG signature, make sure the file wasn't tampered with, then type: cd /var/tmp sh /path/to/sciplore-mindmapping.shar cd sciplore-mindmapping make install clean Thanks a lot. I works OK on my 8.0-RELEASE. Runs as expected on FreeBSD 8.1-STABLE. Java runs like shit, menu's for me have been wacked for some time with no seen fix in the future. I am starting to think its my minimal approach to X using Xmonad as a window manager but the last time I tried to get anyone to test and see if things worked! properly I had no replies. Would be nice to get software like this working but who knows. Other than the above, nice job... Submit Commit! -- jhell,v ___ 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
Signing Request
If you do not need to pgp/gpg sign email message to the lists please don't. I know I probably don't have your pgp public key and a lot more users probably do not either. Please use your best judgment. Thank you and best regards. -- J. Hellenthal jhellent...@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: Signing Request
On Wed, 2009-09-23 at 11:40 -0400, J. Hellenthal wrote: If you do not need to pgp/gpg sign email message to the lists please don't. I know I probably don't have your pgp public key and a lot more users probably do not either. Please use your best judgment. Thank you and best regards. BTW, it also helps to mitigate messages like this one... robert. ___ 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: Signing Request
On Wed, 23 Sep 2009 11:40 -, jhellenthal wrote: If you do not need to pgp/gpg sign email message to the lists please don't. I know I probably don't have your pgp public key and a lot more users probably do not either. Please use your best judgment. Thank you and best regards. Alright If I must. Let me explain this email for the uncommon circumstances and big heads on the subject line. This was just a request not an authoritative (must do) and certainly not spam as some have had a concern over. If I do not have your public key in my keyring then I do not want it, do not need it and have no use for it at this time. This keeps my keyring small and manageable. I do not feel the need to explain my process or setup on this matter as this email was intended as just a request as I don't see the need to sign a message to a mailing list when the information that is contained in more than half of the incoming email is not important enough to be signed. For an example of the emails I am referring to (ports@): I am having problems with such/and/such/port/ Why should it be signed ? I understand, shit happens but I don't need to verify that it happened to Random Joe. Now on the other hand I firmly believe that a patch that is submitted by a maintainer or someone @FreeBSD.org should be signed. I am not referring to these emails at all in the last message and I apologize if that was unrecognizable to you. There is a purpose for signing messages that contain information that someone needs to verify is actually from a trusted source but not all information that is transmitted needs to be verified. And that is all I was referring to when saying use your best judgment. I will not be posting back on this subject as I never intended for this to be a off topic matter (just a request). Best regards -- J. Hellenthal (0x87337C16) gmail.com!jhellenthal :wq ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Need to use some library path before /usr/lib
On Thu, 17 Sep 2009 12:45 -, gerald wrote: Building some (Fortran) applications with lang/gcc44 it turns out we get weird failures upon startup which look like: /libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by ./gendoc not found What is happening here is that lang/gcc44 lays down /usr/local/lib/gcc44/libstdc++.so.6 and puts /usr/local/lib/gcc44 into USE_LDCONFIG. Alas the system then finds and uses /usr/lib/libstdc++.so.6 from our aging system compiler instead. Now, both libraries share the same name/version because these libraries, like also (and especially) libgcc_s.so.1 because new versions are drop ins for older ones, but not the other way round. How can we address this? Updating the old, unsupported by upstream system compiler has been ruled out historically, and does not look like an option (and also would not help older versions of FreeBSD). Use -rpath, somehow, by changing the configuration of the lang/gcc44 ports? That sucks in that it will break updates to newer versions of GCC. Set up ldconfig such that /usr/local/lib/gcc44 comes before /usr/lib? Anything else? Any pointers on how to best implement an ordering of search paths for ldconfig (or rpath, if that is the best of options)? Gerald Would it be possible to just libmap.conf gcc44 and friends just for that lib and the programs it builds. I know this is not such a great solution but for the mean time it may be a relevant answer. -- Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: show port commit history in portmaster
On Sun, 13 Sep 2009 19:57 -, villa.alberto wrote: hello! encouraged by a request, i've written this small utility (attached) to show the commit history for a port (using freshports.org), and i was wondering... how about adding this functionality to portmaster? here's an example of its output: $ ./portchangelog.sh editors/vim === Gathering commit history for editors/vim === Number of commits found: 220 (showing only 100 on this page) = 29 Jul 2009 21:19:43 7.2.239 Committer: w...@freebsd.org Chase patch rename so that it passes make checksum = 29 Jul 2009 08:40:23 7.2.239 Committer: obr...@freebsd.org Change name of diked patch. at the moment it is a bit rough (it is just a shell script), but i can make it more serious if wanted (eg. not using a nbsp; to identify a field) so... what do you think about this? I don't see this as a necessary addition. For one portmaster is a shell script. For two it means that the upgrade always needs to be connected and able to connect to the freshports site. For three freshports is just an 3rd party site where as you can get commit info right from the FreeBSD.org repo's. Four I don't see why anyone needs the commit info at upgrade time because as a part of administration this should be taken care of before you decide to upgrade anything. Best regards. -- Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/9base v2 upgrade to v4
On Thu, 10 Sep 2009 04:24 -, sbrabez wrote: Hi Jason On Wed, Sep 9, 2009 at 6:10 PM, Jason J. Hellenthal jas...@dataix.net wrote: Would it be possible to fit in 9base-4 before the ports freeze. I am planning on going off air within the next couple of weeks and this is my preferred window manager and the provided with 9base-4 read command sure would come in handy. http://dl.suckless.org/tools/9base-4.tar.gz Thanks in advance. -- |-| Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) I prefer wait the port freeze of 14 September to update devel/9base but as you need it. I attached a unified diff which allow you to compile and install the new version 9base-4 released the 2009/09/27. As you could see, It needs lot of changes because lot of new binaries are now in plan9port distribution. That's why I want to wait the port freeze to correct handle them. Regards Thank you very much, This is much appreciated. As a workaround I have been just doing a local compile of 9lib and read then just copying the resulting read static binary to local/9/bin. Though this has provided temporary fixes its a pretty tedious process. Curious question: Have you noticed any weirdness the user environment whether it be in X or on the console while the fdescfs module is loaded ?. I have had some impacts with this being loaded in the past that I can not really explain and has deterred me from wanting to use the environment with that module loaded. I have noticed this happening since 6.1 through 7.2-STABLE and not specific to just the wmii port. Best regards. And thanks again. -- || Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
devel/9base v2 upgrade to v4
Would it be possible to fit in 9base-4 before the ports freeze. I am planning on going off air within the next couple of weeks and this is my preferred window manager and the provided with 9base-4 read command sure would come in handy. http://dl.suckless.org/tools/9base-4.tar.gz Thanks in advance. -- |-| Jason J. Hellenthal http://www.DataIX.net/ jas...@dataix.net 0x691411AC - (2^(N-1)) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/gnome-system-tools-2.22.2_1 self referencing symlink
Additionally Installed by: www/epiphany-extensions - epiphany-extensions-2.26.1 /usr/local/share/gnome/help/epiphany-extensions/C/figures/epi-ext-action-use.png ../../C/figures/epi-ext-action-use.png On Thu, 27 Aug 2009 15:04:27 -0400 Jason J. Hellenthal jas...@dataix.net wrote: [HEADS-UP] gnome-system-tools-2.22.2_1 installs a self referencing symlink. /usr/local/share/gnome/help/services-admin/C/figures lrwxr-xr-x 1 root wheel 38 Aug 27 14:53 service-properties.png - ../../C/figures/service-properties.png This file is referenced by a half dozen or more other symlinks for other area's of that help section. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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/graphviz dangling symlinks
graphics/graphviz dangling symlinks: This port installs these symlinks which point to a missing file(s) dangling: /usr/local/share/doc/graphviz/pdf/neato.pdf - dot.pdf dangling: /usr/local/share/doc/graphviz/pdf/twopi.pdf - dot.pdf dangling: /usr/local/share/doc/graphviz/pdf/fdp.pdf - dot.pdf dangling: /usr/local/share/doc/graphviz/pdf/circo.pdf - dot.pdf dangling: /usr/local/share/doc/graphviz/pdf/dot2gxl.pdf - gxl2dot.pdf -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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
sysutils/gnome-system-tools-2.22.2_1 self referencing symlink
[HEADS-UP] gnome-system-tools-2.22.2_1 installs a self referencing symlink. /usr/local/share/gnome/help/services-admin/C/figures lrwxr-xr-x 1 root wheel 38 Aug 27 14:53 service-properties.png - ../../C/figures/service-properties.png This file is referenced by a half dozen or more other symlinks for other area's of that help section. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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
xine failure during linking on FreeBSD 7.2
ports/multimedia/libxine Somehow links against a lib in its own source directory. Unresolvable link(s) found in: /usr/local/bin/xine-list-1.1 ../src/xine-engine/.libs/libxine.so Is there another way of getting around this problem ? -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portversion and pkg_version have different opinions on current versions
On Sat, 15 Aug 2009 20:48:53 +0200 Thomas Backman seren...@exscape.org wrote: On Aug 15, 2009, at 20:31, Miroslav Lachman wrote: Thomas Backman wrote: [...] [r...@chaos ~]# pkgdb -aF --- Checking the package registry database [r...@chaos ~]# portversion -l '' dnsmasq ezm3 libtool python26 [r...@chaos ~]# pkg_version | awk '$2 !~ /=/' [r...@chaos ~]# portupgrade -a [r...@chaos ~]# [...] As was mentioned, you can use pkg_version -L =, or you can compare it with INDEX.db instead of ports tree: pkg_version -IL =. This is significantly faster. pkg_version -L = Usr: 7.286s Krnl: 3.984s Totl: 0:31.77s pkg_version -IL = Usr: 0.195s Krnl: 0.015s Totl: 0:00.21s And if you want to know the version of newer (available) port, you can use pkg_version -vIL = It gives you something like this: png-1.2.35 needs updating (index has 1.2.38) postfix-2.5.6,1 needs updating (index has 2.6.3,1) vim-lite-7.2.209needs updating (index has 7.2.239) Miroslav Lachman Thanks, guys! However, a new issue appeared... Kind of. I know I read something about portsnap and INDEX on the -current list recently, so I'm guessing this is related? Maybe not, though (see later in the mail). [r...@chaos /usr/ports/ports-mgmt]# portsnap -I fetch update /dev/null [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vL= [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vIL= curl-7.19.5_1 needs updating (index has 7.19.6) dnsmasq-2.49_1 needs updating (index has 2.49_2) ezm3-1.1_2 needs updating (index has 1.2_1) libtool-1.5.26 ! Comparison failed postfix-2.6.2_1,1 needs updating (index has 2.6.3,1) python26-2.6.2_1 needs updating (index has 2.6.2_2) vnstat-1.7_2 needs updating (index has 1.8) vsftpd-ssl-2.1.2 needs updating (index has 2.2.0) [r...@chaos /usr/ports/ports-mgmt]# portupgrade -a [r...@chaos /usr/ports/ports-mgmt]# ls -l /usr/ports/INDEX-* -rw-r--r-- 1 root wheel 17370624 Jul 31 19:45 /usr/ports/INDEX-5 -rw-r--r-- 1 root wheel 19813792 Aug 15 20:42 /usr/ports/INDEX-6 -rw-r--r-- 1 root wheel 19808537 Aug 15 20:42 /usr/ports/INDEX-7 -rw-r--r-- 1 root wheel 34316288 May 8 10:35 /usr/ports/INDEX-7.db -rw-r--r-- 1 root wheel 19816190 Aug 15 20:42 /usr/ports/INDEX-8 -rw-r--r-- 1 root wheel 1291821 May 30 12:06 /usr/ports/INDEX-8.bz2 -rw-r--r-- 1 root wheel 34869248 Aug 14 19:30 /usr/ports/INDEX-8.db [r...@chaos /usr/ports/ports-mgmt]# date Sat Aug 15 20:43:07 CEST 2009 [r...@chaos /usr/ports/ports-mgmt]# So... Using the index causes problems (or the opposite!). Could I be using an index for something like HEAD despite not using that ports tree? (Again, pretty new to this!) I don't know how the INDEX files work, but I do know (thank you DTrace) that INDEX-8 was the only one read during pkg_version -vIL=. Oh, and my understanding is that the INDEX-8 is fetched via portsnap? Running the fetch update took less than 20 seconds (the cron job ran about 2 hours ago, though), so I guess it cannot have been built (that does take a lot of time, yes?)? Regards, Thomas Why not just add weekly_status_pkg_enable=YES to /etc/periodic.conf.local and youll be informed of packages that need updating. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portversion and pkg_version have different opinions on current versions
On Sat, 15 Aug 2009 13:06:56 -0700 Doug Barton do...@freebsd.org wrote: Jason J. Hellenthal wrote: Why not just add weekly_status_pkg_enable=YES to /etc/periodic.conf.local and youll be informed of packages that need updating. Sorry to pick on your response, but this thread is a good time to remind people of some basic mailing list etiquette: No its not a problem at all I must have missed part of the thread and picked up the portion where pkg_version was being discussed. 1. Read the whole thread before you reply (the suggestion you made above was already made earlier in this thread). 2. Make sure you understand the real problem before you reply (the OP has some sort of problem with his INDEX and ports tree not matching, we've moved past just finding out what needs updating). 3. Don't speculate. If you're not 100% sure about something let someone who is more knowledgeable reply. There have been several posts in this thread that gave misleading and/or confusing information that could easily have been avoided. hth, Doug -- This .signature sanitized for your protection -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Updating the Mailscanner port
On Fri, 14 Aug 2009 11:18:13 -0400 Kevin Kobb kk...@skylinecorp.com wrote: Johan Hendriks wrote: Mike Jakubik wrote: On Mon, March 30, 2009 9:49 pm, Mark Linimon wrote: On Thu, Mar 26, 2009 at 09:04:30PM +1100, Peter Jeremy wrote: If the existing maintainer has disappeared, one option would be for you to take over maintainership: Upgrade mailscanner yourself and submit the upgrade as a PR that also transfers maintainership to youself. If there's no response after about 2 weeks, the port is yours. Actually, there is a 2-week timeout on updates, but a 3-month timeout on maintainer inactivity for transferring maintainership. Vacations can last more than 2 weeks :-) I've just submitted a patch that updates this port to the latest version, perhaps we can squeeze it in before the freeze. http://www.freebsd.org/cgi/query-pr.cgi?pr=137747 Thanks. ___ 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 I noticed a couple of things here. The 4.78.9 version is still listed as Beta according to the MailScanner site, though the site may just not have updated yet. Second, the patch submitted forces perl 5.10+ as a requirement. I've seen nothing on the MailScanner site that says that this is a requirement, and have had no problems myself using any of the Beta versions with perl 5.8.9_3. Given that upgrading perl is not something to be done lightly, I was wondering what issues people were seeing that 5.10 fixed. Thanks I am running quit a few Mailscanner servers, and they all failed under perl 5.8.9 This was on FreeBSD 6.x, 7.x and 8-Current that time, when i switched to 5.10.x or back to 5.8.8 my problems went away. if you google on FreeBSD perl 5.8.9 and mailscanner there are a lot of people reporting issues. Regards, Johan Hendriks No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.55/2301 - Release Date: 08/13/09 18:16:00 ___ 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 I do remember seeing these problems reported, but for the life of me, I can not reproduce them. I use 5.8.9 in production, and get 20 to 40 thousand messages a day scanned without a problem. I am setting up a new server, and I will try 5.10 on that and see how things go. ___ 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 This is most likely the common problem. ports/UPDATING states: 20090113: AFFECTS: users of lang/perl5.8 AUTHOR: s...@freebsd.org lang/perl5.8 has been updated to 5.8.9. You should update everything that depends on perl. The easiest way to do that is to use perl-after-upgrade script supplied with lang/perl5.8. Please see its manual page for details. Please check UPDATING after to follow up on any other updates for perl that you might have to perform. This explains why going back to 5.8.8 works for you. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net I pledge Allegiance to the Flag of the United States of America, and to the Republic for which it stands; one Nation under God, Indivisible, with Liberty and Justice for all. ___ 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
ImageMagick-6.5.* missing libs
This has not had any negative effect on any of the operations that I have used ImageMagick for but thought I would get this out there to see if there is something I might have missed or maybe there is something missing upon install. This has gone on repeatedly since 6.5.* versions repeatedly. Output from portmaster: === Creating a backup package for old version ImageMagick-6.5.4.10 tar: lib/ImageMagick-6.5.4/modules-Q16/coders/djvu.a: Cannot stat: No such file or directory tar: lib/ImageMagick-6.5.4/modules-Q16/coders/djvu.la: Cannot stat: No such file or directory tar: lib/ImageMagick-6.5.4/modules-Q16/coders/djvu.so: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 === Backup package creation failed for ImageMagick-6.5.4.10! === Ignore this error [i] === Abort [a] Any insight into this would cetainly be helpful since this causes a automagick ;-) backup process to stop. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: Multiple instances of Mailman on FreeBSD
On Wed, 12 Aug 2009 15:41:19 -0500
Jeffrey Goldberg jeff...@goldmark.org wrote:
On Aug 12, 2009, at 3:21 PM, Paul Schmehl wrote:
--On Wednesday, August 12, 2009 13:55:18 -0500 Jeffrey Goldberg
jeff...@goldmark.org
wrote:
I'm posting this to both the mailman-users list and the freebsd-ports
list. I realize that not all follow-up will make it to both lists.
But when I do
% cd /usr/ports/mail/mailman
% sudo make -DMM_DIR=mailman/vhosts/lists.wilson-pta.org -
DFORCE_PKG_REGISTER install
It just installs in the default location, /usr/local/mailman
This could be a really stupid question (because I've never tried to
do what you're doing), but shouldn't the above line be:
$ sudo make MM_DIR=/mailman/vhosts/lists.wilson-pta.org
In other words, don't you have to provide the *absolute* patch to
the install location?
No. Reading the Makefile it is clear that MM_DIR is relative to $PREFIX
The default setting in the Makefile is
MM_DIR?= mailman
And later on there is a
MAILMANDIR= ${PREFIX}/${MM_DIR}
With MAILMANDIR being the absolute install directory.
The problem is, I'm not exactly sure *where* you want mailman to
install, so it's hard to be correct without more information.
Mailman (under normal defaults) installs in various directories under
/usr/local/mailman
The python for all of the CGIs lives in
/usr/local/mailman/Mailman
and the programs that an administrator might run on the command line
live in
/usr/local/mailmain/bin
And there are various other directories for queues and logs and data
and per list configurations and such
I want to have instances installed in
/usr/local/mailman/vhosts/site1
/usr/local/mailman/vhosts/site2
/usr/local/mailman/vhosts/site3
Cheers,
-j
--
Jeffrey Goldberghttp://www.goldmark.org/jeff/
Can you not just ( cp -r /usr/local/mailman /path/to/vhost/staging ) edit some
of the paths and then just host it. How many of the files are you actually
required to edit ?. If this will be a continual process it might be better off
to rsync your master mailman directory to all the separate vhosts obviously
skipping configs and list directories and then scripting out the exact changes
you need to make up creation of a new vhost.
Best regards.
:wq
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.net
___
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: ImageMagick 6.5.4.10
On Wed, 12 Aug 2009 20:11:20 -0500 ajtiM lum...@gmail.com wrote: Update to 6.5.4.10 on FreeBSD 7.2 magick/.libs/libMagickCore.so: undefined reference to `carg' *** Error code 1 magick/.libs/libMagickCore.so: undefined reference to `carg' *** Error code 1 2 errors *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/graphics/ImageMagick. *** Error code 1 Stop in /usr/ports/graphics/ImageMagick. === make failed for graphics/ImageMagick === Aborting update -- Mitja - http://starikarp.redbubble.com I have just built this as of the last 5 minutes with no problems. I am using all but three configure options... [ ] IMAGEMAGICK_TESTSRun bundled self-tests after build [ ] IMAGEMAGICK_OPENMP OpenMP for SMP (needs threads) [ ] IMAGEMAGICK_HDRI High Dynamic Range Images (HDRI) -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: ImageMagick 6.5.4.10
On Wed, 12 Aug 2009 21:44:39 -0500 (CDT)
Stephen Montgomery-Smith step...@missouri.edu wrote:
On Wed, 12 Aug 2009, Jason J. Hellenthal wrote:
On Wed, 12 Aug 2009 20:11:20 -0500
ajtiM lum...@gmail.com wrote:
Update to 6.5.4.10 on FreeBSD 7.2
magick/.libs/libMagickCore.so: undefined reference to `carg'
*** Error code 1
Try this patch:
diff -u magick/fourier-orig.c magick/fourier.c
--- magick/fourier-orig.c 2009-08-13 02:39:18.0 +
+++ magick/fourier.c2009-08-13 02:40:13.0 +
@@ -515,7 +515,7 @@
for (x=0L; x (long) fourier_info-center; x++)
{
magnitude[i]=cabs(fourier[i]);
-phase[i]=carg(fourier[i]);
+phase[i]=atan2(cimag(fourier[i]),creal(fourier[i]));
i++;
}
else
I conclude this fixes the problem on 7.2-RELEASE-p3/i386 Non-SMP
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.net
___
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/netpbm netpbm-devel
graphics/netpbm netpbm-devel: These two ports dont list and CONFLICTS for either one of them. They do on the other hand list a conflict with mgetty ???. Why don't these list conflicts with each other?. As of now I am doing cleanup once again for two versions of netpbm that have somehow been installed by portmaster during the mass confusion of graphics/jpeg. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: No sound in linux-flashplugin-9.0r246 on -current
On Sat, 08 Aug 2009 22:27:23 +0200 Rainer Hurling rhur...@gwdg.de wrote: Hi Doug, for me it helps to set the following link ln -s /compat/linux/lib/libssl.so.0.9.8g /compat/linux/lib/libssl.so.5 Hope this helps, Rainer Hurling On 08.08.2009 21:25 (UTC+2), Doug Barton wrote: I vaguely recall seeing something about this, but don't recall if there was a resolution. Doug Is this something that could be handled through libmap.conf rather than adding an extraneous symlink to that may stick around after package deletion ? Curious question as I am unsure if libmap.conf can handle /compat/linux. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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
slib-guile
# Date created:3 November 2003 # Whom:Kimura Fuyuki fuy...@nigredo.org # # $FreeBSD: ports/lang/slib-guile/Makefile,v 1.8 2008/06/06 13:41:14 edwin Exp $ #$MCom: ports/lang/slib-guile/Makefile,v 1.3 2006/10/13 02:32:48 marcus Exp $ PORTNAME= slib PORTVERSION=3a4 # Keep this in sync with lang/slib PORTREVISION= 2 CATEGORIES= lang scheme MASTER_SITES= # empty PKGNAMESUFFIX= -guile DISTFILES= # empty This is not in sync with lang/slib is this port used anymore or should I just disregard this to /dev/trash ? -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/*/jpeg Thanks a lot guys
I believe unless I misunderstand what you are meaning, is the same thing that
PORTREVISION is meant for doing. If the maintainer like what has just recently
happened for jpeg bumps the PORTREVISION up one for every port that depends on
jpeg then any upgrade utilities see that port as a new version and upgrade them
happily.
PORTREVISION is the end of the package name as package-VERSION-{ , or _
}PORTREVISION.
Personally I feel that adding another NODE_VERSION as your saying could
possibly be a benefit but at this time would cause a lot of maintainer overhead
on which that they already have. I think more of a short written policy or
checklist system for a maintainer might be a better route. Or possibly a ticket
system built around a dependency checklist that should be fulfilled before a
commit on a newer version would happen. Even with the previous statement that
still causes overhead in workload but eventually speeds the process up due to
lack of errors and re-corrections that have to be made ultimately resulting in
a higher percent of satisfied hobbyists and customers alike thus bringing in
more revenue.
If I could be of more assistance on this matter I have great experience
satisfying time tested analytics that speed up processes in the form of Lean
Manufacturing also plays a role in development.
Best regards.
On Thu, 6 Aug 2009 12:46:12 +0800
Buganini bugan...@gmail.com wrote:
Recently I'm think about how to make ports easier to upgraded:
1) Add a NODE_VERSION in each ports' Makefile, this variable would be stored
in +CONTENTS.
2) Add a volatile-meaning flag in description of dependencies
When a port, A, whose NODE_VERSION in Makefile NODE_VERSION in +CONTENTS,
ports that volatile'ly depends on A would be rebuilt.
Any comment is welcome
--Buganini
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.net
___
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
Ideas upon the port infrastructure. [MOVED] was ports/*/jpeg Thanks a lot guys
That is a very nice idea, I am sure that with a little tweaking it would turn
out just fine.
Another nice aspect or solve for this would be getting something going like
symbol versioning in the libs by means of the developer that supports 2 or so
version's prior to the current lib in order to ease upgrading on any system
rather than just FreeBSD. I am certainly no expert in that field so I can not
comment more.
More comments ? any other takers. Brain storming session
On Fri, 7 Aug 2009 07:13:31 +0800
Buganini bugan...@gmail.com wrote:
The meaning of NODE_VERSION and the flag is to describe dependencies more
detailed,
to make it possible to do automated upgrade, instead of bump PORTREVISION by
man.
An important thing, NODE_VERSION and the flag could be backward compatible,
for port/package don't have NODE_VERSION, it's just 0.
the flag could be just a '!' prefix, for example:
!fltk-threads=1.1.9:${PORTSDIR}/x11-toolkits/fltk-threads
QT_COMPONENTS= gui imageformats_run moc_build !qmake_build !uic_build
without the flag, everything is just like how it is now.
this should be enough for cases like this jpeg case.
For more detail, if we only save NODE_VERSION of port itself in +CONTENTS
upgrade MUST be transactional, but for portupgrade and portmaster, exit in
half way is usual,
so I think to save NODE_VERSION of each dependencies is also necessary,
or even make it part of version string, but this may be confused for
somebody I think.
For the upgrade of perl, now we use port* -o to replace, then -r or -fr to
rebulid required-by
If we have
NODE_VERSION=5.8.0 in lang/perl5.8
NODE_VERSION=5.10.0 in lang/perl5.10
then when we port{upgrade,master} -o lang/perl5.10 perl5.8
we dont have to rebuild required-by manually anymore.
Furthermore, a unified target post-upgrade: is good, some ports has already
have this,
for example, upgrade-site-packages in lang/python
--Buganini
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.net
___
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
ports/*/jpeg Thanks a lot guys
Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg Great real great Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/*/jpeg Thanks a lot guys
On Fri, 31 Jul 2009 16:53:16 -0500 Jeremy Messenger me...@cox.net wrote: On Fri, 31 Jul 2009 12:36:36 -0500, Erik Trulsson ertr1...@student.uu.se wrote: On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg Great real great Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. Nobody is forcing you to rebuild your ports just because the PORTREVISION was bumped. If everything works fine for you there is actually no good reason at all to do so. So now the implication becomes that everyone should resort to manual checking of port versions and upgrade each port manually from here on out ?. Because if that is going to happen then eventually someone or a amateur for that matter is going to manually check their ports and come across an update they need and then it will update hand-in-hand every port that depends on libjpeg just to satisfy itself. Am I wrong ? is this not why portupgrade and portmaster were created so this could be done autonomously ? Don't get me wrong but I have been very involved in this upgrade that slipped into my systems from the 19th and it is frustrating when a rather circumvented actions consequences were not well thought out and gets repeated again for a third time. Please don't take this as a list bash or a personal matter, but I believe this needs to be discussed so it could be prevented in the future. Maybe a policy change on library bumps ? that gets more developers involved so the process is less likely to cause administration overhead. Or a policy stating that if your ports lib is bumped you should also bump all PORTREVISIONS that depend on it at the time it is committed ?. That is up for discussion and these are only thoughts but they are thoughts with a new user community in mind. Best regards. I am not on this list: please CC me in your replies. Yes, but how can you tell if there is newer version? The pkg_version and pkgversion don't tell you that it's PORTREVISION or actually newer version. What about when we run 'port* -a'? Took about two weeks to get PORTREVISION bump isn't right at all. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org Thanks Mezz -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/jpeg especially UPDATING
If you pkg_delete -r that will remove every package that depends on jpeg. This is not the right way of just getting rid of jpeg considering it involves the complete almost full re-installation of the entire system manually. A better route to upgrade would be: pkg_delete -f jpeg-\* reinstall the new jpeg and then portmaster -r jpeg-\* I suppose the damage is already done to most of the systems for people that did not already catch this. On Thu, 23 Jul 2009 08:07:13 +0200 dirk.me...@dinoex.sub.org (Dirk Meyer) wrote: Hallo Jason J. Hellenthal, pkg_delete -r jpeg-6b_7 Please rebuild all ports that depends on it. You should remove this pkg_delete -r line in UPDATING. This is just telling the user to remove any packages that depended on jpeg recursively. There will be nothing left to upgrade if users do this as a lot of packages rely on jpeg. You need rebuild the dependent ports without old jpeg being installed. Maybe a portupgrade -fr or portmaster -r would be more appropriate. maybe, I don't use this tools, so I can not tell. I do. And I know how much of a pain it is to manually replace over 800 packages is by hand. Gruß Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.me...@dinoex.sub.org],[dirk.me...@guug.de],[din...@freebsd.org] http://people.freebsd.org/~dinoex/errorlogs/ -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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
