FreeBSD Port: lang/cmucl

[Andrew Mitchell via freebsd-ports]

Hello,
I am trying to port cmucl to RPI4-B RELEASE-13.0-RC3 (arm64-aarch64), but of 
course I can't as port's and host's architectures are different.
Any method for cross-building/compiling this port? or any other port?

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

Re: Out of memory building lang/ghc-8.8.3

[andrew clarke]

On 2020-05-05 14:19:50, Gleb Popov (arr...@freebsd.org) wrote:

> On Tue, May 5, 2020 at 1:37 PM andrew clarke  wrote:
> 
> > Beware anyone building lang/ghc-8.8.3 from the ports tree. Building it
> > here on FreeBSD 12.1-REL AMD64 with Poudriere, the build ran out of swap,
> > despite the PC having 8 GB RAM, 8 GB swap and not much else running.
> >
> > My /usr/local/etc/poudriere.conf:
> >
> > BASEFS=/poudriere
> > ZPOOL=zroot
> > FREEBSD_HOST=http://mirror.internode.net/
> > POUDRIERE_DATA=/poudriere/data
> > RESOLV_CONF=/etc/resolv.conf
> > DISTFILES_CACHE=/usr/ports/distfiles
> > USE_TMPFS=yes
> > ALLOW_MAKE_JOBS=yes
> > KEEP_OLD_PACKAGES=yes
> > PARALLEL_JOBS=8
> >
> > Maybe I can retune the last three parameters to use less memory. I've not
> > tried yet.
> >
> > This isn't really a whinge, I'm just surprised it failed. I'd have thought
> > 8 GB was enough.
> >
> > (ghc is a build dependency of textproc/hs-pandoc)
> >
> 
> Did you have something else building at the same time?
> 
> On my laptop with 16 Gb of RAM I also see OOM failures when building
> multiple "heavy" packages (llvmXX, gccX, ghc, rust, libreoffice)
> simultaneously. In this case I use -J poudriere option to limit number of
> jobs.

Nothing else building.

This is a headless server, so I've no need to build something the size of
libreoffice or chromium. I've noticed llvm10 takes a long time to build, but
8 GB seems plenty of memory for it.

The -J option sounds like the way to go, provided I remember to use it
next time. Or I could instead set PARALLEL_JOBS=1 in poudriere.conf but then
build performance will suffer for every port, which isn't ideal.

But perhaps there's an option to limit make jobs just for a single port, set in
/usr/local/etc/poudriere.d/make.conf ? That would be nice.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Out of memory building lang/ghc-8.8.3

[andrew clarke]

Beware anyone building lang/ghc-8.8.3 from the ports tree. Building it
here on FreeBSD 12.1-REL AMD64 with Poudriere, the build ran out of swap,
despite the PC having 8 GB RAM, 8 GB swap and not much else running.

My /usr/local/etc/poudriere.conf:

BASEFS=/poudriere
ZPOOL=zroot
FREEBSD_HOST=http://mirror.internode.net/
POUDRIERE_DATA=/poudriere/data
RESOLV_CONF=/etc/resolv.conf
DISTFILES_CACHE=/usr/ports/distfiles
USE_TMPFS=yes
ALLOW_MAKE_JOBS=yes
KEEP_OLD_PACKAGES=yes
PARALLEL_JOBS=8

Maybe I can retune the last three parameters to use less memory. I've not
tried yet.

This isn't really a whinge, I'm just surprised it failed. I'd have thought
8 GB was enough.

(ghc is a build dependency of textproc/hs-pandoc)

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

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[andrew clarke]

On 2020-04-18 09:34:39, Matthew Seaman (matt...@freebsd.org) wrote:

> On 18/04/2020 03:19, Robert Huff wrote:
> > a) according to the Makefile, is it possible to build this with
> > python-37?  (Or even -36?) 
> 
> If the Makefile for the port says:
> 
> USES= python:27
> 
> then the port is for python-2.7.x only.  All other python ports will
> support python-3.x (which practically speaking means python-3.7).  Note
> that ports that are python-2.7.x only are now as rare as hen's teeth as
> there has been an active program of deleting such.

Out of interest I ran "pkg del python27" on my FreeBSD machine just to
see what would break. Conspicuous was devel/mercurial:

PORTVERSION=5.1.2
USES=   cpe python:2.7

Evidently Mercurial versions 5.2 and later support Python 3. The current
stable version is 5.3.2, so the FreeBSD port is a few versions behind for
some reason.

Evidently textproc/asciidoc also still requires Python 2.7.

Though it looks like it's possible to install both Mercurial and Asciidoc
using Python 3's "pip" instead of using FreeBSD ports.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Committer needed: www/p5-Net-Curl build breakage

[Andrew Fengler]

Hi all,

I've made a patch to update p5-Net-Curl to fix the failing build.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245322

If a committer could please take care of this, it would be much appreciated.

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

multimedia/shotcut

[Andrew Johnson]

System: FreeBSD 12.1-STABLE r354452 GENERIC  amd64
Ports: cur 

Symptom: Segmentation fault

