Re: how to include m4 macros stored in m4 folder of port's sources?
On Sat, 2013-05-25 at 01:00 -0500, Scot Hetzel wrote: > On Fri, May 24, 2013 at 1:51 PM, O. Hartmann > wrote: > > The sources of of port provide their own m4 macros (i.e. AX_PTHREAD, > > AX_BOOST) store in ax_boost.m4 in m4 of the toplevel dir of the sources. > > > > I have to issue USE_AUTOTOOLS= aclocal autoheader libtoolize libtool > > autoconf automake to create the proper configure file. > > > > The configure file fails with an error of a missing macro, in particular > > AX_BOOST([]) which is present in the m4 folder and as far as I know, it > > should be addressed with libtool. > > > > I can not find any useful information within the porter's handbook about > > this very common case of having pristine autotool environments and how > > to handle them. > > > > My question in specific is: what is the tag/sequence in the toplevel > > Makefile to endure that macros stored in the m4-folder of the sources > > are loaded automatically? When issuing the > > aclocal-autoheader-libtoolize-autoconf-automake chain in the source > > folder, everything works fine except the fact that the FreeBSD specific > > environment variables are not set. > > > > Please CC me, I do not subscribe this list. > > > > Regards and thanks in advance, > > Oliver > > Have a look at Mk/bsd.autotools.mk for the variables that you can define: > > http://svnweb.freebsd.org/ports/head/Mk/bsd.autotools.mk > Thank you very much. Found the knob. Oliver signature.asc Description: This is a digitally signed message part
Re: The vim port needs a refresh
On 24 May 2013 22:23, Kenta Suzumoto wrote:
>
> Hello all. The editors/vim port is currently a mess and needs some changes.
>
> - It fetches almost 700 patches from what seems like a dial-up connection in
> AUSTRALIA.
>
> You might as well be downloading a 1080p movie from a rock in the north pole,
> because that's about how fast it is.
> This can be very easily avoided by putting all the patches into a single
> tarball and hosting it anywhere decent. I've
> seen someone in ##freebsd on freenode handing out a tarball with all the
> patches many times, and everyone asks
> "why isn't this the default? why is some random guy giving me distfiles?"
> etc. Seems like a no-brainer.
>
> - By default, it builds lots of gui stuff that certainly almost no one wants
>
> It almost seems like the vim-lite port should be renamed vim and the vim port
> should be renamed gvim. I had to
> google to come up with this solution, because I can't even disable that stuff
> in "make config" (another problem!)
>
> .if ${.CURDIR}=="/usr/ports/editors/vim"
> WITH_VIM_OPTIONS=yes
> WITHOUT_X11=yes
> .endif
>
> People shouldn't have to find this hack to be able to install vim normally
> (and no, telling them to use vim-lite isn't normal).
> I'm surprised that none of these changes have been made yet. I've heard it's
> "because the maintainer won't listen to reason"
> but I have no way to know if that's the case or not. I also heard bapt@ had
> an optionsNG patch that he wouldn't
> integrate into the port for some reason. Please, let's get this stuff fixed
> once and for all. None of it requires a large amount
> of work on anyone's part.
I'm very sad to talk of a fellow developer like this, but I'm afraid
the maintainer of vim is a contrarian who thinks he knows better than
everyone else on the matter.
For years, people have been begging him to get over his fear of
OPTIONS, and he sits in the way of progress against almost everyone's
wishes.
He has also impeded progress on the bash port, resulting in the
ridiculous situation where we now have two bash ports, where one will
do. For historical reasons, people seem reluctant to confront him
about this, and he ignores all attempts to reason about it.
It's far beyond time to remove David O'Brien from MAINTAINER lines--
he doesn't do the job properly anyway; several PRs he's timed out on
for his ports:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177597
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/174965
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175447
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/178462
Last time I timed him out on a PR I was subjected to a tirade from
him, with questionable justification, but I may process these too when
I have time.
Alternatively, perhaps we need an editors/vim-options port
Chris
___
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: The vim port needs a refresh
On 05/25/13 10:50, Chris Rees wrote: > > Alternatively, perhaps we need an editors/vim-options port Just for the record, editors/vim was (and shells/bash) was converted to optionsNG not too long ago. Regards! -- Niclas ___ 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: The vim port needs a refresh
On 25 May 2013 11:54, Niclas Zeising wrote: > On 05/25/13 10:50, Chris Rees wrote: >> >> Alternatively, perhaps we need an editors/vim-options port > > Just for the record, editors/vim was (and shells/bash) was converted to > optionsNG not too long ago. Ah, that's at least some good news. I notice that it was on yet another maintainer timeout, so that criticism stands. It appears that David is no longer interested. Chris ___ 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: The vim port needs a refresh
On 5/25/2013 13:24, Chris Rees wrote: On 25 May 2013 11:54, Niclas Zeising wrote: On 05/25/13 10:50, Chris Rees wrote: Alternatively, perhaps we need an editors/vim-options port Just for the record, editors/vim was (and shells/bash) was converted to optionsNG not too long ago. Ah, that's at least some good news. I notice that it was on yet another maintainer timeout, so that criticism stands. It appears that David is no longer interested. FWIW, the default on the vim port have taken the dports users by surprise. I've gotten several complaints about the boatload of ports that get sucked in (and the amount of bandwidth it requires) by vim. They didn't know vim-lite existed. I agree the default should be "light" and the kitchen sink version should be explicitly requested (if two ports are indeed needed for pre-built binary reasons). John ___ 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: The vim port needs a refresh
Am 25.05.2013 13:28, schrieb John Marino: > On 5/25/2013 13:24, Chris Rees wrote: >> On 25 May 2013 11:54, Niclas Zeising wrote: >>> On 05/25/13 10:50, Chris Rees wrote: Alternatively, perhaps we need an editors/vim-options port >>> >>> Just for the record, editors/vim was (and shells/bash) was converted to >>> optionsNG not too long ago. >> >> Ah, that's at least some good news. I notice that it was on yet >> another maintainer timeout, so that criticism stands. >> >> It appears that David is no longer interested. > > FWIW, the default on the vim port have taken the dports users by > surprise. I've gotten several complaints about the boatload of ports > that get sucked in (and the amount of bandwidth it requires) by vim. > They didn't know vim-lite existed. > > I agree the default should be "light" and the kitchen sink version > should be explicitly requested (if two ports are indeed needed for > pre-built binary reasons). I routinely install vim-lite on FreeBSD, and move on. Yes, it may surprise first-time users, but either you have the GUI stuff installed anyways and don't care, or you get into the habit of installing vim-lite on headless and otherwise low-end machines. Frequent timeouts are a reason to reset the maintainer, though. We have policies for that, and we have been re-rolling distributions all the way, from SVN repos, or Github, for example, so why bother. As to the patch hosting, if some port fails and we modified it in any way, we're the first contact of the end user anyhow to pre-filter between what we've botched, and what needs forwarding upstream -- and there should be plenty of vim mirrors around -- perhaps a case to deploy phttpget for bulk fetching of a thousand patches from HTTP-based mirrors. Oh, and look at how snappy portsnap has become on -HEAD. Not sure what it does differently than 9.1-REL, but it sure feels a lot snappier. If that's not phttpget we should consider if we can leverage that. ___ 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: The vim port needs a refresh
One more thing: I see patches up to 7.3.1012 on http://ftp.vim.ossmirror.de/pub/vim/patches/7.3/ So much for the "won't reach 1,000". :-) ___ 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/mtr broken without ipv6
> I build my custom kernel without IPv6 since I'm not going to be using > it any time soon. The mtr port doesn't work anymore > What can I do to fix this without enabling a useless (to me) option in my > kernel and rebuilding? Downgrade the mtr port to mtr-nox11-0.82_1. I update ports tree with `portsnap` and use `svn export` (devel/subversion port) for downgrading a single port. How to learn the revision for downgrading: svn log svn://svn0.us-east.freebsd.org/ports/head/net/mtr | less How to downgrade: rm -rf /usr/ports/net/mtr svn export -r r300897 svn://svn0.us-east.freebsd.org/ports/head/net/mtr /usr/ports/net/mtr portupgrade -f mtr\* ___ 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 +-+ biology/tinker | 6.2.04 | 6.2.05 +-+ devel/gecode| 3.7.3 | 4.1.0 +-+ 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 If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org 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: audio/libsamplerate builds but fails to install
And now (after updates) it fails to build as well: Configuration summary : Version : . 0.1.8 Host CPU : amd64 Host Vendor : . portbld Host OS : . freebsd10.0 Tools : Compiler is GCC : . yes GCC major version : ... 4 Extra tools required for testing and examples : Use FFTW : no Have libsndfile : . yes Installation directories : Library directory : ... /usr/local/lib Program directory : ... /usr/local/bin Pkgconfig directory : . /usr/local/lib/pkgconfig Compiling some other packages against libsamplerate may require the addition of "/usr/local/lib/pkgconfig" to the PKG_CONFIG_PATH environment variable. ===> Building for libsamplerate-0.1.8_3 make: don't know how to make /asp/obj/asp/obj/asp/git/ports/audio/libsamplerate/work/libsamplerate-0.1.8/work/.build_done.libsamplerate._usr_local. Stop make: stopped in /asp/obj/asp/git/ports/audio/libsamplerate/work/libsamplerate-0.1.8 *** Error code 2 Stop. - 10-Current-amd64-using ccache-portstree merged with marcuscom.gnome3 & xorg.devel -- View this message in context: http://freebsd.1045724.n5.nabble.com/audio-libsamplerate-builds-but-fails-to-install-tp5814138p5814958.html Sent from the freebsd-ports mailing list archive at Nabble.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: graphics/libfpx poudriere vs host env conflict
Problem is on-going, but with different error message in poudriere logs: === ===> Building for libfpx-1.3.1.1 Warning: Object directory not changed from original /wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1 g++46 -O2 -pipe -march=k8 -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -fstack-protector -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -fno-rtti -fno-exceptions -fno-strict-aliasing -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/oless/h -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/jpeg -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/ole -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/basics -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/ri_image -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/oless -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/fpx -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/. -I/usr/local/include -D_UNIX -c /wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/fpx/filter.cpp -o filter.o g++46 -O2 -pipe -march=k8 -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -fstack-protector -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -fno-rtti -fno-exceptions -fno-strict-aliasing -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/oless/h -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/jpeg -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/ole -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/basics -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/ri_image -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/oless -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/fpx -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/. -I/usr/local/include -D_UNIX -c /wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/fpx/coltwist.cpp -o coltwist.o g++46 -O2 -pipe -march=k8 -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -fstack-protector -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -fno-rtti -fno-exceptions -fno-strict-aliasing -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/oless/h -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/jpeg -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/ole -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/basics -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/ri_image -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/oless -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/fpx -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/. -I/usr/local/include -D_UNIX -c /wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/fpx/fpximgvw.cpp -o fpximgvw.o g++46 -O2 -pipe -march=k8 -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -fstack-protector -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -fno-rtti -fno-exceptions -fno-strict-aliasing -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/oless/h -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/jpeg -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/ole -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/basics -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/ri_image -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/oless -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/fpx -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/. -I/usr/local/include -D_UNIX -c /wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/fpx/imginfio.cpp -o imginfio.o g++46 -O2 -pipe -march=k8 -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -fstack-protector -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -fno-rtti -fno-exceptions -fno-strict-aliasing -DHAVE_WCHAR_H -DHAVE_DLFCN_H -DHAVE_SYS_TIME_H -DHAVE_SYS_PARAM_H -DHAVE_SYS_MOUNT_H -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/oless/h -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/jpeg -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/ole -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/basics -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/ri_image -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/oless -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-1.3.1-1/fpx -I/wrkdirs/usr/ports/graphics/libfpx/work/libfpx-
audio/nas fails in poudriere due to imake gcpp problem
imake needs link to cpp to function correctly. It seems this error has not been corrected as yet: http://freebsd.1045724.n5.nabble.com/devel-imake-build-breaks-td5810289.html Which results in build fail for audio/nas in poudriere: ===> Configuring for nas-1.9.3 ===> FreeBSD 10 autotools fix applied to /wrkdirs/usr/ports/audio/nas/work/nas-1.9.3/config/aclocal.m4 ===> FreeBSD 10 autotools fix applied to /wrkdirs/usr/ports/audio/nas/work/nas-1.9.3/config/configure mv -f Makefile Makefile.bak imake -DUseInstalled -I/usr/local/lib/X11/config imake: No such file or directory imake: Cannot exec gcpp. Stop. imake: Exit code 1. Stop. /usr/bin/sed -i.bak -e 's:-fPIC:-fpic -DPIC:g' -e 's,-c \$(CCOPTIONS),-c $(CFLAGS),' -e 's,\(\$(AR) \$@ \$\)(OBJS),\1(OBJS:S|^|unshared/|),' /wrkdirs/usr/ports/audio/nas/work/nas-1.9.3/lib/audio/Makefile = === ===> Building for nas-1.9.3 make: don't know how to make all. Stop - 10-Current-amd64-using ccache-portstree merged with marcuscom.gnome3 & xorg.devel -- View this message in context: http://freebsd.1045724.n5.nabble.com/audio-nas-fails-in-poudriere-due-to-imake-gcpp-problem-tp5814963.html Sent from the freebsd-ports mailing list archive at Nabble.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"
[HEADS UP] xorg mega-update committed! (was: svn commit: r319055 ...)
HEADS UP! On 05/25/13 16:37, Niclas Zeising wrote: > Author: zeising > Date: Sat May 25 14:37:02 2013 > New Revision: 319055 > URL: http://svnweb.freebsd.org/changeset/ports/319055 > > Log: > The FreeBSD x11 team proudly presents > an zeising, kwm, miwi, bapt, eadler production: > > Xorg 7.7 > > Starring: > xserver 1.12.4 (new xorg only) > Mesa 8.0.4, including libGL, libGLU and dri (new xorg only) > libX11 1.5.0 > libxcb 1.9 > libdrm 2.4.42 (new xorg only) > freeglut 2.8.1 > Also starring: > Updates to drivers and other libraries and utilities > > Additional notes: > Change pkgconf to be a build dependency. > Add a new USE_XORG, xcb, to depend on libxcb and update all ports to use > this. > Trim makefile headers. > Take maintanership of x11/xcb-proto, ok'd by ashish. > If you are running WITH_NEW_XORG=, you need to rebuild all installed > drivers, see UPDATING for more information. > Various fixes to make ports compile. > > PR: ports/177942 > Exp-run by: miwi > Approved by:portmgr (miwi) > > Thanks to all who helped testing! I'm around to help out if there is any fallout, just mail me or ping me on IRC. Regards! -- Niclas Zeising signature.asc Description: OpenPGP digital signature
Re: net/mtr broken without ipv6
On Sat, May 25, 2013 at 5:21 AM, wrote: > > I build my custom kernel without IPv6 since I'm not going to be using > > it any time soon. The mtr port doesn't work anymore > > > What can I do to fix this without enabling a useless (to me) option in my > > kernel and rebuilding? > > Downgrade the mtr port to mtr-nox11-0.82_1. > I update ports tree with `portsnap` and use `svn export` > (devel/subversion port) for downgrading a single port. > How to learn the revision for downgrading: > > svn log svn://svn0.us-east.freebsd.org/ports/head/net/mtr | less > > How to downgrade: > > rm -rf /usr/ports/net/mtr > svn export -r r300897 > svn://svn0.us-east.freebsd.org/ports/head/net/mtr/usr/ports/net/mtr > portupgrade -f mtr\* > I don't see how downgrading will fix it unless this is a newly introduced bug, however you can also use ports-mgmt/portdowngrade. -jgh -- Jason Helfman | FreeBSD Committer j...@freebsd.org | http://people.freebsd.org/~jgh | The Power to Serve ___ 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/mtr broken without ipv6
> > > I build my custom kernel without IPv6 since I'm not going to be using > > > it any time soon. The mtr port doesn't work anymore > > Downgrade the mtr port to mtr-nox11-0.82_1. > > I update ports tree with `portsnap` and use `svn export` > > (devel/subversion port) for downgrading a single port. > I don't see how downgrading will fix it unless this is a newly introduced > bug It is. 0.82 works, 0.84 doesn't. https://bugs.launchpad.net/mtr/+bug/1130561 > however you can also use ports-mgmt/portdowngrade. portdowngrade also uses subversion, but not "export". I suspect that combination of portdowngrade with portsnap can cause problems. ___ 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/mtr broken without ipv6
On Sat, May 25, 2013 at 9:32 AM, wrote: > > > > I build my custom kernel without IPv6 since I'm not going to be using > > > > it any time soon. The mtr port doesn't work anymore > > > > Downgrade the mtr port to mtr-nox11-0.82_1. > > > > I update ports tree with `portsnap` and use `svn export` > > > (devel/subversion port) for downgrading a single port. > > > I don't see how downgrading will fix it unless this is a newly introduced > > bug > > It is. 0.82 works, 0.84 doesn't. > https://bugs.launchpad.net/mtr/+bug/1130561 > > Good to see they are aware of it, and seeking a fix. > > however you can also use ports-mgmt/portdowngrade. > > portdowngrade also uses subversion, but not "export". > I suspect that combination of portdowngrade with portsnap can cause > problems. > > Nothing has changed between cvs and svn. It is my understanding, and findings, that portsnap doesn't care either way and will clobber any changes that don't match the distributed portsnap snapshots. -jgh -- Jason Helfman | FreeBSD Committer j...@freebsd.org | http://people.freebsd.org/~jgh | The Power to Serve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
ports && 10-CURRENT
Hello, I'm compiling the ports I'm used to use (some 1200) on a 10-CURRENT r250588 (May 13 2013) and it seems that a lot of the ports are now broken, at least on recent 10-CURRENT; the ports tree itself is from SVN r315646 (April 1 2013); it compiled fine on an older 10-CURRENT from May 2012, but meanwhile the compiler in CURRENT changed to clang; the problems I'm facing mostly are: - a lot of qt4 ports do not compile with clang - all ports using devel/imake are broken now (see ports/178666) - a lot of kde3 ports do not compile anymore (well one could say, they are EOL, but KDE4 does not compile either due to the qt4 problems) - www/firefox does not compile - ... I'm not wining, but I do not know what to do now matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: g...@unixarea.de | - Never being an iSlave WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF in E-mail phone: +49-170-4527211 | - Respect for open standards ___ 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
On 05/25/13 20:56, Matthias Apitz wrote: > > Hello, > > I'm compiling the ports I'm used to use (some 1200) on a 10-CURRENT > r250588 (May 13 2013) and it seems that a lot of the ports are now > broken, at least on recent 10-CURRENT; the ports tree itself is from SVN > r315646 (April 1 2013); it compiled fine on an older 10-CURRENT from May > 2012, but meanwhile the compiler in CURRENT changed to clang; > > the problems I'm facing mostly are: > > - a lot of qt4 ports do not compile with clang > - all ports using devel/imake are broken now (see ports/178666) This is hopefully fixed by the big xorg update earlier today. > - a lot of kde3 ports do not compile anymore (well one could say, they > are EOL, but KDE4 does not compile either due to the qt4 problems) > - www/firefox does not compile > - ... Regards! -- Niclas Zeising ___ 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"
Another Firefox 21.0 crash
I'm seeing a repeatable, consistent segmentation fault before the first window appears (though firefox -ProfileManager brings up the profile manager, but crashes when I try to actually start the browser). I've deleted ~/.mozilla and just about everything I can think to get rid of. The system is a 9.1 i386 system: FreeBSD ylum.lunabase.org 9.1-STABLE FreeBSD 9.1-STABLE #28 r250528: Sat May 11 17:19:54 PDT 2013 r...@ylum.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386 Firefox is built under the most recent clang port. Firefox options are all the defaults (make rmconfig). I rebuilt all the ports from scratch within the last week. I've attached a gdb trace from just running the firefox binary under gdb. I'm not sure I believe it, but clues are scarce on the ground. I can get a ktrace if it will help. Let me know if you have any suggestions. -- http://www.lunabase.org/~faber Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG ylum:~$ firefox Multiple segmentation faults occurred; can't display error dialog ylum:~$ gdb `which firefox` 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 "i386-marcel-freebsd"...(no debugging symbols found)... (gdb) run Starting program: /usr/local/bin/firefox (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100663] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 28501080 (LWP 100663/firefox)] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols fo
Re: [HEADS UP] xorg mega-update committed! (was: svn commit: r319055 ...)
Is it still possible to get hardware acceleration with the radeon driver for cards which use UMS? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] xorg mega-update committed!
On 05/26/13 02:55, Warren Block wrote: > Is it still possible to get hardware acceleration with the radeon driver > for cards which use UMS? With the new xserver (1.12) it is not possible currently, it seems. I haven't tested the old server. Hopefully the ATI KMS work will be ready for testing in the not so distant future. Regards! -- Niclas Zeising ___ 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/mtr broken without ipv6
(I'm not subscribed to this list so keep me CC'd) Re: http://lists.freebsd.org/pipermail/freebsd-ports/2013-May/083766.html I've already discussed this before -- with you in fact -- and did the full analysis. Users should read it in full: http://lists.freebsd.org/pipermail/freebsd-ports/2013-March/082144.html I also CC'd the port maintainer on that Email, who did not respond. Proof of that: > From: Jeremy Chadwick > To: s...@tormail.org > Date: Fri, 15 Mar 2013 21:32:14 -0700 > Cc: sunp...@freebsd.org, freebsd-ports@freebsd.org > Subject: Re: net/mtr failed to build I am now CC'ing portmgr@ due to negligence. FreeBSD Ports Management Team: Please read my analysis (March mail above). TL;DR version: This port needs to be reverted to 0.82. I will not mince words: mtr 0.84 is a complete clusterfuck on all BSDs, including OS X. It should be nuked from orbit. As stated in my March Email, while there are fixes in the official mtr github repo for all of this nonsense, but figuring out which fixes/commits is time-consuming and honestly not worth it given the massive scale of breakage (as I said, it affects all BSDs). Please see that this port is rolled back to 0.82 (specifically reverting r213277). I believe PORTREVISION should also be set to 2 when rolling back, because there have been other Makefile changes between 0.82 PORTREVISION=1 and now (specifically r316355). Verification: http://svnweb.freebsd.org/ports/head/net/mtr/Makefile?r1=300897&r2=314277 http://svnweb.freebsd.org/ports/head/net/mtr/Makefile?r1=314277&r2=316355 Thank you. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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/mtr broken without ipv6
On Sat, May 25, 2013 at 11:40:05PM -0700, Jeremy Chadwick wrote: > Please see that this port is rolled back to 0.82 (specifically reverting > r213277). I believe PORTREVISION should also be set to 2 when rolling > back, because there have been other Makefile changes between 0.82 > PORTREVISION=1 and now (specifically r316355). Verification: You know what pisses me off more than the mtr authors not properly testing their software on all platforms before release? When I somehow completely botch SVN revision numbers. :/ The first line of my quoted paragraph SHOULD have read: "Please see that this port is rolled back to 0.82 (specifically reverting r314277 / rolling back to r300897)." -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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"
