[m...@issp.ac.ru: [kde-freebsd] request for test: printer-applet, system-config-printer-kde]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 forward to ports@ and python@ - - Forwarded message from Max Brazhnikov m...@issp.ac.ru - Date: Wed, 6 May 2009 12:15:39 +0400 From: Max Brazhnikov m...@issp.ac.ru To: kde-free...@kde.org Subject: [kde-freebsd] request for test: printer-applet, system-config-printer-kde User-Agent: KMail/1.11.2 (FreeBSD/7.2-PRERELEASE; KDE/4.2.2; i386; ; ) List-Id: kde-freebsd.kde.org X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham version=3.2.5 Hi, KDE 4.2.3 will be released tomorrow and we are almost ready to update our kde4 ports. With this update I'd like to introduce a few new ports: devel/kdebindings-python* print/kdeutils4-printer-applet print/system-config-printer-kde. I've tested them quickly with virtual cups-pdf printer, they seems to be more or less usable. Known issues: 1) python scriptengine for Plasma is disabled in kdebase4-workspace currently, so still no support for python based plasmoids. There is no problem to enable it, however I'd like to not bloat workspace dependencies with pyqt4/pykde4 stuff now and prefer to make separate ports for python scriptengine later. 2) system-config-printer fails on *.UTF-8 locales, the problem however seems to be python related: ~ python /usr/local/kde4/bin/system-config-printer-kde Traceback (most recent call last): File /usr/local/kde4/bin/system-config-printer-kde, line 3249, in module applet = GUI() File /usr/local/kde4/bin/system-config-printer-kde, line 178, in __init__ self.populateList(start_printer, change_ppd) File /usr/local/kde4/bin/system-config-printer-kde, line 342, in populateList self.printers = cupshelpers.getPrinters(self.cups) File /usr/local/lib/python2.5/site-packages/cupshelpers/cupshelpers.py, line 435, in getPrinters printer = Printer(name, connection, **printer) File /usr/local/lib/python2.5/site-packages/cupshelpers/cupshelpers.py, line 40, in __init__ self.update (**kw) File /usr/local/lib/python2.5/site-packages/cupshelpers/cupshelpers.py, line 88, in update self._expand_flags() File /usr/local/lib/python2.5/site-packages/cupshelpers/cupshelpers.py, line 68, in _expand_flags locale.setlocale (locale.LC_CTYPE, current_ctype) File /usr/local/lib/python2.5/locale.py, line 478, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting I haven't looked further, so any clue welcome. Thanks, Max ___ kde-freebsd mailing list kde-free...@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information - - End forwarded message - - -- +---+---+ | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ: 169139903 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoBUrsACgkQdLJIhLHm/Om6KQCfctaBBUav3Qyd0zqvWcPiliA6 l2kAnjRjtjw4m8zTPkwu7aUIemyVCMT2 =wrvK -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
Replacement for hdparm -C?
I just received a PR for munin-node, complaining about error messages related to the lack of a hdparm command on FreeBSD. The munin-plugin hddtemp_smartctl tries to find out if a disk is spun down by invoking hdparm -C $fulldev. The plugin will skip the invocation of smartctl on such disks. Since it is really a bad idea to spin up a disk to ask it for its temperature - with what can I replace that command on FreeBSD? Thanks for your help, Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | ___ 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
eggdrop port fail to compile on 7.2-release
Hi, i've just upgraded to 7.2-release and eggdrop port wont compile.. Seems the problem are with Tcl libraries. checking for Tcl library... using /lib checking for Tcl header... using / checking whether the Tcl system has changed... yes checking for Tcl version... checking for Tcl patch level... configure: error: Your Tcl version is much too old for Eggdrop to use. You should download and compile a more recent version. The most reliable current version is 8.5.X and can be downloaded from ftp://tcl.activestate.com/pub/tcl/tcl8_5/. See doc/COMPILE-GUIDE's 'Tcl Detection and Installation' section for more information. === Script configure failed unexpectedly. Please report the problem to be...@freebsd.org [maintainer] and attach the /usr/ports/irc/eggdrop/work/eggdrop1.6.19/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/irc/eggdrop. *** Error code 1 Stop in /usr/ports/irc/eggdrop. I've Tcl installed from ports, tcl-8.5.7 Tool Command Language tcl-modules-8.5.7 Tcl common modules On 7.1 it was compiled without errors. Thanks Andrea Zulato ___ 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: misc/e2fsprogs-libuuid build failure
Greetings, for lack of proper debugging facilities, and because I have 1:1 votes for/against a test conducted behind the scenes: Could anybody who has issues with building e2fsprogs-libuuid on FreeBSD 6.X please add --disable-tls (without the quote marks) to CONFIGURE_ARGS, as in: CONFIGURE_ARGS=--enable-elf-shlibs --disable-tls and let me know if it helps? no difference on one of my FreeBSD 6.2-RELEASE boxes. If this remains unconclusive, I may later have to ask for unprivileged pubkey-authenticated login to a FreeBSD 6.X machine. i can possibly help with this. Paul. Thanks in advance. Best regards -- http://www.ifdnrg.com *web and video services* *Paul Macdonald* /Director/ *IFDNRG* Edinburgh p...@ifdnrg.com mailto:p...@ifdnrg.com www.ifdnrg.com http://www.ifdnrg.com tel:+44.131 2257470 ___ 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: [munin-users] Replacement for hdparm -C?
On Wednesday, 2009-05-06 at 12:47:31 +0300, Sergey A. Kobzar wrote: Wednesday, May 6, 2009, 12:20:40 PM, Lupe wrote: AFAIK you can get HDD temp using sysutils/smartmontools on FreeBSD only. The plugin use the smartctl command. I never tried to do this for disks which are spin down. But why do you need check temperature of such disks? One time someone will ask you to minitor temperature for suspended server... IMHO it's not fully correct :) The plugin is run every five minutes for all disks it is told to watch. A disk that is always spun down should not be on that list ;-) Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | ___ 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[2]: [munin-users] Replacement for hdparm -C?
Wednesday, May 6, 2009, 2:12:42 PM, Lupe wrote: On Wednesday, 2009-05-06 at 12:47:31 +0300, Sergey A. Kobzar wrote: Wednesday, May 6, 2009, 12:20:40 PM, Lupe wrote: AFAIK you can get HDD temp using sysutils/smartmontools on FreeBSD only. The plugin use the smartctl command. I never tried to do this for disks which are spin down. But why do you need check temperature of such disks? One time someone will ask you to minitor temperature for suspended server... IMHO it's not fully correct :) The plugin is run every five minutes for all disks it is told to watch. A disk that is always spun down should not be on that list ;-) This should help: SMARTCTL(8): -n POWERMODE, --nocheck=POWERMODE Specifieds if smartctl should exit before performing any checks when the device is in a low-power mode. It may be used to pre- vent a disk from being spun-up by smartctl. The power mode is ignored by default. The allowed values of POWERMODE are: Something like: # smartctl -n standby -a /dev/ad0 | grep -i temp ;) Lupe Christoph -- Sergey ___ 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: [munin-users] Replacement for hdparm -C?
Wednesday, May 6, 2009, 12:20:40 PM, Lupe wrote: I just received a PR for munin-node, complaining about error messages related to the lack of a hdparm command on FreeBSD. The munin-plugin hddtemp_smartctl tries to find out if a disk is spun down by invoking hdparm -C $fulldev. The plugin will skip the invocation of smartctl on such disks. Since it is really a bad idea to spin up a disk to ask it for its temperature - with what can I replace that command on FreeBSD? AFAIK you can get HDD temp using sysutils/smartmontools on FreeBSD only. I never tried to do this for disks which are spin down. But why do you need check temperature of such disks? One time someone will ask you to minitor temperature for suspended server... IMHO it's not fully correct :) Thanks for your help, Lupe Christoph -- Sergey ___ 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: [munin-users] Replacement for hdparm -C?
Sergey A. Kobzar schrieb: Wednesday, May 6, 2009, 2:12:42 PM, Lupe wrote: On Wednesday, 2009-05-06 at 12:47:31 +0300, Sergey A. Kobzar wrote: Wednesday, May 6, 2009, 12:20:40 PM, Lupe wrote: AFAIK you can get HDD temp using sysutils/smartmontools on FreeBSD only. The plugin use the smartctl command. I never tried to do this for disks which are spin down. But why do you need check temperature of such disks? One time someone will ask you to minitor temperature for suspended server... IMHO it's not fully correct :) The plugin is run every five minutes for all disks it is told to watch. A disk that is always spun down should not be on that list ;-) This should help: SMARTCTL(8): -n POWERMODE, --nocheck=POWERMODE Specifieds if smartctl should exit before performing any checks when the device is in a low-power mode. It may be used to pre- vent a disk from being spun-up by smartctl. The power mode is ignored by default. The allowed values of POWERMODE are: Something like: # smartctl -n standby -a /dev/ad0 | grep -i temp Does this actually work? ISTR that this failed at least for some SATA controllers, such as VIA 8237. ___ 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: [m...@issp.ac.ru: [kde-freebsd] request for test: printer-applet, system-config-printer-kde]
On Wed, 06 May 2009 04:05:00 -0500, Martin Wilke m...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 forward to ports@ and python@ - - Forwarded message from Max Brazhnikov m...@issp.ac.ru - Date: Wed, 6 May 2009 12:15:39 +0400 From: Max Brazhnikov m...@issp.ac.ru To: kde-free...@kde.org Subject: [kde-freebsd] request for test: printer-applet, system-config-printer-kde User-Agent: KMail/1.11.2 (FreeBSD/7.2-PRERELEASE; KDE/4.2.2; i386; ; ) List-Id: kde-freebsd.kde.org X-Spam-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham version=3.2.5 Hi, KDE 4.2.3 will be released tomorrow and we are almost ready to update our kde4 ports. With this update I'd like to introduce a few new ports: devel/kdebindings-python* print/kdeutils4-printer-applet print/system-config-printer-kde. I've tested them quickly with virtual cups-pdf printer, they seems to be more or less usable. Known issues: 1) python scriptengine for Plasma is disabled in kdebase4-workspace currently, so still no support for python based plasmoids. There is no problem to enable it, however I'd like to not bloat workspace dependencies with pyqt4/pykde4 stuff now and prefer to make separate ports for python scriptengine later. 2) system-config-printer fails on *.UTF-8 locales, the problem however seems to be python related: ~ python /usr/local/kde4/bin/system-config-printer-kde Traceback (most recent call last): File /usr/local/kde4/bin/system-config-printer-kde, line 3249, in module applet = GUI() File /usr/local/kde4/bin/system-config-printer-kde, line 178, in __init__ self.populateList(start_printer, change_ppd) File /usr/local/kde4/bin/system-config-printer-kde, line 342, in populateList self.printers = cupshelpers.getPrinters(self.cups) File /usr/local/lib/python2.5/site-packages/cupshelpers/cupshelpers.py, line 435, in getPrinters printer = Printer(name, connection, **printer) File /usr/local/lib/python2.5/site-packages/cupshelpers/cupshelpers.py, line 40, in __init__ self.update (**kw) File /usr/local/lib/python2.5/site-packages/cupshelpers/cupshelpers.py, line 88, in update self._expand_flags() File /usr/local/lib/python2.5/site-packages/cupshelpers/cupshelpers.py, line 68, in _expand_flags locale.setlocale (locale.LC_CTYPE, current_ctype) File /usr/local/lib/python2.5/locale.py, line 478, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting I haven't looked further, so any clue welcome. It's a very common problem. I never understand why this is issue for FreeBSD. Well, actually, I never really dig in this issue deeper. We have to create many patches in ports tree to remove locale stuff. You can check in net-p2p/deluge/files/patch-deluge_core_core.py for an example. OT: I am planning to check in your gecko TODO sometimes and will give you some suggests of what I was planned to do with gecko. Also, will give some good URLs that I saved somewhere in my HDD. Cheers, Mezz Thanks, Max ___ kde-freebsd mailing list kde-free...@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information - - End forwarded message - - -- +---+---+ | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | ICQ: 169139903 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoBUrsACgkQdLJIhLHm/Om6KQCfctaBBUav3Qyd0zqvWcPiliA6 l2kAnjRjtjw4m8zTPkwu7aUIemyVCMT2 =wrvK -END PGP SIGNATURE- -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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
Re: ports/134156: Unable to build updated: e2fsprogs-libuuid-1.41.5
Folks, I cannot yet reproduce this on a FreeBSD 6.4-RELEASE that I'm running in a virtual machine, but I have reports of FreeBSD 6.4 failing. I need the following info from you - usually the output of a command: 1 - pkg_info -W /usr/local/sbin/uuidd 2+3 - before and after the build: ps ax | grep 'uu[i]dd' 4+5 - before and after the build: ls -l /var/run/libuuid 6 - cat /var/run/libuuid/uuidd.pid 7 - make -V SU_CMD 8 - sysctl kern.securelevel 9 - are you running the build as regular user or as root? 10 - are you building inside a jail or chroot? 11 - cat /etc/rc.conf 12 - cat /etc/make.conf 13 - anything else you may think might help debug this I am aware that for one user, SMP works and Uniprocessor does not. -- 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
Re: [munin-users] Replacement for hdparm -C?
On Wednesday, 2009-05-06 at 14:29:05 +0300, Sergey A. Kobzar wrote: This should help: SMARTCTL(8): -n POWERMODE, --nocheck=POWERMODE Specifieds if smartctl should exit before performing any checks when the device is in a low-power mode. It may be used to pre- vent a disk from being spun-up by smartctl. The power mode is ignored by default. The allowed values of POWERMODE are: That's what I get for trusting a change to the plugin was really necessary, an RTFM :-( Since this parameter was introduced Thu Jul 20 20:59:45 2006 UTC (2 years, 9 months ago) according to CVS, we can safely assume that it is available on all platforms. I'll send an accordingly modified plugin to the PR and the PR's sender for testing. When it tests OK, I'll do the change in the Munin SVN. Thanks a lot, Sergey! Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | ___ 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[2]: [munin-users] Replacement for hdparm -C?
Wednesday, May 6, 2009, 4:25:25 PM, Lupe wrote: On Wednesday, 2009-05-06 at 14:29:05 +0300, Sergey A. Kobzar wrote: This should help: SMARTCTL(8): -n POWERMODE, --nocheck=POWERMODE Specifieds if smartctl should exit before performing any checks when the device is in a low-power mode. It may be used to pre- vent a disk from being spun-up by smartctl. The power mode is ignored by default. The allowed values of POWERMODE are: That's what I get for trusting a change to the plugin was really necessary, an RTFM :-( Since this parameter was introduced Thu Jul 20 20:59:45 2006 UTC (2 years, 9 months ago) according to CVS, we can safely assume that it is available on all platforms. I'll send an accordingly modified plugin to the PR and the PR's sender for testing. When it tests OK, I'll do the change in the Munin SVN. Thanks a lot, Sergey! No prob :) Btw, your fix for exim_mailstats plugin we discussed some time ago was not applied to FreeBSD port yet. Lupe Christoph -- Sergey ___ 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/134156: Unable to build updated: e2fsprogs-libuuid-1.41.5
Hi Jerry, *, we're getting closer, a bit at least. In Jerry's case, the server dies before it can write its PID to the uuidd.pid file (0 size), and doesn't get around to cleaning up, so I assume it exits abnormally. Unfortunately, it doesn't log what's up if it's launched automatically as happens in this test, so we need to run it in debug mode for the test (uuidd -d). Also, the build will use the previously installed daemon, but that shouldn't be a problem here. Could you (or somebody else, it can't hurt if I get several inputs here) help me a bit further (shouldn't take more than 5 minutes): 1. Is /var NFS-mounted? Or what kind of file system is it on? 2. Can you build the software, abort the hanging self-test (I don't need the output) and then do this: 3. as root, run: sh -c 'killall uuidd ; sleep 3 ; truss /usr/local/sbin/uuidd -d serverold.out 21 ' 4. as root, run: sh -c 'truss work/e2fsprogs-1.41.5/lib/uuid/tst_uuid client1.out 21 ' 5. as root, wait 3 seconds (if pasting this) and then run: killall uuidd tst_uuid 6. as root, run: sh -c 'killall uuidd ; sleep 3 ; truss work/e2fsprogs-1.41.5/misc/uuidd -d servernew.out 21 ' 7. as root, run: sh -c 'truss work/e2fsprogs-1.41.5/lib/uuid/tst_uuid client2.out 21 ' 8. as root, wait 3 seconds (if pasting this) and then run: killall uuidd tst_uuid 9. Unless you've already sent it: what is your output of pkg_info -W /usr/local/sbin/uuidd? 10. compress and mail me the four (4) *.out files off-list; the reply-to: header is set. Thanks a lot. Best regards -- 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
Re: freebsd-ports Digest, Vol 311, Issue 3
1) Is it working at all? I always receive SIGBUS on 7x. 2) Is our valgrind from http://valgrind.org/ or valgrind.kde.org? 3) valgrind.org lists 3.4.1 as latest release, but there is 3.52 in ports, how is it possible? I am teaching people C, C++ and UNIX API using FreeBSD at university. There is a need for memory-checking tool. It is, for most intents and purposes, not working on FreeBSD. And it never worked on anything by i386 anyway. According to the author(s), porting it from Linux to anything else would take a substantial research-grade effort. (I think, such effort ought to be sponsored similar to how java-porting was -- valgrind is a MAJOR feature for many.) Does anybody know any alternatives for FreeBSD 7? Modern gcc-4.x has memory-checking features, which -- in a manner remotely similar to Purify -- build various checks into the binary. Look through gcc's man-page for the mudflap keyword. That said, nothing beats Purify in my opinion, but that's not on FreeBSD either and costs thousands of dollars :-( Yours, -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
split xcbgen from xcb-proto
It seems that it is a kind of bloating to require python with X (even if only a small portion of it is needed). Unfortunately upstream guys maintain xcb-proto and xcbgen in the same distribution. But a trend among packgers seem to be to split these two into separate packages. I wonder if anybody is working on the same for our ports. From the point of view of the port itself it seems to be as easy building only one subdirectory of the project, e.g.: http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/x11/xcb-proto/patches/patch-ae?rev=1.1 But it seems to be a more challenging task to decide which higher level ports should depend on xcb-proto alone and which need xcbgen too. -- Andriy Gapon ___ 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
why does portsmon think my port is no longer valid?
http://portsmon.freebsd.org/portoverview.py?category=sysutilsportname=ncdu The portsmon page for one of the ports I maintain says it is no longer a valid port. sysutils/ncdu is no longer a valid port: (deleted but missing from /usr/ports/MOVED) I recently submitted an update for ncdu 1.5, and it is now in the ports tree and installs without any problem. Does the portsmon statement simply mean that it hasn't been packaged yet, or is there some other issue that needs to be addressed? ___ 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: MAKE_JOBS_UNSAFE+= shells/bash, textproc/ispell
David O'Brien wrote: I was under the impression that MAKE_JOBS_UNSAFE was the default and one had to explicity put MAKE_JOBS_SAFE=yes in a port. By default, it is neither SAFE or UNSAFE. By default, its always without the -j argument. -- Philip M. Gollucci (pgollu...@ridecharge.com) p: 703.549.2050x206, did: 703.579.6947 Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ 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
[MAINTAINER] Re: ports/134156: Unable to build updated: e2fsprogs-libuuid-1.41.5
Greetings, the attached patch changes two ports and should fix this bug. * misc/e2fsprogs-libuuid: - bump revision, as we're changing files and fixing a bug even for those who had successfully built libuuid before - patch one more source file to make sure the clock.txt state file gets saved to the right directory - try to run the newly-build uuidd for our self-test (ignoring failures, as they are non-fatal) - (the actual build fix is inherited from the other port) * sysutils/e2fsprogs: - add files/patch-uuid-loop to actually fix the self-test does not terminate bug. What causes the client to see EOF prematurely or the server to fail to send a response remains unknown, but we'll fix the worse part of the issue: loop on EOF (read returning 0). diffstat: misc/e2fsprogs-libuuid/Makefile |9 +- misc/e2fsprogs-libuuid/files/uuidd.in|8 +- sysutils/e2fsprogs/files/patch-uuid-loop | 117 +++ 3 files changed, 129 insertions(+), 5 deletions(-) -- 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
[MAINTAINER] Re: ports/134156: Unable to build updated: e2fsprogs-libuuid-1.41.5
[resent with patch]
Greetings,
the attached patch changes two ports and should fix this bug.
* misc/e2fsprogs-libuuid:
- bump revision, as we're changing files and fixing a bug even for
those who had successfully built libuuid before
- patch one more source file to make sure the clock.txt state file
gets saved to the right directory
- try to run the newly-build uuidd for our self-test (ignoring
failures, as they are non-fatal)
- (the actual build fix is inherited from the other port)
* sysutils/e2fsprogs:
- add files/patch-uuid-loop to actually fix the self-test does not
terminate bug. What causes the client to see EOF prematurely or the
server to fail to send a response remains unknown, but we'll fix the
worse part of the issue: loop on EOF (read returning 0).
diffstat:
misc/e2fsprogs-libuuid/Makefile |9 +-
misc/e2fsprogs-libuuid/files/uuidd.in|8 +-
sysutils/e2fsprogs/files/patch-uuid-loop | 117 +++
3 files changed, 129 insertions(+), 5 deletions(-)
--
Matthias Andree
--- /usr/ports/misc/e2fsprogs-libuuid/Makefile 2009-04-26 00:25:12.0
+0200
+++ /usr/home/ma/ports/misc/e2fsprogs-libuuid/Makefile 2009-05-06
19:56:38.0 +0200
@@ -5,7 +5,7 @@
# $FreeBSD: ports/misc/e2fsprogs-libuuid/Makefile,v 1.9 2009/04/25 22:25:12
miwi Exp $
#
-PORTREVISION= 0
+PORTREVISION= 1
CATEGORIES=misc devel
PKGNAMESUFFIX= -libuuid
@@ -38,14 +38,17 @@
post-patch::
${REINPLACE_CMD} -e 's,/var/lib/libuuid,/var/run/libuuid,g' \
-e 's,/usr/sbin/uuidd,${PREFIX}/sbin/uuidd,' \
- ${WRKSRC}/lib/uuid/uuidd.h
+ ${WRKSRC}/lib/uuid/*.[ch]
pre-build:
${MKDIR} ${WRKSRC}/lib/uuid/elfshared
+# ulimit guards against runaway tests
+# failure to launch uuidd is fine (one might be running, or we may lack
+# privileges); if it works, it'll quit after 50 seconds
post-build:
cd ${WRKSRC}/misc ${MAKE} uuidgen uuidgen.1 uuidd uuidd.8
- cd ${INSTALL_WRKSRC} ${MAKE} check
+ ( ulimit -t 5 ; cd ${INSTALL_WRKSRC} { ../../misc/uuidd -T50 || true
; ${MAKE} check ; } )
post-install:
${INSTALL_PROGRAM} ${WRKSRC}/misc/uuidgen ${PREFIX}/bin/
--- /usr/ports/misc/e2fsprogs-libuuid/files/uuidd.in2008-05-07
00:29:03.0 +0200
+++ /usr/home/ma/ports/misc/e2fsprogs-libuuid/files/uuidd.in2009-05-06
20:17:00.0 +0200
@@ -1,9 +1,13 @@
#!/bin/sh
#
# rcNG script to start uuidd at boot-time on rcNG-enabled systems,
-# such as FreeBSD.
+# such as FreeBSD. Note: Starting uuidd at boot-time is not strictly
+# necessary, the library will - as of 1.41.5 - silently launch an
+# instance of uuidd that exits after 300 seconds; for most accurate
+# time-based uuids generated from unprivileged user accounts it may be
+# useful to run it system-wide.
#
-# (C) 2008 by Matthias Andree.
+# (C) 2008, 2009 by Matthias Andree.
# Licensed under the modified (= 2-clause) BSD license.
# PROVIDE: uuidd
--- /usr/ports/sysutils/e2fsprogs/files/patch-uuid-loop 1970-01-01
01:00:00.0 +0100
+++ /usr/home/ma/ports/sysutils/e2fsprogs/files/patch-uuid-loop 2009-05-06
20:19:28.0 +0200
@@ -0,0 +1,117 @@
+Fix and factor out read_all().
+
+read_all() does not treat 0 (EOF indicator) properly and goes into an
+unterminated loop, assuming blocking read.
+
+Fix: Instead, return 0 if it cannot fulfill the request, because it sees
+a premature EOF.
+
+--- /dev/null
b/lib/read_all.h
+@@ -0,0 +1,32 @@
++/*
++ * read_all - a read variant that masks EAGAIN and EINTR.
++ * This function tries hard to make sure to read the complete requested
++ * length, and if it hits EOF while reading, it returns 0.
++ *
++ * Originally written by Theodore Y. Ts'o.
++ * Factored out from misc/uuidd.c and lib/uuid/gen_uuid.c
++ * and bugfixed by Matthias Andree, 2009.
++ */
++
++ssize_t read_all(int fd, char *buf, size_t count)
++{
++ ssize_t ret;
++ ssize_t c = 0;
++
++ memset(buf, 0, count);
++ while (count 0) {
++ ret = read(fd, buf, count);
++ if (ret == -1) {
++ if ((errno == EAGAIN) || (errno == EINTR))
++ continue;
++ return -1;
++ }
++ if (ret == 0) {
++ return c;
++ }
++ count -= ret;
++ buf += ret;
++ c += ret;
++ }
++ return c;
++}
+--- a/lib/uuid/Makefile.in
b/lib/uuid/Makefile.in
+@@ -190,7 +190,7 @@ clear.o: $(srcdir)/clear.c $(srcdir)/uuidP.h
$(srcdir)/uuid.h
+ compare.o: $(srcdir)/compare.c $(srcdir)/uuidP.h $(srcdir)/uuid.h
+ copy.o: $(srcdir)/copy.c $(srcdir)/uuidP.h $(srcdir)/uuid.h
+ gen_uuid.o: $(srcdir)/gen_uuid.c $(srcdir)/uuidP.h $(srcdir)/uuid.h \
+- $(srcdir)/uuidd.h
++ $(srcdir)/uuidd.h $(top_srcdir)/lib/read_all.h
+ isnull.o: $(srcdir)/isnull.c $(srcdir)/uuidP.h $(srcdir)/uuid.h
py-qt4-* troubles
Hi, While trying to build games/anki I've found that several py-qt4-* ports are unbuildable. For instance graphics/py-qt4-svg complains: === Found saved configuration for py25-qt4-svg-4.4.4,1 === Extracting for py25-qt4-svg-4.4.4,1 = MD5 Checksum OK for PyQt-x11-gpl-4.4.4.tar.gz. = SHA256 Checksum OK for PyQt-x11-gpl-4.4.4.tar.gz. === Patching for py25-qt4-svg-4.4.4,1 === Applying FreeBSD patches for py25-qt4-svg-4.4.4,1 === py25-qt4-svg-4.4.4,1 depends on package: py25-sip=4.7.9 - found === py25-qt4-svg-4.4.4,1 depends on file: /usr/local/bin/python2.5 - found === py25-qt4-svg-4.4.4,1 depends on package: qt4-svg=4.4.3 - found === py25-qt4-svg-4.4.4,1 depends on package: qt4-qmake=4.4.3 - found === py25-qt4-svg-4.4.4,1 depends on shared library: qscintilla2.5 - found === Configuring for py25-qt4-svg-4.4.4,1 cd /usr/ports/graphics/py-qt4-svg/work/PyQt-x11-gpl-4.4.4 /usr/bin/env PYQT4_COMPONENT=svg PYTHON=/usr/local/bin/python2.5 MOC=/usr/local/bin/moc-qt4 UIC=/usr/local/bin/uic-qt4 CPPFLAGS= LIBS= QMAKE=/usr/local/bin/qmake-qt4 QMAKESPEC=/usr/local/share/qt4/mkspecs/freebsd-g++ QTDIR=/usr/local SHELL=/bin/sh CONFIG_SHELL=/bin/sh /usr/local/bin/python2.5 configure.py -b /usr/local/bin -d /usr/local/lib/python2.5/site-packages -p /usr/local/lib/qt4/plugins -q /usr/local/bin/qmake-qt4 --confirm-license --enable QtSvg --qsci-api --qsci-api-destdir=/usr/local/share/qt4/qsci --sipdir /usr/local/share/py-sip Determining the layout of your Qt installation... This is the GPL version of PyQt 4.4.4 (licensed under the GNU General Public License) for Python 2.5.4 on freebsd7. Checking to see if the QtSvg module should be built... Qt v4.4.3 free edition is being used. SIP 4.7.9 is being used. The Qt header files are in /usr/local/include/qt4. The shared Qt libraries are in /usr/local/lib/qt4. The Qt binaries are in /usr/local/bin. The Qt mkspecs directory is in /usr/local/share/qt4. This PyQt module will be built: QtCore. The PyQt Python package will be installed in /usr/local/lib/python2.5/site-packages. The QScintilla API file will be installed in /usr/local/share/qt4/qsci/api/python. The PyQt .sip files will be installed in /usr/local/share/py-sip. Creating QScintilla API file... Creating top level Makefile... /usr/bin/sed -i.bak -e 's|mkspecs/freebsd-g++|share/qt4/mkspecs/freebsd-g++|' -e 's|CC = cc|CC = cc|' -e 's|CXX = c++|CXX = c++|' -e 's|LINK = c++|LINK = c++|' /usr/ports/graphics/py-qt4-svg/work/PyQt-x11-gpl-4.4.4/QtSvg/Makefile sed: /usr/ports/graphics/py-qt4-svg/work/PyQt-x11-gpl-4.4.4/QtSvg/Makefile: No such file or directory *** Error code 1 The same thing for www/py-qt4-webkit. I've reinstalled qt4 and all dependent ports but still no luck. uname -sr: FreeBSD 7.1-RELEASE-p2 and the most recent ports snapshot. I'd appreciate any hint about what to install/update in order to fix the issue. Thanks. -- ~syhpoon ___ 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: Looking for new maintainers for some of my ports
devel/log4c devel/re2c devel/ruby-rbtree net/whois net/ruby-dict If not already re-assigned, I'll take those 5. devel/p5-Config-Options devel/p5-Data-Bind devel/p5-Devel-Events-Objects devel/p5-Devel-Gladiator devel/p5-IO-TieCombine devel/p5-Package-Constants devel/p5-Test-Fixture-DBIC-Schema devel/p5-Tie-Hash-Regex mail/p5-Email-Date-Format Send em to perl@ ? -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
HEADS UP: Berkeley DB versions in upcoming mail/bogofilter* 1.2.0 on FreeBSD
Am 29.03.2009, 00:17 Uhr, schrieb David Relson rel...@osagesoftware.com: Bogofilter v1.2.0 has been promoted from current to stable status. This release adds 3 new options to force bogofilter to use a specified number of tokens when scoring a message. The options are: --token-count=n --token-count-min=n --token-count-max=n When one or more of these options is specified, bogofilter tries to use the specified number of tokens when computing a message's score. Under certain circumstances when multiple tokens have identical scores, bogofilter will compute a score using more tokens than specified. Greetings, I finally got around to updating the FreeBSD ports and submitted the update, which will hopefully show up in the not too distant future. On the good side, we allow any Berkeley DB version = 4.1 (currently up to 4.7), and we support parallel builds now - which makes port builds faster on multicore/multiprocessor computers. If you are installing/updating the bogofilter-sqlite or bogofilter-tc ports, the remainder of this message is not of interest to you. HEADS UP bogofilter-qdbm users: This port is deprecated and marked for removal end June 2009, since the upstream QDBM library is no longer supported and TokyoCabinet is the successor. It is recommended that you dump your word lists, deinstall bogofilter-qdbm, install bogofilter-tc, and load your word lists again. The other three ports, bogofilter, bogofilter-sqlite and bogofilter-tc continue to be supported. HEADS UP for first-time bogofilter (Berkeley DB-based) installs: Consider setting BOGOFILTER_WITH_BDB_VER=nn (nn is a number from 41 to 47, meaning 4.1 to 4.7) in /etc/make.conf to a suitable Berkeley DB version, before building and installing bogofilter, so that you need not manually intervene on future updates. suitable means: 41 or newer, preferably 45 or newer - and it's reasonable to pick a version that is already installed as another port's dependency, for faster install and smaller disk space footprint. HEADS UP for bogofilter (Berkeley DB-based) updates: The new 1.2.0 port sets USE_BDB=41+ (meaning 4.1 or newer) rather than hardcode version 4.3, and will leave the actual choice to the ports build system. You can override this for all ports with WITH_BDB_VER, and for bogofilter with BOGOFILTER_WITH_BDB_VER as shown in (2) below. If you do not override the automatic version, this can cause the Berkeley DB version to change, and consequentially damage your database. YOU MUST DO EITHER: (1) unless you are absolutely sure that the build picked Berkeley DB 4.3 (you can check with make -C /usr/ports/mail/bogofilter -V BDB_VER), dump all your word lists before the update, and reload them after the update. The update procedures are detailed in README.db and *must* be followed if you value your data (it doesn't matter if you read the 1.1.7 or the 1.2.0 README.db file - instructions haven't changed). OR (you need not do both) (2) create a line BOGOFILTER_WITH_BDB_VER=43 in /etc/make.conf and build the port from source. DO NOT USE THE PACKAGE: Do not use portupgrade -P or portupgrade -PP for updating. In the hopes to have saved a few poor wordlist.db databases :-) Happy bogofiltering -- 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
xcb-util 0.3.4 breaks awesome
I've been following the discussions on awesome's IRC channel lately, and there have been a lot of problems with users not being able to use their modkey. It turned out that the problem was that a newer version of xcb-util (0.3.4) conflicts with the current released stable version of awesome. Now I see that xcb-util has been pushed to this version in ports. I'm not sure what the proper procedure is for ports which don't work together, but this is just a heads up that there will be problems for awesome users. According to the awesome devs, the solution is to either stay on xcb-util 0.3.3 or install a newer version of awesome (either from git, or use the release candidate for the next version). -- IRC nick: jrick Jabber: jr...@jabber.org http://identi.ca/jrick ___ 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