(gdb) 
(gdb) core shotcut.core
[New LWP 101419]
[New LWP 100883]
[New LWP 101488]
[New LWP 101489]
[New LWP 101490]
[New LWP 101491]
[New LWP 101492]
[New LWP 101493]
[New LWP 101494]
[New LWP 101495]
Core was generated by `shotcut'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0008006a6ab1 in ?? ()
[Current thread is 1 (LWP 101419)]


% shotcut
Gtk-Message: 09:59:25.944: Failed to load module "appmenu-gtk-module"
[Info   ]  Starting Shotcut version 19.10.20 
[Info   ]  Linux version 
[Info   ]  number of logical cores = 12 
[Info   ]  locale = QLocale(C, Default,
Default) 
[Info   ]  install dir = "/usr/local/bin" 
[Info   ]  device pixel ratio = 1 
[Debug  ]  language "C" 
[Debug  ]  deinterlacer "onefield" 
[Debug  ]  external monitor "" 
[Debug  ]  GPU processing false 
[Debug  ]  interpolation "bilinear" 
[Debug  ]  video mode "atsc_720p_50" 
[Debug  ]  realtime true 
[Debug  ]  audio channels 1 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Info   ]  OpenGL context version 4 5 
[Debug  ]  begin 
[Warning]  mlt_repository_init: failed to dlopen
/usr/local/lib/mlt/libmltavformat.so  (/usr/local/lib/libflite_cmu_us_a
wb.so.1: Undefined symbol "usenglish_init")
[Info   ]  decimal point . 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
Shared object "libDeckLinkAPI.so" not found, required by "shotcut"
[Warning]  [ 0x8078eba10] The DeckLink drivers not installed.
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  1 
[Debug  ]  1 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  "atsc_720p_50" 
[Debug  ]  setting to profile
"atsc_720p_50" 
[Debug  ]  1 
[Debug  ]  1 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  begin true 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin true 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin true 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin true 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin true 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin true 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
[Debug  ]  end 
[Debug  ]  begin 
Segmentation fault (core dumped)

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

Re: devel/dee Python27

[andrew clarke]

On Thu 2019-08-15 13:10:05 UTC+1000, Andrew Johnson (dae...@optushome.com.au) 
wrote:

> Is there any plan to drop the Python2.7 dependency of devel/dee?

It's probably out of scope of FreeBSD Ports to supply patches to the Python
part of the libdee code that rewrites it to use Python 3.x instead of Python 
2.7.

Looking at upstream[1][2], that code hasn't been updated since 2013.
The online documentation[3] is also missing.

Based on the bitrot, my guess is it has been superceded by something else?

Disclaimer: I don't use libdee.

[1] https://launchpadlibrarian.net/151383425/  "No Such Resource"

[2] https://launchpad.net/dee/ still lists the most recent version as 1.2.7

[3] http://developer.ubuntu.com/api/ubuntu-12.04/c/dee/  404: Page not found
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

devel/dee Python27

[Andrew Johnson]

Is there any plan to drop the Python2.7 dependency of devel/dee?

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

Having trouble with firstboot-growfs

[Andrew Villano]

 I've used Firstboot-growfs a few times and it usually goes without a snag.
I touch /firstboot, reboot the box and when it comes back up it resizes the
partition and resizes the filesystem.

I've just spun up a FreeBSD 12 box,
[vagrant@freebsd ~]$ freebsd-version
12.0-RELEASE-p5

I was able to resize the VMDK (by converting it to a VDI.. etc)

3. Name: ada0p3
   Mediasize: 32212254720 (30G)

   type: freebsd-ufs
   index: 3
   end: 65011837
   start: 2097278
Consumers:
1. Name: ada0
   Mediasize: 15728640 (146G)
   Sectorsize: 512
   Mode: r2w2e5

but I can't seem to get past this point. Nothing shows up in
/var/log/messages or in dmesg to indicate that there was a failure.
Strangely enough on reboot, the triggerfile /firstboot is gone as if to
indicate something was done.


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

Re: net/rtg committer needed

[Andrew]

Hi,

Any chance someone could take a look at this?  Is there still something 
missing?


Thanks,
Andrew Fengler
ScaleEngine Inc.

On 2019-05-24 12:18 p.m., Andrew wrote:

Hi,

net/rtg no longer runs on modern perl.  The maintainer made a patch 
almost a year ago, but it's been stalled on some flavour stuff.


I've modified the patch to remove the offending flavour bits, but 
haven't heard back from the maintainer in almost a month, even tried 
poking him out of band.


The orginal patch is here: https://reviews.freebsd.org/D17637
And I've uploaded my fixed patch to the bug report on bugzilla here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227376

Works on 12.0, and the maintainer's original patch before it got kicked 
out is working on both 11.x and 12.0


Is there a commiter that could take a look at this and see if we can get 
it back to working?


Thanks,
Andrew Fengler
ScaleEngine Inc.

Email: andrew.feng...@scaleengine.com
Phone: (800) 224-0095
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

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

net/rtg committer needed

[Andrew]

Hi,

net/rtg no longer runs on modern perl.  The maintainer made a patch 
almost a year ago, but it's been stalled on some flavour stuff.


I've modified the patch to remove the offending flavour bits, but 
haven't heard back from the maintainer in almost a month, even tried 
poking him out of band.


The orginal patch is here: https://reviews.freebsd.org/D17637
And I've uploaded my fixed patch to the bug report on bugzilla here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227376

Works on 12.0, and the maintainer's original patch before it got kicked 
out is working on both 11.x and 12.0


Is there a commiter that could take a look at this and see if we can get 
it back to working?


Thanks,
Andrew Fengler
ScaleEngine Inc.

Email: andrew.feng...@scaleengine.com
Phone: (800) 224-0095
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

[NEW PORT] databases/mongodb40-tools: Tools for MongoDB

[Andrew Shevchuk]

New port proposal: Tools for MongoDB 4.x

PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237352
PATCH: 
https://raw.githubusercontent.com/ashevchuk/mongodb40-tools-freebsd-port/master/mongodb40-tools.patch
Actually, the patch itself (feel free to make the necessary
corrections, if the Makefile needs changes):
--[cut]
Index: databases/Makefile
===
--- databases/Makefile (revision 499215)
+++ databases/Makefile (working copy)
@@ -201,6 +201,7 @@
 SUBDIR += mongodb36
 SUBDIR += mongodb36-tools
 SUBDIR += mongodb40
+SUBDIR += mongodb40-tools
 SUBDIR += mroonga
 SUBDIR += mrtg-mysql-load
 SUBDIR += mtools-mongodb
Index: databases/mongodb40-tools/Makefile
===
--- databases/mongodb40-tools/Makefile (nonexistent)
+++ databases/mongodb40-tools/Makefile (working copy)
@@ -0,0 +1,116 @@
+# $FreeBSD$
+
+PORTNAME= mongodb40-tools
+DISTVERSIONPREFIX= r
+DISTVERSION= 4.0.8
+CATEGORIES= databases
+
+MAINTAINER= dev.ashevc...@gmail.com
+COMMENT= Tools for MongoDB
+
+LICENSE= APACHE20
+
+ONLY_FOR_ARCHS= amd64 i386
+ONLY_FOR_ARCHS_REASON= "not yet ported to anything other than i386 and amd64"
+
+BUILD_DEPENDS= go>=${GO_LANG_VERSION}:lang/go${GO_LANG_VERSION_PATH_STR}
+
+USES= compiler:c++14-lang localbase go
+
+GO_LANG_VERSION=   1.4
+GO_LANG_VER_PATH_STR=  ${GO_LANG_VERSION:S/.//}
+
+GO_LANG_PATH_DIR= .gopath
+
+SSL_USE= my_tags=ssl
+SSL_USES= ssl
+
+SASL_USE= my_tags=sasl
+SASL_LIB_DEPENDS= libsasl2.so:security/cyrus-sasl2
+
+CONFLICTS_INSTALL= mongodb3[46] mongodb3[46]-tools
+
+USE_LDCONFIG= yes
+
+CC= clang
+
+USE_GITHUB= yes
+GH_ACCOUNT= mongodb
+GH_PROJECT= mongo-tools
+GH_TAG= 5db0b4a18cc1366ebd368eed8e7c4d426d851f13
+
+OPTIONS_SUB= yes
+NO_OPTIONS_SORT= yes
+
+OPTIONS_DEFINE= DOCS
+OPTIONS_DEFAULT= SSL SASL MONGOFILES MONGOEXPORT MONGOIMPORT
MONGORESTORE MONGODUMP
+
+OPTIONS_MULTI= TOOLS SECURITY
+OPTIONS_MULTI_TOOLS= BSONDUMP MONGOSTAT MONGOFILES MONGOEXPORT
MONGOIMPORT MONGORESTORE MONGODUMP MONGOTOP MONGOREPLAY
+OPTIONS_MULTI_SECURITY=SSL SASL
+
+BSONDUMP_DESC= BSON files into human-readable formats
+MONGOSTAT_DESC= Status of a running mongod or mongos instance
+MONGOFILES_DESC= Interface to GridFS in a MongoDB instance
+MONGOEXPORT_DESC= JSON or CSV export of MongoDB instance data
+MONGOIMPORT_DESC= Importing JSON, CSV, or TSV into a MongoDB instance
+MONGORESTORE_DESC= BSON data to a MongoDB instance
+MONGODUMP_DESC= BSON data from the contents of a MongoDB instance
+MONGOTOP_DESC= Track the amount of data I/O time
+MONGOREPLAY_DESC= Traffic capture and replay tool
+
+BSONDUMP_VARS= tool_build+=bsondump
+MONGOSTAT_VARS= tool_build+=mongostat
+MONGOFILES_VARS= tool_build+=mongofiles
+MONGOEXPORT_VARS= tool_build+=mongoexport
+MONGOIMPORT_VARS= tool_build+=mongoimport
+MONGORESTORE_VARS= tool_build+=mongorestore
+MONGODUMP_VARS= tool_build+=mongodump
+MONGOTOP_VARS= tool_build+=mongotop
+MONGOREPLAY_VARS= tool_build+=mongoreplay
+
+MAKE_CMD= ${LOCALBASE}/go${GO_LANG_VER_PATH_STR}/bin/go build
+
+MY_TAGS= -tags "${USE_MY_TAGS}"
+
+.include 
+
+post-patch:
+ @${ECHO_MSG} "Preparing hierarchy"
+ ${MKDIR} ${WRKSRC}/${GO_LANG_PATH_DIR} && \
+ ${LN} -sf ${WRKSRC}/vendor ${WRKSRC}/${GO_LANG_PATH_DIR}/src && \
+ ${MKDIR} ${WRKSRC}/${GO_LANG_PATH_DIR}/src/github.com/${GH_ACCOUNT} && \
+ ${LN} -sf ${WRKSRC}
${WRKSRC}/${GO_LANG_PATH_DIR}/src/github.com/${GH_ACCOUNT}/${GH_PROJECT}
+
+do-build:
+.for TOOL in ${TOOL_BUILD}
+ @${ECHO_MSG} "Building ${TOOL}"
+ ${SETENV} ${MAKE_ENV} \
+ GOPATH="${WRKSRC}/${GO_LANG_PATH_DIR}:${WRKSRC}/vendor" \
+ CGO_CPPFLAGS="-isystem ${LOCALBASE}/include" \
+ CGO_LDFLAGS="-L${LOCALBASE}/lib" \
+ ${MAKE_CMD} \
+ -o ${WRKSRC}/bin/${TOOL} \
+ ${MY_TAGS} \
+ ${WRKSRC}/${TOOL}/main/${TOOL}.go
+.endfor
+
+do-install:
+.for TOOL in ${TOOL_BUILD}
+ @${ECHO_MSG} "Installing ${TOOL}"
+ ${INSTALL_PROGRAM} ${WRKSRC}/bin/${TOOL} ${STAGEDIR}${PREFIX}/bin/
+.endfor
+
+ ${MKDIR} ${STAGEDIR}${DOCSDIR}
+.for DOC in README.md CONTRIBUTING.md LICENSE.md THIRD-PARTY-NOTICES
+ @${ECHO_MSG} "Installing ${DOC}"
+ ${INSTALL_MAN} ${WRKSRC}/${DOC} ${STAGEDIR}${DOCSDIR}
+.endfor
+
+post-install:
+.for TOOL in ${TOOL_BUILD}
+ @${ECHO_MSG} "Stripping ${TOOL}"
+ ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/${TOOL}
+.endfor
+
+.include 
Index: databases/mongodb40-tools/distinfo
===
--- databases/mongodb40-tools/distinfo (nonexistent)
+++ databases/mongodb40-tools/distinfo (working copy)
@@ -0,0 +1,3 @@
+TIMESTAMP = 139033
+SHA256 (mongodb-mongo-tools-r4.0.8_GH0.tar.gz) =
c224df31f85476c0f651c4b5d70871b581f14bf16a8595a4aa7717e66ad07c5c
+SIZE (mongodb-mongo-tools-r4.0.8_GH0.tar.gz) = 11134459
Index: databases/mongodb40-tools/files/patch-common_util_file.go
===
--- 

[PATCH]: databases/mongodb40 update to latest release

[Andrew Shevchuk]

Index: databases/mongodb40/Makefile
===
--- databases/mongodb40/Makefile (revision 498768)
+++ databases/mongodb40/Makefile (working copy)
@@ -2,7 +2,7 @@

 PORTNAME= mongodb
 DISTVERSIONPREFIX= r
-DISTVERSION= 4.0.6
+DISTVERSION= 4.0.8
 PORTREVISION= 1
 CATEGORIES= databases net
 MASTER_SITES= https://fastdl.mongodb.org/src/ \
Index: databases/mongodb40/distinfo
===
--- databases/mongodb40/distinfo (revision 498768)
+++ databases/mongodb40/distinfo (working copy)
@@ -1,3 +1,3 @@
-TIMESTAMP = 1549337164
-SHA256 (mongodb-src-r4.0.6.tar.gz) =
34165ef42c7199c438e1706fef515cbde012d6a884406d102082d39eab72c235
-SIZE (mongodb-src-r4.0.6.tar.gz) = 49511958
+TIMESTAMP = 1553817480
+SHA256 (mongodb-src-r4.0.8.tar.gz) =
83e694405b72002588a64275be00bf1e36e12f5955451171645f45cb3f16f251
+SIZE (mongodb-src-r4.0.8.tar.gz) = 49841488
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

net/rtg updates got reverted

[Andrew]

A bunch of fixes to rtg, most importantly making it work with modern 
perl, were committed to the ports tree in rev 484406, but immediately 
reverted.  Can we get that patch reopened, since the port is pretty 
broken without it.
I can confirm that building from r484406 works great on FreeBSD 11.2 and 
12.0.


http://svnweb.freebsd.org/changeset/ports/484406

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

Re: databases/mongodb40 port proposal

[Andrew Shevchuk]

> I also shamelessly asked Andrew if he can provide a mongodb40-tools port 8-}
The first attempt to port mongodb40-tools, I have failed.
It looks like there will be difficulties with dependencies.
As soon as there is a bit of free time, I will try to fix this port.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: databases/mongodb40 port proposal

[Andrew Shevchuk]

> > Latest stable MongoDB (4.0.6) port proposal:
> > https://raw.githubusercontent.com/ashevchuk/mongodb40-freebsd-port/master/mongodb40.patch
> I just tried to apply it so I can do some tests but I'm unable to apply
> your patch.
> I tested it with:
> patch -i mongodb40.patch

First of all, please make sure you have the latest patch file.
You can apply this patch using one of the following examples:
===
/usr/bin/fetch -qo -
https://raw.githubusercontent.com/ashevchuk/mongodb40-freebsd-port/master/mongodb40.patch
| patch -d /usr/ports
/usr/local/bin/curl -so -
https://raw.githubusercontent.com/ashevchuk/mongodb40-freebsd-port/master/mongodb40.patch
| /usr/bin/patch -d /usr/ports
/usr/bin/patch -d /usr/ports -i mongodb40.patch
===
I just rechecked the patch to work with such an environment:
the patch utility version is "2.0-12u11",
latest svn version of the ports tree is "494358".
The patch is applied without any problems...

Alternatively, you can download and use a snapshot of the directory
without applying the patch itself:
https://github.com/ashevchuk/mongodb40-freebsd-port/tree/master/databases/mongodb40
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

deskutils/cairo-dock-plugins

[Andrew Johnson]

Is the pkg-plist right?

The install failed when it wanted a non-existent libcd_xfce-
integration.so and icon-png

.svn_revision 494144
.ctm_status ports-cur 12883
11.2-STABLE FreeBSD Feb 22 2019 GENERIC amd64


...
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/nl/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/pl/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/pt/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/pt_BR/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/ru/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/sk/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/sr/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: 
/usr/ports/deskutils/cairo-dock-plugins/work/stage/usr/local/share/locale/sr@latin
/LC_MESSAGES/cairo-dock-plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/sv/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/tr/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/uk/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/uz/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/zh_CN/LC_MESSAGES/cairo-dock-
plugins.mo
-- Installing: /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/locale/zh_TW/LC_MESSAGES/cairo-dock-
plugins.mo
> Compressing man pages (compress-man)
root@certhas:/usr/ports/deskutils/cairo-dock-plugins # make install
clean
===>  Installing for cairo-dock-plugins-3.4.1_7
===>  Checking if cairo-dock-plugins is already installed
===>   Registering installation for cairo-dock-plugins-3.4.1_7
pkg-static: Unable to access file /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/lib/cairo-dock/libcd_xfce-
integration.so:No such file or directory
pkg-static: Unable to access file /usr/ports/deskutils/cairo-dock-
plugins/work/stage/usr/local/share/cairo-dock/plug-ins/xfce-
integration/icon.png:No such file or directory
*** Error code 74

Stop.
make[1]: stopped in /usr/ports/deskutils/cairo-dock-plugins
*** Error code 1

Stop.
make: stopped in /usr/ports/deskutils/cairo-dock-plugins


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

databases/mongodb40 port proposal

[Andrew Shevchuk]

Latest stable MongoDB (4.0.6) port proposal:
https://raw.githubusercontent.com/ashevchuk/mongodb40-freebsd-port/master/mongodb40.patch
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: category qt?

[andrew clarke]

On Mon 2018-12-24 11:06:56 UTC+0100, Walter Schwarzenfeld 
(w.schwarzenf...@utanet.at) wrote:

> The qt* ports spreads around in the whole portstree.
> 
> It is reasonable to concentrate all these ports in a qt category? I think it
> is easier to find (and also easier to maintain).

Why?

You'd end up with, for eg. VirtualBox at emulators/virtualbox-ose being
moved to qt/virtualbox-ose, and QEMU remain as emulators/qemu, which is a
system that makes no sense to me.

I suspect many other people would object to something like that.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

w3mir & webcopy

[Andrew Johnson]

Hi,
  As there's nothing in the forums could someone please let me know whether 
either of these ports are still working on their system as they are not doing 
so here;
my system: FreeBSD 11.2-STABLE #6: Sun Oct 28 GENERIC amd64

My last ports update/rebuild was 4/Dec/2018 but neither port have been updated 
since then.


% w3mir "https://www.cdc.gov/zika;
Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at 
/usr/local/lib/perl5/site_perl/htmlop.pm line 230.
Compilation failed in require at /usr/local/bin/w3mir line 203.
BEGIN failed--compilation aborted at /usr/local/bin/w3mir line 203.


% webcopy "https://www.cdc.gov/zika;
Use of assignment to $[ is deprecated at /usr/local/bin/webcopy line 46.
dump() better written as CORE::dump(). dump() will no longer be available in 
Perl 5.30 at /usr/local/bin/webcopy line 89.
Can't locate x86/_types.ph in @INC (did you run h2ph?) (@INC contains: 
/usr/local/lib/perl5/site_perl/mach/5.26 /usr/local/lib/perl5/site_perl 
/usr/local/lib/perl5/5.26/mach /usr/local/lib/perl5/5.26)
at /usr/local/lib/perl5/site_perl/mach/5.26/machine/_types.ph line 5.
Compilation failed in require at 
/usr/local/lib/perl5/site_perl/mach/5.26/sys/_types.ph line 8.
Compilation failed in require at 
/usr/local/lib/perl5/site_perl/mach/5.26/sys/socket.ph line 8.
Compilation failed in require at /usr/local/bin/webcopy line 50.


# pkg info | grep perl
p5-ExtUtils-Config-0.008_1 Wrapper for perl configuration
p5-Filter-1.59 Number of source filters for perl5 programs
p5-MIME-Tools-5.509,2  Set of perl5 modules for MIME
p5-Scalar-List-Utils-1.50,1Perl subroutines that would be nice to have in 
the perl core
p5-Test-Simple-1.302141Basic utilities for writing tests in perl
p5-Tk-804.034  Re-port of a perl5 interface to Tk8.4
p5-Tk-TableMatrix-1.23_7   Table/matrix extension to perl/tk for displaying 
table formatted data
perl5-5.26.2_2 Practical Extraction and Report Language
py27-hyperlink-18.0.0  Featureful, correct URL for Python

N.B.: there was a perl5.24-5.24.4_2 still on the system but as nothing needs it 
to run I deinstalled it with no effect on wwebcopy or w3mir


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

Re: Updating poudriere jail

[andrew clarke]

On Fri 2018-12-14 11:13:16 UTC+, Carmel NY (carmel...@outlook.com) wrote:

> ># build Postfix with Cyrus SASL support
> >mail_postfix_SET=SASL
> >
> >Of course, be sure to point your FreeBSD 12.0-REL systems to your new 12.0
> >repo, instead of your old 11.x repo.
> >
> >Regards
> >Andrew
> 
> You know, that there are both a:
> 
> Port:   postfix-current-sasl-3.4.20181202,5
> Path:   /usr/ports/mail/postfix-current-sasl
> Info:   Experimental Postfix version
> 
> and
> 
> Port:   postfix-sasl-3.3.2_1,1
> Path:   /usr/ports/mail/postfix-sasl
> Info:   Postfix with Cyrus SASL support
> 
> Why not just use one of them?

I had no idea until it was mentioned to me off-list earlier.

You learn something new every day :-)

Thanks,

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

Re: Updating poudriere jail

[andrew clarke]

On Thu 2018-12-13 19:43:30 UTC+, Carmel NY (carmel...@outlook.com) wrote:

> I am using FreeBSD 11.2-RELEASE-p6. If I use freebsd-update to install the
> new version 12, what do I have to do to update the poudriere jail? Plus, if I
> do update, will I have to rebuild all of my installed applications?
> 
> Thanks :)

I found it simplest to create a new poudriere jail named 12amd64 to coincide
with my existing 11amd64 jail.

In my case the only port I build that needs non-standard options is
mail/postfix, to enable Cyrus SASL support. Consequently I have this setting
in /usr/local/etc/poudriere.d/make.conf (outside the jail) which from what I
understand applies to both my 11amd64 and 12amd64 (and future) poudriere jails:

# build Postfix with Cyrus SASL support
mail_postfix_SET=SASL

Of course, be sure to point your FreeBSD 12.0-REL systems to your new 12.0 repo,
instead of your old 11.x repo.

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

Re: Correct __cplusplus where std::tr1::function turns into std::function ?

[andrew clarke]

On Wed 2017-11-29 13:32:32 UTC-0800, Yuri (y...@freebsd.org) wrote:

> |This code picks the latter (tr1) version on 11,1-STABLE while the correct
> choice is the former variant. #elif __cplusplus >= 201103L ||
> (defined(_MSC_VER) && _MSC_VER >= 1800) using std::function; #else using
> std::tr1::function; #endif symbols What is the correct __cplusplus then? And
> how to find it for other symbols for future reference? (Googling failed to
> find it.) Thanks! Yuri |

You probably need to enable C++11 support:

clang++ -std=c++11

otherwise clang++ sets __cplusplus to 199711L.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Procmail Vulnerabilities check

[andrew clarke]

On Sat 2017-11-25 22:20:13 UTC-0500, Kevin P. Neal (k...@neutralgood.org) wrote:

> Is that the consensus to replace use of procmail with maildrop?
> 
> A little googling makes it look like maildrop has the easy integration
> with sendmail just like procmail. But is maildrop going to be around for
> the next, oh, 20 years like procmail was?

maildrop began circa 1999 and is part of the Courier Mail Server
software. procmail began circa 1990. Arguably both are due for a
modern replacement, although at least maildrop does not suffer from
vulnerabilities, afaik.

I migrated from procmail to maildrop a few years ago. My only real
gripe with it is that it doesn't create Maildir subdirectories
automatically, so you have to call 'maildirmake' from within each
filter rule (but only if the subdirectory doesn't already exist!)
making each maildroprc filter more complicated than necessary.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Time for a firefox-56 port?

[andrew clarke]

On Fri 2017-11-24 12:11:04 UTC+1100, Greg 'groggy' Lehey (g...@freebsd.org) 
wrote:

> I'm sure I'm not the only person who relies on old addons.  How about
> a firefox-56 port until the current problems die down?

Is using www/firefox-esr an option?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Audacity program appears to be dead

[Andrew Johnson]

Thanks  Kevin, unfortunately I only got around to emailing the
maintainer on Saturday. I would have emailed him a week ago but an
older issue with shotcut & kdenlive already had me trying port updates
(which is when audacity stopped working) and repeatedly checking the
system's sanity and in desperation rebuilding the entire ports tree to
ensure there were no hidden legacy issues.

Thanks Lars, the update for wxgtk30 sounds promising but it'll be
another 24hr before I get the update and can test the downstream apps. 

 :)

On Sun, 2017-06-11 at 09:07 -0700, Kevin Oberman wrote:
> On Sun, Jun 11, 2017 at 12:21 AM, Andrew Johnson
> <dae...@optushome.com.au> wrote:
> > It builds nicely but Audacity has ceased working and produces the
> > following message:
> > % audacity
> > Fatal Error: Mismatch between the program and library build
> > versions
> > detected.
> > The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx
> > containers,compatible with 2.6,compatible with 2.8),
> > and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx
> > containers,compatible with 2.6,compatible with 2.8).
> > Abort (core dumped)
> > 
> > == It is possible that this began with my first update that
> > included an edit in audacity/Makefile that was done back on
> > 1/April.
> I see the same error. I have nor run it is a while, so I have no idea
> when it started.
> 
> Have you notified the maintainer? That and opening a  bug report
> should be your first actions. You can find the maintainer (if any) by
> running "make maintainer" in the port's directory. In this case the
> maintainer is xxjack1...@gmail.com. A bug report can be filed at
> https://bugs.freebsd.org/bugzilla/.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer

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

Audacity program appears to be dead

[Andrew Johnson]

It builds nicely but Audacity has ceased working and produces the
following message:

% audacity
Fatal Error: Mismatch between the program and library build versions
detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx
containers,compatible with 2.6,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx
containers,compatible with 2.6,compatible with 2.8).
Abort (core dumped)


== It is possible that this began with my first update that included an
edit in audacity/Makefile that was done back on 1/April.

There's been a couple more updates in audacity during the past week but
the program continues to die with the same Fatal Error message.

FreeBSD 10.3-STABLE FreeBSD 10.3-STABLE Sun Jun  4 18:11:09 2017
GENERIC  amd64

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

audio/rosegarden

[Andrew Johnson]

Still broken, still unable to build due to file mismatch

===>  Staging for rosegarden-17.04
===>   rosegarden-17.04 depends on executable: dssi_osc_update -
found
===>   rosegarden-17.04 depends on executable: flac - found
===>   rosegarden-17.04 depends on executable: wavpack - found
===>   rosegarden-17.04 depends on executable: xdg-open - found
===>   rosegarden-17.04 depends on executable: lilypond - not found
===>   NOTICE:

The lilypond port currently does not have a maintainer. As a result,
it is
more likely to have unresolved issues, not be up-to-date, or even be
removed in
the future. To volunteer to maintain this port, please create an issue
at:
https://bugs.freebsd.org/bugzilla
More information about port maintainership is available at:
https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html#maintain-port
===>  License GPLv3 accepted by the user
===>   lilypond-2.18.2_5 depends on file: /usr/local/sbin/pkg -
found
===> Fetching all distfiles required by lilypond-2.18.2_5 for building
===>  Extracting for lilypond-2.18.2_5
=> SHA256 Checksum OK for lilypond-2.18.2.tar.gz.
===>  Patching for lilypond-2.18.2_5
===>  Applying FreeBSD patches for lilypond-2.18.2_5
/usr/bin/sed -i.bak -e 's||"/usr/include/FlexLexer.h"|' 
/usr/ports/print/lilypond/work/lilypond-2.18.2/lily/include/includable-lexer.hh
===>   lilypond-2.18.2_5 depends on executable: pdftexi2dvi - not
found
===>  License GPLv3+ accepted by the user
===>   texinfo-6.3_1,1 depends on file: /usr/local/sbin/pkg - found
=> texinfo.tex doesn't seem to exist in
/usr/ports/distfiles/texinfo/6.3.
=> Attempting to fetch ftp://127.0.0.1/distfiles/texinfo.tex
fetch: ftp://127.0.0.1/distfiles/texinfo.tex: Connection refused
=> Attempting to fetch http://ftpmirror.gnu.org/texinfo/texinfo.tex
fetch: http://ftpmirror.gnu.org/texinfo/texinfo.tex: size mismatch:
expected 380556, actual 380853
=> Attempting to fetch http://ftp.gnu.org/gnu/texinfo/texinfo.tex
fetch: http://ftp.gnu.org/gnu/texinfo/texinfo.tex: size mismatch:
expected 380556, actual 380853
=> Attempting to fetch ftp://ftp.gnu.org/gnu/texinfo/texinfo.tex
fetch: ftp://ftp.gnu.org/gnu/texinfo/texinfo.tex: size mismatch:
expected 380556, actual 380853

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

Committing Bug 217108 with maintainer timeout - (net/rtg)

[Andrew]

Hi,

Can someone commit this patch?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217108

Regards,
Andrew Fengler
ScaleEngine Inc.

Email: andrew.feng...@scalengine.com
Phone: (800) 224-0095

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

Change system configuration files with port install

[Andrew Hotlab]

Hi to all, I'm working to build a simple port which, after copying a couple of 
scripts under ${PREFIX}, leaves to the user the task to set a few variables in 
/boot/loader.conf and /etc/rc.conf.


I was wondering if there is a method and (first and foremost) if it's a sane 
idea, to make the port apply changes to these system configuration files.


At this time, I output with pkg-message the instructions to change these files.


Thanks.


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

Re: [SOLVED] How to create a port only for specific FreeBSD releases

[Andrew Hotlab]

> From: Adam Weinberger <ad...@adamw.org>
> Sent: Monday, February 27, 2017 6:05 PM
> To: Andrew Hotlab
> Cc: Ernie Luzar; freebsd-ports@freebsd.org
> Subject: Re: [SOLVED] How to create a port only for specific FreeBSD releases
> 
>> On 27 Feb, 2017, at 10:00, Andrew Hotlab <andrew.hot...@hotmail.com> wrote:
>> 
>>> From: Ernie Luzar <luzar...@gmail.com>
>>> Sent: Monday, February 27, 2017 5:43 PM
>>> To: Adam Weinberger
>>> Cc: Andrew Hotlab; freebsd-ports@freebsd.org
>>> Subject: Re: [SOLVED] How to create a port only for specific FreeBSD 
>>> releases
>>> 
>>>>>> Since these scripts are designed to run on FreeBSD 10.0 and newer, I'd 
>>>>>> like to
>>>>>> know if there is a way to prevent the port from installing on older 
>>>>>> FreeBSD
>>>>>> releases. In the Porter's Handbook I found this paragraph, but it seems 
>>>>>> regarding
>>>>>> only ported app's source  code:
>>>>>>  
>>>>>> https://www.freebsd.org/doc/en/books/porters-handbook/porting-versions.html
>>>>> 
>>>>> Sorry, just found by myself. I included these lines before the do-install 
>>>>> section:
>>>>> 
>>>>> .include 
>>>>> .if ${OSVERSION} < 1000100
>>>>> IGNORE= runs only on FreeBSD 10.0 and newer
>>>>> .endif
>>>> 
>>>> It's really not needed at all. Nothing below 10.3 is supported, and the 
>>>> ports system will
>>>> complain already. Please don't include that block in your port.
>>>> 
>>>> # Adam
>>>> 
>>>> 
>>> Thats not true. I have port version just for 9.x and even today I still 
>>> see the source file the port fetches still being downloaded.
>>> 
>>> It has
>>> IGNORE_FreeBSD_10= and IGNORE_FreeBSD_11= in it's Makefile.
>>> Best you have IGNORE_FreeBSD_9=  in your Makefile to be sure you get 
>>> what you want.
>> 
>> Actually, it seems that Matthew and Adam are right, but I'm not able to 
>> understand if
>> it's a warn or a block action:
>> https://svnweb.freebsd.org/ports?view=revision=431746
> 
> It's a block, but it's overridable.
> 

Ok, I guess the better way is to let bsd.port.mk do the job for me! :)

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

Re: [SOLVED] How to create a port only for specific FreeBSD releases

[Andrew Hotlab]

> From: Ernie Luzar <luzar...@gmail.com>
> Sent: Monday, February 27, 2017 5:43 PM
> To: Adam Weinberger
> Cc: Andrew Hotlab; freebsd-ports@freebsd.org
> Subject: Re: [SOLVED] How to create a port only for specific FreeBSD releases
> 
>>>> Since these scripts are designed to run on FreeBSD 10.0 and newer, I'd 
>>>> like to
>>>> know if there is a way to prevent the port from installing on older FreeBSD
>>>> releases. In the Porter's Handbook I found this paragraph, but it seems 
>>>> regarding
>>>> only ported app's source  code:
>>>>  
>>>> https://www.freebsd.org/doc/en/books/porters-handbook/porting-versions.html
>>>
>>> Sorry, just found by myself. I included these lines before the do-install 
>>> section:
>>>
>>> .include 
>>> .if ${OSVERSION} < 1000100
>>> IGNORE= runs only on FreeBSD 10.0 and newer
>>> .endif
>> 
>> It's really not needed at all. Nothing below 10.3 is supported, and the 
>> ports system will
>> complain already. Please don't include that block in your port.
>> 
>> # Adam
>> 
>> 
> Thats not true. I have port version just for 9.x and even today I still 
> see the source file the port fetches still being downloaded.
> 
> It has
> IGNORE_FreeBSD_10= and IGNORE_FreeBSD_11= in it's Makefile.
> Best you have IGNORE_FreeBSD_9=  in your Makefile to be sure you get 
> what you want.

Actually, it seems that Matthew and Adam are right, but I'm not able to 
understand if
it's a warn or a block action:
https://svnweb.freebsd.org/ports?view=revision=431746
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [SOLVED] How to create a port only for specific FreeBSD releases

[Andrew Hotlab]

> From: Adam Weinberger <ad...@adamw.org>
> 
> Sent: Monday, February 27, 2017 5:30 PM
> To: Andrew Hotlab
> Cc: freebsd-ports@freebsd.org
> Subject: Re: [SOLVED] How to create a port only for specific FreeBSD releases
>     
>> On 27 Feb, 2017, at 9:07, Andrew Hotlab <andrew.hot...@hotmail.com> wrote:
>> 
>>> From: Andrew Hotlab <andrew.hot...@hotmail.com>
>>> Sent: Monday, February 27, 2017 3:37 PM
>>> To: freebsd-ports@freebsd.org
>>> Subject: How to create a port only for specific FreeBSD releases
>>>  
>>> Hi to all, I'm trying to make a port which installs only a couple of simple 
>>> scripts
>>> (thus NO_BUILD, NO_ARCH, and void MASTER_SITES and DISTFILES...).
>>> 
>>> Since these scripts are designed to run on FreeBSD 10.0 and newer, I'd like 
>>> to
>>> know if there is a way to prevent the port from installing on older FreeBSD
>>> releases. In the Porter's Handbook I found this paragraph, but it seems 
>>> regarding
>>> only ported app's source  code:
>>>  https://www.freebsd.org/doc/en/books/porters-handbook/porting-versions.html
>> 
>> 
>> Sorry, just found by myself. I included these lines before the do-install 
>> section:
>> 
>> .include 
>> .if ${OSVERSION} < 1000100
>> IGNORE= runs only on FreeBSD 10.0 and newer
>> .endif
> 
> It's really not needed at all. Nothing below 10.3 is supported, and the ports 
> system
> will complain already. Please don't include that block in your port.
> 
> # Adam

Thank you Adam, I wrote my previous post before reading Matthew's reply.

I removed that check from my port.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

[SOLVED] How to create a port only for specific FreeBSD releases

[Andrew Hotlab]

> From: Andrew Hotlab <andrew.hot...@hotmail.com>
> Sent: Monday, February 27, 2017 3:37 PM
> To: freebsd-ports@freebsd.org
> Subject: How to create a port only for specific FreeBSD releases
    
> Hi to all, I'm trying to make a port which installs only a couple of simple 
> scripts
> (thus NO_BUILD, NO_ARCH, and void MASTER_SITES and DISTFILES...).
> 
> Since these scripts are designed to run on FreeBSD 10.0 and newer, I'd like to
> know if there is a way to prevent the port from installing on older FreeBSD
> releases. In the Porter's Handbook I found this paragraph, but it seems 
> regarding
> only ported app's source  code:
> https://www.freebsd.org/doc/en/books/porters-handbook/porting-versions.html


Sorry, just found by myself. I included these lines before the do-install 
section:

.include 
.if ${OSVERSION} < 1000100
IGNORE= runs only on FreeBSD 10.0 and newer
.endif
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

How to create a port only for specific FreeBSD releases

[Andrew Hotlab]

Hi to all, I'm trying to make a port which installs only a couple of simple 
scripts (thus NO_BUILD, NO_ARCH, and void MASTER_SITES and DISTFILES...).

Since these scripts are designed to run on FreeBSD 10.0 and newer, I'd like to 
know if there is a way to prevent the port from installing on older FreeBSD 
releases. In the Porter's Handbook I found this paragraph, but it seems 
regarding only ported app's source code:
https://www.freebsd.org/doc/en/books/porters-handbook/porting-versions.html

TIA

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

[Patch] net/rtg - maintainer timeout (bug 213293)

[Andrew]

Hi all,


I have a patch for net/rtg languishing in bugzilla -
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213293

Could someone get this committed with maintainer timeout?


Thanks,

Andrew Fengler
ScaleEngine Inc.

Email: andrew.feng...@scalengine.com
Phone: (800) 224-0095

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

pkg updating crash in pkg-1.8.0

[andrew clarke]

Hi,

The command "pkg updating" crashes since pkg-1.8.0.

Out of curiosity I rebuilt it from source, then single-stepped
pkg-static using gdb:

$ uname -a
FreeBSD blizzard.phoenix 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264:
Fri Mar 25 02:10:02 UTC 2016
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

$ gdb --args pkg-static updating
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) break main
Breakpoint 1 at 0x40980e: file main.c, line 570.
(gdb) r
Starting program: /usr/home/ozzmosis/src/pkg/pkg-1.8.0/src/pkg-static updating

Breakpoint 1, main (argc=2, argv=0x7fffe4c8) at main.c:570
570 int64_t   debug = 0;
Current language:  auto; currently minimal
(gdb) n
584 struct option longopts[] = {
(gdb)
602 setvbuf(stdout, NULL, _IONBF, 0);
(gdb)
605 signal(SIGPIPE, SIG_IGN);
(gdb)
607 if (argc < 2)
(gdb)
616 if (setenv("POSIXLY_CORRECT", "1",  1) == -1)
(gdb)
626 while ((ch = getopt_long(argc, argv, 
"+d"JAIL_OPT"c:C:R:r:lNvo:46", longopts, NULL)) != -1) {
(gdb)
671 argv += optind;
(gdb)
673 pkg_set_debug_level(debug);
(gdb)
675 if (version == 1)
(gdb)
678 if (show_commands && version == 0) {
(gdb)
686 umask(022);
(gdb)
687 pkg_event_register(_callback, );
(gdb)
690 optreset = 1;
(gdb)
691 optind = 1;
(gdb)
693 if (debug == 0 && version == 0)
(gdb)
462 child_pid = fork();
(gdb)
464 if (child_pid == 0) {
(gdb)
473 while (waitpid(child_pid, , 0) == -1) {
(gdb)
478 ret = WEXITSTATUS(status);
(gdb)
480 if (WIFEXITED(status) && ret != EX_NEEDRESTART)
(gdb)
482 if (WIFSIGNALED(status)) {
(gdb) 
484 fprintf(stderr, "Child process pid=%d 
terminated abnormally: %s\n",
(gdb) 
485 (int)child_pid, 
strsignal (WTERMSIG(status)));
(gdb) 
484 fprintf(stderr, "Child process pid=%d 
terminated abnormally: %s\n",
(gdb) 
Child process pid=33151 terminated abnormally: Trace/BPT trap
486 ret = 128 + WTERMSIG(status);
(gdb) 
492 exit(ret);
(gdb) 
Program exited with code 0205.
(gdb) 

I'm not really sure what's going on here but it might be obvious to
the devs.

Thanks,

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

openblas 0.2.15,1 port broke build for BARCELONA AMD core

[Andrew Reilly]

Hi there,

My portmsaster run just broke on the recent openblas upgrade, with version 
stamp in head/math/openblas/Makefile 409114 26-02-18 16:35:48Z rakuco.  Now 
that I’ve hacked on this to make it build, I remember having done something 
like this the last time, so perhaps nothing has actually changed in this 
respect, there’s just been a version increase that still doesn’t know about my 
CPU.

My build/target machine is, according to sysctl:
hw.machine: amd64
hw.model: AMD A6-3500 APU with Radeon(tm) HD Graphics
hw.ncpu: 3

The auto-config system for openblas has determined that this is (in config.h):
#define AMD_UNKNOWN
but also
#define CORE_BARCELONA
#define CHAR_CORENAME “BARCELONA”

So on the assumption that the AMD_UNKNOWN should be BARCELONA, I have tweaked 
cpuid_x86.c to add case   3 along with case 1 and case 10 in the 
switch(exfamily) to return CPUTYPE_BARCELONA.

I’m not sure if it wouldn’t have been better to slide that in with case 6, 
because model=1 and support_avx()->0, so that would have worked too.

the full set of get_cputype() values for my machine are:
family=0xf, exfamily=0x3, model=0x1, exmodel=0x0, support_avx=0

The code in cpuid_x86.c thinks that NUM_CORES is 1, despite the sysctl 
information above, so I guess that only one core is going to be used, but since 
this is not a high performance machine and is generally thermally challenged, 
I’m not too concerned about that.  Just want it to build at all.

With this couple of tweaks the math/openblas port seems to have built OK, so I 
hope that this change can be included in the port or the up-stream so that I 
don’t have to remember to do this all again next time!

Cheers,

— 
Andrew

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

Re: freebsd-ports Digest, Vol 661, Issue 2

[Andrew Harris]

On Tue, Jan 19, 2016 at 7:00 AM,  wrote:

> Send freebsd-ports mailing list submissions to
> freebsd-ports@freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> or, via email, send a message with subject or body 'help' to
> freebsd-ports-requ...@freebsd.org
>
> You can reach the person managing the list at
> freebsd-ports-ow...@freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-ports digest..."
>
>
> Today's Topics:
>
>1. Re: error upgrading graphics/dri port
>   "/usr/local/llvm36/bin/clang: not found" (Brooks Davis)
>2. Re: error upgrading graphics/dri port
>   "/usr/local/llvm36/bin/clang: not found" (Graham Menhennitt)
>3. Fw: Unexpected dependencies of graphics/libGL
>   (Lu?s Fernando Schultz Xavier da Silveira)
>4. Re: Unexpected dependencies of graphics/libGL (Manfred Antar)
>5. FreeBSD ports you maintain which are out of date
>   (portsc...@freebsd.org)
>
>
> --
>
> Message: 1
> Date: Mon, 18 Jan 2016 19:31:46 +
> From: Brooks Davis 
> To: Graham Menhennitt 
> Cc: freebsd-ports@freebsd.org
> Subject: Re: error upgrading graphics/dri port
> "/usr/local/llvm36/bin/clang: not found"
> Message-ID: <20160118193145.ga38...@spindle.one-eyed-alien.net>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sun, Jan 17, 2016 at 07:08:14PM +1100, Graham Menhennitt wrote:
> > Does anybody have any clues, please?
> >
> > Thanks,
> > Graham
> >
> > root@starker# uname -a
> > FreeBSD starker 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r294103: Sun Jan
> > 17 13:26:05 AEDT 2016
> > gfm@starker:/usr/obj/usr/data/FreeBSD/src_11-Current/sys/starker  amd64
> > root@starker# ll /usr/local/llvm36/bin
> > total 22384
> > -rwxr-xr-x  1 root  wheel277720 Jan  6 19:54 bugpoint
> > -rwxr-xr-x  1 root  wheel  18292472 Sep 25 07:49 clang-cpp
> > -rwxr-xr-x  1 root  wheel  7288 Jan  6 19:53 count
> > -r-xr-xr-x  2 root  wheel220280 Jan  6 19:54 FileCheck
> > -r-xr-xr-x  4 root  wheel82 Jan  6 19:54 lit
> > -rwxr-xr-x  1 root  wheel117368 Jan  6 19:54 llc
> > -rwxr-xr-x  1 root  wheel 96128 Jan  6 19:54 lli
> > -rwxr-xr-x  1 root  wheel 14648 Jan  6 19:54 lli-child-target
> > -rwxr-xr-x  1 root  wheel 58200 Jan  6 19:54 llvm-ar
> > -rwxr-xr-x  1 root  wheel 16960 Jan  6 19:54 llvm-as
> > -rwxr-xr-x  1 root  wheel 46088 Jan  6 19:54 llvm-bcanalyzer
> > -rwxr-xr-x  1 root  wheel 91416 Jan  6 19:54 llvm-config
> > -rwxr-xr-x  1 root  wheel 92552 Jan  6 19:54 llvm-cov
> > -rwxr-xr-x  1 root  wheel 49200 Jan  6 19:54 llvm-diff
> > -rwxr-xr-x  1 root  wheel 20432 Jan  6 19:54 llvm-dis
> > -rwxr-xr-x  1 root  wheel 32992 Jan  6 19:54 llvm-dsymutil
> > -rwxr-xr-x  1 root  wheel 24888 Jan  6 19:54 llvm-dwarfdump
> > -rwxr-xr-x  1 root  wheel 33008 Jan  6 19:54 llvm-extract
> > -rwxr-xr-x  1 root  wheel 24904 Jan  6 19:54 llvm-link
> > -r-xr-xr-x  4 root  wheel82 Jan  6 19:54 llvm-lit
> > -rwxr-xr-x  1 root  wheel 74560 Jan  6 19:54 llvm-mc
> > -rwxr-xr-x  1 root  wheel 18072 Jan  6 19:54 llvm-mcmarkup
> > -rwxr-xr-x  1 root  wheel 79432 Jan  6 19:54 llvm-nm
> > -rwxr-xr-x  1 root  wheel244848 Jan  6 19:54 llvm-objdump
> > -rwxr-xr-x  1 root  wheel 46400 Jan  6 19:54 llvm-profdata
> > lrwxr-xr-x  1 root  wheel 7 Jan  6 19:54 llvm-ranlib -> llvm-ar
> > -rwxr-xr-x  1 root  wheel314824 Jan  6 19:54 llvm-readobj
> > -rwxr-xr-x  1 root  wheel 52520 Jan  6 19:54 llvm-rtdyld
> > -rwxr-xr-x  1 root  wheel 64744 Jan  6 19:54 llvm-size
> > -rwxr-xr-x  1 root  wheel 64640 Jan  6 19:54 llvm-stress
> > -rwxr-xr-x  1 root  wheel 64736 Jan  6 19:54 llvm-symbolizer
> > -rwxr-xr-x  1 root  wheel   1622424 Jan  6 19:53 llvm-tblgen
> > -rwxr-xr-x  1 root  wheel 39064 Jan  6 19:54 llvm-vtabledump
> > -rwxr-xr-x  1 root  wheel 36944 Jan  6 19:54 macho-dump
> > -rwxr-xr-x  1 root  wheel 41112 Jan  6 19:53 not
> > -rwxr-xr-x  1 root  wheel 47168 Jan  6 19:54 obj2yaml
> > -rwxr-xr-x  1 root  wheel302320 Jan  6 19:54 opt
> > -rwxr-xr-x  1 root  wheel 34264 Jan  6 19:54 verify-uselistorder
> > -rwxr-xr-x  1 root  wheel 66032 Jan  6 19:54 yaml2obj
> > root@starker# pkg info|grep llvm
> > llvm36-3.6.2_2 Low Level Virtual Machine
> > root@starker# portupgrade -aWw
> > [Reading data from pkg(8) ... - 854 packages found - done]
> > --->  Upgrading 'dri-11.0.7_1,2' to 'dri-11.0.8,2' (graphics/dri)
> > --->  Building '/usr/ports/graphics/dri'
> > ===>   dri-11.0.8,2 depends on executable: makedepend - found
> > ===>   dri-11.0.8,2 depends on package: libclc>=0.0.r222830 - not found
> > ===>  Building for libclc-0.1.0.20150710
> > 

FreeBSD Port: py27-vatnumber-1.2

[Andrew Hotlab]

Hi, and thank you for maintaining this port. I've just updated it on a bunch of 
machines running Odoo (formerly OpenERP), and the service hang on start with 
the following error:

pkg_resources.DistributionNotFound: The 'python-stdnum' distribution was not 
found and is required by vatnumber

Thus I guess this latest version of Python's vatnumber needs the stdnum 
extension, which I found no presence for in the Ports tree.

Since I'm not able to create a port, I wonder if you'd like to create a new 
py-stdnum port. Please let me know if you eventually need any contribution for 
that.

Thank you in advance.

Sincerely.

Andrew

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

RE: FreeBSD Port: py27-vatnumber-1.2

[Andrew Hotlab]

Wonderful, the new port installs and runs correctly: Odoo is working again! :)

Now it only needs to change the finance/py-vatnumber port to depend from this 
new one.

Thank you so much for the light-speed solution, Kurt!

Best regards

Andrew


 Date: Sun, 26 Jul 2015 20:07:17 +0200
 From: li...@opsec.eu
 To: andrew.hot...@hotmail.com
 CC: chian@gmail.com; po...@freebsd.org
 Subject: Re: FreeBSD Port: py27-vatnumber-1.2

 Hi!

 Thus I guess this latest version of Python's vatnumber needs the
 stdnum extension, which I found no presence for in the Ports tree.

 Since I'm not able to create a port, I wonder if you'd like to
 create a new py-stdnum port. Please let me know if you eventually
 need any contribution for that.

 There's a port now in the ports tree:

 https://lists.freebsd.org/pipermail/svn-ports-all/2015-July/100364.html

 Can you test whether it works as required ?

 --
 p...@opsec.eu +49 171 3101372 5 years to 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

RE: FreeBSD Port: py27-vatnumber-1.2

[Andrew Hotlab]

 Date: Sun, 26 Jul 2015 20:34:30 +0200
 From: li...@opsec.eu
 To: andrew.hot...@hotmail.com
 CC: chian@gmail.com; po...@freebsd.org
 Subject: Re: FreeBSD Port: py27-vatnumber-1.2

 Hi!

 Wonderful, the new port installs and runs correctly: Odoo is working again! 
 :)

 Nice 8-)

 Now it only needs to change the finance/py-vatnumber port to
 depend from this new one.

 Can you open a problem report on https://bugs.freebsd.org/ about
 it, so that this does not get lost ?

Just done: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201897

Thank you 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

Re: damage to pkg's sqlite data base

[andrew clarke]

On Wed 2015-05-13 19:00:27 UTC+1000, Peter Jeremy (pe...@rulingia.com) wrote:

 On 2015-May-13 18:12:44 +1000, andrew clarke m...@ozzmosis.com wrote:
 You can reinstall just those ports. Check /var/log/messages, eg.
 
 $ grep pkg /var/log/messages
 May 12 14:34:38 blizzard pkg: poudriere upgraded: 3.1.4 - 3.1.6 
 May 12 14:38:08 blizzard pkg: git-lite-2.4.0 installed
 May 13 08:29:04 blizzard pkg: sqlite3 upgraded: 3.8.9_1 - 3.8.10.1 
 May 13 08:29:05 blizzard pkg: spamassassin reinstalled: 3.4.1_1 - 3.4.1_1 
 May 13 08:29:05 blizzard pkg: ca_root_nss upgraded: 3.18.1 - 3.19 
 
 That assumes you have syslog messages back to when you started using pkg.
 syslog was never intended to provide an audit trail.

True. I'd been wondering about why the pkg developers didn't add
logging functionality, but it looks like I just needed to add this to
/etc/syslog.conf:

!pkg
*.* /var/log/pkg.log

then run:

sudo touch /var/log/pkg.log
sudo service restart syslogd

I think that's correct. I'm not sure the syslog.conf entry above will
include pkg-static - maybe it should be !pkg* instead? I must admit
I find the syslog.conf man page to be not very helpful.

$ cat /var/log/pkg.log 
May 13 20:58:25 blizzard pkg: jive-1.1 deinstalled
May 13 20:58:29 blizzard pkg: jive-1.1 installed

I tend to think pkg.log creation  use should be a normal thing for a
new FreeBSD install.

 The trick is to revert to a known-good backup of the pkg database
 that's generated daily by /usr/local/etc/periodic/daily/411.pkg-backup
 in /var/backups/ :
 
 -rw-r--r--  1 root  wheel   2207320 2015-05-13 04:20:30 pkg.sql.xz
 -rw-r--r--  1 root  wheel   2196088 2015-05-12 04:21:24 pkg.sql.xz.2
 
 Assuming that they aren't corrupt.  But that's better than nothing.  Note
 that the backup is taken every day, whether or not there has been any
 change to the pkg database, so you have 2 days of backups, not the last
 two revisions.

Yes, that's a deficiency in the periodic script. Probably not
difficult to improve either, with the correct use of /usr/bin/diff.

 On 2015-May-13 18:17:12 +1000, andrew clarke m...@ozzmosis.com wrote:
 Actually I was wrong about this. The pkg command has the sqlite3
 interpreter built-in, accessed via pkg shell, that opens local.sqlite
 by default:
 
 Some experimenting suggests that none of the pragma commands work in
 pkg shell, so you probably will need to find a copy of sqlite3.

Oh dear, that's unfortunate.

Regards
Andrew
___
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: damage to pkg's sqlite data base

[andrew clarke]

On Tue 2015-05-12 01:17:46 UTC-0500, Scott Bennett (benn...@sdf.org) wrote:

  For nearly two weeks I've been stymied by an apparently damaged record
 in the sqlite data base used by pkg(8) and pkg-static(8).  Unfortunately,
 it is a record for a port that is depended upon rather heavily, lang/gcc.
 lang/gcc compiled and linked just fine, but any attempt to install the result
 ends up like this.
 
 ===  Checking if gcc already installed
 ===   Registering installation for gcc-4.8.4_3
 Installing gcc-4.8.4_3...
 pkg-static: sqlite error while executing iterator in file 
 pkgdb_iterator.c:931: database disk image is malformed
 pkg-static: sqlite error while executing INSERT OR REPLACE INTO files (path, 
 sha256, package_id) VALUES (?1, ?2, ?3) in file pkgdb.c:1722: database disk 
 image is malformed
 *** Error code 70
 
 Stop.
 make: stopped in /usr/ports/lang/gcc

database disk image is malformed is an error from SQLite, the
underlying database library that pkg uses, not pkg itself.

If you can confidently rule-out hardware or filesystem error then
presumably there is a glitch in SQLite that causes it to corrupt the
database it's writing to. It shouldn't happen, and is evidently very
rare judging from the lack of FreeBSD PRs about it.

SQLite is quite popular and is used by Mozilla Firefox  Google Chrome
internally.

It's possible pkg did something to trigger a bug in SQLite, so it may
be worthwhile uploading your local.sqlite to a web site somewhere for
one of the pkg developers to investigate, and file a PR with a link to
the file.

A bit of Googling indicates a fix may be possible, along the lines of:

$ sqlite3 /var/db/pkg/local.sqlite
SQLite version 3.8.10.1 2015-05-09 12:14:55
Enter .help for usage hints.
sqlite pragma integrity_check;
ok

[sqlite may give an error here, but you can hopefully keep going...]

sqlite .mode insert
sqlite .output local.sqlite.dump
sqlite .dump
sqlite .quit

$ ls -l local.sqlite.dump 
-rw-r--r--  1 ozzmosis  ozzmosis  10113463 2015-05-13 17:24:46 local.sqlite.dump

Note that the database dump is simply a text file:

$ file local.sqlite.dump
local.sqlite.dump: ASCII text

We can then recreate the database from the dump we just made:

$ sqlite3 local.sqlite.new
SQLite version 3.8.10.1 2015-05-09 12:14:55
Enter .help for usage hints.
sqlite .read local.sqlite.dump 
sqlite .quit

Now we can use our newly created database, which should be error-free:

$ sudo cp /var/db/pkg/local.sqlite /var/db/pkg/local.sqlite.backup
$ sudo mv local.sqlite.new /var/db/pkg/local.sqlite

I don't guarantee any of the above will work. It will depend on how
much the database is corrupted etc.

You will also need databases/sqlite3 installed, which unfortunately
isn't provided in the FreeBSD base system. This could be a problem if
pkg refuses to install anything. In that case I would either run the
above sqlite3 commands on another machine (or a jail?) and sort it out
there, or run the sqlite3 binary from the
/usr/ports/databasess/sqlite3 directory without installing it, or if
that's not possible, make a backup of local.sqlite, delete
local.sqlite, install sqlite3 from ports (or pkg install), then work
on fixing the corrupt database.

Obviously another option is to simply declare pkg bankruptcy. Get a
list of all your installed packages (with pkg info -ao  pkglist.txt),
delete the corrupt local.sqlite then reinstall your packages.

Regards
Andrew
___
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: damage to pkg's sqlite data base

[andrew clarke]

On Wed 2015-05-13 00:12:51 UTC-0500, Scott Bennett (benn...@sdf.org) wrote:

  Simply rename your (now) corrupt db, and copy the backup over.
 
  However, if I do that, then what happens to all the ports that have
 been updated or added since that version of the data base was backed up?
 I have run portmaster -a (with some additional options) quite a few
 times since the lang/gcc problem first appeared, so an old local.sqlite
 will no longer accurately reflect what is currently installed.

You can reinstall just those ports. Check /var/log/messages, eg.

$ grep pkg /var/log/messages
May 12 14:34:38 blizzard pkg: poudriere upgraded: 3.1.4 - 3.1.6 
May 12 14:38:08 blizzard pkg: git-lite-2.4.0 installed
May 13 08:29:04 blizzard pkg: sqlite3 upgraded: 3.8.9_1 - 3.8.10.1 
May 13 08:29:05 blizzard pkg: spamassassin reinstalled: 3.4.1_1 - 3.4.1_1 
May 13 08:29:05 blizzard pkg: ca_root_nss upgraded: 3.18.1 - 3.19 


   4) I was unable to find any instructions for recreating a pkg data
   base if the data base gets damaged/destroyed.  Is there a way to
   do that that I missed?
 
  There must be a way to do this, right?  I mean, really, it's pretty
 fundamental that no new data base be put into production without a way to
 rebuild it.  The FreeBSD developers haven't really broken so ancient and
 basic a principle, have they?  So what's the trick?  What is the method
 to rebuild /var/db/pkg/local.sqlite from scratch based upon the currently
 installed ports/packages?

You can't rebuild it. You couldn't rebuild it in the years before
pkgng existed, either.

The trick is to revert to a known-good backup of the pkg database
that's generated daily by /usr/local/etc/periodic/daily/411.pkg-backup
in /var/backups/ :

-rw-r--r--  1 root  wheel   2207320 2015-05-13 04:20:30 pkg.sql.xz
-rw-r--r--  1 root  wheel   2196088 2015-05-12 04:21:24 pkg.sql.xz.2

The .sql.xz files are just a SQLite dump, in xz compressed format.

Regards
Andrew
___
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: damage to pkg's sqlite data base

[andrew clarke]

On Wed 2015-05-13 17:55:26 UTC+1000, andrew clarke (m...@ozzmosis.com) wrote:

 $ sqlite3 local.sqlite.new
 SQLite version 3.8.10.1 2015-05-09 12:14:55
 Enter .help for usage hints.
 sqlite .read local.sqlite.dump 
 sqlite .quit
 
 Now we can use our newly created database, which should be error-free:
 
 $ sudo cp /var/db/pkg/local.sqlite /var/db/pkg/local.sqlite.backup
 $ sudo mv local.sqlite.new /var/db/pkg/local.sqlite
 
 I don't guarantee any of the above will work. It will depend on how
 much the database is corrupted etc.
 
 You will also need databases/sqlite3 installed, which unfortunately
 isn't provided in the FreeBSD base system. This could be a problem if
 pkg refuses to install anything. In that case I would either run the

Actually I was wrong about this. The pkg command has the sqlite3
interpreter built-in, accessed via pkg shell, that opens local.sqlite
by default:

$ pkg shell
SQLite version 3.8.8.2 2015-01-30 14:30:45
Enter .help for usage hints.
sqlite .quit  

So there is no real need to install databases/sqlite3.

Regards
Andrew
___
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: damage to pkg's sqlite data base

[andrew clarke]

On Tue 2015-05-12 23:47:02 UTC-0700, Chris H (bsd-li...@bsdforge.com) wrote:

 I whined about it the first time my DB blew up. It's become
 corrupted several times since on different boxes/versions. *but*
 after the first time, I made it a habit of making a copy of it *before*
 embarking on an upgrade, or install of any ports.

Can you post a link to your message and/or a link to your FreeBSD PR on 
Bugzilla?

I use FreeBSD on a number of machines (bare metal  virtual) and have
never encountered local.sqlite corruption, and maybe I haven't been
paying attention but I haven't noticed anyone else mention it on the
list until now.

As I said to the OP, if you encounter this problem and you're sure
it's not caused externally (hardware or filesystem corruption) then
it's probably worthwhile making your corrupted local.sqlite available
somewhere for it to be looked at by someone who understands SQLite.

Regards
Andrew
___
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: Shared object libiconv.so.2 not found

[andrew clarke]

On Fri 2014-12-12 09:44:10 UTC+0100, Joel Dahl (j...@vnode.se) wrote:

 I installed 10.1 on a new box. Rebooted. Did a ”pkg install tmux zsh
 open-vm-tools-nox11”. Added the vmware_guestd options to rc.conf.
 Rebooted again.
 
 Now I see the following during boot:
 
 /dev/da0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS
 /dev/da0p2: clean, 3260251 free (771 frags, 407435 blocks, 0.0% fragmentation)
 Mounting local file systems:.
 Shared object libiconv.so.2 not found, required by libglib-2.0.so.0
 Shared object libiconv.so.2 not found, required by libglib-2.0.so.0
 Shared object libiconv.so.2 not found, required by libglib-2.0.so.0
 Shared object libiconv.so.2 not found, required by libglib-2.0.so.0
 Writing entropy file:.
 
 Eh? What is this?

Do you have libiconv installed?

$ pkg which /usr/local//lib/libiconv.so.2
/usr/local/lib/libiconv.so.2 was installed by package libiconv-1.14_6

$ ls -l /usr/local//lib/libiconv*
-rw-r--r--  1 root  wheel  1107752 2014-12-05 18:43:00 
/usr/local//lib/libiconv.a
lrwxr-xr-x  1 root  wheel   17 2014-12-05 18:43:00 
/usr/local//lib/libiconv.so - libiconv.so.2.5.1
lrwxr-xr-x  1 root  wheel   17 2014-12-05 18:43:00 
/usr/local//lib/libiconv.so.2 - libiconv.so.2.5.1
-rw-r--r--  1 root  wheel  1072522 2014-12-05 18:43:00 
/usr/local//lib/libiconv.so.2.5.1
lrwxr-xr-x  1 root  wheel   13 2014-12-05 18:43:00 
/usr/local//lib/libiconv.so.3 - libiconv.so.2

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

Re: FreeBSD Port: exif-0.6.21

[andrew clarke]

On Fri 2014-12-12 15:51:25 UTC+, James McGuire 
(james.a.mcguir...@virgin.net) wrote:

 Hi there,
 
 I recently used your port to attempt to clear the exif tags from a set 
 of jpeg files I had taken while on holiday.
 
 The port failed to clear the model of camera used, the latitude and 
 longitude when used in the following manner 'exif --remove *' and 
 complains that my camera a Nikon Coolpix S9700 has 'corrupt data' 
 apparently an unrecognised EXIF field:

As a workaround you might want to try the graphics/jhead port.

 -deDelete the Exif header entirely.  Leaves other metadata sections
intact.

See the jhead man page for other options.

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

Re: port www/elog

[andrew clarke]

On Wed 2014-12-10 03:18:39 UTC-0800, Thomas Mueller (mueller6...@bellsouth.net) 
wrote:

  I am using this software with outdated version of FreeBSD. As I can see,
  this port is DEPRECATED and no longer available.
 
  Can any step up to maintain it? Please!
 
 -Chen
 
 I just looked found www/elog was not in the ports tree.
 
 I am not familiar with elog and wouldn't know where to find it.

Evidently elog was removed from the ports tree in September:

Remove non staged ports without pending PR from www

http://www.freshports.org/www/elog

I suspect a FreeBSD 9.3 ISO from July 2014 should have a Ports tarball
with the necessary www/elog files which you can then use as a basis to
have it re-added to Ports by a maintainer.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: port www/elog

[andrew clarke]

On Wed 2014-12-10 14:44:38 UTC+0100, Torsten Zuehlsdorff 
(mailingli...@toco-domains.de) wrote:

  I am not familiar with elog and wouldn't know where to find it.
 
 have a look at the old files in SVN:
 http://svnweb.freebsd.org/ports/head/www/elog/?pathrev=360228

I was under the wrong impression that deleted files disappeared from
the SVN history.

Disregard my previous reply about hunting down a FreeBSD 9.3, then.
Obviously not necessary.
___
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

poudriere ports -u, divide by zero

[andrew clarke]

I'm assuming this is just a superficial bug in the output.

Possibly related: I have pkg-1.4.0 installed.

# poudriere ports -u
[00:00:00]  Updating portstree default
Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found.
Fetching snapshot tag from ec2-ap-southeast-2.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Wed Dec 10 09:57:21 AEDT 2014 to Wed Dec 10 11:26:11 AEDT 2014.
Fetching 3 metadata patches.. done.
Applying metadata patches... done.
Fetching 0 metadata files... done.
Fetching 0 patches.
dc: divide by zero
dc: divide by zero
(0/0) 0.00%  done.
done.
Applying patches...
done.
Fetching 0 new ports or files... done.
Ports tree is already up to date.
___
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: virtualbox issue

[andrew clarke]

On Tue 2014-11-25 09:34:17 UTC-0500, R. Scott Evans 
(freebsd-emulat...@rsle.net) wrote:

 I sucessfully updated virtualbox on my 9.3-RELEASE (amd64) hosts today 
 without incident but trying to update an existing virtualbox-ose-4.3.18 
 port to 4.3.20 on a 10.1-RELEASE (amd64) box and I get a fail message 
 that I don't have 32 bit libraries.  Worked without them before but 
 okay, I try and install the 32 bit libraries:
 
 cd /usr/src; make build32 install32
 
 and I now choke on libmagic...
 
 ...
 cd /usr/src/lib/libmagic;  WORLDTMP=/usr/obj/usr/src/tmp  MAKEFLAGS=-m 
 /usr/src/tools/build/mk  -m /usr/src/share/mk 
 MAKEOBJDIRPREFIX=/usr/obj/lib32 make SSP_CFLAGS= DESTDIR= 
 DIRPRFX=lib/libmagic/ -DNO_LINT -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF 
 -DEARLY_BUILD build-tools
 cc -O2 -pipe  -DMAGIC='/usr/share/misc/magic' -DHAVE_CONFIG_H 
 -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file/src 
 -std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include -DCOMPILE_ONLY 
 -L/usr/obj/usr/src/tmp/legacy/usr/lib -o mkmagic 
 /usr/src/lib/libmagic/../../contrib/file/src/apprentice.c 
 /usr/src/lib/libmagic/../../contrib/file/src/cdf_time.c 
 /usr/src/lib/libmagic/../../contrib/file/src/encoding.c 
 /usr/src/lib/libmagic/../../contrib/file/src/funcs.c 
 /usr/src/lib/libmagic/../../contrib/file/src/magic.c 
 /usr/src/lib/libmagic/../../contrib/file/src/print.c  -lz -legacy
 /usr/bin/ld: cannot find -legacy
 cc: error: linker command failed with exit code 1 (use -v to see invocation)
 *** Error code 1

I encountered this last month:

https://lists.freebsd.org/pipermail/freebsd-ports/2014-October/096077.html

https://lists.freebsd.org/pipermail/freebsd-ports/2014-November/096359.html

Regards
Andrew
___
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: [SOLVED] multimedia/x264 build failure, linker error

[Andrew Berg]

On 2014.11.25 08:56, Gary Palmer wrote:
 On Tue, Nov 25, 2014 at 08:35:12AM -0600, Andrew Berg wrote:
 On 2014.11.25 08:26, Gary Palmer wrote:
  Since I assume most of the packages that depend on the old 
  x264-0.136.2358_4
  depend on the library rather than the CLI command, is there any harm in
  doing
  
  portmaster -o multimedia/libx264 x264-0.136.2358_4
  
  instead?  That way the dependancies are kept (mostly) correct
 Don't do that. The dependency change has been properly handled, and those 
 ports
 know to use multimedia/libx264.
 
 If you followed the instructions in the mail I replied to, the installed
 packages are left with a dependency on x264 and not libx264.
 
 The real problem is that the few times I tried to use automated update
 methods ran into problems because x264 was already installed and libx264
 couldn't be installed because they conflicted.  Nothing seems to be
 in UPDATING or MOVED so the upgrades break.  There needs to be a better
 way of handling these cases.
As I have stated already in this thread, I am trying to get an UPDATING entry
committed:

  x264 was split into the application and its library. If an application
  that uses libx264 is updated before x264 itself, multimedia/libx264 will
  conflict with the old x264 package.

  Delete the existing x264:
  # pkg delete x264

  And then install the updated x264 and/or upgrade the other applications that
  depend on libx264.


This is my fault for not testing upgrades via ports when creating the patch.
___
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: archivers/arj fails to build

[andrew clarke]

On Mon 2014-11-17 20:00:01 UTC+0100, Kurt Jaeger (li...@opsec.eu) wrote:

  Unfortunately, archivers/arj fails to build:
 
 I just tested it on my reference install (10.1, amd64). It just builds.

ARJ builds OK here on 10.1.

My first thought is the OP has something unusual in /etc/make.conf.

My second thought is whether you actually need ARJ. ClamAV evidently
has it as a dependency, but I think it probably shouldn't given that
ARJ archives are rarely seen in the wild these days.

In any case you can exclude arj from the rebuild with:

portmaster [options] -x arj

Regards
Andrew
___
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: Deleting ports distfiles

[andrew clarke]

On Sun 2014-11-16 23:29:37 UTC+0100, Dr. Peter Voigt (pvo...@uos.de) wrote:

 I have just seen that /usr/ports/distfiles has grown up to 12 GiB. My
 hopefully not too stupid question is: Can I safely delete all files
 under /usr/ports/distfiles, e.g.
 
 # rm -rf /usr/ports/distfiles/*
 
 I strongly suppose so but I am not sure. Thanks for any feedback.

Yes. Missing distfiles will be redownloaded when/if you rebuild a port.

Regards
Andrew
___
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: cannot find -legacy error building /usr/lib32 with FreeBSD 10.1-RC3

[andrew clarke]

On Thu 2014-10-23 22:45:52 UTC+1100, andrew clarke (m...@ozzmosis.com) wrote:

 My intention was to build virtualbox-ose-additions-4.3.18 from ports...
 
 # uname -a
 FreeBSD vbox-freebsd10 10.1-RC3 FreeBSD 10.1-RC3 #0 r273437: Tue Oct 21 
 23:55:15 UTC 2014
 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
 
 # cd /usr/ports/emulators/virtualbox-ose-additions
 # make
 Requires 32-bit libraries installed under /usr/lib32.
 Do: cd /usr/src; make build32 install32; ldconfig -v -m -R /usr/lib32
 *** Error code 1
 
 Stop.

It turns out I just needed to download

ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.1-RC3/lib32.txz

untar it to / and then I could build the above port.

Not sure why I didn't have lib32 already installed. I must've
unchecked it during the initial 10.0 install for some reason.
___
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

cannot find -legacy error building /usr/lib32 with FreeBSD 10.1-RC3

[andrew clarke]

My intention was to build virtualbox-ose-additions-4.3.18 from ports...

# uname -a
FreeBSD vbox-freebsd10 10.1-RC3 FreeBSD 10.1-RC3 #0 r273437: Tue Oct 21 
23:55:15 UTC 2014
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

# cd /usr/ports/emulators/virtualbox-ose-additions
# make
Requires 32-bit libraries installed under /usr/lib32.
Do: cd /usr/src; make build32 install32; ldconfig -v -m -R /usr/lib32
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/emulators/virtualbox-ose-additions

# cd /usr/src; make build32 install32; ldconfig -v -m -R /usr/lib32
...
cc -O2 -pipe  -DMAGIC='/usr/share/misc/magic' -DHAVE_CONFIG_H
-I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file/src
-std=gnu99   -I/usr/obj/usr/src/tmp/legacy/usr/include -DCOMPILE_ONLY
-L/usr/obj/usr/src/tmp/legacy/usr/lib -o mkmagic
/usr/src/lib/libmagic/../../contrib/file/src/apprentice.c
/usr/src/lib/libmagic/../../contrib/file/src/cdf_time.c
/usr/src/lib/libmagic/../../contrib/file/src/encoding.c
/usr/src/lib/libmagic/../../contrib/file/src/funcs.c
/usr/src/lib/libmagic/../../contrib/file/src/magic.c
/usr/src/lib/libmagic/../../contrib/file/src/print.c  -lz -legacy
/usr/bin/ld: cannot find -legacy
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Stop.
make[2]: stopped in /usr/src/lib/libmagic
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src


According to this thread, 

http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044253.html

make build32 no longer works?

make buildworld seems a little excessive just for a single port.

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

Re: multimedia/mkvtoolnix gui

[andrew clarke]

On Wed 2014-10-01 21:01:59 UTC-0700, Russell L. Carter (rcar...@pinyon.org) 
wrote:

 So my stupid question is, how do you invoke the gui?

It should be at /usr/local/bin/mmg .
___
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: [HEADSUP] pkg(8) is now the only package management tool

[Andrew Berg]

On 2014.09.01 20:51, Michelle Sullivan wrote:
 And for the portsnap users?
 
 In short, this change doesn't directly effect portsnap users.
   
 Sure about that?
I'm sure of it. Your issue is with the tree itself, not the tool used to fetch 
it.

 Correct, take a 9.2 install disk, install it, portsnap and then install
 pkg on it...  Oh wait, you can't.. pkg_install is broken, and 9.2
 install disks don't have pkg in the BaseOS
Use the ports tree tarball included, or fetch it (either during or after
installation). It is not impossible to get an old version of the ports tree
with only the 9.2 base system. I don't see how this is anything more than an
inconvenience.
Also, 9.3 is out and the 9.2 EOL is not far away. Not sure why you would be
doing a new install with 9.2.
___
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: [HEADSUP] pkg(8) is now the only package management tool

[Andrew Berg]

On 2014.09.01 21:39, Julian Elischer wrote:
 sigh..  when are we as a project, all going to learn that reality in 
 business is
 that you often need to install stuff that is old. Its not always your 
 choice.
 The custommers require it..
 You should try arguing with someone like Bank of Americas security and 
 operations
 department some day about whether they want to suddenly upgrade 300 
 machines
 for no real reason (from their perspective).
FreeBSD minor version upgrades are meant to be non-disruptive. However, I will
admit that I have not performed any such upgrades in a critical environment, so
if you think they are disruptive, please enlighten me with the details.
Also, there are options out there for getting support for extended periods if
you need it. Some companies are built around providing support for things that
the original developers have long abandoned because some businesses need it.
___
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: [HEADSUP] pkg(8) is now the only package management tool

[Andrew Berg]

On 2014.09.01 21:27, Michelle Sullivan wrote:
 Actually it's an inconvenience for someone like me and you.  Not for
 many freebsd users, and certainly not for me 6 months ago if I hadn't
 been writing my own ports oh and what was it, 1.3.6 - 1.3.7? broke
 shit... (badly) ...
There were instructions for upgrading 1.3.6 to 1.3.7 alongside a notice that
things would not be good if the instructions were not followed and an
explanation of the issue. I think these kinds of notices need to reach more
people, but of course, that is easier said than done.
BTW, from what I have observed, 1.3.x issues have affected Poudriere users the
most, binary package users a bit less (but still significantly), and pure ports
users very little.

 Also, 9.3 is out and the 9.2 EOL is not far away. Not sure why you would be
 doing a new install with 9.2.
   
 Try getting yourself a FreeBSD server at Softlayer...  They still
 install 7.x for Christ's sake (amongst others - but last time I checked,
 on new servers, 8.4, 9.0, 9.1, 10.0*)
Fair enough.

 (not had time - because an EOL message is not a 'It will not
 work after this date' message it is a 'you're unsupported after this
 date and things *might* not work as expected'
No, it means we're not supporting this any more, so we don't care if there are
new vulnerabilities or things stop working. I'm not going to dictate to other
people what their upgrade schedule should be, but anyone running unsupported
versions of software should not have any expectation that the ecosystem around
it will be accommodating.
The ports tree already requires a lot work to make sure everything works on
supported versions of FreeBSD, and I see no reason whatsoever for anyone to put
effort into making it work on EOL versions.
___
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: [HEADSUP] pkg(8) is now the only package management tool

[Andrew Berg]

On 2014.09.01 22:09, Michelle Sullivan wrote:
 That's my point - there was a patch waiting to submit that knowingly
 broke pkg_install at midnight on the day after the EOL... the EOL
 shouldn't be an EOL - because it was really a 'portsnap after this date
 before you upgrade and you're screwed it won't work any more at all...'
As Peter outlined, this EOL was announced long ago, and it was mentioned at
least once that it was to allow breaking changes. There really would be no
reason to drop support for it in the ports tree if there were no plans to make
changes.

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

pkg 1.3.6 output bug

[andrew clarke]

Installing a package built on another system I noticed pkg 1.3.6 shows
incorrect output when installing with a dependency:

# ls -l
total 41123
-rw-r--r--  1 ozzmosis  ozzmosis  2428 24 Aug 18:07 
clang-devel-3.6.r216160.txz
-rw-r--r--  1 ozzmosis  ozzmosis  19728928 24 Aug 18:08 
llvm-devel-3.6.r216160.txz
# pkg add clang-devel-3.6.r216160.txz
Installing llvm-devel-3.6.r216160: 100%
Installing llvm-devel-3.6.r216160: 100%
# pkg -v
1.3.6

ie. llvm-devel is output twice, clang-devel not at all.

Pretty sure this is a bug?

Thanks,

Regards
Andrew
___
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

Upgrade to sysutils/nut-2.7.2 yesterday broke rc.d scripts by deleting libexec/nut/upsdrvctl

[Andrew Reilly]

Hi cy, itetcu,

An upgrade to the sysutils/nut port happened on Friday July 4, and was 
portmaster -a’d on my system this morning, and now doesn’t start properly.  
Specifically rc.d/nut has a prestart command that attempts to run 
/usr/local/libexec/upsdrvctl start, but that file was deleted by this change.
http://svnweb.freebsd.org/ports/head/sysutils/nut/pkg-plist?r1=360497r2=360496pathrev=360497

I didn’t see any descriptions or work-arounds in UPDATING.  Any suggestions for 
how to proceed?

Cheers,

— 
Andrew

___
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: Upgrade to sysutils/nut-2.7.2 yesterday broke rc.d scripts by deleting libexec/nut/upsdrvctl

[Andrew Reilly]

Hi again,

Found it: it has moved to /usr/local/sbin.  So the attached patch is needed to 
the sysutils/nut port.  Works for me.


nut.in.diff
Description: Binary data

Cheers,

— 
Andrew

On 5 Jul 2014, at 14:14 , Andrew Reilly arei...@bigpond.net.au wrote:

 Hi cy, itetcu,
 
 An upgrade to the sysutils/nut port happened on Friday July 4, and was 
 portmaster -a’d on my system this morning, and now doesn’t start properly.  
 Specifically rc.d/nut has a prestart command that attempts to run 
 /usr/local/libexec/upsdrvctl start, but that file was deleted by this 
 change.
 http://svnweb.freebsd.org/ports/head/sysutils/nut/pkg-plist?r1=360497r2=360496pathrev=360497
 
 I didn’t see any descriptions or work-arounds in UPDATING.  Any suggestions 
 for how to proceed?
 
 Cheers,
 
 — 
 Andrew
 

___
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: Who was the mental genius

[andrew clarke]

On Fri 2014-06-06 17:17:40 UTC+0200, Baptiste Daroussin (b...@freebsd.org) 
wrote:

 Yes it would have been a good idea to give a warning to the user about
 the fact that the ports tree won't be support long on after EOL of
 8.3, given the ports tree will break again quite soon after EOL of 8.4
 I should think about adding such a message right now (btw this is not

Is it viable to add an EOL message to portsnap(8)?
___
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

editors/uemacs

[andrew clarke]

On Sat 2014-05-10 10:33:52 UTC-0500, Bryan Drewery (bdrew...@freebsd.org) wrote:

 On June 31st, all unstaged ports will be marked DEPRECATED and have
 their MAINTAINER reset.
 On August 31st, all unstaged ports will be removed from the ports tree.

I'm the listed maintainer of editors/uemacs, which is currently
unstaged.

Since I switched to JED some time ago I haven't used MicroEMACS, so
have little motivation in working through this just for a single port.

If anyone still using uemacs would like to take over as maintainer,
that'd be cool.

Regards
Andrew
___
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: editors/uemacs

[andrew clarke]

On Mon 2014-05-12 10:13:46 UTC+1000, andrew clarke (m...@ozzmosis.com) wrote:

 I'm the listed maintainer of editors/uemacs, which is currently
 unstaged.
 
 Since I switched to JED some time ago I haven't used MicroEMACS, so
 have little motivation in working through this just for a single port.
 
 If anyone still using uemacs would like to take over as maintainer,
 that'd be cool.

Update: Joseph Benden submitted a patch already!

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

Thanks Joseph.
___
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: [HEADSUP] pkg 1.3.0 alpha1: Breath of fresh air from Kirov

[Andrew Thompson]

On 18 March 2014 06:21, Baptiste Daroussin b...@freebsd.org wrote:

 Hello,

 I'm really pleased to announce that the release process for the new major
 version of pkg(8) has started with this first alpha1 release.

 The main feature for this release is the complete rework of the solver.
 pkg(8) now features a real SAT solver and uses it for every operations
 requested
 by the user that may add, upgrade or remove packages.


I am sure this has been discussed before but does this release do anything
to help automating UPDATING or is this a planned feature?

Taking the last entry which says to pkg set -o
misc/p5-OSSP-uuid:misc/ossp-uuid-perl, just do it for me pkg!


Andrew
___
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: [patch] sysutils/beadm

[Andrew Hotlab]

 Date: Mon, 10 Mar 2014 16:11:16 -0500
 From: bdrew...@freebsd.org
 To: andrew.hot...@hotmail.com; verma...@interia.pl
 CC: po...@freebsd.org
 Subject: Re: [patch] sysutils/beadm

 On 2014-02-13 16:19, Andrew Hotlab wrote:

 In my setup I have the following layout (several datasets for /usr,
 /var, etc.):

 At this moment the utility does not seems to be able to manage this
 scheme, since it sets the mountpoint property as legacy for all
 datasets under the root, thus preventing to automatically mount any
 subdirectory at boot.
 I've tested this simple solution (to let do the job to the canmount
 property), and it seems to solve the problem without affecting the
 behavior when all system folders are located under a single root
 dataset (please see the patch below). I'd be glad if you'll include it
 in the next port revision.

 I'm at your disposal for any further detail.

 Best regards.

 Andrew


 --- ./beadm 2014-01-11 17:08:31.112384992 +0100
 +++ /usr/local/sbin/beadm 2014-01-11 17:06:38.620706860 +0100
 @@ -505,7 +505,7 @@
 if [ ${MOUNT} -eq 0 ]
 then
 zfs umount ${POOL}/${BEDS}/${2}
 - zfs set mountpoint=legacy ${POOL}/${BEDS}/${2}
 + zfs set mountpoint=/ ${POOL}/${BEDS}/${2}

 I've tested this and agree with it. It should be added upstream as it
 makes it simpler to have these extra /mounts. Otherwise you have to
 explicitly set them with mountpoint=/usr, /var, instead of inheriting
 from the / dataset.
 The problems I mentioned were probably before we got the 'canmount'
 support in to prevent remounting over /.

 fi
 fi
 if ! zpool set bootfs=${POOL}/${BEDS}/${2} ${POOL} 1 /dev/null 2
 /dev/null
 @@ -518,6 +518,7 @@
 ZFS_LIST=$( zfs list -H -o name -r ${POOL}/${BEDS} )
 # disable automatic mount on all inactive boot environments
 echo ${ZFS_LIST} \
 + | grep -v ^${POOL}/${BEDS}$ \

 Note that this change is unrelated.

 | grep -v ^${POOL}/${BEDS}/${2}$ \
 | grep -v ^${POOL}/${BEDS}/${2}/ \
 | while read NAME


Great! I'm glad to be helpful. I'll look forward to see the change committed to 
the Ports repository.

Thank you so much for this wonderful tool!

Regards.

Andrew
___
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: [patch] sysutils/beadm

[Andrew Hotlab]

 Date: Wed, 19 Feb 2014 07:27:45 -0600
 From: bdrew...@freebsd.org
 To: andrew.hot...@hotmail.com
 CC: po...@freebsd.org; verma...@interia.pl
 Subject: Re: [patch] sysutils/beadm

 On 2/13/2014 4:19 PM, Andrew Hotlab wrote:
 First of all, thank you very much for the good work with this port. I'm sure 
 it's changing the life of a lot FreeBSD system administrators!

 In my setup I have the following layout (several datasets for /usr, /var, 
 etc.):

 NAME USED AVAIL REFER MOUNTPOINT
 sys 1.55G 18.0G 31K none
 sys/ROOT 532M 18.0G 31K none
 sys/ROOT/default 114K 18.0G 250M /
 sys/ROOT/default/tmp 22K 18.0G 38K /tmp
 sys/ROOT/default/usr 1K 18.0G 245M /usr
 sys/ROOT/default/var 48.5K 18.0G 36.4M /var
 sys/swap 1.03G 19.0G 16K -

 At this moment the utility does not seems to be able to manage this scheme, 
 since it sets the mountpoint property as legacy for all datasets under the 
 root, thus preventing to automatically mount any subdirectory at boot.
 I've tested this simple solution (to let do the job to the canmount 
 property), and it seems to solve the problem without affecting the behavior 
 when all system folders are located under a single root dataset (please see 
 the patch below). I'd be glad if you'll include it in the next port revision.


 ACK on this. CC'ing upstream maintainer too.

 I run the same setup but I specifically set /usr /var and /tmp mntpoints
 to /usr,/var/,/tmp to avoid this issue. I am not sure if mntpoint=/ is
 proper. I recall there being an issue with it. I would much prefer your
 patch though if it is safe.

 Does beadm mount still work with this to mount a new BE into /tmp?

 Ie,

 beadm create newbe
 beadm mount newbe

 Does it go and remount / or only touch /tmp?


It seems to behave correctly, as you can see in the attached transcript.

 How about activating? Does it blow away / right away or wait until reboot?

Since beadm changes only the canmount ZFS property to set the active 
environment for the next reboot, there is no implications for the running 
environment.

Regards

Andrewroot@BETEST:~ # zfs list -t all
NAMEUSED  AVAIL  REFER  MOUNTPOINT
sys1.55G  18.0G31K  none
sys/ROOT535M  18.0G31K  none
sys/ROOT/RELENG_9_2 535M  18.0G   251M  /
sys/ROOT/RELENG_9_2/tmp  36K  18.0G36K  /tmp
sys/ROOT/RELENG_9_2/usr 247M  18.0G   247M  /usr
sys/ROOT/RELENG_9_2/usr/obj  31K  18.0G31K  /usr/obj
sys/ROOT/RELENG_9_2/usr/ports31K  18.0G31K  /usr/ports
sys/ROOT/RELENG_9_2/usr/src  31K  18.0G31K  /usr/src
sys/ROOT/RELENG_9_2/var35.8M  18.0G  35.8M  /var
sys/swap   1.03G  19.0G16K  -
root@BETEST:~ # beadm list
BE Active Mountpoint  Space Created
RELENG_9_2 NR /  533.9M 2014-01-13 12:38
root@BETEST:~ # beadm create test
Created successfully
root@BETEST:~ # zfs list -t all
NAMEUSED  AVAIL  REFER  
MOUNTPOINT
sys1.55G  18.0G31K  none
sys/ROOT535M  18.0G31K  none
sys/ROOT/RELENG_9_2 535M  18.0G   251M  /
sys/ROOT/RELENG_9_2@2014-02-19-17:03:490  -   251M  -
sys/ROOT/RELENG_9_2/tmp  36K  18.0G36K  /tmp
sys/ROOT/RELENG_9_2/tmp@2014-02-19-17:03:490  -36K  -
sys/ROOT/RELENG_9_2/usr 247M  18.0G   247M  /usr
sys/ROOT/RELENG_9_2/usr@2014-02-19-17:03:490  -   247M  -
sys/ROOT/RELENG_9_2/usr/obj  31K  18.0G31K  /usr/obj
sys/ROOT/RELENG_9_2/usr/obj@2014-02-19-17:03:490  -31K  -
sys/ROOT/RELENG_9_2/usr/ports31K  18.0G31K  
/usr/ports
sys/ROOT/RELENG_9_2/usr/ports@2014-02-19-17:03:49  0  -31K  -
sys/ROOT/RELENG_9_2/usr/src  31K  18.0G31K  /usr/src
sys/ROOT/RELENG_9_2/usr/src@2014-02-19-17:03:490  -31K  -
sys/ROOT/RELENG_9_2/var35.8M  18.0G  35.8M  /var
sys/ROOT/RELENG_9_2/var@2014-02-19-17:03:490  -  35.8M  -
sys/ROOT/test 7K  18.0G   251M  /
sys/ROOT/test/tmp 1K  18.0G36K  /tmp
sys/ROOT/test/usr 4K  18.0G   247M  /usr
sys/ROOT/test/usr/obj 1K  18.0G31K  /usr/obj
sys/ROOT/test/usr/ports   1K  18.0G31K  
/usr/ports
sys/ROOT/test/usr/src 1K  18.0G31K  /usr/src
sys/ROOT/test/var 1K  18.0G  35.8M  /var
sys/swap   1.03G  19.0G16K  -
root@BETEST:~ # beadm mount test
Mounted

[patch] sysutils/beadm

[Andrew Hotlab]

First of all, thank you very much for the good work with this port. I'm sure 
it's changing the life of a lot FreeBSD system administrators!

In my setup I have the following layout (several datasets for /usr, /var, etc.):

NAME                   USED  AVAIL  REFER  MOUNTPOINT
sys                   1.55G  18.0G    31K  none
sys/ROOT               532M  18.0G    31K  none
sys/ROOT/default       114K  18.0G   250M  /
sys/ROOT/default/tmp    22K  18.0G    38K  /tmp
sys/ROOT/default/usr     1K  18.0G   245M  /usr
sys/ROOT/default/var  48.5K  18.0G  36.4M  /var
sys/swap              1.03G  19.0G    16K  -

At this moment the utility does not seems to be able to manage this scheme, 
since it sets the mountpoint property as legacy for all datasets under the 
root, thus preventing to automatically mount any subdirectory at boot.
I've tested this simple solution (to let do the job to the canmount property), 
and it seems to solve the problem without affecting the behavior when all 
system folders are located under a single root dataset (please see the patch 
below). I'd be glad if you'll include it in the next port revision.

I'm at your disposal for any further detail.

Best regards.

Andrew


--- ./beadm 2014-01-11 17:08:31.112384992 +0100
+++ /usr/local/sbin/beadm 2014-01-11 17:06:38.620706860 +0100
@@ -505,7 +505,7 @@
if [ ${MOUNT} -eq 0 ]
then
zfs umount ${POOL}/${BEDS}/${2}
- zfs set mountpoint=legacy ${POOL}/${BEDS}/${2}
+ zfs set mountpoint=/ ${POOL}/${BEDS}/${2}
fi
fi
if ! zpool set bootfs=${POOL}/${BEDS}/${2} ${POOL} 1 /dev/null 2 /dev/null
@@ -518,6 +518,7 @@
ZFS_LIST=$( zfs list -H -o name -r ${POOL}/${BEDS} )
# disable automatic mount on all inactive boot environments
echo ${ZFS_LIST} \
+ | grep -v ^${POOL}/${BEDS}$ \
| grep -v ^${POOL}/${BEDS}/${2}$ \
| grep -v ^${POOL}/${BEDS}/${2}/ \
| while read NAME 
___
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: USE_GCC doesn't set rpath

[Andrew W. Nosenko]

On Thu, Jan 23, 2014 at 9:56 PM, John Marino freebsd.cont...@marino.stwrote:

 On 1/23/2014 20:53, Bernhard Fröhlich wrote:
  Am 23.01.2014 20:04 schrieb Yuri y...@rawbw.com:
 
  On 01/21/2014 15:31, Shane Ambler wrote:
 
  I think you will find that qbittorrent will need to be built with the
  same gcc version as libtorrent-rasterbar.
 
  I believe qbittorrent is loading /usr/lib/libstdc++.so.6 then it loads
  libtorrent-rasterbar.so.7 which tries to load libstdc++ and it is given
  the already open copy which doesn't have GLIBCXX_3.4.15 that it needs
 to
  run.
 
 
  Yes, you are right, thst's what is happening.
  So if any dependency has USE_GCC set, all dependent packages should also
  have USE_GCC set. Can ports build infrastructure automatically set
 USE_GCC
  for dependent ports? Because doing this by hand in each port is tedious
 and
  error prone.
 
  Yuri
 
  No it can't right now and this is why we need a ports compiler. Right now
  we are hiding this problems by the fact that we are able to build 95%
  percent of the tree with clang and everyone is happy. We add dozens of
  patches to compile with clang or add this rpath workarounds to even more
  ports just because nobody wants to acknowledge that this is shit and
 won't
  work properly unless really everything is build with one compiler.
 
  The rpath stuff is only a workaround that works in a few cases but it
  doesn't work in all cases. You will still see very hard to diagnose
 runtime
  crashes.

 While I basically agree with this sentiment, is not it just ports that
 use C++ that are affected?  Could not this be narrowed down to We need
 a single compiler for ports that use C++ ?


No.  Everything that uses language- or feature-support library are
affected.  I'm, for example, unable to use OpenMP higher than 2.5 even if
compiler is gcc-4.8, which is openmp-3.x capable).

But, from my point of view, the problem is not a compiler nor rpath.  rpath
is unneeded indeed, and library indeed may be only one (under /lib).  The
real problem is that this is ancient library, not the most recent one.
 They are especially designed to be backward compatible and have the same
so-number for a reason.

-- 
Andrew W. Nosenko andrew.w.nose...@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: pkg audit -F segfault

[andrew clarke]

On Tue 2013-12-10 21:53:16 UTC-0500, Phil Stone (phil.st...@gmx.com) wrote:

 Hi,
 I've just installed pkg-1.2.3 on FreeBSD 8.4-RELEASE-p6.

It's also segfaulting on 9.2-RELEASE-p2 here.

I noticed the segfault in my syslog just now, since pkg audit -F is
run daily from /usr/local/etc/periodic/security/410.pkg-audit.
 
 Running the command pkg audit -F causes a segfault:
 # pkg audit -F
 Vulnxml file up-to-date.
 Segmentation fault (core dumped)
 #

(gdb) set args audit -F
(gdb) r
Starting program: /usr/ports/ports-mgmt/pkg/work/pkg-1.2.3/pkg/pkg audit -F
[New LWP 101360]
[New Thread 803407400 (LWP 101360/pkg)]
Vulnxml file up-to-date.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 803407400 (LWP 101360/pkg)]
0x000800ddb130 in archive_read_free () from /usr/lib/libarchive.so.5
(gdb) bt
#0  0x000800ddb130 in archive_read_free () from /usr/lib/libarchive.so.5
#1  0x00407772 in fetch_and_extract (src=0x803425070 
http://www.vuxml.org/freebsd/vuln.xml.bz2;, 
dest=0x7fffcfd0 /var/db/pkg/vuln.xml, xml=true) at audit.c:211
#2  0x0040902e in exec_audit (argc=0, argv=0x7fffd530) at 
audit.c:882
#3  0x004105b0 in main (argc=2, argv=0x7fffd520) at main.c:754

 Implementing the following patch solves the issue:
 --- audit_orig.c 2013-12-11 03:36:21.390625000 +0100
 +++ audit.c 2013-12-11 03:36:59.796875000 +0100
 @@ -206,9 +206,10 @@
  
         cleanup:
         unlink(tmp);
 -       if (a != NULL)
 +       if (a != NULL) {
                 archive_read_close(a);
                 archive_read_free(a);
 +       }
         if (fd = 0)
                 close(fd);
 
 Thanks in advance for your help.
 Phil

Indeed, adding the erroneously missing braces fixes the problem here.

Thanks Phil,

Regards
Andrew
___
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: [games/ofortune] CFT and pending issues

[Andrew Berg]

On 2013.12.05 15:54, A.J. 'Fonz' van Werven wrote:
 A short recap for those of you who are subscribed to freebsd-ports@ but
 not freebsd-stable@: when I opened my inbox this morning I found a typical
 WTF thread: the (hardly) offensive fortune cookies have been kicked out
 of 10-BETA4. Since I (and many others) find this Just Plain Stupid (tm) I
 created a port to bring some sanity back into fortune(6).
Thank you for making this port. I was quite saddened when these fortunes were 
removed.

 Anyone running FreeBSD 10-BETA4 feel free to test the port and comment on
 it before I file the PR asking for it to be committed.
I will test it this weekend.

 PENDING ISSUES:
 
 -1-
 It's tentatively called ofortune. If you can think of a better name, then
 by all means shoot.
Going by the other fortune file ports, misc/fortune-offensive or something very 
similar would be more appropriate.
It's not really a game in itself and the others are in misc, so misc is 
probably more appropriate.

 -4-
 I wanted to mark the port as IGNORE for versions of FreeBSD prior to
 10-BETA4. But this breaks stuff (see point 6) and I need to know exactly
 what the version number (OSVERSION) is for 10-BETA4.
The fortunes were removed in one of the ALPHA releases if not before then 
(certainly before 10 was branched to -STABLE), so I'm sure it's
fine to simply target 10.
Anyone still running a version of 10 from when it was still -CURRENT can expect 
problems anyway.

 COMMENT=  The offensive fortune cookies that used to be in base.
Perhaps it would be better to specify the version - e.g., The offensive 
fortune cookies present the 9.x base system that were removed in 10.x.
___
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: opencv update

[Andrew W. Nosenko]

On Thu, Dec 5, 2013 at 12:07 AM, Lowell Gilbert 
freebsd-ports-lo...@be-well.ilk.org wrote:

 Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org writes:

  Ajtim lum...@gmail.com writes:
 
  I did what is in /usr/ports/UPDATING and looks like I am in trouble
  now. My system is FreeBSD 10.0-BETA4 (amd64):
 
  === FreeBSD 10 autotools fix applied to
  /usr/ports/multimedia/ffmpeg0/work/ffmpeg-0.7.16/configure
  ERROR: opencv-core not found
 
  Looks like ffmpeg0's opencv support should now depend on graphics/opencv
  rather than graphics/opencv-core. I'm testing this theory now...

 No, that's not right. There's some configure-script editing in the port
 that I hadn't noticed. It's probably a minor fix, but in the meantime
 turning off ffmpeg0's option for opencv should get you around it.


I didn't verified it yet, but my assumption that it's combination of wrong
order of linker parameters and --as-needed option.  Libraries placed before
object file, which uses them (wrong order), so at the time of theirs
occurrence they are unneeded and therefore skipped.  Similar problem would
to occur independently of --as-needed if static libraries would be used
instead of dynamic, or linker occur more strict/conservative.

PS. @Mark: cvCreateImageHeader, symbol, which test program tries to find in
opencv-core.so library, exists there and exported indeed.  It absent in the
output of plain nm (or 'nm -a' in your case) just because library is heavy
stripped (removed anything unneeded for ld.so).  If use 'nm -D', you will
see that symbol.


-- 
Andrew W. Nosenko andrew.w.nose...@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: opencv update

[Andrew W. Nosenko]

On Thu, Dec 5, 2013 at 3:38 AM, Andrew W. Nosenko 
andrew.w.nose...@gmail.com wrote:

 On Thu, Dec 5, 2013 at 12:07 AM, Lowell Gilbert 
 freebsd-ports-lo...@be-well.ilk.org wrote:

 Lowell Gilbert freebsd-ports-lo...@be-well.ilk.org writes:

  Ajtim lum...@gmail.com writes:
 
  I did what is in /usr/ports/UPDATING and looks like I am in trouble
  now. My system is FreeBSD 10.0-BETA4 (amd64):
 
  === FreeBSD 10 autotools fix applied to
  /usr/ports/multimedia/ffmpeg0/work/ffmpeg-0.7.16/configure
  ERROR: opencv-core not found
 
  Looks like ffmpeg0's opencv support should now depend on graphics/opencv
  rather than graphics/opencv-core. I'm testing this theory now...

 No, that's not right. There's some configure-script editing in the port
 that I hadn't noticed. It's probably a minor fix, but in the meantime
 turning off ffmpeg0's option for opencv should get you around it.


 I didn't verified it yet, but my assumption that it's combination of wrong
 order of linker parameters and --as-needed option.  Libraries placed before
 object file, which uses them (wrong order), so at the time of theirs
 occurrence they are unneeded and therefore skipped.  Similar problem would
 to occur independently of --as-needed if static libraries would be used
 instead of dynamic, or linker occur more strict/conservative.

 PS. @Mark: cvCreateImageHeader, symbol, which test program tries to find
 in opencv-core.so library, exists there and exported indeed.  It absent in
 the output of plain nm (or 'nm -a' in your case) just because library is
 heavy stripped (removed anything unneeded for ld.so).  If use 'nm -D', you
 will see that symbol.


ffmpeg0 configure script considers as libraries only parameters started
with '-l'.  See check_ld() functions.

But opencv-core pkg-config file (opencv-core.pc) reports absolute
library filenames
/usr/local/lib/libopencv_core.so /usr/local/lib/libopencv_imgproc.so
instead of expected by configure
-L/usr/local/lib -lopencv_core -lopencv_imgproc.
It results in treating these .so as CFLAGS with all consequences.

There are two ways to cure:
1. patch ffmpeg0 configure to detect libraries without -l
2. patch opencv-core .pc file to report libraries as -lname instead of
   /path/to/libname.so

Patch for ffmpeg0 configure is attached.

-- 
Andrew W. Nosenko andrew.w.nose...@gmail.com


patch-configure-check-ld
Description: Binary data
___
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

www/netsurf

[Andrew Johnson]

  Any idea why Netsurf stopped working some months ago?

  It fires up but is unable to load any web page, but last year it was a nice 
quick browser.

i386 FreeBSD 9.2-BETA2 #4: Sat Aug  3
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

portmaster glitch with /usr/ports/MOVED

[andrew clarke]

I made the mistake of telling portmaster-3.17.3 to build
mail/mutt-devel instead of mail/mutt. Evidently portmaster sees the
port has moved based on /usr/ports/MOVED, which is good, but it 
erroneously calls pkg, apparently without arguments, and the remaining
output looks a bit broken.

Regards
Andrew

# portmaster mail/mutt-devel

=== The mail/mutt-devel port moved to mail/mutt
=== Reason: mail/mutt-devel is ready for primetime

=== Exiting
Usage: pkg info pkg-name
   pkg info -a
   pkg info [-AbBDdefgiIklOqRrsx] pkg-name
   pkg info [-AbBDdfIlqRrs] -F pkg-file

For more information see 'pkg help info'.

=== The second argument to -o can be a package name,
   or a port directory from /usr/ports

does not seem to be installed,
   or listed as a dependency

=== No valid installed port, or port directory given
=== Try portmaster --help

=== Killing background jobs
Terminated
=== Exiting
___
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: www/aria2 dependencies lang/llvm33 build error

[andrew clarke]

On Sun 2013-11-17 14:15:02 UTC+0100, Michael Gmelin (free...@grem.de) wrote:

   www/aria2 1.18.1 requires lang/clang33. Is this really necessary?
   Previous aria2 versions didn't require clang.
  
  I've now had a chance to check the aria2 sources and evidently it now
  requires C++11 support, which I find surprising, but that's progress I
  suppose...
 
 From a developer's standpoint this makes a lot of sense, since C++11 is
 more productive and a lot more fun to use.

Sounds good. I just wonder about the logic behind doing that for a
minor 1.17 - 1.18 release though.

 I just built sudo successfully on 9.1 using system clang 3.1 and
 CXX=clang++
 CXXFLAGS+=-std=c++11 -stdlib=libc++

Yeah, I have no problem building sudo with clang. The sudo code is all
C though, not C++.

I upgraded from FreeBSD 8.4-REL to 9.2-REL during the week. Trying to
build aria2 with or without the above in /etc/make.conf still results
in:

checking whether clang++ supports C++11 features by default... no

The only place I can get aria2 1.18 to build successfully is under
FreeBSD 10.0-BETA(3) (tested in a VM). So that tends to rule out
aria2's configure script being broken at least.

For the time being I'm using portdowngrade to install aria2 1.17. Not
a big deal, and I suspect I'll be upgrading my servers from FreeBSD
9.2 to 10.x sometime early next year, whereby this issue will fix
itself...

 The problem you're facing is probably the lack of libc++, which
 contains all the C++11 library features. You can use C++11 using the
 old gcc standard C++ library, but then you won't have access to about
 2/3 of the new features which are all implemented in the library. To
 get those on a system that doesn't ship with clang already you could
 install devel/libc++. Unfortunately this won't build on older hosts due
 to the lack of aligned_alloc. While this can be worked around by
 defining your local aligned_alloc, you'll probably trip over the lack of
 xlocale(3) support, which is required to build libc++ successfully and
 first appeared in 9.1.

Out of curiosity I tried building devel/libc++ under 9.2 but it failed with:

Shared object libz.so.5 not found, required by libLLVM-3.3.so

Evidently the fix is to add libz.so.5 libz.so to /etc/libmap.conf.

I then point /etc/make.conf to lang/clang33:

CC=clang33
CXX=clang++33
CPP=clang++33 -E

aria2 1.18's configure still breaks though, darn:

checking whether clang++33 supports C++11 features by default... no

 So basically I see two options for you:
 - Update to 9.2-RELEASE, 8.4 will be EoL soon anyway

FWIW the reason I stuck with 8.4 was because it's EoL in June 2015,
whereas 9.2 is EoL in September 2014.

http://www.freebsd.org/security/security.html#sup

Upgrading from 8.4 to 9.2 was surprisingly painless though, so I'm not
as concerned with future upgrades. My main worry was root on ZFS, and
whether the pool would be bootable from the newer kernel. It all went
swimmingly though. Disk performance seems to have improved a little
too which is nice.

 - Try building aria with a recent gcc instead

I've had no success with that either!

Thanks for the pointers, though.

Regards
Andrew
___
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: www/aria2 dependencies lang/llvm33 build error

[andrew clarke]

On Fri 2013-11-22 15:37:56 UTC+0100, Michael Gmelin (free...@grem.de) wrote:

   I just built sudo successfully on 9.1 using system clang 3.1 and
   CXX=clang++
   CXXFLAGS+=-std=c++11 -stdlib=libc++
  
  Yeah, I have no problem building sudo with clang. The sudo code is all
  C though, not C++.
 
 Well, that was supposed to be aria2 and not sudo (no idea why I
 wrote sudo in the first place, probably multitasking when I shouldn't
 have). A tried it specifically because it didn't build about two weeks
 earlier due to being incompatible with C++11. So it went straight from
 not working with C++11 to requiring C++11. Good times :)

Ah.

Then the obvious question is... How did you get aria2 to build in 9.1
when I can't get it to build in 9.2? ;-)

Regards
Andrew
___
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: www/aria2 dependencies lang/llvm33 build error

[andrew clarke]

On Fri 2013-11-22 15:51:14 UTC+0100, Michael Gmelin (free...@grem.de) wrote:

  Then the obvious question is... How did you get aria2 to build in 9.1
  when I can't get it to build in 9.2? ;-)
 
 I built 9.1 from source using:
 
 WITH_LIBCPLUSPLUS=YES
 (and later WITH_CLANG_EXTRAS=1)
 
 (make buildworld installworld kernel)
 
 So I've got libc++.
 
 All ports are built using:
 CC=clang
 CXX=clang++
 CXXFLAGS+= -std=c++11 -stdlib=libc++
 CPP=clang-cpp

I see! I'll give that a try if I get some free time, although the
effort required seems excessive just to build the latest aria2 . :)

Thanks Michael,

Regards
Andrew
___
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: www/aria2 dependencies lang/llvm33 build error

[andrew clarke]

Following up on my question from yesterday...

On Sun 2013-11-17 00:22:13 UTC+1100, andrew clarke (m...@ozzmosis.com) wrote:

 I'm running FreeBSD 8.4-RELEASE-p4.
 
 www/aria2 1.18.1 requires lang/clang33. Is this really necessary?
 Previous aria2 versions didn't require clang.

I've now had a chance to check the aria2 sources and evidently it now
requires C++11 support, which I find surprising, but that's progress I
suppose...

 If so, I already have lang/clang-devel (3.4) installed, but the port
 still wants to build lang/clang33, which of course requires
 devel/llvm33.

I've just noticed for lang/clang-devel, the actual clang binary has
been recently renamed to clang-devel, but this isn't mentioned in
/usr/ports/UPDATING.

If I set CXX=clang++-devel in make.conf, the aria2 configure script
still fails though, complaining of missing C++11 support. Odd.

 However on 8.4-REL, currently llvm33 fails to build:
 
 gmake[1]: Leaving directory 
 `/usr/ports/devel/llvm33/work/llvm-3.3.src/bindings'
 llvm[0]: * Completed Release Build
 sphinx-build -b man -d _build/doctrees   . _build/man
 Traceback (most recent call last):
   File /usr/local/bin/sphinx-build, line 5, in module
 from pkg_resources import load_entry_point
   File build/bdist.freebsd-8.3-RELEASE-p3-amd64/egg/pkg_resources.py, line 
 2805, in module
   File build/bdist.freebsd-8.3-RELEASE-p3-amd64/egg/pkg_resources.py, line 
 696, in require
   File build/bdist.freebsd-8.3-RELEASE-p3-amd64/egg/pkg_resources.py, line 
 594, in resolve
 pkg_resources.DistributionNotFound: markupsafe
 gmake: *** [man] Error 1
 *** Error code 2

