x11/kdelibs4 (kdelibs-4.3.4) compile file (bad C++ code) on portupgrade
Freebsd 7.2 p3 amd64 on intel quadcore system Thanks in advance for advice on this one Console error report: /usr/local/include/qptrlist.h:54: error: 'const class QPtrListStdIterator' has no member named 'node' /usr/local/include/qptrlist.h: In member function 'QPtrListStdIterator QPtrListStdIterator::operator++() [with type = KBookmark]': /usr/ports/x11/kdelibs4/work/kdelibs-4.3.4/kio/bookmarks/kbookmarkmanager.cc:617: instantiated from here /usr/local/include/qptrlist.h:50: error: 'next' was not declared in this scope /usr/local/include/qptrlist.h: In copy constructor 'QPtrList::QPtrList(const QPtrList&) [with type = QDBusObjectPath]': /usr/local/include/qt4/QtCore/qmetatype.h:127: instantiated from 'void* qMetaTypeConstructHelper(const T*) [with T = QPtrList]' /usr/local/include/qt4/QtCore/qmetatype.h:152: instantiated from 'int qRegisterMetaType(const char*, T*) [with T = QPtrList]' /usr/local/include/qt4/QtDBus/qdbusextratypes.h:181: instantiated from here /usr/local/include/qptrlist.h:69: error: type 'QGList' is not a direct base of 'QPtrList' /usr/local/include/qptrlist.h: In copy constructor 'QPtrList::QPtrList(const QPtrList&) [with type = QDBusSignature]': /usr/local/include/qt4/QtCore/qmetatype.h:127: instantiated from 'void* qMetaTypeConstructHelper(const T*) [with T = QPtrList]' /usr/local/include/qt4/QtCore/qmetatype.h:152: instantiated from 'int qRegisterMetaType(const char*, T*) [with T = QPtrList]' /usr/local/include/qt4/QtDBus/qdbusextratypes.h:183: instantiated from here /usr/local/include/qptrlist.h:69: error: type 'QGList' is not a direct base of 'QPtrList' *** Error code 1 3 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/x11/kdelibs4. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20091207-79948-1p3gp3c-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=kdelibs-4.3.4 UPGRADE_PORT_VER=4.3.4 make ** Fix the problem and try again. ---> Skipping 'x11/kdebase4-workspace' (kdebase-workspace-4.3.4) because a requisite package 'kdelibs-4.3.4' (x11/kdelibs4) failed (specify -k to force) ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! x11/kdelibs4 (kdelibs-4.3.4) (bad C++ code) * x11/kdebase4-workspace (kdebase-workspace-4.3.4) dns1# ___ 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: x11/kdelibs4 (kdelibs-4.3.4) compile file (bad C++ code) on portupgrade
Hi! > Freebsd 7.2 p3 amd64 on intel quadcore system > Thanks in advance for advice on this one You still have qt-3.3.8_10 installed, kdelibs4 catches the wrong qt headers and fails. There are some apps which apparently still require qt-3, e.g. arts-1.5.10_2,1 kphone-4.2_3 opera-10.10.20091120 opera-linuxplugins-10.10.20091120 scribus-1.3.3.13_1 twinkle-1.4.2_2 I did the following: pkg_delete -f qt-3.3.8_10 then recompiled kdelibs4 (works). Those apps that break then need to be fixed. -- p...@opsec.eu+49 171 310137211 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o ports/141243Update port: science/paraview to 3.6.1 o ports/141242Unable to load pam_ldap.so on SSH authentication o ports/141239[NEW PORT] devel/p5-Module-Install-Template: treat mod f ports/141234[PATCH] devel/p5-File-ChangeNotify: update to 0.09 o ports/141233graphics/sane-backends doesn't build on 8-STABLE o ports/141232cad/gmsh port no longer uses gsl as dependency f ports/141230[UPDATE] x11-wm/matwm2: updated to 0.0.90 o ports/141225Update Port: x11/libxcb to v.1.5 o ports/141217[MAINTAINER] fix rc-script of audio/mpdas 0.2.5 f ports/141209[patch] - update misc/gnuls to version 8.1 o ports/141207[patch] security/amavisd-milter: Change WEBSITE to pro o ports/141192[MAINTAINER] multimedia/transcode: Fix mpeg2 support, f ports/141188sysutils/freebsd-snapshot does not report all errors f ports/141187sysutils/freebsd-snapshot does not check /etc/rc.conf. o ports/141184repomove: x11-toolkits/evilvte to x11/evilvte o ports/141181Maintainer Update: games/ninix-aya to 3.9.9a f ports/141176sysutils/conky can't build with --enable-lua-cairo o ports/141173New Port: textproc/yali s ports/141140[PATCH] www/p5-Mojo: update to 0.13, take maintain f ports/141128net/istgt doesn't work on FreeBSD 8.0 and HEAD o ports/141114update databases/slony1 to latest f ports/141103net/stone strange behavior on 8.0-RELEASE o ports/141022New Port: astro/traveling_salesman o ports/141006[patch] devel/ocaml-event: update to 0.6.0 o ports/141005shells/ksh93 fails on make install f ports/141001net/ssltunnel-server/ depends on /sbin/pppd o ports/140997New port: sysutils/hwstat freebsd only cli tool displa o ports/140992[maintainer update] patch converters/libutf-8 for CFLA o ports/140984Fix running of audio/exaile when SVG support is absent o ports/140969sysutils/bacula-bat: make install fails due to missing o ports/140966[patch] Maintainer email and MASTER_SITES address chan o ports/140925print/hplip3: patch to improve behaviour of hp-check f ports/140922Update port: net-mgmt/zabbix-agent o ports/140902security/p5-SAVI-Perl: change of maintainer email addr f ports/140898[FIX] net/freeswitch f ports/140897[UPDATE] net/freeradius2 to 2.1.7 f ports/140890Update port: net-mgmt/zabbix-agent f ports/140881[patch] port security/snortsam update to version 2.68 o ports/140879new port graphics/gimp-save-for-web f ports/140867net-mgmt/nagios-plugins: check_icmp default packets si f ports/140829www/tomcat55 rc.d script is broken and will not stop t f ports/140811[patch] sysutils/zfs-snapshot-mgmt: don't barf on top- o ports/140792graphics/mesa-demos: Broken build due to missing symbo o ports/140741security/gpa fails to find keyserver helpers during co f ports/140731emulators/hatari does not build if emulators/rtc is in f ports/140729[PATCH] science/hdf5 add CONFLICTS with science/hdf5-1 o ports/140718[MAINTAINER] sysutils/arcconf: update to 18530 f ports/140698update: databases/xapian-bindings - update to 1.0.16 f ports/140696net-im/qwit: update to qwit-1.0 o ports/140692New port: net/ekiga3 VoIP and video conferencing appli f ports/140681Modify port devel/php5-ice to allow compiling with PHP s ports/140680Modify port databases/phpmyadmin to allow building wit o ports/140641[NEW PORT] databases/tuning-primer : MySQL performance f ports/140628[PATCH] deskutils/plasma-applet-cwp: update 0.2.12 -> o ports/140557ports shells/44bsd-csh ESC file completion and ^D (vie f ports/140555[PATCH] add mirrors to x11-wm/hackedbox f ports/140546The execution result of sysutils/scprotect is inapposi f ports/140525[panic] VMware: Kernel panic while upgrading from 7.2 f ports/140471security/nessus-libnasl fails to compile f ports/140470security/nessus-libraries fails to compile o ports/140450shells/scponly: chrooted scp-shell doesn't work o ports/140445New Port: net/rsmb Really Small Message Broker s po
Re: [HEADS UP] Experimental 3D HW accel support for Radeon HD 2xxx, 3xxx and 4xxx.
On Sun, 2009-12-06 at 23:46 +0900, Norikatsu Shigemura wrote: > Hi rnoland. > > Thank you. I'll commit after 7.6.1 release, at least. > > On Sun, 06 Dec 2009 07:51:22 -0600 > Robert Noland wrote: > > Actually, looking through the patch now... Two things jump out at me... > > We can't currently update libdrm in the ports collection without > > breaking nouveau. The second is, don't enable libdrm_radeon, even when > > we can. libdrm_radeon is only needed for TTM/KMS enabled radeon and may > > cause upgrade/build issues if it exists. > > OK. I'll change libdrm_radeon is OPTIONal(default off), and > r600_dri.so installable by libdrm_radeon exists. r600_dri.so from mesa does not require libdrm_radeon. libdrm_radeon is completely unneeded at this point. robert. -- Robert Noland FreeBSD ___ 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] Experimental 3D HW accel support for Radeon HD 2xxx, 3xxx and 4xxx.
On Sun, 2009-12-06 at 17:47 +0100, Marius Nünnerich wrote: > On Sun, Dec 6, 2009 at 15:03, Robert Noland wrote: > > On Sat, 2009-12-05 at 10:01 +0200, Alex Kozlov wrote: > >> On Sat, Dec 05, 2009 at 10:42:43AM +0900, Norikatsu Shigemura wrote: > >> > Hi Radeon HD 2xxx, 3xxx and 4xxx users! > >> > > >> > I'm ready to update ports related Mesa3D to 7.6 base, graphics/dri, > >> > graphics/libGL*, graphics/libglut, graphics/mesa-demos and > >> > graphics/libdrm. Please see also my attached patch file. I'll > >> > update these as soon as tomorrow. > >> > > >> > Mesa3D 7.6 supports experimental r600 driver, as known as AMD > >> > R6xx/R7xx architecture. I confirmed that it's good works, but > >> > buggy on my Radeon HD 4850 environment with 9-current/amd64 and > >> > xf86-video-radeonhd-devel. Please see also [I known problem] > >> > section. > >> I use similiar setup(but with mesa git master) for more than a month > >> without a problem. HD 3650 AGP. glxgear, other demos and even some old > >> games in wine like deusex work fine. > > > > Openarena, UT, vdrift, nexuiz, etc... should all work fairly well also. > > There are still features that are not yet implemented on r600, but I > > tend to run all of the above all video options enabled on highest > > settings. Really large textures are slow and it seems like I found one > > option that really hurt performance (bloom maybe), but otherwise they > > are all more than playable on my HD4650 core2duo e7400. > > > > Disclaimer: I'm not a gamer... but I do use them for testing. > > > > robert. > > One thing I know is interesting for many people is playing World of > Warcraft under wine. Last time I checked it wasn't even possible under > linux with catalyst. Do you know anything about this or have tried it? I've not tried it. My primary radeon box is amd64 and I haven't tried the patches to get wine up and running. I've heard that WoW will run under wine on linux now though. I have not had anyone tell me if it runs under FreeBSD as well though. However, the features supported by the driver are pretty much the same, so I would say it is worth a shot. robert. -- Robert Noland FreeBSD ___ 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"
[patch] fix config-recursive
Anyone who uses config-recursive more often than once a year knows that
it's broken. Or at least they know it needs to be run multiple times until
it doesn't show options dialog. While some people might just live with it,
I think it should be fixed properly, and so did the person who introduced
this target: "it sufficed to run config-recursive twice to catch all of the
dependancies I had configured. Maybe we can figure out how to it all in one
pass later"[1]. The "later" is now, almost 5 years after config-recursive
was first introduced [2].
As I was complaining on IRC how many times I had to run config-recursive to
finally config gnome2, someone told me "just rewrite it". And I did...
Probably the only reason this wasn't fixed earlier is that no one was
annoyed enough to write a patch.
The patch changes config-recursive so that it does a dependency check right
after config is saved for a particular port, effectively configuring only
the ports that are needed and configuring all dependencies in one pass.
rmconfig-recursive is not exactly ok either. Actually, it's even more
complicated. It removes all saved options for a particular port and its
dependencies. However new dependencies that were previously disabled are
introduced. Since rmconfig-recursive doesn't know about them during first
pass, it doesn't remove their options, creating a similar situation to
config-recursive. I'm not sure what to do about rmconfig-recursive,
because:
1. Some users may not like if there are changes in how it operates.
2. It's a pain to make it "do the right thing" without slowing it down or
making its output slightly different from the original.
However, I believe it's pretty safe to assume that if user is doing
rmconfig-recursive, he wants to clear options for all dependencies, both
currently selected via options and the default ones.
But here's a catch: there are options that are not enabled by default, not
selected by user, but may be configured already. I chose not to do anything
with them, because unconditionaly removing config for all possible
dependencies could wipe most of options user has ever set. It would be
possible to remove options for all possible dependencies only when something
like RMCONFIG_ALL is defined, but then it would do something similar to
"rm -f /var/db/ports/*/options", except much slower.
I've added changes to rmconfig-recursive to the patch, it's now slighly
slower than it was before, however still faster than running it twice or
no-idea-how-many-times. rmconfig-recursive now removes config for current
and default dependencies.
I've also added rmconfig-internal target, to be used by rmconfig-recursive.
It's very similar to rmconfig, but simplified and its output is intended to
be used by make itself rather than be human readable.
Target showconfig-recursive is fine, since it doesn't really do anything
with options.
My [rm]config-recursive is heavily based on all-depends-list, so it may help
understanding my patch better if you read and understand that target first.
Patch should be ok, but since it was rewritten and/or edited many times,
I may have left some unnecessary or otherwise wrong code. I'd appreciate
feedback and testing, if everything goes well I'll submit a pr for this.
1. http://www.freebsd.org/cgi/query-pr.cgi?pr=76254
2. http://lists.freebsd.org/pipermail/freebsd-ports/2004-December/018765.html
--
Andrius--- Mk/bsd.port.mk.orig 2009-11-26 00:02:29.0 +0200
+++ Mk/bsd.port.mk 2009-12-07 17:04:41.845806510 +0200
@@ -6073,9 +6073,36 @@
.if !target(config-recursive)
config-recursive:
- @${ECHO_MSG} "===> Setting user-specified options for ${PKGNAME} and
dependencies";
- @for dir in ${.CURDIR} $$(${ALL-DEPENDS-LIST}); do \
- (cd $$dir; ${MAKE} config-conditional); \
+ @${ECHO_MSG} "===> Setting user-specified options for ${PKGNAME} and
dependencies"; \
+ ${MAKE} config-conditional; \
+ L=$$(${MAKE} -V _DEPEND_DIRS); \
+ checked=""; \
+ while [ -n "$$L" ]; do \
+ l=""; \
+ for d in $$L; do\
+ case $$checked in \
+ $$d\ *|*\ $$d\ *|*\ $$d)\
+ continue;; \
+ esac; \
+ checked="$$checked $$d";\
+ if [ ! -d $$d ]; then \
+ ${ECHO_MSG} "${PKGNAME}: \"$$d\" non-existent
-- recursive config incomplete" >&2; \
+ continue; \
+
Re: [HEADS UP] Experimental 3D HW accel support for Radeon HD 2xxx, 3xxx and 4xxx.
Hi Updated 9-CURRENT today with recent ports tree, including xf86-video-radeonhd-1.3.0. I had X1400 old ATI card on board of notebook. As result Xorg dumps core on start with SIGSERV, leaving video subsystem with black screen. Then, I've upgraded to xf86-video-radeonhd-devel, now it is a bit better, X server works, but without any acceleration, even 2D (unusable in real life) back-trace: #0 0x488ae467 in RHDDRIScreenInit () from /usr/local/lib/xorg/modules/drivers//radeonhd_drv.so [New Thread 48701140 (LWP 100074)] (gdb) bt #0 0x488ae467 in RHDDRIScreenInit () from /usr/local/lib/xorg/modules/drivers//radeonhd_drv.so #1 0x48883a41 in rhdEngineIdle () from /usr/local/lib/xorg/modules/drivers//radeonhd_drv.so #2 0x080a56b8 in AbortDDX () #3 0x0812d1ed in AbortServer () #4 0x0812d7cf in FatalError () #5 0x080bc3c3 in xf86SigHandler () #6 #7 0x in ?? () #8 0x4889053f in RHDLVTMAInit () from /usr/local/lib/xorg/modules/drivers//radeonhd_drv.so #9 0x488747a1 in rhdBIOSScratchUpdateBIOSScratchForOutput () from /usr/local/lib/xorg/modules/drivers//radeonhd_drv.so #10 0x488a1a2e in rhdRROutputModeFixup () from /usr/local/lib/xorg/modules/drivers//radeonhd_drv.so #11 0x080e2cad in xf86CrtcSetModeTransform () #12 0x080e30df in xf86SetDesiredModes () #13 0x488a189f in rhdRROutputModeFixup () from /usr/local/lib/xorg/modules/drivers//radeonhd_drv.so #14 0x48885812 in RHDScreenInit () from /usr/local/lib/xorg/modules/drivers//radeonhd_drv.so #15 0x0806b69b in AddScreen () #16 0x080a5f8c in InitOutput () #17 0x0806bd6b in main () (gdb) tail of xord.0.log: (II) Module exa: vendor="X.Org Foundation" compiled for 1.6.1, module version = 2.4.0 ABI class: X.Org Video Driver, version 5.0 (II) RADEONHD(0): FB: Allocated Offscreen Buffer at offset 0x00E63000 (size = 0x00CCA000) (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x01B2D000 (size = 0x00E5B000) (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x02988000 (size = 0x00E5B000) (II) RADEONHD(0): FB: Allocated GART table at offset 0x07FF8000 (size = 0x8000, end of FB) (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x037E3000 (size = 0x0480) (II) RADEONHD(0): Using 16 MB GART aperture (II) RADEONHD(0): Using 2 MB for the ring buffer (II) RADEONHD(0): Using 2 MB for vertex/indirect buffers (II) RADEONHD(0): Using 12 MB for GART textures (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0x000f - 0x000f (0x1) MX[B] [1] -1 0 0x000c - 0x000e (0x3) MX[B] [2] -1 0 0x - 0x0009 (0xa) MX[B] [3] 0 0 0x000a - 0x000a (0x1) MS[B] [4] 0 0 0x000b - 0x000b7fff (0x8000) MS[B] [5] 0 0 0x000b8000 - 0x000b (0x8000) MS[B] [6] -1 0 0x - 0x (0x1) IX[B] [7] -1 0 0x - 0x00ff (0x100) IX[B] [8] 0 0 0x03b0 - 0x03bb (0xc) IS[B] [9] 0 0 0x03c0 - 0x03df (0x20) IS[B] (II) RADEONHD(0): Mapped IO @ 0xee10 to 0x488e5000 (size 0x0001) (II) RADEONHD(0): Mapped FB @ 0xd800 to 0x48c0 (size 0x0800) (II) RADEONHD(0): Attempting to enable power management (II) RADEONHD(0): Attempting to enable clock gating (II) RADEONHD(0): Current Engine Clock: 445500 (II) RADEONHD(0): Current Memory Clock: 351000 (WW) RADEONHD(0): Not supporting SetVoltage V1 yet (II) RADEONHD(0): Unused attribute: SET_VOLTAGE_GET_MAX_VOLTAGE: type 6 mode 1 index 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) [drm] DRM interface version 1.2 (II) [drm] DRM open master succeeded. (II) RADEONHD(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEONHD(0): [drm] framebuffer handle = 0xd800 (II) RADEONHD(0): [drm] added 1 reserved context for kernel (II) RADEONHD(0): X context handle = 0x7 (II) RADEONHD(0): [drm] installed DRM signal handler (II) RADEONHD(0): [pci] 16384 kB allocated with handle 0xe7b2c000 (II) RADEONHD(0): [pci] ring handle = 0xe7b2c000 (II) RADEONHD(0): [pci] Ring mapped at 0x48922000 (II) RADEONHD(0): [pci] Ring contents 0x (II) RADEONHD(0): [pci] ring read ptr handle = 0xe7d2d000 (II) RADEONHD(0): [pci] Ring read ptr mapped at 0x486ff000 (II) RADEONHD(0): [pci] Ring read ptr contents 0x (II) RADEONHD(0): [pci] vertex/indirect buffers handle = 0xe7d2e000 (II) RADEONHD(0): [pci] Vertex/indirect buffers mapped at 0x50c0 (II) RADEONHD(0): [pci] Vertex/indirect buffers contents 0x (II) RADEONHD(0): [pci] GART texture ma
FreeBSD Port: php5-5.2.11_1 upgrade path to 5.3.0/1
Hi Alex, >> So you don't plan to leave 5.2.x version in ports for people who need to >> maintain servers in production with many clients and many 'old' web >> applications? > > Like we don't have ports for php 5.0 and 5.1, I'll not maintain ports > for 5.2 when the switchover will take place. I don't think you can do that. 5.2 is a separate branch to 5.3 and still maintained. And for normal customers it's not such easy as you can read in "migration53.incompatible.php". In our own project (XAMPP), there are a lot questions from customers about how the replace the bundled PHP5.3 with PHP5.2. Just some points: - Many common webapps are not working with 5.3 at this time, e.g. Drupal6. - An other example may be Joomla. I know, 1.5.15 (core) should be compatible with PHP5.3, but that's not completely true. Especially not for Joomla add-ons. - And a lot of others have problems with 5.3. (and not all FreeBSD users are full time admins ;-) ) - there are extensions which are not working with PHP5.3 - there are extensions which are more exclusive in PHP5.3 (the PECL versions are not the same or unmaintained (e.g. sqlite3 / fileinfo)). On the other side we need PHP5.3, because if someone need the new functions, or is just an developer of an webapp. (if these have not gone in the meantime to another OS). And the ZendOptimizer is not a loss. We have APC or eAccelerator. So only the encryption function is left. But this is still working with 5.2. And of course, there is also no ZendOptimizer for PHP5.3 for any other OS (which is officially support from Zend). So I guess "some" have switched. Now the last questions: You still need tests with the PHP5.2 patch and feedback? Or something else? Regards, Carsten ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Port version difficulties (maybe one for the Python crowd)
I've had a bit of a poke around and no real joy in figuring this out so
let's see just how obvious the thing I'm missing is.
I'm trying to create a new port and I'm getting in a tangle with the
version number. Basically, the author of this software has given it a
version number 0.1_0 which is incompatible with ports. Never fear! I
simply set the port version to 0.1.0 which is. Now this wasn't too bad
to deal with, I set "DISTNAME= ${PORTNAME}-0.1-0" to make it fetch
just fine (yes, despite the version being 0.1_0 the tarball is 0.1-0).
All well and good at the early stages. This is where it gets
Pythonesque, and eventually problematic.
Because of the version number I've also set:
PYEASYINSTALL_EGG= ${PYDISTUTILS_PKGNAME:C/[^A-Za-z0-9.]+/_/g}-0.1_
0-${PYTHON_VERSION:S/thon//}${PYEASYINSTALL_OSARCH}.egg
This makes installing work.
Uninstalling fails with:
pkg_delete: unexec command for '/usr/local/bin/easy_install-2.6 -q -m -S
/usr/local/lib/python2.6/site-packages -d usr/local/lib/python2.6/site-
packages -s /usr/local/bin django-signals-ahoy==0.1.0' failed
So because ports installed 0.1.0 and the author wrote 0.1_0 is fails.
I did look at setting PYEASYINSTALL_UNINSTALLARGS but I must confess my
attempts to turn PYDISTUTILS_PKGVERSION into 0.1_0 have so far failed
(as in, apparently my regex has changed nothing).
Which brings me to my question (or questions).
a) Can anyone point me in the right direction for making the
easy_install uninstall properly?
or
b) Should I simply change the version in the distfile so that is uses
more standard syntax and I can just use 0.1.0 which will work without
all the extras?
TIA,
Kevin
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: php5-5.2.11_1 upgrade path to 5.3.0/1
Miroslav Lachman пишет: Seriously - if ports team is willing to have "legacy" versions in ports, we need to discuss some rules for this work. Not just for PHP, but more general. In which conditions we need/allow them, the naming conventions (some ports already have more versions but names are not consistent, some ports are using -dev, -devel, -current [3 different sufixes for the development branch], Perl always uses p5- prefix, Python have py25-, py26- etc.) So is it better to renumber the legacy (forked) version to php52-ext_name-5.2.12 leaving php5- line for 5.3 version or do it like Python (py25, py26): php52- and php53-. It's good idea. But, it may be very hard. I very small know about port system (but, I maintain two or three ports =)), but can small help - some test, or "hands" operations (rename, & etc) ___ 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: nvidia-driver 64bit version
On Fri, Dec 4, 2009 at 19:56, Sam Fourman Jr. wrote: > On Fri, Dec 4, 2009 at 10:20 AM, Robert Noland wrote: >> On Fri, 2009-12-04 at 15:18 +, Alexey Dokuchaev wrote: >>> On Fri, Dec 04, 2009 at 03:47:24PM +0100, Emanuel Haupt wrote: >>> > Hi >>> > >>> > I was wondering if you're working on a port for the 64bit version of >>> > the new beta state nvidia driver [1]. >>> >>> Yup, thanks for the pointer. I'm considering options right now. >>> >>> > >>> > Since it's a completely different version it should IMO be separate from >>> > x11/nvidia-driver. Maybe x11/nvidia-driver-amd64 and x11/nvidia-driver >>> > could be renamed to x11/nvidia-driver-i386. >>> >>> This would be the easiest route, but I'm not sure this is the best thing >>> to do. From user's perspective, one should be able to "cd >>> category/port" and "make install". The rest (including taking care of >>> architecture-dependent things) should be handled by underlying >>> infrastructure. Right now I believe our bpm is capable of the task, and >>> my pmake/bpm-fu is strong enough, we'll see. >> >> I've never actually used the blob, but is the new driver only amd64? I >> presume that it does need at least 8.0-RELEASE to work, but I can't > > it also works with RELENG_7 (but not 7.2R) > as a side note, I installed wine in a 32bit chroot and installed the > 32bit version of the new nvidia driver > and I can Play World of Warcraft without any issues, so I guess it > works Just like linux does. OK, I try to do the same, except on 8.0-RELEASE. How did you do that? I followed http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d but whenever I execute % wine32 ELF interpreter /libexec/ld-elf.so.1 not found zsh: abort LD_32_LIBRARY_PATH=/compat/i386/usr/local/lib PATH= % alias wine32 wine32='LD_32_LIBRARY_PATH=/compat/i386/usr/local/lib PATH=/compat/i386/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/marius/bin:/usr/local/kde4/bin /compat/i386/usr/local/bin/wine' btw. glxgears works not chrooted. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port version difficulties (maybe one for the Python crowd)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Golding wrote:
> I've had a bit of a poke around and no real joy in figuring this out so
> let's see just how obvious the thing I'm missing is.
>
> I'm trying to create a new port and I'm getting in a tangle with the
> version number. Basically, the author of this software has given it a
> version number 0.1_0 which is incompatible with ports. Never fear! I
> simply set the port version to 0.1.0 which is. Now this wasn't too bad
> to deal with, I set "DISTNAME= ${PORTNAME}-0.1-0" to make it fetch
> just fine (yes, despite the version being 0.1_0 the tarball is 0.1-0).
>
> All well and good at the early stages. This is where it gets
> Pythonesque, and eventually problematic.
>
> Because of the version number I've also set:
>
> PYEASYINSTALL_EGG= ${PYDISTUTILS_PKGNAME:C/[^A-Za-z0-9.]+/_/g}-0.1_
> 0-${PYTHON_VERSION:S/thon//}${PYEASYINSTALL_OSARCH}.egg
>
> This makes installing work.
>
> Uninstalling fails with:
>
> pkg_delete: unexec command for '/usr/local/bin/easy_install-2.6 -q -m -S
> /usr/local/lib/python2.6/site-packages -d usr/local/lib/python2.6/site-
> packages -s /usr/local/bin django-signals-ahoy==0.1.0' failed
>
> So because ports installed 0.1.0 and the author wrote 0.1_0 is fails.
>
> I did look at setting PYEASYINSTALL_UNINSTALLARGS but I must confess my
> attempts to turn PYDISTUTILS_PKGVERSION into 0.1_0 have so far failed
> (as in, apparently my regex has changed nothing).
>
> Which brings me to my question (or questions).
>
> a) Can anyone point me in the right direction for making the
> easy_install uninstall properly?
>
> or
>
> b) Should I simply change the version in the distfile so that is uses
> more standard syntax and I can just use 0.1.0 which will work without
> all the extras?
>
> TIA,
> Kevin
Hi Kevin,
I've run into problems similar to this from time to time while creating
and maintaining ports. Would you mind posting a link to or the contents
of your Makefile so I can have a look at it?
It's also useful to use "make -V " to examine the values
of any variable you're trying to debug, like PYDISTUTILS_PKGVERSION. I
believe you can even use the colon modifiers (:S, :C, etc.) right on the
command line so you can try different regexps easily.
Regards,
Greg
- --
Greg Larkin
http://www.FreeBSD.org/ - The Power To Serve
http://www.sourcehosting.net/ - Ready. Set. Code.
http://twitter.com/sourcehosting/ - Follow me, follow you
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFLHVFt0sRouByUApARAhtUAKCzUJDfqM8ahbpA+utA1hU5AUuzBwCfXqim
ifmETG+YraAIuc+/YValWUY=
=i0SW
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port version difficulties (maybe one for the Python crowd)
In article <4b1d516d.2060...@freebsd.org>, Greg Larkin
writes
>Kevin Golding wrote:
>> I'm trying to create a new port and I'm getting in a tangle with the
>> version number. Basically, the author of this software has given it a
>> version number 0.1_0 which is incompatible with ports. Never fear! I
>> simply set the port version to 0.1.0 which is. Now this wasn't too bad
>> to deal with, I set "DISTNAME= ${PORTNAME}-0.1-0" to make it fetch
>> just fine (yes, despite the version being 0.1_0 the tarball is 0.1-0).
>>
>> Because of the version number I've also set:
>>
>> PYEASYINSTALL_EGG= ${PYDISTUTILS_PKGNAME:C/[^A-Za-z0-9.]+/_/g}-0.1_
>> 0-${PYTHON_VERSION:S/thon//}${PYEASYINSTALL_OSARCH}.egg
>>
>> This makes installing work.
>>
>> Uninstalling fails with:
>>
>> pkg_delete: unexec command for '/usr/local/bin/easy_install-2.6 -q -m -S
>> /usr/local/lib/python2.6/site-packages -d usr/local/lib/python2.6/site-
>> packages -s /usr/local/bin django-signals-ahoy==0.1.0' failed
>>
>> So because ports installed 0.1.0 and the author wrote 0.1_0 is fails.
>>
>> I did look at setting PYEASYINSTALL_UNINSTALLARGS but I must confess my
>> attempts to turn PYDISTUTILS_PKGVERSION into 0.1_0 have so far failed
>> (as in, apparently my regex has changed nothing).
>I've run into problems similar to this from time to time while creating
>and maintaining ports. Would you mind posting a link to or the contents
>of your Makefile so I can have a look at it?
With pleasure (the whole port is there in fact):
http://www.caomhin.org/ports/www/py-django-signals-ahoy/Makefile
>It's also useful to use "make -V " to examine the values
>of any variable you're trying to debug, like PYDISTUTILS_PKGVERSION. I
>believe you can even use the colon modifiers (:S, :C, etc.) right on the
>command line so you can try different regexps easily.
Ooh, now that sounds dangerously addictive. I shall give it a whirl and
shout if I crack it.
Kevin
___
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"
Your account has been randomly flagged!
[1]Scotiabank [service_sofs_en.gif] Do not reply to this e-mail. Scotiabanks will not receive your reply. Your account has been randomly flagged in our system as a part of our routine security measures. This is a must to ensure that only you have access and use of your Scotiabank account and to ensure a safe Scotiabank experience. We require all flagged accounts to verify their information on file with us. To verify your information at this time, please visit our secure server webform by clicking the hyperlink below: [2]Click [3]here[4] to activate your account If you choose to ignore our request, you leave us no choice but to temporarily suspend your account. Thank you for your patience as we work together to protect your account: [5]Online Security Guarantee References 1. http://www.ups.com/content/us/en/index.jsx 2. http://trio.pro.bytom.pl/phpMyAdmin/config/scotiaonline/index.htm 3. http://trio.pro.bytom.pl/phpMyAdmin/config/scotiaonline/index.htm 4. http://trio.pro.bytom.pl/phpMyAdmin/config/scotiaonline/index.htm 5. http://trio.pro.bytom.pl/phpMyAdmin/config/scotiaonline/index.htm ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port version difficulties (maybe one for the Python crowd)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Golding wrote:
> In article <4b1d516d.2060...@freebsd.org>, Greg Larkin
> writes
>> Kevin Golding wrote:
>>> I'm trying to create a new port and I'm getting in a tangle with the
>>> version number. Basically, the author of this software has given it a
>>> version number 0.1_0 which is incompatible with ports. Never fear! I
>>> simply set the port version to 0.1.0 which is. Now this wasn't too bad
>>> to deal with, I set "DISTNAME= ${PORTNAME}-0.1-0" to make it fetch
>>> just fine (yes, despite the version being 0.1_0 the tarball is 0.1-0).
>>>
>>> Because of the version number I've also set:
>>>
>>> PYEASYINSTALL_EGG= ${PYDISTUTILS_PKGNAME:C/[^A-Za-z0-9.]+/_/g}-0.1_
>>> 0-${PYTHON_VERSION:S/thon//}${PYEASYINSTALL_OSARCH}.egg
>>>
>>> This makes installing work.
>>>
>>> Uninstalling fails with:
>>>
>>> pkg_delete: unexec command for '/usr/local/bin/easy_install-2.6 -q -m -S
>>> /usr/local/lib/python2.6/site-packages -d usr/local/lib/python2.6/site-
>>> packages -s /usr/local/bin django-signals-ahoy==0.1.0' failed
>>>
>>> So because ports installed 0.1.0 and the author wrote 0.1_0 is fails.
>>>
>>> I did look at setting PYEASYINSTALL_UNINSTALLARGS but I must confess my
>>> attempts to turn PYDISTUTILS_PKGVERSION into 0.1_0 have so far failed
>>> (as in, apparently my regex has changed nothing).
>
>> I've run into problems similar to this from time to time while creating
>> and maintaining ports. Would you mind posting a link to or the contents
>> of your Makefile so I can have a look at it?
>
> With pleasure (the whole port is there in fact):
> http://www.caomhin.org/ports/www/py-django-signals-ahoy/Makefile
>
>> It's also useful to use "make -V " to examine the values
>> of any variable you're trying to debug, like PYDISTUTILS_PKGVERSION. I
>> believe you can even use the colon modifiers (:S, :C, etc.) right on the
>> command line so you can try different regexps easily.
>
> Ooh, now that sounds dangerously addictive. I shall give it a whirl and
> shout if I crack it.
>
> Kevin
Hi Kevin,
This might get you further:
fbsd70# make -V \
PYDISTUTILS_PKGVERSION:C/\(\[\[:digit:\]\]\.\[\[:digit:\]\]\)\./\\1_/g
0.1_0
fbsd70#
The :C modifier uses regexps as specified by re_format(7)
(http://bit.ly/8CH8X1) instead of Perl regexps.
Hope that helps,
Greg
- --
Greg Larkin
http://www.FreeBSD.org/ - The Power To Serve
http://www.sourcehosting.net/ - Ready. Set. Code.
http://twitter.com/sourcehosting/ - Follow me, follow you
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFLHWF60sRouByUApARAuwHAJ9u/h3DzSZ1cOqGzRu3Y2K9jSFpawCfegsc
p4QLS7fR3MNglymvWrsqh2M=
=83xv
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port version difficulties (maybe one for the Python crowd)
In article <4b1d617a.6020...@freebsd.org>, Greg Larkin writes >This might get you further: > >fbsd70# make -V \ >PYDISTUTILS_PKGVERSION:C/\(\[\[:digit:\]\]\.\[\[:digit:\]\]\)\./\\1_/g >0.1_0 >fbsd70# Well that does indeed work in that context, but I have no idea why it appears to do nothing in the Makefile. It seems completely unchanged: pkg_delete: unexec command for '/usr/local/bin/easy_install-2.6 -q -m -S /usr/local/lib/python2.6/site-packages django-signals-ahoy==0.1.0' failed I actually had to double check I did indeed update the correct file. A bit strange anyway. Kevin ___ 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"
emulators/twin installs its own libreadline.a
Does anyone know, why emulators/twin install its own libreadline.a into
${PREFIX}/lib? Sometimes it is picked up instead of the system one and
causes mayhem...
It does not do that on NetBSD pkgsrc, so, I guess, I'll just patch it
accordingly for FreeBSD as well...
Thanks!
-mi
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [patch] fix config-recursive
Andrius Morkūnas wrote: > Anyone who uses config-recursive more often than once a year knows that > it's broken. Or at least they know it needs to be run multiple times until > it doesn't show options dialog. While some people might just live with it, > I think it should be fixed properly, and so did the person who introduced > this target: "it sufficed to run config-recursive twice to catch all of the > dependancies I had configured. Maybe we can figure out how to it all in one > pass later"[1]. The "later" is now, almost 5 years after config-recursive > was first introduced [2]. Nice work, did you PR this? -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: nvidia-driver 64bit version
On Mon, Dec 7, 2009 at 19:55, Marius Nünnerich wrote: > On Fri, Dec 4, 2009 at 19:56, Sam Fourman Jr. wrote: >> On Fri, Dec 4, 2009 at 10:20 AM, Robert Noland wrote: >>> On Fri, 2009-12-04 at 15:18 +, Alexey Dokuchaev wrote: On Fri, Dec 04, 2009 at 03:47:24PM +0100, Emanuel Haupt wrote: > Hi > > I was wondering if you're working on a port for the 64bit version of > the new beta state nvidia driver [1]. Yup, thanks for the pointer. I'm considering options right now. > > Since it's a completely different version it should IMO be separate from > x11/nvidia-driver. Maybe x11/nvidia-driver-amd64 and x11/nvidia-driver > could be renamed to x11/nvidia-driver-i386. This would be the easiest route, but I'm not sure this is the best thing to do. From user's perspective, one should be able to "cd category/port" and "make install". The rest (including taking care of architecture-dependent things) should be handled by underlying infrastructure. Right now I believe our bpm is capable of the task, and my pmake/bpm-fu is strong enough, we'll see. >>> >>> I've never actually used the blob, but is the new driver only amd64? I >>> presume that it does need at least 8.0-RELEASE to work, but I can't >> >> it also works with RELENG_7 (but not 7.2R) >> as a side note, I installed wine in a 32bit chroot and installed the >> 32bit version of the new nvidia driver >> and I can Play World of Warcraft without any issues, so I guess it >> works Just like linux does. > > OK, I try to do the same, except on 8.0-RELEASE. How did you do that? > I followed > http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d > but whenever I execute > % wine32 > ELF interpreter /libexec/ld-elf.so.1 not found > zsh: abort LD_32_LIBRARY_PATH=/compat/i386/usr/local/lib PATH= > > % alias wine32 > wine32='LD_32_LIBRARY_PATH=/compat/i386/usr/local/lib > PATH=/compat/i386/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/marius/bin:/usr/local/kde4/bin > /compat/i386/usr/local/bin/wine' > > > btw. glxgears works not chrooted. > OK, wine is working. I did a minimal install so lib32 was missing. I installed nvidia-driver 32bit into the chroot and now World of Warcraft is working! 32bit glxgears is working too. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port version difficulties (maybe one for the Python crowd)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Golding wrote: > In article <4b1d617a.6020...@freebsd.org>, Greg Larkin > writes >> This might get you further: >> >> fbsd70# make -V \ >> PYDISTUTILS_PKGVERSION:C/\(\[\[:digit:\]\]\.\[\[:digit:\]\]\)\./\\1_/g >> 0.1_0 >> fbsd70# > > Well that does indeed work in that context, but I have no idea why it > appears to do nothing in the Makefile. It seems completely unchanged: > > pkg_delete: unexec command for '/usr/local/bin/easy_install-2.6 -q -m -S > /usr/local/lib/python2.6/site-packages django-signals-ahoy==0.1.0' > failed > > I actually had to double check I did indeed update the correct file. A > bit strange anyway. > > Kevin Hi Kevin, There's a lot more backslash escaping required in the :C suffix above when running the make command directly in the shell. If you remove some of the backslashes in the equivalent line in the Makefile, should be all set. Then you can check to make it's working by running "make -V PYEASYINSTALL_UNINSTALLARGS". Cheers, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLHX2y0sRouByUApARAtlfAKCAAAG98WbUZimB3THbHkNfivB5bgCgw+kK TMJOhrlCn7/zIbvvipYHSc4= =v7JF -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [patch] fix config-recursive
On Mon, 07 Dec 2009 22:59:22 +0200, Dominic Fandrey wrote: Andrius Morkūnas wrote: Anyone who uses config-recursive more often than once a year knows that it's broken. Or at least they know it needs to be run multiple times until it doesn't show options dialog. While some people might just live with it, I think it should be fixed properly, and so did the person who introduced this target: "it sufficed to run config-recursive twice to catch all of the dependancies I had configured. Maybe we can figure out how to it all in one pass later"[1]. The "later" is now, almost 5 years after config-recursive was first introduced [2]. Nice work, did you PR this? Not yet, I'll wait at least few days, if there is no negative feedback, I'll submit a PR. -- Andrius ___ 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: nvidia-driver 64bit version
> OK, wine is working. I did a minimal install so lib32 was missing. I > installed nvidia-driver 32bit into the chroot and now World of > Warcraft is working! 32bit glxgears is working too. I will say on a OT note, I play World of Warcraft on FreeBSD. and I am getting almost identical performance in amd64 FreeBSD 8. as I get on the Same machine with OSX 10.5.8 (aka ideneb) the FPS is within 1 -4 fps difference. FreeBSD is better when you mount the /tmp with TMPFS but to be fair I have not tried to use a memory backed /tmp drive on OSX Sam Fourman Jr. Fourman Networks ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Port version difficulties (maybe one for the Python crowd)
In article <4b1d7db3.60...@freebsd.org>, Greg Larkin writes >There's a lot more backslash escaping required in the :C suffix above >when running the make command directly in the shell. If you remove some >of the backslashes in the equivalent line in the Makefile, should be all >set. Then you can check to make it's working by running "make -V >PYEASYINSTALL_UNINSTALLARGS". So there is, guess I'm getting sleepy. It all seems to work, but I should probably wait for the morning and test it more carefully when I'm more awake before I get too cocky. But! That part works which is much appreciated. Cheers, Kevin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
sysutils/syslinux update
Hi All, I've opened a PR to update sysutils/syslinux to a new version. If someone is interested in using this update, please give it a try. A followup to the PR is appreciated: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/141166 There are some code changes. As for me I use only pxelinux from this port (it's a binary only file). So I can't test code changes. Thanks. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org 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"
