Re: [ECFT] drm/dri/mesa/xorg-server update [Part 1]
Also I tried with intel D510MO motherboard (dmidecode said me Intel(R) GMA 3150 Video Device). /usr/ports/x11-drivers/xf86-video-intel doesn`t support this video device. /usr/ports/x11-drivers/xf86-video-intel29 doesn`t compile (ussually I use this driver) and patches provided by George Liaskos (Mar 12, 2011; 07:21pm and Mar 14, 2011; 12:03am) doesn`t help =( === Building for xf86-video-intel29-2.9.1 make `test -z @ echo -s` all-recursive Making all in uxa ../doltcompile /bin/sh /usr/ports/x11-drivers/xf86-video-intel29/work/xf86-video-intel-2.9.1/./shave cc cc -DHAVE_CONFIG_H -I. -I..-D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include -I/usr/local/include/pixman-1-I/usr/local/include -I/usr/local/include/libdrm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include -I/usr/local/include/pixman-1 -O2 -pipe -fno-strict-aliasing -MT uxa.lo -MD -MP -MF .deps/uxa.Tpo -c -o uxa.lo uxa.c CCuxa.o In file included from uxa.c:37: uxa-priv.h: In function 'uxa_get_screen': uxa-priv.h:185: warning: passing argument 2 of 'dixLookupPrivate' from incompatible pointer type uxa.c: In function 'uxa_close_screen': uxa.c:393: warning: 'Xfree' is deprecated (declared at /usr/local/include/xorg/os.h:234) uxa.c: In function 'uxa_driver_alloc': uxa.c:411: warning: 'Xcalloc' is deprecated (declared at /usr/local/include/xorg/os.h:225) uxa.c: In function 'uxa_driver_init': uxa.c:463: warning: 'Xcalloc' is deprecated (declared at /usr/local/include/xorg/os.h:225) uxa.c:473: warning: passing argument 2 of 'dixSetPrivate' from incompatible pointer type mv -f .deps/uxa.Tpo .deps/uxa.Plo ../doltcompile /bin/sh /usr/ports/x11-drivers/xf86-video-intel29/work/xf86-video-intel-2.9.1/./shave cc cc -DHAVE_CONFIG_H -I. -I..-D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include -I/usr/local/include/pixman-1-I/usr/local/include -I/usr/local/include/libdrm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include -I/usr/local/include/pixman-1 -O2 -pipe -fno-strict-aliasing -MT uxa-accel.lo -MD -MP -MF .deps/uxa-accel.Tpo -c -o uxa-accel.lo uxa-accel.c CCuxa-accel.o In file included from uxa-accel.c:33: uxa-priv.h: In function 'uxa_get_screen': uxa-priv.h:185: warning: passing argument 2 of 'dixLookupPrivate' from incompatible pointer type uxa-accel.c: In function 'uxa_poly_point': uxa-accel.c:523: warning: 'Xalloc' is deprecated (declared at /usr/local/include/xorg/os.h:221) uxa-accel.c:537: warning: 'Xfree' is deprecated (declared at /usr/local/include/xorg/os.h:234) uxa-accel.c: In function 'uxa_poly_lines': uxa-accel.c:560: warning: 'Xalloc' is deprecated (declared at /usr/local/include/xorg/os.h:221) uxa-accel.c:576: warning: 'Xfree' is deprecated (declared at /usr/local/include/xorg/os.h:234) uxa-accel.c:600: warning: 'Xfree' is deprecated (declared at /usr/local/include/xorg/os.h:234) uxa-accel.c: In function 'uxa_poly_segment': uxa-accel.c:631: warning: 'Xalloc' is deprecated (declared at /usr/local/include/xorg/os.h:221) uxa-accel.c:659: warning: 'Xfree' is deprecated (declared at /usr/local/include/xorg/os.h:234) mv -f .deps/uxa-accel.Tpo .deps/uxa-accel.Plo ../doltcompile /bin/sh /usr/ports/x11-drivers/xf86-video-intel29/work/xf86-video-intel-2.9.1/./shave cc cc -DHAVE_CONFIG_H -I. -I..-D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include -I/usr/local/include/pixman-1-I/usr/local/include -I/usr/local/include/libdrm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include -I/usr/local/include/pixman-1 -O2 -pipe -fno-strict-aliasing -MT uxa-glyphs.lo -MD -MP -MF .deps/uxa-glyphs.Tpo -c -o uxa-glyphs.lo uxa-glyphs.c CCuxa-glyphs.o In file included from uxa-glyphs.c:49: uxa-priv.h: In function 'uxa_get_screen': uxa-priv.h:185: warning: passing argument 2 of 'dixLookupPrivate' from incompatible pointer type uxa-glyphs.c: In function 'uxa_unrealize_glyph_caches': uxa-glyphs.c:131: warning: 'Xfree' is deprecated (declared at /usr/local/include/xorg/os.h:234) uxa-glyphs.c:136: warning: 'Xfree' is deprecated (declared at /usr/local/include/xorg/os.h:234) uxa-glyphs.c: In function 'uxa_realize_glyph_caches': uxa-glyphs.c:217: warning: 'Xalloc' is deprecated (declared at /usr/local/include/xorg/os.h:221) uxa-glyphs.c:218: warning: 'Xalloc' is deprecated (declared at /usr/local/include/xorg/os.h:221) mv -f .deps/uxa-glyphs.Tpo .deps/uxa-glyphs.Plo ../doltcompile /bin/sh /usr/ports/x11-drivers/xf86-video-intel29/work/xf86-video-intel-2.9.1/./shave cc cc -DHAVE_CONFIG_H -I. -I..-D_THREAD_SAFE -I/usr/local/include/xorg -I/usr/local/include
Re: [HEADS UP] GNU make 3.82
Am 14.03.2011 04:45, schrieb Ade Lovett: On Mar 13, 2011, at 16:27 , Peter Jeremy wrote: Having read through this thread, it is still unclear to me why it is not possible to fix up the problematic ports before importing gmake 3.82, removing the need for a gmake381 port. I believe Mark has offered up, on multiple occasions a wiki page from the _first_ exp run. Of course, if port A fails as a result of gmake (or, quite frankly, whatever), and it has dependent ports, then unti such time as the proverbial quick hack to unbreak it, we have absolutely no idea of the carnage further down the tree. devel/gmake381 exists for one reason, and one reason only. To allow -exp runs to fully test what breaks, and what doesn't with a devel/gmake being 3.82. You'll notice that it is not attached to the build (in devel/Makefile) and it is also marked IGNORE. Using a few extra inodes in order to be able to properly test things (you should also note that USE_GMAKE=381 is merely part of an -exp patchset, and not present in the existing Mk/bsd.port.mk) is a minor cost for substantial gains when actually running said -exp runs. Could this have been handled better. Sure, maybe. But it would require *proactive* work within the community as opposed to the you're doing it wrong *reactive* mentality. It's easy to criticize. Much harder to do work that affects thousand of ports and, in the best case, no-one actually sees a change. Dear colleagues, I've been reading this discussion on and off and trying to get on top of the facts to make up my own mind. Looks like people who have done the work (Ade and Mark) first didn't know the exact implications of non-triviality of the task, and have now become defensive, and Doug has become frustrated about a perceived lack of information -- that I have shared for a couple of days, until the Wiki address crossed my Inbox, possibly for the 2nd time. I think we all agree that we have learnt a bit from how things happened, and people involved in the frame-work and -exp runs will probably do things differently the next time around. You all are in what I'd call a violent agreement, and it's naturally easier to criticise with hindsight. However, please let's quit the defending now and get productive again, and please share information about possible framework breakage sooner. As much as we would have liked the GNU make maintainers to call this pick up the shards release 4.00, this hasn't happened, and we've got to deal with it, and work is underway to achieve just that. What I've understood is that the first -exp run didn't get us the whole picture and thus the gmake381 hack was added to get an overview and cut the dependency tree short -- but nonetheless it is useful to start the job of fixing gmake 3.82 incompatibilities while 2nd, 3rd, 4th -exp passes proceed. I've also seen that there are volunteers, such as maintainers and unaffiliated contributors who are always willing to lend a hand, have been trying to sort things out for gmake 3.82. Of course being more transparent and open with information can cause anxiety, but if more people take interest in an issue, things get understood and fixed sooner. The only remaining question is whether a policy needs to be established to do such -exp things openly in general, or if it was just a lack of proactive communication as a one-time event that will not happen again anyways. And I'd rather not overengineer. Anyways, I see *chance there* for the -exp and autotools and gmake janitors to share a bit of their task get gmake3.82 in ports to fly workload on more shoulders. Best -- Matthias Andree ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
site-packages upgrades (was: portmaster comments)
Am 14.03.2011 14:19, schrieb Wesley Shields: This doesn't have any effect for, /usr/ports/lang/python/Makefile:31:.if defined(USE_PORTMASTER) Does it ? It has an effect on how the upgrade-site-packages target works. I wrote it specifically because I didn't want to have to install portupgrade just to get the upgrade-site-packages target to work. Oh, if I may add a shameless plug here, I'd like to advertise ports-mgmt/pkgs_which that I've written partially out of the same motivation (get upgrade-site-packages targets working without portupgrade or pkg_which) and efficiently. Basically you can do pkgs_which -qo /usr/local/lib/python2.6 to get a list of packages that need upgrading (takes 10 s for a dual-core energy-efficient 2 GHz-class computer with somewhat slow disks and UFS) or portmaster -d $(pkgs_which -qo /usr/local/lib/python2.6) to upgrade them all. Yeah, this code should've been written much sooner, and I've been having this idea for a while, but now it's there. I think you might be confusing two different issues. The USE_PORTMASTER knob was put in place specifically for the upgrade-site-packages target, which is not something called during the normal build process by any upgrading tool. I'm not sure how using UPGRADE_TOOL will help this at all. Possibly not at all -- it would possibly be more useful to standardize these post-upgrade jobs. One post-install for the regular stuff, and one post-nontrivial-upgrade (for want of a better name) for the 2.6-2.7 or Perl 5.10-5.12 migration pains. -- Matthias Andree ports committer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
ports/154859 (www/uzbl) forgotten -- and now superseeded
Hi, almost a month ago I submitted ports/154859, a maintainer update of www/uzbl to the then up-to-date release. Nothing has happend so far, and in the mean time a new version has been released and I'm currently testing the updated port; I expect so send a PR in the next days. Now I wonder, whether I should prepare the diff under the assumption that ports/154859 gets committed first (which would be good, to have a complete history in the ports tree!), or whether I should asume that ports/154859 will never get handled and send a patch with respect to the currently commited version. Best regards, Klaus ___ 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/154859 (www/uzbl) forgotten -- and now superseeded
am about to commit this update tonight. On Tue, Mar 15, 2011 at 8:30 PM, Klaus T. Aehlig aeh...@linta.de wrote: Hi, almost a month ago I submitted ports/154859, a maintainer update of www/uzbl to the then up-to-date release. Nothing has happend so far, and in the mean time a new version has been released and I'm currently testing the updated port; I expect so send a PR in the next days. Now I wonder, whether I should prepare the diff under the assumption that ports/154859 gets committed first (which would be good, to have a complete history in the ports tree!), or whether I should asume that ports/154859 will never get handled and send a patch with respect to the currently commited version. Best regards, Klaus ___ 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
gnome-translate-0.99_14 problem
Hello! I was trying to install the port textproc/gnome-translate (gnome-translate-0.99_14), but a problem occurred. And I have upgraded perl to 5.12.3 version earlier. [root@lucky /usr/ports/textproc/gnome-translate]# make install clean === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Found saved configuration for gnome-translate-0.99_14 = gnome-translate-0.99.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch http://nongnu.askapache.com/libtranslate/gnome-translate-0.99.tar.gz gnome-translate-0.99.tar.gz 100% of 291 kB 207 kBps === Extracting for gnome-translate-0.99_14 = SHA256 Checksum OK for gnome-translate-0.99.tar.gz. === Patching for gnome-translate-0.99_14 === Applying FreeBSD patches for gnome-translate-0.99_14 === gnome-translate-0.99_14 depends on executable: gmake - found === gnome-translate-0.99_14 depends on file: /usr/local/bin/intltool-extract - found === gnome-translate-0.99_14 depends on file: /usr/local/libdata/pkgconfig/gnome-mime-data-2.0.pc - found === gnome-translate-0.99_14 depends on executable: pkg-config - found === gnome-translate-0.99_14 depends on file: /usr/local/libdata/pkgconfig/gnome-doc-utils.pc - found === gnome-translate-0.99_14 depends on file: /usr/local/libdata/pkgconfig/pygtk-2.0.pc - found === gnome-translate-0.99_14 depends on shared library: translate - found === gnome-translate-0.99_14 depends on shared library: aspell - found === gnome-translate-0.99_14 depends on shared library: esd.2 - found === gnome-translate-0.99_14 depends on shared library: atk-1.0.0 - found === gnome-translate-0.99_14 depends on shared library: eel-2.2 - found === gnome-translate-0.99_14 depends on shared library: gconf-2.4 - found === gnome-translate-0.99_14 depends on shared library: glib-2.0.0 - found === gnome-translate-0.99_14 depends on shared library: gnome-desktop-2.17 - found === gnome-translate-0.99_14 depends on shared library: gnomevfs-2.0 - found === gnome-translate-0.99_14 depends on shared library: gtk-x11-2.0.0 - found === gnome-translate-0.99_14 depends on shared library: art_lgpl_2.5 - found === gnome-translate-0.99_14 depends on shared library: bonobo-2.0 - found === gnome-translate-0.99_14 depends on shared library: bonoboui-2.0 - found === gnome-translate-0.99_14 depends on shared library: glade-2.0.0 - found === gnome-translate-0.99_14 depends on shared library: gnome-2.0 - found === gnome-translate-0.99_14 depends on shared library: gnomecanvas-2.0 - found === gnome-translate-0.99_14 depends on shared library: gnomeui-2.0 - found === gnome-translate-0.99_14 depends on shared library: IDL-2.0 - found === gnome-translate-0.99_14 depends on shared library: xml2.5 - found === gnome-translate-0.99_14 depends on shared library: xslt.2 - found === gnome-translate-0.99_14 depends on shared library: ORBit-2.0 - found === gnome-translate-0.99_14 depends on shared library: pango-1.0.0 - found === Configuring for gnome-translate-0.99_14 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... gawk checking whether gmake sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by gmake... GNU checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking dependency style of cc... gcc3 checking how to run the C preprocessor... cpp checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for dgettext in libc... no checking for bindtextdomain in -lintl... yes checking for dgettext in -lintl... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/local/bin/msgfmt checking for dcgettext... yes checking for gmsgfmt... /usr/local/bin/msgfmt checking for xgettext... /usr/local/bin/xgettext checking for catalogs to be installed... fr checking for perl... /usr/bin/perl checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool === Script
Re: gnome-translate-0.99_14 problem
On Tue, Mar 15, 2011 at 3:19 PM, Alexey Zaivenko - Vysochin zaivenkoxxxa...@gmail.com wrote: Hello! I was trying to install the port textproc/gnome-translate (gnome-translate-0.99_14), but a problem occurred. And I have upgraded perl to 5.12.3 version earlier. [root@lucky /usr/ports/textproc/gnome-translate]# make install clean (...) checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool (...) It sounds like you're missing textproc/p5-XML-Parser , which is listed in RUN_DEPENDS for textproc/intltool . Could you check if both are indeed installed? If you just want a workaround, I suggest you try (re)installing textproc/p5-XML-Parser - but it'd probably be useful to track down what has happened. -- Daniel Nebdal ___ 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: Compiling ports in a post-9.0-RELEASE world
13.03.2011, 01:00, Doug Barton do...@freebsd.org: Howdy, As many of you are no doubt already aware, much work has been undertaken to make clang the default compiler for the src tree starting with 9.0-RELEASE. It is not 100% certain that this change will be made, but it's looking more likely every day. This raises an interesting question for how to deal with compiling ports after 9.0 is released. So far there are 2 main ideas for how to deal with this: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. 3. Fix Clang to compile more ports My $0.02 -- Regards, Konstantin ___ 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: gnome-translate-0.99_14 problem
On Tue, 2011-03-15 at 16:19 +0200, Alexey Zaivenko - Vysochin wrote: Hello! I was trying to install the port textproc/gnome-translate (gnome-translate-0.99_14), but a problem occurred. And I have upgraded perl to 5.12.3 version earlier. You need to look up and read the entry in ports/UPDATING about the perl upgrade. -Koop [root@lucky /usr/ports/textproc/gnome-translate]# make install clean === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Found saved configuration for gnome-translate-0.99_14 = gnome-translate-0.99.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch http://nongnu.askapache.com/libtranslate/gnome-translate-0.99.tar.gz gnome-translate-0.99.tar.gz 100% of 291 kB 207 kBps === Extracting for gnome-translate-0.99_14 = SHA256 Checksum OK for gnome-translate-0.99.tar.gz. === Patching for gnome-translate-0.99_14 === Applying FreeBSD patches for gnome-translate-0.99_14 === gnome-translate-0.99_14 depends on executable: gmake - found === gnome-translate-0.99_14 depends on file: /usr/local/bin/intltool-extract - found === gnome-translate-0.99_14 depends on file: /usr/local/libdata/pkgconfig/gnome-mime-data-2.0.pc - found === gnome-translate-0.99_14 depends on executable: pkg-config - found === gnome-translate-0.99_14 depends on file: /usr/local/libdata/pkgconfig/gnome-doc-utils.pc - found === gnome-translate-0.99_14 depends on file: /usr/local/libdata/pkgconfig/pygtk-2.0.pc - found === gnome-translate-0.99_14 depends on shared library: translate - found === gnome-translate-0.99_14 depends on shared library: aspell - found === gnome-translate-0.99_14 depends on shared library: esd.2 - found === gnome-translate-0.99_14 depends on shared library: atk-1.0.0 - found === gnome-translate-0.99_14 depends on shared library: eel-2.2 - found === gnome-translate-0.99_14 depends on shared library: gconf-2.4 - found === gnome-translate-0.99_14 depends on shared library: glib-2.0.0 - found === gnome-translate-0.99_14 depends on shared library: gnome-desktop-2.17 - found === gnome-translate-0.99_14 depends on shared library: gnomevfs-2.0 - found === gnome-translate-0.99_14 depends on shared library: gtk-x11-2.0.0 - found === gnome-translate-0.99_14 depends on shared library: art_lgpl_2.5 - found === gnome-translate-0.99_14 depends on shared library: bonobo-2.0 - found === gnome-translate-0.99_14 depends on shared library: bonoboui-2.0 - found === gnome-translate-0.99_14 depends on shared library: glade-2.0.0 - found === gnome-translate-0.99_14 depends on shared library: gnome-2.0 - found === gnome-translate-0.99_14 depends on shared library: gnomecanvas-2.0 - found === gnome-translate-0.99_14 depends on shared library: gnomeui-2.0 - found === gnome-translate-0.99_14 depends on shared library: IDL-2.0 - found === gnome-translate-0.99_14 depends on shared library: xml2.5 - found === gnome-translate-0.99_14 depends on shared library: xslt.2 - found === gnome-translate-0.99_14 depends on shared library: ORBit-2.0 - found === gnome-translate-0.99_14 depends on shared library: pango-1.0.0 - found === Configuring for gnome-translate-0.99_14 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... gawk checking whether gmake sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by gmake... GNU checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ANSI C... none needed checking dependency style of cc... gcc3 checking how to run the C preprocessor... cpp checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for dgettext in libc... no checking for bindtextdomain in -lintl... yes checking for dgettext in -lintl... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/local/bin/msgfmt checking for dcgettext... yes checking for gmsgfmt...
Re: Compiling ports in a post-9.0-RELEASE world
On Tue 15 Mar 2011 at 11:20:40 PDT Konstantin Tokarev wrote: 3. Fix Clang to compile more ports That would be my vote too, but we should probably focus on solutions the ports team can control. ___ 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: Compiling ports in a post-9.0-RELEASE world
15.03.2011, 21:32, Charlie Kester corky1...@comcast.net: On Tue 15 Mar 2011 at 11:20:40 PDT Konstantin Tokarev wrote: 3. Fix Clang to compile more ports That would be my vote too, but we should probably focus on solutions the ports team can control. You can post bug reports to Clang team. maybe some of them will be solved before the release of 9.0 -- Regards, Konstantin ___ 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: Compiling ports in a post-9.0-RELEASE world
On Tue 15 Mar 2011 at 11:39:28 PDT Konstantin Tokarev wrote: 15.03.2011, 21:32, Charlie Kester corky1...@comcast.net: On Tue 15 Mar 2011 at 11:20:40 PDT Konstantin Tokarev wrote: 3. Fix Clang to compile more ports That would be my vote too, but we should probably focus on solutions the ports team can control. You can post bug reports to Clang team. maybe some of them will be solved before the release of 9.0 Of course, we should definitely do that. But ports team should have a plan in place, in case those PR's aren't resolved in time. ___ 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: Compiling ports in a post-9.0-RELEASE world
On Mar 15, 2011, at 14:14 , Charlie Kester wrote: Of course, we should definitely do that. But ports team should have a plan in place, in case those PR's aren't resolved in time. A single, really small boot/livefs/install with no packages (half-smiley) In all seriousness, with a change of this complexity, in order to get more eyes on the prize, some form of slightly-hardened functional snapshot would be useful to load up on virtualbox/vmware/whatever slaves, install the necessary components for a ports-tinderbox client system and then start building. On personal machines (not the package building clusters), package building and testing can take a non-trivial amount of time to run, so everyone interested in participating running from the same snapshot (base, dict, proflibs, src/sys [and, for amd64, lib32] sets are all that's needed to run a ports-tinderbox) will considerably ease the situation. -aDe ___ 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
Update of www/mod_proxy_html and adding www/mod_xml2enc
Hey guys, I've submitted a request for updating port www/mod_proxy_html and adding a new port www/mod_xml2enc a couple of weeks ago. The requests are generally for making www/mod_xml2enc as a dependency for www/mod_proxy_html. Could you please have a look at these requests and possibly commit them? PRs: - http://www.freebsd.org/cgi/query-pr.cgi?pr=155203 - http://www.freebsd.org/cgi/query-pr.cgi?pr=155204 Thanks and regards, Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.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
deprecated ports
I see there's been another few batch commits deprecating some unmaintained ports where upstream is gone and/or distfile is no longer available. Maintainers and prospective maintainers should be sure to look at the ports listed in these commits. I don't think much effort was made to check the availability of the distfiles. Instead, it seems that all that was done was to try the MASTER_SITES, etc. from the port Makefiles, and if the fetch failed, onto the list they went. NOTE: I'm NOT saying the committers' procedure was too lazy or anything like that. There are a lot of these broken ports in the tree, and deprecation seems like a reasonable step to take -- especially if the result is to trigger some action from people who want to see these ports retained. I just rescued one of these, sysutils/lookat, that was deprecated a few days ago. I followed the WWW link in the pkg-descr, found that the author's website was still up and that the distfile could still be downloaded -- but the download url had changed. So all the port needed was a tweak to the MASTER_SITES. Today I see that the fairly popular graphics/gimpshop has also been deprecated. Here the WWW link from pkg-descr also fails, but a quick websearch found the new (?) official website for this app: http://www.gimpshop.com, where the distfile is available for download. So here's another one that can be easily rescued. And I'll bet there are more. ___ 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: deprecated ports
On Tue, Mar 15, 2011 at 02:58:01PM -0700, Charlie Kester thus spake: I see there's been another few batch commits deprecating some unmaintained ports where upstream is gone and/or distfile is no longer available. Maintainers and prospective maintainers should be sure to look at the ports listed in these commits. I don't think much effort was made to check the availability of the distfiles. Instead, it seems that all that was done was to try the MASTER_SITES, etc. from the port Makefiles, and if the fetch failed, onto the list they went. NOTE: I'm NOT saying the committers' procedure was too lazy or anything like that. There are a lot of these broken ports in the tree, and deprecation seems like a reasonable step to take -- especially if the result is to trigger some action from people who want to see these ports retained. I just rescued one of these, sysutils/lookat, that was deprecated a few days ago. I followed the WWW link in the pkg-descr, found that the author's website was still up and that the distfile could still be downloaded -- but the download url had changed. So all the port needed was a tweak to the MASTER_SITES. Today I see that the fairly popular graphics/gimpshop has also been deprecated. Here the WWW link from pkg-descr also fails, but a quick websearch found the new (?) official website for this app: http://www.gimpshop.com, where the distfile is available for download. So here's another one that can be easily rescued. And I'll bet there are more. To this point I just found another: sysutils/idled was just deprecated the other day. In following some weblinks, I found that doinkd has replaced it: sysutils/doinkd :) Maybe the DEPRECATION line should be altered. -jgh ___ 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: deprecated ports
On Tue 15 Mar 2011 at 14:59:57 PDT Jason Helfman wrote: On Tue, Mar 15, 2011 at 02:58:01PM -0700, Charlie Kester thus spake: I see there's been another few batch commits deprecating some unmaintained ports where upstream is gone and/or distfile is no longer available. Maintainers and prospective maintainers should be sure to look at the ports listed in these commits. I don't think much effort was made to check the availability of the distfiles. Instead, it seems that all that was done was to try the MASTER_SITES, etc. from the port Makefiles, and if the fetch failed, onto the list they went. NOTE: I'm NOT saying the committers' procedure was too lazy or anything like that. There are a lot of these broken ports in the tree, and deprecation seems like a reasonable step to take -- especially if the result is to trigger some action from people who want to see these ports retained. I just rescued one of these, sysutils/lookat, that was deprecated a few days ago. I followed the WWW link in the pkg-descr, found that the author's website was still up and that the distfile could still be downloaded -- but the download url had changed. So all the port needed was a tweak to the MASTER_SITES. Today I see that the fairly popular graphics/gimpshop has also been deprecated. Here the WWW link from pkg-descr also fails, but a quick websearch found the new (?) official website for this app: http://www.gimpshop.com, where the distfile is available for download. So here's another one that can be easily rescued. And I'll bet there are more. To this point I just found another: sysutils/idled was just deprecated the other day. In following some weblinks, I found that doinkd has replaced it: sysutils/doinkd :) Maybe the DEPRECATION line should be altered. Two more found with a simple web query: finance/xinvest and finance/xquote are now on sourceforge. http://xinvest.sourceforge.net/ BTW, I don't use either of these, or gimpshop, so I'm not going to fix the ports myself. Instead, I'll leave that to anyone who's interested. ___ 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: deprecated ports
2011/3/15 Charlie Kester corky1...@comcast.net I see there's been another few batch commits deprecating some unmaintained ports where upstream is gone and/or distfile is no longer available. Maintainers and prospective maintainers should be sure to look at the ports listed in these commits. I don't think much effort was made to check the availability of the distfiles. Instead, it seems that all that was done was to try the MASTER_SITES, etc. from the port Makefiles, and if the fetch failed, onto the list they went. NOTE: I'm NOT saying the committers' procedure was too lazy or anything like that. There are a lot of these broken ports in the tree, and deprecation seems like a reasonable step to take -- especially if the result is to trigger some action from people who want to see these ports retained. I just rescued one of these, sysutils/lookat, that was deprecated a few days ago. I followed the WWW link in the pkg-descr, found that the author's website was still up and that the distfile could still be downloaded -- but the download url had changed. So all the port needed was a tweak to the MASTER_SITES. Today I see that the fairly popular graphics/gimpshop has also been deprecated. Here the WWW link from pkg-descr also fails, but a quick websearch found the new (?) official website for this app: http://www.gimpshop.com, where the distfile is available for download. So here's another one that can be easily rescued. And I'll bet there are more. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org I am responsible for the deprecation and I have done more than just look if the distfiles fetch (I fixed lot of them) I may have missed some for sure, when when I deprecate sysutils/lookat I wasn't able to join the main website nor to fetch a distfile. About gimpshop it may be wrong, but one there website I only found windows and mac binaries, nothing. I am human and I can make mistakes. thanks pointing the mistakes. I really will be happy to remove the deprecation and expiration if people wanted to maintain or point me to the right WWW and MASTER_SITES for the given ports. regards, Bapt ___ 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: deprecated ports
2011/3/15 Charlie Kester corky1...@comcast.net On Tue 15 Mar 2011 at 14:59:57 PDT Jason Helfman wrote: On Tue, Mar 15, 2011 at 02:58:01PM -0700, Charlie Kester thus spake: I see there's been another few batch commits deprecating some unmaintained ports where upstream is gone and/or distfile is no longer available. Maintainers and prospective maintainers should be sure to look at the ports listed in these commits. I don't think much effort was made to check the availability of the distfiles. Instead, it seems that all that was done was to try the MASTER_SITES, etc. from the port Makefiles, and if the fetch failed, onto the list they went. NOTE: I'm NOT saying the committers' procedure was too lazy or anything like that. There are a lot of these broken ports in the tree, and deprecation seems like a reasonable step to take -- especially if the result is to trigger some action from people who want to see these ports retained. I just rescued one of these, sysutils/lookat, that was deprecated a few days ago. I followed the WWW link in the pkg-descr, found that the author's website was still up and that the distfile could still be downloaded -- but the download url had changed. So all the port needed was a tweak to the MASTER_SITES. Today I see that the fairly popular graphics/gimpshop has also been deprecated. Here the WWW link from pkg-descr also fails, but a quick websearch found the new (?) official website for this app: http://www.gimpshop.com, where the distfile is available for download. So here's another one that can be easily rescued. And I'll bet there are more. To this point I just found another: sysutils/idled was just deprecated the other day. In following some weblinks, I found that doinkd has replaced it: sysutils/doinkd :) Maybe the DEPRECATION line should be altered. Two more found with a simple web query: finance/xinvest and finance/xquote are now on sourceforge. http://xinvest.sourceforge.net/ BTW, I don't use either of these, or gimpshop, so I'm not going to fix the ports myself. Instead, I'll leave that to anyone who's interested. ___ 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 Concerning those two try to follow a single link on the main website, they are all broken and I tested them. The workaround would have been to goes from the sourceforge interface to the project page instead of being confident on the website of the project (normally non stalled project have working websites). But you are right I should have gone the the sourceforge project page and then try to download the files. ___ 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: deprecated ports
On Tue 15 Mar 2011 at 15:19:29 PDT Baptiste Daroussin wrote: I am responsible for the deprecation and I have done more than just look if the distfiles fetch (I fixed lot of them) I may have missed some for sure, when when I deprecate sysutils/lookat I wasn't able to join the main website nor to fetch a distfile. About gimpshop it may be wrong, but one there website I only found windows and mac binaries, nothing. I am human and I can make mistakes. thanks pointing the mistakes. I really will be happy to remove the deprecation and expiration if people wanted to maintain or point me to the right WWW and MASTER_SITES for the given ports. regards,* Bapt My apologies for misrepresenting your efforts, bapt. I meant no disrespect. I'm just trying to whip up some followup action from the readers, so you don't have to do all this by yourself. :) We've recently heard calls for new blood. Well, here's a way people can help. Maybe it wasn't there when you looked, but http://www.gimpshop.com/download.shtml has links to download sources for both the development version and the latest release (2.2.8). They even have an alternate link for the release version. ___ 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: deprecated ports
2011/3/15 Charlie Kester corky1...@comcast.net On Tue 15 Mar 2011 at 15:19:29 PDT Baptiste Daroussin wrote: I am responsible for the deprecation and I have done more than just look if the distfiles fetch (I fixed lot of them) I may have missed some for sure, when when I deprecate sysutils/lookat I wasn't able to join the main website nor to fetch a distfile. About gimpshop it may be wrong, but one there website I only found windows and mac binaries, nothing. I am human and I can make mistakes. thanks pointing the mistakes. I really will be happy to remove the deprecation and expiration if people wanted to maintain or point me to the right WWW and MASTER_SITES for the given ports. regards,* Bapt My apologies for misrepresenting your efforts, bapt. I meant no disrespect. I'm just trying to whip up some followup action from the readers, so you don't have to do all this by yourself. :) We've recently heard calls for new blood. Well, here's a way people can help. Maybe it wasn't there when you looked, but http://www.gimpshop.com/download.shtml has links to download sources for both the development version and the latest release (2.2.8). They even have an alternate link for the release version. ___ 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 Sorry, I misunderstood your mail, this is fixt thanks for the report. regards. Bapt ___ 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: can make -j be used for ports?
Is this possible or am I being unreasonable, or both, or not?
This is unsupported, but you are not being unreasonable. This is a
much wanted feature.
Yes. Ports which support parallel builds will have MAKE_JOBS_SAFE=yes set in
the port Makefile. It defaults to running -j with
MAKE_JOBS_NUMBER=`${SYSCTL} -n kern.smp.cpus`, but you can change that to
some other # if you like.
No, this is incorrect. The MAKE_JOBS_NUMBER and MAKE_JOBS_SAFE is used
internally when building a single port. When the OP is asking if he
can manually specify -j on the command line which would end up
building multiple ports in parallel. This can not be done (primarily
because there is no locking done on ports)
Certain utilities can make this process faster. For example portmaster
prefetches as much as it can,
--
Eitan Adler
___
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: can make -j be used for ports?
On Mar 15, 2011, at 3:35 PM, Eitan Adler wrote:
[ ... ]
Yes. Ports which support parallel builds will have MAKE_JOBS_SAFE=yes set
in the port Makefile. It defaults to running -j with
MAKE_JOBS_NUMBER=`${SYSCTL} -n kern.smp.cpus`, but you can change that to
some other # if you like.
No, this is incorrect. The MAKE_JOBS_NUMBER and MAKE_JOBS_SAFE is used
internally when building a single port.
What is incorrect?
When the OP is asking if he can manually specify -j on the command line which
would end up
building multiple ports in parallel. This can not be done (primarily
because there is no locking done on ports)
It certainly wasn't clear to me that this is what the OP meant. If you:
cd /usr/ports/www/apache22
make -j 3
...what do you expect to happen, and how many ports would you expect to be
built at once?
(Building one port in parallel is supported, where the port itself is safe to
do so; building many at the same time is not. Supporting the former provides
more speed gain for many situations as compared to the latter; which doesn't
help at all if you are just installing or updating one port.)
Regards,
--
-Chuck
___
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: can make -j be used for ports?
What is incorrect? MAKE_JOBS_SAFE uses make -j on a single port (when in the WRKSRC directory) but does *not* build multiple ports at the same time, It certainly wasn't clear to me that this is what the OP meant. If you: cd /usr/ports/www/apache22 make -j 3 ...what do you expect to happen, and how many ports would you expect to be built at once? What *would* happen is that make would try to build multiple ports at once. This is not supported. (Building one port in parallel is supported, where the port itself is safe to do so; building many at the same time is not. ) This is what I said. This feature is automatic and does not require -j specified. On Tue, Mar 15, 2011 at 5:44 PM, David Forsythe dfors...@freebsd.org wrote: I had patches for this a couple of years ago when I worked on this problem for summer of code. What I did back then is surely stale, but if people really want it, I'd be happy to take another stab at it. I've seen that work: it looked quite good. Yes, I think this would be very useful and I think a lot of people would want it :-). -- Eitan Adler ___ 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: can make -j be used for ports?
On Mar 15, 2011, at 3:51 PM, Eitan Adler wrote: It certainly wasn't clear to me that this is what the OP meant. If you: cd /usr/ports/www/apache22 make -j 3 ...what do you expect to happen, and how many ports would you expect to be built at once? What *would* happen is that make would try to build multiple ports at once. Did you actually try and see what happens? I'm thinking no...since, unless something is very different, you ought to find it terminating as follows: # cd /usr/ports/www/apache22 ; make -j 3 === apache-2.2.17_1 depends on file: /usr/local/lib/libcrypto.so.7 - found === apache-2.2.17_1 depends on file: /usr/local/bin/perl5.12.3 - found === apache-2.2.17_1 depends on file: /usr/local/bin/autoconf-2.68 - found === apache-2.2.17_1 depends on package: libtool=2.4 - found === apache-2.2.17_1 depends on shared library: expat.6 - found === apache-2.2.17_1 depends on shared library: apr-1 - found === apache-2.2.17_1 depends on shared library: pcre.0 - found === apache-2.2.17_1 depends on shared library: iconv.3 - found === apache-2.2.17_1 depends on shared library: mysqlclient.15 - found === apache-2.2.17_1 depends on shared library: db-4.4.0 - found === apache-2.2.17_1 depends on shared library: sqlite3.8 - found === Configuring for apache-2.2.17_1 ...whereas just typing make proceeds with: checking for chosen layout... FreeBSD checking for working mkdir -p... yes checking build system type... i386-portbld-freebsd7.4 checking host system type... i386-portbld-freebsd7.4 checking target system type... i386-portbld-freebsd7.4 [ ...followed by an actual build... ] Regards, -- -Chuck ___ 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: can make -j be used for ports?
I had patches for this a couple of years ago when I worked on this
problem for summer of code. What I did back then is surely stale, but
if people really want it, I'd be happy to take another stab at it.
On Tue, Mar 15, 2011 at 3:35 PM, Eitan Adler li...@eitanadler.com wrote:
Is this possible or am I being unreasonable, or both, or not?
This is unsupported, but you are not being unreasonable. This is a
much wanted feature.
Yes. Ports which support parallel builds will have MAKE_JOBS_SAFE=yes set
in the port Makefile. It defaults to running -j with
MAKE_JOBS_NUMBER=`${SYSCTL} -n kern.smp.cpus`, but you can change that to
some other # if you like.
No, this is incorrect. The MAKE_JOBS_NUMBER and MAKE_JOBS_SAFE is used
internally when building a single port. When the OP is asking if he
can manually specify -j on the command line which would end up
building multiple ports in parallel. This can not be done (primarily
because there is no locking done on ports)
Certain utilities can make this process faster. For example portmaster
prefetches as much as it can,
--
Eitan Adler
___
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
--
David
___
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: Compiling ports in a post-9.0-RELEASE world
On Tuesday 15 March 2011 19:20:40 Konstantin Tokarev wrote: 3. Fix Clang to compile more ports lots of problems are due to gcc-isms in software, so it's not always possible -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla The yankees, son, are up north. The damnyankees are down here. signature.asc Description: This is a digitally signed message part.
portmaster versus portsclean
After switching to portmaster, portsclean is the last part of
portupgrade I'm using.
portsclean -C can be replaced with 'rm /usr/ports/*/*/work', or better
with 'find -X /usr/ports/ -name work -depth 3 -exec rm -rf {} \;'.
I don't see a way to do this with portmaster, but it's trivial.
portsclean -D can be replaced with 'portmaster -t --clean-distfiles'.
portsclean -DD can be replaced with 'portmaster --clean-distfiles'.
(Those might be backwards, the wording in the portmaster man page is a
little ambiguous.)
Is there an equivalent for portsclean -L, to delete old, duplicated, or
orphaned shared libraries in a batch?
___
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: can make -j be used for ports?
On 15/03/2011 22:35, Eitan Adler wrote: No, this is incorrect. The MAKE_JOBS_NUMBER and MAKE_JOBS_SAFE is used internally when building a single port. When the OP is asking if he can manually specify -j on the command line which would end up building multiple ports in parallel. This can not be done (primarily because there is no locking done on ports) Actually, he has it partially right, at least in the idea I was trying to convey. I'll explain again, because maybe I wasn't coherent enough previously: I have an amd x2 6000+ with 8GB RAM. It's a wonderful fast desktop. Not the fastest, but it's fast enough for me. What I want to do is this: 1. If I can speed things up, with *ports* as I have a dual cpu, I want to maybe run j2 or j3. I seek clarification which is logically best, because some literature says jn, others jn+1 where n is number of cores. kern.smp.cpus: 2 on my machine. Is there benefit setting this to 3,4,5? I want to know if there is perhaps a conf file or sysctl where I can specify this *for ports only.* - if not I'm happy to specify on the command line. It's just that the manual is a tad unclear about this. 2. Where I was being unclear I think is when I was talking about building the system. I have seen in the literature that -jn when installing world Breaks Things. This isn't an issue as I run RELEASE and so only either apply patches or make the system, so easy to specify, where I can, -j3 except in make installkernel and make installworld. thanks, -- John li...@reiteration.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: can make -j be used for ports?
1.
I want to know if there is perhaps a conf file or sysctl where I can
specify this *for ports only.* - if not I'm happy to specify on the
command line. It's just that the manual is a tad unclear about this.
Yes - simply install ports as normal:
specifically unless you specifically tell the ports system otherwise
you will be the maximum amount of supported parallelization.
.if defined(MAKE_JOBS_SAFE) || defined(FORCE_MAKE_JOBS)
MAKE_JOBS_NUMBER?= `${SYSCTL} -n kern.smp.cpus`
_MAKE_JOBS?=-j${MAKE_JOBS_NUMBER}
causes ports to be build with the proper number of jobs for your
system. If you wish to override this number change MAKE_JOBS_NUMBER.
DO NOT manually set -j when running make install from the ports
directory. It will only hurt,
--
Eitan Adler
___
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: deprecated ports
On 03/15/2011 15:16, Charlie Kester wrote: BTW, I don't use either of these, or gimpshop, so I'm not going to fix the ports myself. Instead, I'll leave that to anyone who's interested. Charlie, I think you've been very diplomatic in your approach, so to be clear I don't have a problem with either the content or method of your messages. That said, I think that un-deprecating these ports just because someone can find a distfile somewhere is the wrong approach. bapt has been very careful to only deprecate ports that are on the absolute bottom of the pile. They are unmaintained, and unfetchable. That's generally a very good indication that they are also unused. Thus marking them deprecated to see if anyone picks them up, and then removing them if not, is the right approach. I also think that what you did with sysutils/lookat is proof that this method works. Further, IMO we need to be much more aggressive in removing stale ports. Anything that is removed that it turns out people actually use can be restored from CVS literally with a few keystrokes. It's all well and good to say how cool it is that we have 22,000+ ports, but when you start looking at maintenance, infrastructure updates, etc. having stale stuff makes life much harder for everyone. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: deprecated ports
16.03.2011 01:27, Charlie Kester пишет: Maybe it wasn't there when you looked, but http://www.gimpshop.com/download.shtml has links to download sources for both the development version and the latest release (2.2.8). They even have an alternate link for the release version. gimpshop is pretty old and development seems stalled. The next gimp release will have gimpshop-like UI by default so i think it worth deprecating. I also saw that graphics/gimp-greycstoration is finally deprecated. Baptiste you may want to look at ports/154596 to close it. -- Regards, Ruslan ___ 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: deprecated ports
On Wed, 2011-03-16 at 07:40 +0300, Ruslan Mahmatkhanov wrote: gimpshop is pretty old and development seems stalled. The next gimp release will have gimpshop-like UI by default so i think it worth deprecating. That's almost too optimistic thing to say at the moment, as GIMP's single window interface has been in talks, like, since when, early 2009? Instead, we got this: http://libregraphicsworld.org/news.php?readmore=667 While I agree that that gimpshop itself is pretty rotten, there's no viable alternative for people willing (needing?) to use it, so backing up its deprecation with the planned (*cough*) release of GIMP 2.8 probably isn't the very best possible course in this case... At this time, there isn't even a specific release date in plans for 2.8 and even if that eventually happens, many people [citation needed] doubt that the single-UI will actually make it there (as, currently, there's not even a spec finalized for it). Just saying. m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: can make -j be used for ports?
On Mar 15, 2011, at 7:38 PM, John wrote: 1. If I can speed things up, with *ports* as I have a dual cpu, I want to maybe run j2 or j3. I seek clarification which is logically best, because some literature says jn, others jn+1 where n is number of cores. kern.smp.cpus: 2 on my machine. Is there benefit setting this to 3,4,5? If you have plenty of RAM, then setting it somewhat higher than #CPUs is likely to improve performance. Frankly, it's best if you measure things on your own machine against the software you care about building, and decide for yourself whether the difference matters. :-) I want to know if there is perhaps a conf file or sysctl where I can specify this *for ports only.* - if not I'm happy to specify on the command line. It's just that the manual is a tad unclear about this. Setting MAKE_JOBS_NUMBER in /etc/make.conf will only apply to things using the bsd.ports.mk Makefile, unless they've chosen to honor the same variable independently. In other words, you're unlikely to hurt things much by setting it to some reasonable value. Obtain some data and let us know if you run into surprises... Regards, -- -Chuck ___ 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
science/py-obspy.core needs to be renamed
Wen,
The default cvsupd configuration (cvsignore to be exact) prevents the
download of files named *.core
(http://www.freebsd.org/cgi/cvsweb.cgi/CVSROOT-ports/cvsignore?rev=1.4;content-type=text%2Fplain).
The ports you recently committed have this:
cd /usr/ports/science/
grep py-obspy.core Makefile py-obspy.*/*
Makefile:SUBDIR += py-obspy.core
py-obspy.gse2/Makefile:
${PYTHON_PKGNAMEPREFIX}obspy.core=0.4.6:${PORTSDIR}/science/py-obspy.core
py-obspy.mseed/Makefile:BUILD_DEPENDS=
${PYTHON_PKGNAMEPREFIX}obspy.core=0.4.6:${PORTSDIR}/science/py-obspy.core
py-obspy.mseed/Makefile:RUN_DEPENDS=
${PYTHON_PKGNAMEPREFIX}obspy.core=0.4.6:${PORTSDIR}/science/py-obspy.core
py-obspy.signal/Makefile:BUILD_DEPENDS=
${PYTHON_PKGNAMEPREFIX}obspy.core=0.4.6:${PORTSDIR}/science/py-obspy.core
Using cvsup (csup in my case) science/py-obspy.core doesn't get
downloaded, so INDEX creation throws multiple errors, and I'm sure that
if I tried to build those ports they would fail. :)
FYI,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