On a hunch I tried reinstalling textproc/py-sphinx, which failed with
the same error. Evidently py-sphinx is missing a dependency on
textproc/py-MarkupSafe. Once markupsafe is installed I could build 
install llvm33  clang33.

But even so, the aria2 build still complains about missing C++11 support:

checking whether /usr/local/bin/clang++33 supports C++11 features by default... 
no
checking whether /usr/local/bin/clang++33 supports C++11 features with 
-std=c++11 ... no
checking whether /usr/local/bin/clang++33 supports C++11 features with 
-std=c++11 -stdlib=libc++... no
checking whether /usr/local/bin/clang++33 supports C++11 features with 
-std=c++0x ... no
checking whether /usr/local/bin/clang++33 supports C++11 features with 
-std=c++0x -stdlib=libc++... no
configure: error: *** A compiler with support for C++11 language features is 
required.
===  Script configure failed unexpectedly.

Any suggestions?

Regards
Andrew
___
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

www/aria2 dependencies lang/llvm33 build error

[andrew clarke]

Hi,

I'm running FreeBSD 8.4-RELEASE-p4.

www/aria2 1.18.1 requires lang/clang33. Is this really necessary?
Previous aria2 versions didn't require clang.

If so, I already have lang/clang-devel (3.4) installed, but the port
still wants to build lang/clang33, which of course requires
devel/llvm33.

