Problem till din faktura : 87-4484524812668
Hej! Åtkomst till ditt konto är begränsat eftersom vi har märkt att du har betalat din faktura tva ganger på samma gång, och det är på grund av ett tekniskt fel. När du bekräftar informationen på kortet, kommer vi att återbetala till ditt konto Detaljer : Beställningsnummer : 87-4484524812668 Mobile operator: Telia Betalas av : Kreditkort Status : Väntar på återbetalning Återbetala process: 1 -ladda ner det bifogade dokumentet och öppna den i ett webbläsarfönster. 2 -öppnad kommer du bli ombedd att följa en uppsättning instruktioner. Tack för ditt förtroende, Vi ses snart på www.telia.se Detta mail har skickats automatiskt. Snälla, inte svara, skulle din förfrågan inte verkställas. Telia se @ 2013 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD unmaintained ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: biology/dotter broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=dotter portname: biology/finchtv broken because: fails to checksum build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=finchtv portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con portname: chinese/bitchx broken because: patch reject build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=bitchx portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: converters/p5-Unicode-Lite broken because: Overwrites bin/map from converters/p5-Unicode-Map build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=p5-Unicode-Lite portname: databases/grass broken because: Does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=grass portname: databases/msql broken because: Broken on FreeBSD 9+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=msql portname: databases/ruby-interbase broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-interbase portname: deskutils/libopensync-plugin-python-devel broken because: fails to build with recent libopensync build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=libopensync-plugin-python-devel portname: devel/libYGP broken because: Does not build with recent boost build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libYGP portname: devel/lua50-dfui broken because: Does not build build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/lua50-dfui-0.1.20050901.log (Mar 14 00:26:27 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=lua50-dfui portname: devel/mico broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=mico portname: devel/ppl broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ppl portname: devel/ros_comm broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ros_comm portname: devel/rubygem-zoom broken because: does not work with ruby 1.9 build errors: none. overview:
FreeBSD ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: accessibility/yasr broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=accessibilityportname=yasr portname: archivers/ruby-bz2 broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=ruby-bz2 portname: audio/ruby-vorbisfile broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-vorbisfile portname: audio/ruby-xmms broken because: does not compile with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ruby-xmms portname: biology/dotter broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=dotter portname: biology/finchtv broken because: fails to checksum build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=finchtv portname: cad/salome-geom broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-geom portname: cad/salome-kernel broken because: Does not configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-kernel portname: cad/salome-med broken because: Fails to fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-med portname: cad/salome-yacs broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=salome-yacs portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con portname: chinese/bitchx broken because: patch reject build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=bitchx portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: converters/p5-Unicode-Lite broken because: Overwrites bin/map from converters/p5-Unicode-Map build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=p5-Unicode-Lite portname: converters/pdf2djvu broken because: does not build build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/pdf2djvu-0.5.11_10.log (Mar 14 00:22:50 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=pdf2djvu portname: converters/py-svglib broken because: Does not fetch build errors: none. overview:
FreeBSD unmaintained ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: databases/ruby-interbase description:Ruby interface to Firebird/Interbase library maintainer: po...@freebsd.org status: BROKEN deprecated because: Does not work with Ruby 1.9 expiration date:2013-05-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-interbase portname: devel/ppl description:The Parma Polyhedra Library maintainer: po...@freebsd.org status: BROKEN deprecated because: obsolete version; fails to build expiration date:2013-09-21 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ppl portname: devel/rubygem-zoom description:A Ruby binding to the Z39.50 Object-Orientation Model (ZOOM) maintainer: po...@freebsd.org status: BROKEN deprecated because: Does not work with Ruby 1.9 expiration date:2013-05-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-zoom portname: net-im/jabber-pymsn description:Python MSN-Transport for Jabber maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=jabber-pymsn portname: net-im/p5-Net-MSN description:Net::MSN interface maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=p5-Net-MSN portname: net-im/py-msnp description:MSN messaging in Python maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=py-msnp portname: net-im/pymsn description:MSN Connection library maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=pymsn portname: textproc/fileshuffle description:Filter for shuffling lines in a text file into random order maintainer: po...@freebsd.org deprecated because: Does not work, use gshuf from sysutils/coreutils instead expiration date:2013-09-23 build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/fileshuffle-0.1.log (Mar 14 02:22:34 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=fileshuffle portname: textproc/referrercop description:Filters referrer spam from Apache logs and AWStats data files maintainer: po...@freebsd.org deprecated because: distfile unfetchable expiration date:2014-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=referrercop portname: www/notftp description:An easy to use Web to FTP gateway written in PHP maintainer: po...@freebsd.org deprecated because: distfile unfetchable expiration date:2014-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=notftp portname: www/suphp description:Securely execute PHP scripts under Apache maintainer: po...@freebsd.org deprecated because: Upstream dead, EOL: https://lists.marsching.com/pipermail/suphp/2013-May/002554.html expiration date:2013-12-17 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=suphp portname: x11/silo description:A simple X11 launcher
[HEADS UP] Improved python package support ahead
Two new port Makefile knobs are to be committed to the ports tree in a couple of days or few weeks. PYDISTUTILS_AUTOPLIST This knob will enable the creation of an automatic package list similar to the linux rpm ports and rubygems. It will work for the majority packages that do not install files outside of the site-packages and include directories for python. Ports installing e.g. binaries might need some additional care, since there is a small regression for directories within BSD.local.dist. The knob supports the traditional distutils as well as easy_install on all currently supported python versions. You can mix contents of an existing pkg-plist (e.g. if the port installs additional documentation) with the automatic results. PYTHON_PY3K_PLIST_HACK Several ports currently install python scripts without using the typical python way of doing things (e.g. devel/glib20), but which are byte-compiled. To enable proper support for python 3.2+ within the package lists, this knob will replace the contents of the existing pkg-plist (e.g. share/port/foo.pyc, share/port/foo.pyo) with the proper values. It's based on the plist include hack existing in devel/py-virtualenv, which is currently used by various ports. Both knobs will improve the situation for python packages to be built for Python 3.x as default version. This will not solve all problems at an instant, but reduces the wrong plist entries being created, if you use python3.x as DEFAULT_PYTHON_VERSION. The patch itself can be retrieved from http://people.freebsd.org/~mva/python_mod_plist.diff Cheers Marcus pgpdhrAQxsdVq.pgp Description: PGP signature
[CFT/HEADSUP] Ports now have Stack Protector support
Ports now support enabling Stack Protector [1] support on FreeBSD 10 i386 and amd64, and older releases on amd64 only currently. Support may be added for earlier i386 releases once all ports properly respect LDFLAGS. To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports. The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all may optionally be set instead. Please help test this on your system. We would like to eventually enable this by default, but need to identify any major ports that have run-time issues due to it. [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
New devd-based X.Org autoconfiguration backend
On 09/09/2013 17:52, Niclas Zeising wrote: The attached patch, also available in the latest updated version at http://people.freebsd.org/~zeising/xorg-mesaupdate.diff updates various xorg related libraries and drivers, most of this is visible for all users of xorg. xorg-server now has the possibility to use devd instead of hal for autoconfiguration. And here's an update to that patch that implements a (hopefully) better devd-based autoconfiguration backend. Comments, questions, failure reports are welcome. Note that this backend is only enabled if you're using WITH_NEW_XORG. My attempts to port it to older xserver has so far been a failure (I left a piece of code that will compile with xserver-1.5.x, but X will fail to load drivers when my code asks it to). == How to install it Apply xorg-mesaupdate.diff to your ports tree, or grab the ports tree from Xorg development repo [2] (which is what I do). Apply the patch at [1] on top of that. Reinstall x11-servers/xorg-server with DEVD option on. As a first-time measure, either reboot or run service xhotplug start. Then (re)start X server (don't forget to remove InputDevice sections from your xorg.conf, if you've been using static configuration before). == What it does The backend will first add two devices: syscons keyboard device and sysmouse mouse device. Then, any atp(4), joy(4), psm(4), uep(4), uhid(4) and ums(4) devices will be added and removed dynamically, as they appear in your system. atp, psm and ums devices will by default use xf86-input-mouse driver; uep will use xf86-input-egalax, if it's installed. The rest will have no default driver. You can change the driver, and set any needed options for any of the devices by using InputClass section of xorg.conf (see xorg.conf man page). == Cooperation with moused(8) The backend will try to play along with moused(8): if you have moused_enable=YES (by default it's NO), or moused_nondefault_enable=YES (by default it's YES) set in your rc.conf, moused will be given the priority to take over psm and ums devices. The upside of this is that you'll have mouse working in console. The downside is that X server will only see the combined mouse device (sysmouse), and will not be able to configure each mouse individually. == Keyboards While it is possible to make X server to see and configure each keyboard individually, this backend chooses to let kbdmux(4) take over any ukbd device that appears in your system, and only expose X to one combined keyboard. This is so that your keyboards would work in both X and the console. The alternative (to let Xorg see each keyboard separately, but not to enable them in console) seems too error prone for my taste. == Multiple Xorg servers running at once As discussed earlier in this thread, sharing input devices is not really possible in FreeBSD. If multiple X servers are running on your machine at the same time, each will try to grab every input device, but aside from syscons and sysmouse, they will fail, and only the first server will be able to actually use the device. == Debugging hotplug (Users are not expected to know or care about this part). You can get a list of devices the backend tried to add by running service xhotplug list. Here's what it should show on a typical machine: # service xhotplug list syscons driver=kbd device= flags=keyboard name=System%20Keyboard product=syscons sysmouse driver=mouse flags=pointer name=System%20Mouse product=sysmouse psm0 driver=mouse flags=pointer name=PS%2f2%20Mouse You can remove any device like this: # service xhotplug remove psm0 ... and add it back, with different options: # service xhotplug add psm0 Emulate3Buttons=OFF To verify that X actually has all the devices you think it should have, you can use x11/xinput utility: # xinput ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ System Mouse id=7[slave pointer (2)] ⎜ ↳ PS/2 Mouseid=8[slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ System Keyboard id=6[slave keyboard (3)] [1] http://tx97.net/~magv/diff/xorg-server-1.12.4_2.hotplug.diff [2] https://wiki.freebsd.org/Xorg#Development_Repo ___ 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: [CFT/HEADSUP] Ports now have Stack Protector support
On 09/21/13 05:47, Bryan Drewery wrote: Ports now support enabling Stack Protector [1] support on FreeBSD 10 i386 and amd64, and older releases on amd64 only currently. Why only those architectures? -Nathan ___ 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: [CFT/HEADSUP] Ports now have Stack Protector support
On 9/21/2013 9:00 AM, Nathan Whitehorn wrote: On 09/21/13 05:47, Bryan Drewery wrote: Ports now support enabling Stack Protector [1] support on FreeBSD 10 i386 and amd64, and older releases on amd64 only currently. Why only those architectures? -Nathan I was only able to test on amd64 and i386. And that took 37 exp-runs over a month. See commit and CHANGES for more discussion on why not i386 on 10: http://svnweb.freebsd.org/ports?view=revisionrevision=327697 -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: [CFT/HEADSUP] Ports now have Stack Protector support
On 09/21/13 09:09, Bryan Drewery wrote: On 9/21/2013 9:00 AM, Nathan Whitehorn wrote: On 09/21/13 05:47, Bryan Drewery wrote: Ports now support enabling Stack Protector [1] support on FreeBSD 10 i386 and amd64, and older releases on amd64 only currently. Why only those architectures? -Nathan I was only able to test on amd64 and i386. And that took 37 exp-runs over a month. See commit and CHANGES for more discussion on why not i386 on 10: http://svnweb.freebsd.org/ports?view=revisionrevision=327697 OK. If I set this on powerpc anyway, will it turn on? I'm happy to (slowly) test it there. -Nathan ___ 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: [CFT/HEADSUP] Ports now have Stack Protector support
On 9/21/2013 9:26 AM, Nathan Whitehorn wrote:
On 09/21/13 09:09, Bryan Drewery wrote:
On 9/21/2013 9:00 AM, Nathan Whitehorn wrote:
On 09/21/13 05:47, Bryan Drewery wrote:
Ports now support enabling Stack Protector [1] support on FreeBSD 10
i386 and amd64, and older releases on amd64 only currently.
Why only those architectures?
-Nathan
I was only able to test on amd64 and i386. And that took 37 exp-runs
over a month.
See commit and CHANGES for more discussion on why not i386 on 10:
http://svnweb.freebsd.org/ports?view=revisionrevision=327697
OK. If I set this on powerpc anyway, will it turn on? I'm happy to
(slowly) test it there.
-Nathan
You will need to modify Mk/bsd.ssp.mk to allow it. It would be great to
get feedback on it!
Like so:
.if defined(WITH_SSP) !defined(WITHOUT_SSP) !defined(SSP_UNSAFE) \
-(${ARCH} == i386 || ${ARCH} == amd64)
+(${ARCH} == i386 || ${ARCH} == amd64 || ${ARCH} == powerpc)
# Overridable as a user may want to use -fstack-protector-all
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
net-mgmt/netmond is too old
Dear Colleagues, The net-mgmt/netmond port is very old. netmond-2.3.7 is already available at http://people.freebsd.org/~ae/netmond-2.3.7.tgz Could you update the port please? I have tested netmond-2.3.7 on 8.4-RELEASE i386 with about 80 objects, it works just fine. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: Gimp package?
On 9/19/13, Gary Aitken vagab...@blackfoot.net wrote: On 09/19/13 12:46, grarpamp wrote: Hi. I see that a gimp port exists so I went to try the gimp package but could not find it in the stable i386 package branches on the FTP server, or in say 9 stable amd64. Is there a problem building or distributing it to FTP or am I missing something? The release packages are usually rather old so I use stable. Thanks. I have gimp installed under 9.1, amd64, built from ports and it works great. I don't know about packages, however. Well then that would mean packaging is broken or the port code hasn't made it to FTP package building yet, so nobody can use the package for a while now. ___ 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: Help in testing Basho Riak port
Thank you all for your work and valuable comments! Please, test the latest version of the port, that you can find here: https://www.dropbox.com/s/me9ej0br78ayws1/riak.20130921.tgz and let me know if you can find any issues. Kind regards, B. On Fri, Sep 20, 2013 at 6:57 PM, Big Lebowski spankthes...@gmail.comwrote: Hi list! I've been working for couple last days on porting Basho Riak database (latest version 1.4.2) and finally I think it is ready to be presented: https://www.dropbox.com/s/2ztu2bdiip1u2un/riak.tgz Please, grab the port and test it on anything you can, break it in any way possible, and comment on anything you see that's been done wrong - I am open to any suggestion on how to make it worthy candidate for send-pr with port submission. Any help will be highly appreciated and will motivate me to port more cool software to FreeBSD! ;) Kind regards, S. ___ 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
Fwd: Help in testing Basho Riak port
Hi,
Thanks for your comments, see mine below.
On Fri, Sep 20, 2013 at 9:37 PM, Bryan Drewery br...@shatow.net wrote:
On Fri, Sep 20, 2013 at 06:57:52PM +0100, Big Lebowski wrote:
Hi list!
I've been working for couple last days on porting Basho Riak database
(latest version 1.4.2) and finally I think it is ready to be presented:
https://www.dropbox.com/s/2ztu2bdiip1u2un/riak.tgz
MASTER_SITES=
http://s3.amazonaws.com/downloads.basho.com/riak/1.4/1.4.2/ \
http://downloads.basho.com.s3.amazonaws.com/riak/1.4/1.4.2/
Use ${PORTVERSION} instead of 1.4.2
Fixed.
USES= ${GMAKE}
Use 'gmake', not ${GMAKE} here.
Fixed.
Fails to build on 8.3 i386:
db/version_set.cc:59: warning: this decimal constant is unsigned only in
ISO C90
db/version_set.cc:59: warning: this decimal constant is unsigned only in
ISO C90
db/version_set.cc:60: error: integer constant is too large for 'long'
type
db/version_set.cc:60: error: integer constant is too large for 'long'
type
db/version_set.cc:61: error: integer constant is too large for 'long'
type
db/version_set.cc:61: error: integer constant is too large for 'long'
type
db/version_set.cc:62: error: integer constant is too large for 'long'
type
db/version_set.cc:62: error: integer constant is too large for 'long'
type
table/filter_block.cc: In member function 'bool
leveldb::FilterBlockReader::KeyMayMatch(uint64_t, const leveldb::Slice)':
table/filter_block.cc:112: warning: comparison between signed and
unsigned integer expressions
util/env_posix.cc: In constructor
'leveldb::unnamed::PosixEnv::PosixEnv()':
util/env_posix.cc:788: warning: unused variable 'ts'
gmake[1]: *** [libleveldb.so.1.9] Error 1
gmake[1]: Leaving directory
`/wrkdirs/usr/ports/databases/riak/work/riak-1.4.2/deps/eleveldb/c_src/leveldb'
Can you provide any more details on your testing environment, like 32/64
bit, GCC version, any compile optimizations in make.conf and so on?
Unfortunately, I dont have any 8.x machine to test it, so I wasnt able to
see that before. Could you also try to build it on 8.3 using CLANG?
Instead of bsd.port.pre.mk ... bsd.port.post.mk, use bsd.port.options.mk...
bsd.port.mk. Although, it doesn't look like you even need that. Just use
bsd.port.mk at the end, no 2nd include.
I dont think I can get away with only using bsd.port.mk - I've tried that,
and the port fails miserably, somwhere on the level of interpretation of
the Makefile, where it is missing many macros, so I've stayed with two
includes.
Otherwise, good work. I will pkg-build test any updates you send out.
Thanks, great to hear that. Latest version will be posted in response to my
original message.
B.
Please, grab the port and test it on anything you can, break it in any
way
possible, and comment on anything you see that's been done wrong - I am
open to any suggestion on how to make it worthy candidate for send-pr
with
port submission.
Any help will be highly appreciated and will motivate me to port more
cool
software to FreeBSD! ;)
Kind regards,
S.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Fwd: Help in testing Basho Riak port
On Fri, Sep 20, 2013 at 10:26 PM, Bryan Drewery br...@shatow.net wrote: You also need this in the pkg-plist to fix it being a leftover: @dirrmtry %%RIAK_DBDIR%% Unfortunately this doesnt work, because it gets expanded to /usr/local//var/db/riak from pkg-plist. That's why its not there. B. That will only remove the directory if it is empty. On Fri, Sep 20, 2013 at 06:57:52PM +0100, Big Lebowski wrote: Hi list! I've been working for couple last days on porting Basho Riak database (latest version 1.4.2) and finally I think it is ready to be presented: https://www.dropbox.com/s/2ztu2bdiip1u2un/riak.tgz Please, grab the port and test it on anything you can, break it in any way possible, and comment on anything you see that's been done wrong - I am open to any suggestion on how to make it worthy candidate for send-pr with port submission. Any help will be highly appreciated and will motivate me to port more cool software to FreeBSD! ;) Kind regards, S. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Fwd: Help in testing Basho Riak port
On Sat, Sep 21, 2013 at 9:48 PM, Dimitry Andric d...@freebsd.org wrote: On Sep 21, 2013, at 21:58, Big Lebowski spankthes...@gmail.com wrote: ... While this is of course true, their package has some issues: * it doesnt work with pkgng - mine, built with make package from port does * it is using and requiring sudo - mine is patched to use su, one dependency less * it requires explicit OpenSSL version from ports, forcing users to use libmap.conf - mine works with OpenSSL from base * it doesnt have rc scripts - mine does Because of all these reasons I decided to write this port, as it was scratching my own itch, I needed Riak on FreeBSD, and the package was almost unusable. Not mentioning, that now you've freedom to compile it with GCC/CLANG with any optimizations you want. Hope it makes some sense :) Sure, that makes perfect sense. It would be nice if you could let Basho know once there is an official port, so they can direct their FreeBSD users to it, instead of the hand-built package. I've contacted with Basho (at least one of their staff via their IRC channel) when I started working on that port, and I've received quite a lot of help from him. However, their mysterious 'package guy' is not a fan of port, because he built a set of scripts to build package, and I think he considers that as a direct competition, instead of help, even thought the person I've been talking to understand all the points above and argees with me. Btw, does the port pull in Erlang and its dependencies? Or does it include the interpreter and support stuff in the package? If you'd test it, you would know the answer ;) The port has Erlang as build dependency, as the Basho marke rel target builds everything the Riak needs, and after make install/package it can be removed. B. -Dimitry ___ 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: Fwd: Help in testing Basho Riak port
On 9/21/2013 5:08 PM, Big Lebowski wrote:
On Fri, Sep 20, 2013 at 10:26 PM, Bryan Drewery br...@shatow.net wrote:
You also need this in the pkg-plist to fix it being a leftover:
@dirrmtry %%RIAK_DBDIR%%
Unfortunately this doesnt work, because it gets expanded to
/usr/local//var/db/riak from pkg-plist. That's why its not there.
RIAK_DBDIR?=/var/db/${PORTNAME}
You have it right there as /var/db, there is no PREFIX there for
/usr/local to slip in. Perhaps you have RIAK_DBDIR=/usr/local/var/db in
your make.conf? And even if you do, it should try to remove any
directory it creates on uninstall. It doesn't matter where it is.
Having a leftover like that means the port will not be committed.
B.
That will only remove the directory if it is empty.
On Fri, Sep 20, 2013 at 06:57:52PM +0100, Big Lebowski wrote:
Hi list!
I've been working for couple last days on porting Basho Riak database
(latest version 1.4.2) and finally I think it is ready to be presented:
https://www.dropbox.com/s/2ztu2bdiip1u2un/riak.tgz
Please, grab the port and test it on anything you can, break it in any
way
possible, and comment on anything you see that's been done wrong - I am
open to any suggestion on how to make it worthy candidate for send-pr
with
port submission.
Any help will be highly appreciated and will motivate me to port more
cool
software to FreeBSD! ;)
Kind regards,
S.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
signature.asc
Description: OpenPGP digital signature
Re: Fwd: Help in testing Basho Riak port
On 9/21/2013 5:08 PM, Big Lebowski wrote:
Hi,
Thanks for your comments, see mine below.
On Fri, Sep 20, 2013 at 9:37 PM, Bryan Drewery br...@shatow.net wrote:
On Fri, Sep 20, 2013 at 06:57:52PM +0100, Big Lebowski wrote:
Hi list!
I've been working for couple last days on porting Basho Riak database
(latest version 1.4.2) and finally I think it is ready to be presented:
https://www.dropbox.com/s/2ztu2bdiip1u2un/riak.tgz
MASTER_SITES=
http://s3.amazonaws.com/downloads.basho.com/riak/1.4/1.4.2/ \
http://downloads.basho.com.s3.amazonaws.com/riak/1.4/1.4.2/
Use ${PORTVERSION} instead of 1.4.2
Fixed.
USES= ${GMAKE}
Use 'gmake', not ${GMAKE} here.
Fixed.
Fails to build on 8.3 i386:
db/version_set.cc:59: warning: this decimal constant is unsigned only in
ISO C90
db/version_set.cc:59: warning: this decimal constant is unsigned only in
ISO C90
db/version_set.cc:60: error: integer constant is too large for 'long'
type
db/version_set.cc:60: error: integer constant is too large for 'long'
type
db/version_set.cc:61: error: integer constant is too large for 'long'
type
db/version_set.cc:61: error: integer constant is too large for 'long'
type
db/version_set.cc:62: error: integer constant is too large for 'long'
type
db/version_set.cc:62: error: integer constant is too large for 'long'
type
table/filter_block.cc: In member function 'bool
leveldb::FilterBlockReader::KeyMayMatch(uint64_t, const leveldb::Slice)':
table/filter_block.cc:112: warning: comparison between signed and
unsigned integer expressions
util/env_posix.cc: In constructor
'leveldb::unnamed::PosixEnv::PosixEnv()':
util/env_posix.cc:788: warning: unused variable 'ts'
gmake[1]: *** [libleveldb.so.1.9] Error 1
gmake[1]: Leaving directory
`/wrkdirs/usr/ports/databases/riak/work/riak-1.4.2/deps/eleveldb/c_src/leveldb'
Can you provide any more details on your testing environment, like 32/64
bit, GCC version, any compile optimizations in make.conf and so on?
Unfortunately, I dont have any 8.x machine to test it, so I wasnt able to
see that before. Could you also try to build it on 8.3 using CLANG?
8.3 i386 (32 bit). GCC 4.2. This error is of too much data for 32bit
variable. Clang won't help.
Here is the issue upstream as well with a recommended fix and a SO
explaining more:
https://github.com/basho/leveldb/issues/87
http://stackoverflow.com/questions/5541560/integer-constant-is-too-large-for-long-type
Instead of bsd.port.pre.mk ... bsd.port.post.mk, use bsd.port.options.mk...
bsd.port.mk. Although, it doesn't look like you even need that. Just use
bsd.port.mk at the end, no 2nd include.
I dont think I can get away with only using bsd.port.mk - I've tried that,
and the port fails miserably, somwhere on the level of interpretation of
the Makefile, where it is missing many macros, so I've stayed with two
includes.
Otherwise, good work. I will pkg-build test any updates you send out.
Thanks, great to hear that. Latest version will be posted in response to my
original message.
B.
Please, grab the port and test it on anything you can, break it in any
way
possible, and comment on anything you see that's been done wrong - I am
open to any suggestion on how to make it worthy candidate for send-pr
with
port submission.
Any help will be highly appreciated and will motivate me to port more
cool
software to FreeBSD! ;)
Kind regards,
S.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
signature.asc
Description: OpenPGP digital signature
Re: net-mgmt/netmond is too old
On Sat, Sep 21, 2013 at 10:40:09PM +0700, Victor Sudakov wrote: Could you update the port please? The best way to help with this is to file a PR; with the patches (if you have already made them). mcl ___ 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: [CFT/HEADSUP] Ports now have Stack Protector support
On 9/21/2013 5:47 AM, Bryan Drewery wrote: Ports now support enabling Stack Protector [1] support on FreeBSD 10 i386 and amd64, and older releases on amd64 only currently. Support may be added for earlier i386 releases once all ports properly respect LDFLAGS. To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports. Please use WITH_SSP_PORTS now. WITH_SSP will hit some issues when running 'make installworld'. I have a pending fix for that for current, but it will still be an issue in existing releases / 9.2. The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all may optionally be set instead. Please help test this on your system. We would like to eventually enable this by default, but need to identify any major ports that have run-time issues due to it. [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: net-mgmt/netmond is too old
On 21.09.2013 19:40, Victor Sudakov wrote: Dear Colleagues, The net-mgmt/netmond port is very old. netmond-2.3.7 is already available at http://people.freebsd.org/~ae/netmond-2.3.7.tgz Could you update the port please? I have tested netmond-2.3.7 on 8.4-RELEASE i386 with about 80 objects, it works just fine. The version in this tarball isn't the same that in ports. It is highly refactored. I removed some parts of code that we don't used, included most of patches from ports and also some new. It will be better if someone hosted this tarball somewhere. freefall isn't right place for it. -- WBR, Andrey V. Elsukov ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: net-mgmt/netmond is too old
Andrey V. Elsukov wrote: The net-mgmt/netmond port is very old. netmond-2.3.7 is already available at http://people.freebsd.org/~ae/netmond-2.3.7.tgz Could you update the port please? I have tested netmond-2.3.7 on 8.4-RELEASE i386 with about 80 objects, it works just fine. The version in this tarball isn't the same that in ports. It is highly refactored. I removed some parts of code that we don't used, included most of patches from ports and also some new. Thank you for that. It will be better if someone hosted this tarball somewhere. freefall isn't right place for it. I could host it somewhere at ftp://ftp.sibptus.ru but isn't there a special place for such distfiles somewhere at freebsd.org ? I would also like to revive the maillist dedicated to netmond. The one at net...@service.risp.ru seems dead. I could host the maillist too. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: net-mgmt/netmond is too old
Mark Linimon wrote: On Sat, Sep 21, 2013 at 10:40:09PM +0700, Victor Sudakov wrote: Could you update the port please? The best way to help with this is to file a PR; with the patches (if you have already made them). Andrey, Do you care to prepare the patches or should I do it? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: net-mgmt/netmond is too old
On 22.09.2013 08:18, Victor Sudakov wrote: Mark Linimon wrote: On Sat, Sep 21, 2013 at 10:40:09PM +0700, Victor Sudakov wrote: Could you update the port please? The best way to help with this is to file a PR; with the patches (if you have already made them). Andrey, Do you care to prepare the patches or should I do it? I don't plan to maintain this port, so you can try to take it. -- WBR, Andrey V. Elsukov ___ 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
