Re: Poudriere Haskell ports Options changed, deleting every time
On 21/05/2014 04:30, J David wrote: Whenever I build a ports list with Haskell modules in it, poudriere insists on rebuilding those Haskell modules every time, claiming the options have changed. The options haven't changed; it will happily report this even if run twice in a row on a system with no other activity in between: [...] Does anyone have any idea where I should look to figure this out? Is there a way to manually see what the before and after options are that poudriere is looking at to determine that something has changed? Try CHECK_CHANGED_OPTIONS=verbose in /usr/local/etc/poudriere.conf ? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk signature.asc Description: OpenPGP digital signature
Re: lang/gcc and tmpfs no space let on device
On Fri, May 16, 2014 at 02:43:09PM +0200, Marko Cupa?? wrote: Hi, I am using 10.0-RELEASE-p3 amd64, and am trying to build lang/gcc as a dependency for emulators/virtualbox-ose. Building fails giving the following messages: jc1: fatal error: error writing to /tmp/ccwgXZ8m.s: No space left on device compilation terminated. gmake[5]: *** [javax/crypto/spec.lo] Error 1 gmake[5]: *** Waiting for unfinished jobs [...] I am using 128mb tmpfs file system mounted at /tmp: tmpfs /tmp tmpfs rw,size=128m,mode=1777 0 0 tmpfs-backed WRKDIR is certainly possible with lang/gcc* ports, albeit I'm not sure if 128MB is enough. However, normally I never limit tmpfs size, but try to provide sufficient swap space. That said, I observed similar no space left on device errors even on a box with 16GB of RAM when building lang/gcc *with default options*, which includes JAVA. Does anyone know how big /tmp do I need to have in order to compile lang/gcc successfully? I always patch all lang/gcc* ports locally like this: -OPTIONS_DEFAULT_i386=JAVA -OPTIONS_DEFAULT_amd64= JAVA +#OPTIONS_DEFAULT_i386= JAVA +#OPTIONS_DEFAULT_amd64= JAVA It allows to use tmpfs-backed storage of sane sizes to build them. I once wondered why is JAVA in the defaults anyways; someone gave me the reason, which I cannot remember right now. ./danfe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: archivers/rpm5 broken because: Does not package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=rpm5 portname: audio/aureal-kmod broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=aureal-kmod portname: audio/cowbell broken because: No more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=cowbell portname: audio/lastfm-desktop broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=lastfm-desktop portname: audio/ruby-esound broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-esound portname: audio/xmms-openspc broken because: does not build on FreeBSD 10.x and later build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=xmms-openspc portname: biology/p5-Bio-Graphics broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=p5-Bio-Graphics portname: biology/p5-bioperl broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=p5-bioperl portname: cad/alliance broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=alliance portname: cad/calculix broken because: Checksum and size mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=calculix portname: cad/p5-Verilog-Perl broken because: not staged build errors: http://beefy1.isc.freebsd.org/bulk/10i386-quarterly/latest/logs/errors/p5-Verilog-Perl-3.400.log ((not currently populated)) overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=p5-Verilog-Perl portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: chinese/tin broken because: Fails to patch build errors: http://beefy1.isc.freebsd.org/bulk/91i386-default/latest/logs/errors/zh-tin-2.2.1_6.log ((not currently populated)) overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=tin portname: comms/aldo broken because: Does not build with modern compilers build errors: http://beefy2.isc.freebsd.org/bulk/10amd64-quarterly/latest/logs/errors/aldo-0.7.5_2.log ((not currently populated)) overview: http://portsmon.FreeBSD.org/portoverview.py?category=commsportname=aldo portname:
FreeBSD unmaintained ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/cowbell broken because: No more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=cowbell portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: chinese/tin broken because: Fails to patch build errors: http://beefy1.isc.freebsd.org/bulk/91i386-default/latest/logs/errors/zh-tin-2.2.1_6.log ((not currently populated)) overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=tin portname: databases/flare broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=flare portname: databases/kinterbasdb broken because: Does not build with modern compilers build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=kinterbasdb portname: databases/msql broken because: Broken on FreeBSD 9+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=msql portname: databases/py-cmemcache broken because: Does not build with CLANG or GCC greater than 4.2 build errors: http://beefy2.isc.freebsd.org/bulk/10amd64-quarterly/latest/logs/errors/py27-cmemcache-0.95.log ((not currently populated)) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=py-cmemcache portname: databases/sqlrelay broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=sqlrelay portname: devel/clint broken because: fails to find python.h build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=clint portname: devel/fsmgenerator broken because: Fails to link build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=fsmgenerator portname: dns/ldapdns broken because: is gone - no public distfiles. port needs upgrade to version 3 (ldapdns.sourceforge.net) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=dnsportname=ldapdns portname: editors/p5-Padre broken because: not staged build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=editorsportname=p5-Padre portname: editors/textedit broken because: Does not link build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=editorsportname=textedit portname: editors/xemacs-devel-mule broken because: does not build on FreeBSD 9.X build errors: none. overview:
FreeBSD unmaintained ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: databases/py-cmemcache description:Python API for memcached, a distributed memory cache daemon maintainer: po...@freebsd.org status: BROKEN deprecated because: Deprecated upstream expiration date:2014-06-12 build errors: http://beefy2.isc.freebsd.org/bulk/10amd64-quarterly/latest/logs/errors/py27-cmemcache-0.95.log ((not currently populated)) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=py-cmemcache portname: databases/py-simplecouchdb description:Simple Library to Allow Python Applications to Use CouchDB maintainer: po...@freebsd.org deprecated because: Obsolete, abandoned expiration date:2014-07-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=py-simplecouchdb portname: devel/bzapi description:Bugzilla REST API maintainer: po...@freebsd.org deprecated because: Bugzilla has a native REST API, see https://wiki.mozilla.org/BMO/REST expiration date:2014-06-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=bzapi portname: devel/clint description:Static source code checker for C++ maintainer: po...@freebsd.org status: BROKEN deprecated because: Broken for more than 6 months expiration date:2014-05-27 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=clint portname: german/bsdforen-firefox-searchplugin description:Firefox search plugins for the www.bsdforen.de board and wiki maintainer: po...@freebsd.org deprecated because: No longer works after forum software update expiration date:2014-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=bsdforen-firefox-searchplugin portname: german/bsdgroup-firefox-searchplugin description:Firefox search plugins for the www.BSDGroup.de board maintainer: po...@freebsd.org deprecated because: bsdgroup.de no longer seems to exist expiration date:2014-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=bsdgroup-firefox-searchplugin portname: lang/clisp description:A Common Lisp implementation maintainer: po...@freebsd.org deprecated because: development has ceased, not staged expiration date:2014-07-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=langportname=clisp portname: net-im/pidgin-facebookchat description:Facebook Chat for Pidgin maintainer: po...@freebsd.org deprecated because: obsolete, development has ceased, not staged expiration date:2014-07-27 build errors: http://beefy1.isc.freebsd.org/bulk/head-i386-default/latest/logs/errors/pidgin-facebookchat-1.69_2.log ((not currently populated)) overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=pidgin-facebookchat ___ 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 META: Installed files conflict between ports
W dniu 2014-05-21 03:53, Robert Backhaus pisze: The fact that those two ports install conflicting binaries isn't a problem. The problem is that you were allowed to install the second port. With mplayer, there is a correct CONFLICTS line in mplayer2, but does not appear to be one in mplayer. But both samba ports seem to have the correct CONFLICTS line, but that may have been fixed after you installed the port. Try installing security/openssl and sysutils/moreutils together - that is one fine example of naming collision. -- best regards, Lukasz Wasikowski ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports which are currently marked forbidden
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users about ports that are marked as forbidden in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of each port, including errors seen on the build farm, is included below. portname: devel/bugzilla40 forbidden because: no upstream fixes for CVE-2014-1517, see http://www.bugzilla.org/security/4.0.11/ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=bugzilla40 portname: devel/bugzilla42 forbidden because: no upstream fixes for CVE-2014-1517, see http://www.bugzilla.org/security/4.0.11/ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=bugzilla42 portname: net/ntp forbidden because: CVE-2013-5211 / VU build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=netportname=ntp portname: net/ntp-rc forbidden because: CVE-2013-5211 / VU build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=netportname=ntp-rc ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: audio/bonk description:Lossy/lossless audio compressor maintainer: na...@freebsd.org deprecated because: Obsolete experimental codec, use audio/flac or audio/wavpack expiration date:2014-07-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=bonk portname: audio/xmms-bonk description:XMMS input plugin to play bonk files maintainer: na...@freebsd.org deprecated because: Obsolete experimental codec, use audio/flac or audio/wavpack expiration date:2014-07-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=xmms-bonk portname: databases/py-cmemcache description:Python API for memcached, a distributed memory cache daemon maintainer: po...@freebsd.org status: BROKEN deprecated because: Deprecated upstream expiration date:2014-06-12 build errors: http://beefy2.isc.freebsd.org/bulk/10amd64-quarterly/latest/logs/errors/py27-cmemcache-0.95.log ((not currently populated)) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=py-cmemcache portname: databases/py-simplecouchdb description:Simple Library to Allow Python Applications to Use CouchDB maintainer: po...@freebsd.org deprecated because: Obsolete, abandoned expiration date:2014-07-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=py-simplecouchdb portname: devel/bugzilla40 description:Bug-tracking system developed by Mozilla Project maintainer: bugzi...@freebsd.org status: FORBIDDEN deprecated because: expiration date:2014-06-21 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=bugzilla40 portname: devel/bugzilla42 description:Bug-tracking system developed by Mozilla Project maintainer: bugzi...@freebsd.org status: FORBIDDEN deprecated because: expiration date:2014-06-21 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=bugzilla42 portname: devel/bzapi description:Bugzilla REST API maintainer: po...@freebsd.org deprecated because: Bugzilla has a native REST API, see https://wiki.mozilla.org/BMO/REST expiration date:2014-06-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=bzapi portname: devel/clint description:Static source code checker for C++ maintainer: po...@freebsd.org status: BROKEN deprecated because: Broken for more than 6 months expiration date:2014-05-27 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=clint portname: devel/glib-java description:Java wrapper GLib 2 maintainer: gn...@freebsd.org deprecated because: Unmaintained, outdated not depend on expiration date:2014-05-25 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=glib-java portname: devel/libgconf-java description:Java wrapper for GConf maintainer: gn...@freebsd.org deprecated because: Unmaintained, outdated not depend on expiration date:2014-05-25 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libgconf-java portname: devel/libglade-java description:Java wrapper for libglade maintainer: gn...@freebsd.org deprecated because: Unmaintained, outdated not depend on expiration date:2014-05-25 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libglade-java portname: dns/maradns1 description:DNS server with focus on security and simplicity maintainer: m...@freebsd.org deprecated because: MaraDNS 1
mail/postfix-current failing
[jakobbg@core2 /usr/ports/mail/postfix-current]$ sudo make distclean sudo make === Cleaning for postfix-base-2.12.20140507,4 === Deleting distfiles for postfix-base-2.12.20140507,4 === License IPL10 accepted by the user === Found saved configuration for postfix-base-2.12.20140507,4 === postfix-base-2.12.20140507,4 depends on file: /usr/local/sbin/pkg - found = postfix-2.12-20140507.tar.gz doesn't seem to exist in /usr/ports/distfiles/postfix. = Attempting to fetch ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/postfix-2.12-20140507.tar.gz postfix-2.12-20140507.tar.gz 100% of 3940 kB 1263 kBps 00m03s = postfix-2.8.0-libspf2-1.2.x-0.patch.gz doesn't seem to exist in /usr/ports/distfiles/postfix. = Attempting to fetch http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/mm/postfix-2.8.0-libspf2-1.2.x-0.patch.gz postfix-2.8.0-libspf2-1.2.x-0.patch.gz100% of 8191 B 118 kBps 00m01s === Fetching all distfiles required by postfix-base-2.12.20140507,4 for building === Extracting for postfix-base-2.12.20140507,4 === License IPL10 accepted by the user === Found saved configuration for postfix-base-2.12.20140507,4 === postfix-base-2.12.20140507,4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by postfix-base-2.12.20140507,4 for building = SHA256 Checksum OK for postfix/postfix-2.12-20140507.tar.gz. = SHA256 Checksum OK for postfix/postfix-2.8.0-libspf2-1.2.x-0.patch.gz. === Patching for postfix-base-2.12.20140507,4 === Applying distribution patches for postfix-base-2.12.20140507,4 1 out of 2 hunks failed--saving rejects to src/global/mail_params.c.rej *** Error code 1 Stop. make[2]: stopped in /usr/ports/mail/postfix-current *** Error code 1 Stop. make[1]: stopped in /usr/ports/mail/postfix-current *** Error code 1 Stop. make: stopped in /usr/ports/mail/postfix-current -- Vyrdsamt, Jakob Breivik Grimstveit | +47 4829 8152 http://grimstveit.no/jakob ___ 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: Staging issue with staging of net-im/libpurple (libtool?)
On 20/05/2014 22:13, Tijl Coosemans wrote:
On Tue, 20 May 2014 08:52:46 -0700 Kevin Oberman wrote:
Removed the FIND and re-built. After the build I looked in
stage/usr/local/lib and the .so.0 files are still present! I then installed
with no errors. I'll admit that I don't understand what is happening or why
the touch of the files would break things, but it seems to be fixed, now.
The touch didn't always give all files the same timestamp so sometimes
make thought the configure script was out of date and regenerated it
erasing any patches that had been applied to it.
I figure something like:
find FOO -exec touch {} +
would do the trick.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: firefox-29.0,1 -- dumps core
Ronald F. Guilmette wrote: Please allow me to clarify two things: 1) The exact set of build options that are needed in order to reproduce the crash I have reported are as follows: DBUS (enabled by default) GIO (enabled by default) GSTREAMER (enabled by default) ALSA (enabled by default) DEBUG Apparently enabling or disabling the LOGGING option makes no difference at all. The crash will arise (when broswing around on, e.g. www.newegg.com) as long as the DEBUG build-time option is enabled. 2) When built with DEBUG, Firefox is quite a bit more verbose than when it is built without that option. In particular, some text messages that Firefox writes to its stderr channel just before it segfaults appear to provide some indication of the reason why it elects to do so: ... XRE_main+0x0058 [/usr/local/lib/firefox/libxul.so +0x03348aa7] _start+0x0825 [/usr/local/bin/firefox +0x4935] _start+0x0c20 [/usr/local/bin/firefox +0x4d30] _start+0x008e [/usr/local/bin/firefox +0x419e] UNKNOWN 0x800696000 [79233] ###!!! ABORT: Should be tracking any image we're going to use!: 'mImageTracked', file /usr/ports/www/firefox/work/mozilla-release/layout/style/nsStyleStruct.h, line 208 Hit MOZ_CRASH() at /usr/ports/www/firefox/work/mozilla-release/memory/mozalloc/mozalloc_abort.cpp:30 Can anybody who knows their way around the Firefox code look into this further? I myself am not at all familiar with the code base of Firefox. ___ freebsd-ge...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-gecko To unsubscribe, send any mail to freebsd-gecko-unsubscr...@freebsd.org I have similar problem, but with seamonkey 2.26. Without checked DEBUG it works almost fine to say nothing about lightning that completely useless, today I've tried to build it with DEBUG wondering whether I'd find out why lightning shows me the finger, but I had crash dump at browser startup: % seamonkey (process:36402): GLib-CRITICAL **: void g_slice_set_config(GSliceConfig, gint64): assertion `sys_page_size == 0' failed [36402] WARNING: dependent window created without a parent: file /mnt/ssdtmp/mnt/mod_usr/head/www/seamonkey/work/comm-release/mozilla/toolkit/components/startup/nsAppStartup.cpp, line 650 ++DOCSHELL 0x81c02e800 == 1 [pid = 36402] [id = 1] ++DOMWINDOW == 1 (0x81a2c65b8) [pid = 36402] [serial = 1] [outer = 0x0] ++DOMWINDOW == 2 (0x81a2c6938) [pid = 36402] [serial = 2] [outer = 0x81a2c65b8] [36402] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /mnt/ssdtmp/mnt/mod_usr/head/www/seamonkey/work/comm-release/mozilla/layout/style/Loader.cpp, line 2137 [36402] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /mnt/ssdtmp/mnt/mod_usr/head/www/seamonkey/work/comm-release/mozilla/layout/style/Loader.cpp, line 2137 [36402] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /mnt/ssdtmp/mnt/mod_usr/head/www/seamonkey/work/comm-release/mozilla/layout/style/Loader.cpp, line 2137 [36402] WARNING: Asking for app status on a principal with an unknown app id: 'mAppId != nsIScriptSecurityManager::UNKNOWN_APP_ID', file /mnt/ssdtmp/mnt/mod_usr/head/www/seamonkey/work/comm-release/mozilla/caps/src/nsPrincipal.cpp, line 552 [36402] WARNING: OpenGL-accelerated layers are not supported on this system: file /mnt/ssdtmp/mnt/mod_usr/head/www/seamonkey/work/comm-release/mozilla/widget/xpwidgets/nsBaseWidget.cpp, line 900 [36402] ###!!! ASSERTION: You can't dereference a NULL nsRefPtr with operator-().: 'mRawPtr != 0', file ../../dist/include/nsAutoPtr.h, line 1048 Segmentation fault(core dumped) -- SY, Marat smime.p7s Description: S/MIME Cryptographic Signature
Re: Staging issue with staging of net-im/libpurple (libtool?)
On Wed, 21 May 2014 11:26:57 +0200 Dominic Fandrey wrote:
On 20/05/2014 22:13, Tijl Coosemans wrote:
On Tue, 20 May 2014 08:52:46 -0700 Kevin Oberman wrote:
Removed the FIND and re-built. After the build I looked in
stage/usr/local/lib and the .so.0 files are still present! I then installed
with no errors. I'll admit that I don't understand what is happening or why
the touch of the files would break things, but it seems to be fixed, now.
The touch didn't always give all files the same timestamp so sometimes
make thought the configure script was out of date and regenerated it
erasing any patches that had been applied to it.
I figure something like:
find FOO -exec touch {} +
would do the trick.
No, that would run a separate touch for every file. The touch command
just needs an explicit time (with -r or -t flag).
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ audio/sooperlooper | 1.7.0 | 1.7.2 +-+ devel/p5-Object-Enum| 0.072 | 0.073 +-+ devel/smake | 1.2.3 | 1.2.4 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
databases/qdbm fails
Hello, databases/qdbm port fails to build on 9.2 amd64, see attached log. I would guess it ignores CFLAGS. Best regards Andreas qdbm-1.8.78_1.log 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
Disappearing programs: Is FreeBSD ports unmaintained?
Hi, the programs star and smake seem to have disappeared from the FreeBSD ports collection. The supposed reason is: no longer compiles but it seems that the real reason is that somebody did modify the build system in a way that harms portability and this way caused a FreeBSD change (introducing the compiler clang that causes compatibilty problems) to be the reason for a package that no longer compiles. Isn't it obvious to check more recent version of the sources and to check whether _unmodified_ sources compile before removing software from the collection? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ 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
[QAT] 354749: 4x leftovers
Update distinfo since the DESCRIPTION file was updated when the module was marked as orphaned - Build ID: 20140521124600-3594 Job owner: skreu...@freebsd.org Buildtime: 16 minutes Enddate: Wed, 21 May 2014 13:02:15 GMT Revision: 354749 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=354749 - Port:math/R-cran-sspir 0.2.10_3 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~skreu...@freebsd.org/20140521124600-3594-335690/R-cran-sspir-0.2.10_3.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~skreu...@freebsd.org/20140521124600-3594-335691/R-cran-sspir-0.2.10_3.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~skreu...@freebsd.org/20140521124600-3594-335692/R-cran-sspir-0.2.10_3.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~skreu...@freebsd.org/20140521124600-3594-335693/R-cran-sspir-0.2.10_3.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140521124600-3594 redports https://qat.redports.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Poudriere Haskell ports Options changed, deleting every time
On Wed, May 21, 2014 at 2:07 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: Try CHECK_CHANGED_OPTIONS=verbose in /usr/local/etc/poudriere.conf ? Great suggestion, thanks! With just one Haskell port, hs-text, here's what happens: Calculating ports order and dependencies Sanity checking the repository Options changed, deleting: hs-text-0.11.3.1_4.txz Pkg: DYNAMIC New: DOCS DYNAMIC Deleting stale symlinks Running bulk devel/hs-text twice in a row produces the above result both times. After doing poudriere options -c devel/hs-text and clearing the DOCS option, poudriere stopped trying to rebuild it. Doing the same for the rest of the Haskell modules resolved the issue completely. So somehow if the DOCS option is enabled, it isn't making it from the config to the package, so poudriere keeps trying to rebuild to pick it up. It looks like the underlying lang/ghc package did not have DOCS enabled. So it seems like this was overriding the individual modules' DOCS option and creating the discrepancy. Probably there is some widget in the lang/ghc package that's needed to build the documentation. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Disappearing programs: Is FreeBSD ports unmaintained?
Dear Joerg, The only problem is that if such port is unmaintained (its maintainer email address is po...@freebsd.org) there's no one who could do such thing, because commiters are busy working on the entire ports tree, and apparently no one from maintainers was interested in the port to do so. If you are, submit a PR with setting yourself as a maintainer, and then you can take care of the ports updates and adjustment to changing and evolving ports tree. Regards, BL On Wed, May 21, 2014 at 2:55 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Hi, the programs star and smake seem to have disappeared from the FreeBSD ports collection. The supposed reason is: no longer compiles but it seems that the real reason is that somebody did modify the build system in a way that harms portability and this way caused a FreeBSD change (introducing the compiler clang that causes compatibilty problems) to be the reason for a package that no longer compiles. Isn't it obvious to check more recent version of the sources and to check whether _unmodified_ sources compile before removing software from the collection? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
bsd.emacs.mk does not detect non-GUI, non-X11 options
All of my freebsd boxes are headless, and I build all ports without X11. To accomplish this, I specify in make.conf the following: WITHOUT_GNOME=yes WITHOUT_X11=yes OPTIONS_UNSET=X11 GUI I have to specify both WITHOUT_X11 and OPTIONS_UNSET since I have found some ports to not honor OPTIONS_UNSET yet. So now I'm moving from individually building ports on each server to using poudriere and pkgng to build packages customized for my environment. This is where I run into problems... One of the packages I need to build is textproc/markdown-mode.el. This port specifies USE_EMACS in the Makefile. When I build this port on a system which has emacs-nox11 installed, all is fine. WhenI try to build this port inside poudriere, it wants to build emacs24 as a dependency. Thus, the package for markdown-mode.el will install emacs instead of using emacs-nox11. Is there some way to convince markdown-mode.el to depend on emacs-nox11 instead when building the packages via poudriere? I don't even see how to explicitly state the dependency outside of poudriere. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
LandR Launch
Good afternoon I wanted to get in touch and let you know we just launched LandR which is the worlds first intelligent online mastering service. It's a spectral analysis system that listens to music and detects detailed features in the audio signals to give a studio-quality master. Here's a link for more www.landr.com Would love to hear your feedback! best Reed Reed Thomas Lawrence | Artist Relationships Manager Intelligent Audio Tools 615.200.8107 | rlawre...@mixgenius.com www.mixgenius.com www.landr.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: Done with this port
On 05/20/14 22:10, Matthias Andree wrote: Am 21.05.2014 03:49, schrieb Paul Schmehl: Thanks. With some of my ports I have been really struggling trying to get staging working. I'd be very interested to see what you did, since it was apparently easy for you to do. A bit of experience with packaging helped indeed. The differences are visible in this automated message: http://lists.freebsd.org/pipermail/svn-ports-head/2014-May/058212.html The INSTALL_TARGET that sets the INSTALL_ROOT (supported by iwidget's Makefile) is useful, and more help (for the MANN conversion) is available on the FreeBSD Wiki: http://wiki.freebsd.org/ports/StageDir/ ___ 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 Mathias, I think that brief description of how you did this would be VERY useful to some of us looking at this problem and not knowing where to start. Perhaps an: 'this is the way it was' and a 'this is the way it should be' document would be good. Or even a list of links to 'helpful hints' documents. Thanks! I really appreciate your efforts on the ports and packages ___ 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: Done with this port
On Wed, 21 May 2014 14:58:32 -0700 Patrick Powell papow...@astart.com wrote: Mathias, I think that brief description of how you did this would be VERY useful to some of us looking at this problem and not knowing where to start. Perhaps an: 'this is the way it was' and a 'this is the way it should be' document would be good. Or even a list of links to 'helpful hints' documents. Looking at already-done ports is good. Someone has kindly done one of mine for me so I did a diff on that. Pretty simple example but gives you the idea. FWIW, the port in question is textproc/ml1 ___ 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: Poudriere Haskell ports Options changed, deleting every time
2014-05-21 17:24 GMT+02:00 J David j.david.li...@gmail.com: Probably there is some widget in the lang/ghc package that's needed to build the documentation. Yes, there is. That is called Haddock, the documentation tool similar to Javadoc and Doxygen. Since it parses the same source code as the compiler itself, and the compiler tends to change quickly, they both come in the same package. Disabling the documentation disables the haddock tool, so the dependent Haskell Cabal packages cannot generate their documentation. ___ 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: Done with this port
Bob Eager wrote: On Wed, 21 May 2014 14:58:32 -0700 Patrick Powell papow...@astart.com wrote: Mathias, I think that brief description of how you did this would be VERY useful to some of us looking at this problem and not knowing where to start. Perhaps an: 'this is the way it was' and a 'this is the way it should be' document would be good. Or even a list of links to 'helpful hints' documents. Looking at already-done ports is good. Someone has kindly done one of mine for me so I did a diff on that. Pretty simple example but gives you the idea. FWIW, the port in question is textproc/ml1 Just as a comment to this - I did my first the other day and most of my time spent trying to decipher the messages of how to make them 'go away' ... First was the fact I couldn't seem to find any documentation on pkg-plist - what it is, what should be in it etc... Second was the 'Orphaned' vs 'Missing' messages - especially as I had followed the docs and couldn't (for 12 hours) find the fact that putting in PORTDOCS settings you remove the corresponding entries in the pkg-plist file... That all said - I don't know how one would make it easier to 'get' as most of the docs are very explicit.. with the exception of documenting pkg-plist (or making it googleable.) my $0.02.. ;-) -- Michelle Sullivan http://www.mhix.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Done with this port
Am 21.05.2014 23:58, schrieb Patrick Powell: Mathias, I think that brief description of how you did this would be VERY useful to some of us looking at this problem and not knowing where to start. Perhaps an: 'this is the way it was' and a 'this is the way it should be' document would be good. Or even a list of links to 'helpful hints' documents. Thanks! I really appreciate your efforts on the ports and packages As much as I'd like to do that, my trouble is that if one (meaning I in this particular case) has accumulated a certain amount of experience with common staging failure patterns, it becomes hard to tell what newcomers will stumble about or not. So for me the initial thing was to go check if the package had some staging support already, and it had - the iwidgets Makefile (not the port's, but the one that gets unpacked) prefixes all installations with $(INSTALL_ROOT) or similar, and that's what I leveraged. The rest were minor cleanups AFAIR. Feel free to ask more questions on the diff of the why did you... or how did you come to do this particular change (quote the relevant part). HTH ___ 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