However on 8.4-REL, currently llvm33 fails to build:

gmake[1]: Leaving directory `/usr/ports/devel/llvm33/work/llvm-3.3.src/bindings'
llvm[0]: * Completed Release Build
sphinx-build -b man -d _build/doctrees   . _build/man
Traceback (most recent call last):
  File /usr/local/bin/sphinx-build, line 5, in module
from pkg_resources import load_entry_point
  File build/bdist.freebsd-8.3-RELEASE-p3-amd64/egg/pkg_resources.py, line 
2805, in module
  File build/bdist.freebsd-8.3-RELEASE-p3-amd64/egg/pkg_resources.py, line 
696, in require
  File build/bdist.freebsd-8.3-RELEASE-p3-amd64/egg/pkg_resources.py, line 
594, in resolve
pkg_resources.DistributionNotFound: markupsafe
gmake: *** [man] Error 1
*** Error code 2

Stop in /usr/ports/devel/llvm33.
*** Error code 1

Thanks.

Regards
Andrew
___
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: CC, CPP etc vs CONFIGURE_ENV

[Andrew W. Nosenko]

On Wed, Nov 6, 2013 at 6:51 PM, Charles Swiger cswi...@mac.com wrote:
 On Nov 6, 2013, at 7:25 AM, Andriy Gapon a...@freebsd.org wrote:
 Setting $CC and such worked with older ./configure which didn't implement 
 $CONFIGURE_ENV.
 It also plays more nicely with things which roll their own ./configure as a 
 shim
 that isn't actually GNU autoconf.

 Apologies, you seem to think that CONFIGURE_ENV is an environment variable of
 its own.  But, as far as I can see, it is not.  It is a make variable with a
 value that expands to FOO=BAR VAR=VAL ... and those FOO, VAR, etc are the
 environment variables that are to be set in configure's environment:

 ${SETENV} ... ${CONFIGURE_ENV} ./${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}

 Yes, setup via ports/bsd.options.mk and such (aka configure.mk on some other 
 platforms).

 So, either I didn't understand what you said or what you said is not 
 relevant.

 That's fair enough-- I don't always manage to be both comprehensible and 
 relevant.  :-)

 I seemed to recall that sufficiently modern configure's would look into
 $CONFIGURE_ENV if you set it via:

export ${CONFIGURE_ENV}; ./${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}

 ...instead.  But I don't see signs of that in GNU autoconf, so that might be
 a non-standard thing.


After variable substitution by make, it will become something like
export VAR1=FOO VAR2=BAR; ./configure
and then executed by shell.  So, from configure script point of view,
it is the same environment variables.

-- 
Andrew W. Nosenko andrew.w.nose...@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: Should /usr/bin/perl be a link to /usr/local/bin/perl ?

[andrew clarke]

On Mon 2013-10-21 09:47:29 UTC-0700, Yuri (y...@rawbw.com) wrote:

 I found that many ports specify /usr/bin/perl as an interpreter. This 
 comes from Linux. Examples: valgrind-snapshot, windowmaker, enscript-a4, 
 a2ps, svgalib
 /usr/bin/perl isn't installed by perl port.
 
 There are several solutions, in the order of increasing complexity of 
 solution:
 1. Install the link /usr/bin/perl (hackish, but it will fix many broken 
 ports in one shot)
 2. Make a package scripts check for interpreter and break the install of 
 offending packages
 3. Fix all offending packages
 
 Which solution should be preferred in your opinion?

Are you aware the Perl interpreter ports already have a make option to
create symlinks in /usr/bin?

$ pwd
/usr/ports/lang/perl5.14

$ make showconfig | grep USE_PERL
 USE_PERL=on: Rewrite links in /usr/bin

$ ls -l /usr/bin/perl
lrwxr-xr-x  1 root  wheel  25 10 Oct 14:04 /usr/bin/perl - 
/usr/local/bin/perl5.14.4

Regards
Andrew
___
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: [HEADSUP] Staging, packaging and more

[Andrew W. Nosenko]

On Tue, Oct 8, 2013 at 11:47 AM, Baptiste Daroussin b...@freebsd.org wrote:

 Concerning the fact that you need a couple of new packages to be able to
 actually build something out github or whatever, this is a developer problem 
 and
 doing pkg install gtk2-dev is not complicated at all.

While installing gtk2-dev is not hard indeed, finding the name of
package, which you need (gtk2-dev in your example) may be much harder.

Just an example:
Ubuntu has a package for curl (commandline utility):
http://packages.ubuntu.com/precise/curl

curl (commandline utility) is a thin wrapper around libcurl, libcurl
is registered as a dependency.  No problems yet, just go through
hypelink.  http://packages.ubuntu.com/precise/libcurl3

Now, can you say me, what package should I install for obtain headers,
.pc, debug symbols and other developer-related stuff for that libcurl?
 Not some libcurl, but that specific libcurl, which was fetched as
dependency of the curl (commandline utility)?

It just a fear.  My fear.  Fear that possibility to create
packages/subpackages may lead to creating them randomly, and these
randomly created packages/subpackages may lead to the same problems as
demonstrated above.
And, seems, I'm not alone in that.


-- 
Andrew W. Nosenko andrew.w.nose...@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

Bitmessage

[Andrew]

Is there any interest in getting Bitmessage in ports? I heard about it on a 
podcast and it seems pretty interesting.

https://bitmessage.org/wiki/Main_Page

https://github.com/Bitmessage

They've got a few FreeBSD-related commits, so maybe it wouldn't be too hard to 
port. Anyone wanna try?

___
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

libgcrypt security

[Andrew]

Hi all. GPG and libgcrypt were updated for security problems, 
http://lists.gnupg.org/pipermail/gnupg-announce/2013q3/000330.html

but I still don't see this update in ports. The vuXML entry: 
http://www.vuxml.org/freebsd/80771b89-f57b-11e2-bf21-b499baab0cbe.html

Can we get it updated please?

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

Re: ports 10-CURRENT

[Andrew W. Nosenko]

On Wed, Jun 19, 2013 at 4:32 PM, Cy Schubert cy.schub...@komquats.com wrote:
 You don't understand. devel/imake is a fine piece of software but people do
 not want to install more software than they have to. net/vnc comes with
 it's own integrated Xserver. Using this logic we should integrate
 x11-servers/xorg into it too. Neither makes sense. The only reason to use
 devel/imake is if net/vnc _installs_ its own imake, which it does not.
 There's no reason to install more software just to build other software if
 we don't need it. It's extra baggage.

If follow this logic, net/vnc should  to bundle it's own C compiler then...

-- 
Andrew W. Nosenko andrew.w.nose...@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

distfile fetching vs ISP site-help spoofing: any suggestions?

[Andrew Reilly]

I've just tried to portupgrade after a three-month hiatus and noticed a problem 
with the libgcrypt distfile
checksum that didn't go away after my usual strategy of waiting for a couple of 
days,
re-syncing the ports tree and trying again.  Closer inspection and a hint from 
a google search
revealed that the first-level problem is that the wrong file had been fetched: 
it was a short
HTML file, rather than the expected tar.bz2 file.  How did that happen?  
Apparently my ISP
(Bigpond, in Australia) has recently turned on a site-helper mechanism that 
spoofs any site
for which a DNS-lookup fails.  That is, there are now no missing or expired 
sites.  In this
case, the first item in the ports/Mk/bsd.sites.mk list used by the 
security/libgcrypt Makefile
is gnupg.org.favoritelinks.net which does not (any longer?) resolve.

I've arranged to proceed by deleting the line in bsd.sites.mk, which allowed 
the fetch to
succeed.  This seems a bit lame though, because perhaps that site will come 
back one day.
Seems like a fragile, non-scaling approach.

It might be possible to subvert my ISP's evil helpfulness by pointing my DNS 
requests further
upstream, but that might prevent the government from blocking my access to 
things it considers
distasteful, and I'm not sure I want to go there just yet.

Anyone have any suggestions or best practices?

Should I try to raise a PR against bsd.sites.mk or security/libgcrypt?

Cheers,

-- 
Andrew

___
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

net/tcpflow

[andrew clarke]

Maybe it would be useful to have a make config option to disable
cairo in the net/tcpflow port? The Cairo dependency pulls in about
twenty X11 libraries that I'd prefer not to install on my server.

This was my quick  dirty Makefile hack to disable Cairo:

--- Makefile.orig   2013-06-12 04:41:45.0 +1000
+++ Makefile2013-06-12 20:37:32.283320340 +1000
@@ -12,7 +12,7 @@
 LICENSE=   GPLv3
 
 BUILD_DEPENDS=
 ${LOCALBASE}/include/boost/icl/interval.hpp:${PORTSDIR}/devel/boost-libs
-LIB_DEPENDS=   cairo:${PORTSDIR}/graphics/cairo
+#LIB_DEPENDS=  cairo:${PORTSDIR}/graphics/cairo
 
 GNU_CONFIGURE= yes
 CPPFLAGS+= -I${LOCALBASE}/include

Thanks,

Regards
Andrew
___
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/tcpflow

[andrew clarke]

On Wed 2013-06-12 13:48:31 UTC+0200, Antoine Brodin (anto...@freebsd.org) wrote:

 Yes, cairo is needed to have a nice 1 page PDF summary.
 You can compile cairo with custom options if you don't want x11 etc.

Ah, you're right. I wasn't expecting that. That removes the dependency
count considerably. Thank you!
___
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/tcpflow

[andrew clarke]

On Wed 2013-06-12 22:38:47 UTC+1000, andrew clarke (m...@ozzmosis.com) wrote:

 Ah, you're right. I wasn't expecting that. That removes the dependency
 count considerably. Thank you!

Erm.

s/removes/lowers/

:-)
___
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: [HEADSUP] dialog4ports does not popup anymore only for global options

[Andrew W. Nosenko]

On Fri, Jun 7, 2013 at 9:58 PM, Chris Rees utis...@gmail.com wrote:
 On 7 June 2013 18:49, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote:
 On Fri, Jun 7, 2013 at 8:15 PM, Chris Rees utis...@gmail.com wrote:

 I can see your point when talking about DOCS, but for NLS it's insanity
 *for general use*.  Give me an example of where NLS non-globals are
 appropriate and I'll shut up.

 The GIMP in Russian locale.
 GNU Make in any non-English locale.

 I guess you mean the translations are bad?

Your guess is wrong.  For some reason you are treating NLS as black
and white thing.  Either completely enable, or completely disable.
Please, just belive that there are lot of grays in between.

But I'm completely against:
1. Poor or confusing translations (when easiest way to understand
something is to try to back-translate to English, or in some
pathological cases, start application in the English locale and match
UI elements by position);
2. Translations of tools, which are intended to or used to interact
with other tools, as opposed to the end users (GNU make, GCC, Git,
GnuPG are perfect examples)
3. Ports which do not provide the easy enough and consistent way to
disable NLS.  Just because it deprives me a way to workaround cases #1
and #2.

And the #3 is the reason, why I stand up in this thread.
I don't bother about popping-up dialogs.  After all, I'm not in a
business of rebuilding the whole ports tree from scratch every day.
And even a machine will wait my answer the whole night -- not a
problem.  Summary time required to build plus wasted time is
negligible in comparison to time spent in using application.
Therefore, the first thing, which I optimize, is a comfort of using
application, and other things are going only after that.

-- 
Andrew W. Nosenko andrew.w.nose...@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: [HEADSUP] dialog4ports does not popup anymore only for global options

[Andrew W. Nosenko]

On Fri, Jun 7, 2013 at 8:15 PM, Chris Rees utis...@gmail.com wrote:

 I can see your point when talking about DOCS, but for NLS it's insanity
 *for general use*.  Give me an example of where NLS non-globals are
 appropriate and I'll shut up.

The GIMP in Russian locale.
GNU Make in any non-English locale.

-- 
Andrew W. Nosenko andrew.w.nose...@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: [HEADSUP] dialog4ports does not popup anymore only for global options

[Andrew W. Nosenko]

On Fri, Jun 7, 2013 at 8:23 PM, Michael Gmelin free...@grem.de wrote:

 I was mostly talking about DOCS, I (poorly) chose NLS as an additional
 example to show how multiple groups could work. Usually NLS is a
 true global option.

NLS is global option only for people with en_* locale, who, therefore,
just don't see the pain produced by it.  DOCS are just a space on HDD.
 But localized names of image filters, tools  Co in GIMP -- it's just
a barrier to use books and other knowledge sources.  And I don't say
just about stupid eye-blow errors in translations, when results of
automatic merge went in the release and the wild without even fast
looking through by the someone, who has that language as native.

-- 
Andrew W. Nosenko andrew.w.nose...@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: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

[Andrew W. Nosenko]

On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
me...@bristol.ac.uk wrote:
 From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013

 On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer ger...@pfeifer.com 
 wrote:
  On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
  I've now run ia64 with the above change for over 2 weeks,
  mostly rebuilding ports, etc.
  I didn't see any issues with gcc47.
  So, from my very limited testing,
  gcc47 can be made default.
 
  Thanks for the feedback, Anton!  To really make that switch
  globally, we'll need more extensive testing, a full ports builds
  run, since there is a chance that some port you are not using may
  be broken, and I hope to get this done in the coming weeks.

 From my expiriense, devel/glib20 cannot be compiled with gcc47.

 Isn't it built with the system default compiler:

 configure:3954: checking for C compiler version
 configure:3963: cc --version 5
 cc (GCC) 4.2.1 20070831 patched [FreeBSD]

 I think we are only talking about updating lang/gcc to 4.7.

By default -- yes, it is going to build with base gcc.  But topic and,
therefore, my reaction was about overriding compiler to be lang/gcc*
from ports and whether there are ports, which fail in that case.  At
least, as I understand it.

Now, why overriding the compiler for Glib seems important to me and
why I tried to do that:

Since
commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58
Author: Ryan Lortie de...@desrt.ca
Date:   Tue Oct 18 16:21:50 2011 -0400

gatomic: introduce G_ATOMIC_LOCK_FREE

glib atomics implementation depends on gcc predefined macro
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base
gcc-4.2 and on Clang (all version, at least at that time).

As consequence, we have a mutex-based implementation of atomics.
Building Glib using more modern GCC (e.g. gcc-4.7) would help, but
gnome-libtool hack prevents us from that.

See also:
Thread atomic ops broken on mac/xcode
https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00089.html

Gnome bugzilla #682818: atomic ops broken on mac/xcode
https://bugzilla.gnome.org/show_bug.cgi?id=682818

LLVM/Clang bugzilla #11174: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_
http://llvm.org/bugs/show_bug.cgi?id=11174

-- 
Andrew W. Nosenko andrew.w.nose...@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: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

[Andrew W. Nosenko]

On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger
mezz.free...@gmail.com wrote:
 On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
 andrew.w.nose...@gmail.com wrote:
 On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
 me...@bristol.ac.uk wrote:
 From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013

 On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer 
 ger...@pfeifer.com wrote:
  On Mon, 25 Mar 2013, Anton Shterenlikht wrote:
  I've now run ia64 with the above change for over 2 weeks,
  mostly rebuilding ports, etc.
  I didn't see any issues with gcc47.
  So, from my very limited testing,
  gcc47 can be made default.
 
  Thanks for the feedback, Anton!  To really make that switch
  globally, we'll need more extensive testing, a full ports builds
  run, since there is a chance that some port you are not using may
  be broken, and I hope to get this done in the coming weeks.

 From my expiriense, devel/glib20 cannot be compiled with gcc47.

 Isn't it built with the system default compiler:

 configure:3954: checking for C compiler version
 configure:3963: cc --version 5
 cc (GCC) 4.2.1 20070831 patched [FreeBSD]

 I think we are only talking about updating lang/gcc to 4.7.

 By default -- yes, it is going to build with base gcc.  But topic and,
 therefore, my reaction was about overriding compiler to be lang/gcc*
 from ports and whether there are ports, which fail in that case.  At
 least, as I understand it.

 Now, why overriding the compiler for Glib seems important to me and
 why I tried to do that:

 Since
 commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58
 Author: Ryan Lortie de...@desrt.ca
 Date:   Tue Oct 18 16:21:50 2011 -0400

 gatomic: introduce G_ATOMIC_LOCK_FREE

 glib atomics implementation depends on gcc predefined macro
 __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base
 gcc-4.2 and on Clang (all version, at least at that time).

 As consequence, we have a mutex-based implementation of atomics.
 Building Glib using more modern GCC (e.g. gcc-4.7) would help, but
 gnome-libtool hack prevents us from that.

 Did you install all ports with GCC 4.7? If you install libtool with
 foo compiler then install other ports with bar compiler will be
 broken. You have to reinstall libtool with the bar compiler to make
 other ports with bar compiler works.

No, I should not do that (of course if assume that port machinery
doesn't interfere with configure results by discarding part of them).

libtool script is a _generated_ thing when used with autoconf.
'configure' does some checks (including how to execute linker
depending on used languages) and generates the current libtool sript
using these results.  This generated script has nothing with
/usr/local/bin/libtool.  Moreover, the system-wide libtool has no
business there, not used and may be completely absent until you want
regenerate and replace all package-supplied tools by your copy by
something like 'autoreconf -f'.

As you can see, under proper workflow, there no dependency, which
version of compiler was installed or used on the time of
/usr/local/bin/libtool generation.  All knowledge about currently used
language, compiler, linker abelities and so on are gatchered by
configure and written into local package-specific libtool script (in
contrast to the global /usr/local/bin/libtool).

The only one problem that ports machinery decides to trow out these
results and use own copy, which know nothing about actual package
preferences, needs, nor used language.


 See also:
 Thread atomic ops broken on mac/xcode
 https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00089.html

 Gnome bugzilla #682818: atomic ops broken on mac/xcode
 https://bugzilla.gnome.org/show_bug.cgi?id=682818

 LLVM/Clang bugzilla #11174: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_
 http://llvm.org/bugs/show_bug.cgi?id=11174



-- 
Andrew W. Nosenko andrew.w.nose...@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