Re: fsvs port
Here is a link to the port.. http://sfedu.ru/~alp/other/fsvs.tar.bz2 Alexander Pyhalov wrote: Hello. I've attached it. Maybe mailing list software cut it... I'll publish it and post a link later... -- Best regards, Alexander Pyhalov, system administrator of Computer Center of South Federal University ___ 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: fsvs port
Hello. I've attached it. Maybe mailing list software cut it... I'll publish it and post a link later... Sergey V. Dyatko wrote: On Mon, 11 Jan 2010 10:16:14 +0300 Alexander Pyhalov wrote: AP> Hello. AP> This is my port for fsvs 1.2.1 (a tool which allow you to store AP> your filesystem versions in subversion repository in quite a AP> flexible way, including file permissions and without a lot of .svn AP> dirs, http://fsvs.tigris.org/). It works for me (tested in amd64 AP> jailed environment on FreeBSD 8.0). I had to do several patches to AP> compile it, but most of them have been included in fsvs main tree AP> (thanks to Phil Marek) , in future patch included in port will be AP> quite small :) Hi, some times ago i'll trying compile it but unsuccessfully. Where I can find your port (thereis no any attachments)? -- wbr, tiger -- С уважением, Александр Пыхалов, системный администратор ЮГИНФО ЮФУ. ___ 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: fsvs port
On Mon, 11 Jan 2010 10:16:14 +0300 Alexander Pyhalov wrote: AP> Hello. AP> This is my port for fsvs 1.2.1 (a tool which allow you to store AP> your filesystem versions in subversion repository in quite a AP> flexible way, including file permissions and without a lot of .svn AP> dirs, http://fsvs.tigris.org/). It works for me (tested in amd64 AP> jailed environment on FreeBSD 8.0). I had to do several patches to AP> compile it, but most of them have been included in fsvs main tree AP> (thanks to Phil Marek) , in future patch included in port will be AP> quite small :) Hi, some times ago i'll trying compile it but unsuccessfully. Where I can find your port (thereis no any attachments)? -- wbr, tiger ___ 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"
fsvs port
Hello. This is my port for fsvs 1.2.1 (a tool which allow you to store your filesystem versions in subversion repository in quite a flexible way, including file permissions and without a lot of .svn dirs, http://fsvs.tigris.org/). It works for me (tested in amd64 jailed environment on FreeBSD 8.0). I had to do several patches to compile it, but most of them have been included in fsvs main tree (thanks to Phil Marek) , in future patch included in port will be quite small :) -- Best regards, Alexander Pyhalov, system administrator of Computer Center of South Federal University ___ 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"
PR 142414 incorrectly marked as committed
Hi, I submitted PR 142414 to update graphics/lcdtest and the PR was closed with the message "Committed. Thanks!" but I don't see where it was actually committed. Could someone take another look at this? Thanks. -- Rob Farmer ___ 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-mngmt/portmaster fetch process
On 1/10/2010 3:41 PM, Doug Barton wrote: > On Sat, 9 Jan 2010, jhell wrote: > >>> Doug, >>> >>> Curious if I can get your comments about a possible change in >>> portmaster to change the behavior of its fetch method. >>> >>> While currently its fetch method is optimal for a environment that >>> has a speedy ultra-fast connection, it runs havoc on a dial line "56k >>> with speed-boost ;)" > > I'm sorry to hear that you're having problems, but you're correct that > the assumption is that the user will have a line faster than 56k. :) > Going from 6Mbps connection down to a dial line sucks but its only temporary for now. But has also allowed me to see this behavior with portmaster which I take as a win win for the project on my behalf and for unsaid other users that may have slower connections too. > >>> Would it be possible to: ? >>> 1) Add a switch that changes its behavior to single fetches - or - >>> 2) Change the default of multiple fetches to single. >>> >>> I opt for (2). as I really see no need have more then one fetch >>> present at a time since it will wait for all others to finish anyway. > > I'm not sure what you mean here. Currently the background fetching is > done in parallel, and the only time portmaster waits is when the port > it's actually trying to build hasn't finished downloading yet. > You have explained this better than I could below. >>> The problem I am noticing is that fetches that are over the amount of >>> three consecutive connections just revolve until others have finished >>> causing DNS lookups on a line that is already at full speed and >>> resulting in slower transactions of the first three connections. > > Not sure what you mean here either, the behavior you describe is not > something that portmaster is doing. > No this is not a problem of portmaster but more a of a problem with a slow line that it exploits if you may. Because the line can be easily saturated and limited to minimal concurrent number of connections a large amount of fetches can easily make DNS lookups for new addresses that have not been resolved not actually make it back down the line to the client. So if fetch process 1, 2 & 3 resolve and start downloading then the line is at its max download rate, further DNS lookups by fetch process 4, 5 & 6 never resolve because they never make it back down the line resulting in a host not found and the process just trying to find the next address causing another lookup that can not be resolved until some of the bandwidth has been reclaimed after a previous process finishes. >>> If there is something that I have looked over in the script then >>> please excuse me but I have not noticed a predetermined way to change >>> this as it stands right now. > > No, there is no option to affect how it does fetching at this time. I > can think of two things that might help. The first would be for you to > fetch the files in advance before portmaster starts trying to build > things. Use whatever method you use to determine that there are packages > that need updating (portmaster -L, pkg_version, etc.) and then do: > portmaster -F pkg-one-1.23 && portmaster -F pkg-two-2.34 > This is effectively what I am doing now after I noticed what was happening. pkg_version -vl'<' and get the update list and then ( cd /usr/ports/*/updated_port ; make checksum-recursive ). But this is a lot of manual intervention I would rather avoid. Of course I could just write a simple script to parse the output of pkg_version and run portmaster -F on that and if it completes successfully just run portmaster -a. > The other alternative that I can think of off hand is a new option to > disable background fetching altogether. This would allow the ports > infrastructure to handle the fetching when you got to that port in the > build list. You'd have to wait for each port to fetch before you can > build it, but you would be guaranteed not to have more than one fetch > working at a time. I don't think that would be too hard to implement, > but before I start working on it I want to be sure that it is something > that would meet your needs. > This would be perfect!. As I was searching through portmaster before I was specificly looking through the option -v for verbose and had thought to my self that it would be pretty cool if that functionality would reside within that option "Just an idea". > As for the other problem you described, are you saying that after you > hit ^C to kill portmaster while there were background fetches happening > that the fetch processes were still there after portmaster exited? If > so, that's a fairly serious problem. What version of portmaster and > FreeBSD are you using? > Yes, background fetches were left after ^C of portmaster. approximately the same amount of fetches as the amount of ports to be updated. On stable/7, portmaster version 2.16 I am curious if this is possibly a result of the slow connection I have as normally on a fast connection you really would not see
[cft] sysutils/conky per-core CPU statistics
Hi! Here's a patch for per-core cpu statistics support in conky which we'd like to have tested: http://people.freebsd.org/~amdmi3/patch-src-freebsd.c Related PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/142577 Thanks to: fidaj, for bringing this up & original patch -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.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: Call for testers - mplayer svn port
On 10.01.2010 21:14 (UTC+1), Rainer Hurling wrote: On 09.01.2010 12:19 (UTC+1), Stefan Ehmann wrote: On Friday 08 January 2010 22:48:50 Thomas Zander wrote: On Fri, Jan 8, 2010 at 11:40, Stefan Ehmann wrote: VDPAU support would also be nice. Noted, thanks. I have overlooked that one. I'll include it with the next iteration in a few days. Meanwhile, I tried getting it to work myself. If I move the vdpau-headers from /usr/local/share/doc/NVIDIA_GLX-1.0 (installed by x11/nvidia-driver) to /usr/local/include/vdpau, mplayer is compiled with vdpau support. On my systems (9.0-CURRENT amd64 with binary NVidia driver) it was not necessary to copy the vdpau header files. MPlayer seems to find the right files. After some more tests it turns out to me that Stefan Ehmann is right. Without having at least a link from /usr/local/share/doc/NVIDIA_GLX-1.0/vdpau* to /usr/local/include/vdpau there is no VDPAU support! You can prove it with 'mplayer -vo help'. In the first lines you should see: Available video output drivers: vdpau VDPAU with X11 ... Sorry for the noise. Instead for me it was necessary to remove old configuration files in ~/.mplayer and to copy from /usr/local/share/mplayer/example/etc/example.conf to gui.conf. After that I only need to uncomment 'vo=vdpau' and 'vc=ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau,'. Now I can watch HD movies even with NVidia Quadro NVS 135M on a notebook :-) Thank you very much, Rainer Hurling It's working nicely. Having to specify -vc manually is cumbersome, but that's not related to the port :) ___ 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: science/paraview: gmake[2]: *** [bin/QVTKCxxTests] Error 1, gmake[1]: *** [VTK/GUISupport/Qt/Testing/Cxx/CMakeFiles/QVTKCxxTests.dir/all] Error 2,gmake: *** [all] Error 2,*** Error code 1
On Sun, 10 Jan 2010, O. Hartmann wrote: Since a while I'm incapable of compiling ports/science/paraview on the most FreeBSD 8.0-STABLE/amd64 boxes around here. I do portmaster -dv on a regular basis on all of those machines and I suspect the port maintanance facility beeing corrupted since this error shows up on nearly every FreeBSd box. The -d option refers to deleting stale distfiles, and -v is verbose, so I'm not sure how this is directly relevant. How can I check what's going wrong? Well it seems pretty obvious that there is a problem with one of your dependencies, but that port has a lot of them, which would make it hard to diagnose exactly which one is causing the problem. I would suggest that you do this: portmaster -Dv -e paraview-3.6.1 and let portmaster uninstall all of the dependencies that are only related to that port. when that's done, do the same command line with your installed version of cmake. Then try reinstalling paraview. If that still doesn't work you'll need to do some digging to determine what is failing, and then you can reinstall that port too. hope this helps, Doug ___ 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-mngmt/portmaster fetch process
On Sat, 9 Jan 2010, jhell wrote: Doug, Curious if I can get your comments about a possible change in portmaster to change the behavior of its fetch method. While currently its fetch method is optimal for a environment that has a speedy ultra-fast connection, it runs havoc on a dial line "56k with speed-boost ;)" I'm sorry to hear that you're having problems, but you're correct that the assumption is that the user will have a line faster than 56k. :) Would it be possible to: ? 1) Add a switch that changes its behavior to single fetches - or - 2) Change the default of multiple fetches to single. I opt for (2). as I really see no need have more then one fetch present at a time since it will wait for all others to finish anyway. I'm not sure what you mean here. Currently the background fetching is done in parallel, and the only time portmaster waits is when the port it's actually trying to build hasn't finished downloading yet. The problem I am noticing is that fetches that are over the amount of three consecutive connections just revolve until others have finished causing DNS lookups on a line that is already at full speed and resulting in slower transactions of the first three connections. Not sure what you mean here either, the behavior you describe is not something that portmaster is doing. If there is something that I have looked over in the script then please excuse me but I have not noticed a predetermined way to change this as it stands right now. No, there is no option to affect how it does fetching at this time. I can think of two things that might help. The first would be for you to fetch the files in advance before portmaster starts trying to build things. Use whatever method you use to determine that there are packages that need updating (portmaster -L, pkg_version, etc.) and then do: portmaster -F pkg-one-1.23 && portmaster -F pkg-two-2.34 The other alternative that I can think of off hand is a new option to disable background fetching altogether. This would allow the ports infrastructure to handle the fetching when you got to that port in the build list. You'd have to wait for each port to fetch before you can build it, but you would be guaranteed not to have more than one fetch working at a time. I don't think that would be too hard to implement, but before I start working on it I want to be sure that it is something that would meet your needs. As for the other problem you described, are you saying that after you hit ^C to kill portmaster while there were background fetches happening that the fetch processes were still there after portmaster exited? If so, that's a fairly serious problem. What version of portmaster and FreeBSD are you using? Doug ___ 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: Call for testers - mplayer svn port
On 09.01.2010 12:19 (UTC+1), Stefan Ehmann wrote: On Friday 08 January 2010 22:48:50 Thomas Zander wrote: On Fri, Jan 8, 2010 at 11:40, Stefan Ehmann wrote: VDPAU support would also be nice. Noted, thanks. I have overlooked that one. I'll include it with the next iteration in a few days. Meanwhile, I tried getting it to work myself. If I move the vdpau-headers from /usr/local/share/doc/NVIDIA_GLX-1.0 (installed by x11/nvidia-driver) to /usr/local/include/vdpau, mplayer is compiled with vdpau support. On my systems (9.0-CURRENT amd64 with binary NVidia driver) it was not necessary to copy the vdpau header files. MPlayer seems to find the right files. Instead for me it was necessary to remove old configuration files in ~/.mplayer and to copy from /usr/local/share/mplayer/example/etc/example.conf to gui.conf. After that I only need to uncomment 'vo=vdpau' and 'vc=ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau,'. Now I can watch HD movies even with NVidia Quadro NVS 135M on a notebook :-) Thank you very much, Rainer Hurling It's working nicely. Having to specify -vc manually is cumbersome, but that's not related to the port :) ___ 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: Call for testers - mplayer svn port
Thomas Zander wrote: > Hello Heino, > > On Sun, Jan 10, 2010 at 14:55, Heino Tiedemann > wrote: > >> => Patch patch-CVE-2008-3162 failed to apply cleanly. >> *** Error code 1 > > This looks like a leftover patch from the old mplayer port. There is > no patch-CVE-* anymore. > It is probably best if you delete the mplayer and mencoder dirs before > extracting the tarball. .. of course.. (im awake 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: Call for testers - mplayer svn port
On Sun, 10 Jan 2010 09:08:15 +0300 Yuri Pankov wrote: > On Sat, Jan 09, 2010 at 10:34:13PM +0100, Stefan Ehmann wrote: > > On Saturday 09 January 2010 21:55:21 Yuri Pankov wrote: > > > On Sat, Jan 09, 2010 at 12:19:51PM +0100, Stefan Ehmann wrote: > > > > On Friday 08 January 2010 22:48:50 Thomas Zander wrote: > > > > > On Fri, Jan 8, 2010 at 11:40, Stefan Ehmann > > > > > wrote: > > > > > > VDPAU support would also be nice. > > > > > > > > > > Noted, thanks. I have overlooked that one. I'll include it > > > > > with the next iteration in a few days. > > > > > > > > Meanwhile, I tried getting it to work myself. If I move the > > > > vdpau-headers from /usr/local/share/doc/NVIDIA_GLX-1.0 > > > > (installed by x11/nvidia-driver) to /usr/local/include/vdpau, > > > > mplayer is compiled with vdpau support. > > > > > > Thanks for the hint, makes a difference here. Should we ask > > > maintainer of nvidia-driver to install those headers with the > > > port? > > (CCed the nvidia-driver maintainer) > > I think modifying the nvidia-driver port to install the header > > files into a different location would be preferable. But I haven't > > really looked at the port, maybe there's a reason for them to be in > > doc. > > > > > > It's working nicely. Having to specify -vc manually is > > > > cumbersome, but that's not related to the port :) > > > > > > I guess you mean -vo here. You could specify it in > > > ~/.mplayer/config, BTW. > > Unfortunately, no. In order to get hardware acceleration, you also > > need to specify -vc depending on the type of video. From the man > > page: > > > > vdpau (with −vc ffmpeg12vdpau, ffwmv3vdpau, ffvc1vdpau or > > ffh264vdpau) > > You still can specify it as: > vo=vdpau, > vc=ffmpeg12vdpau,ffh264vdpau,ffodivxvdpau, > > commas at the end to fallback to standard codecs if necessary. > My 8600GT doesn't seem to support ffodivxvdpau, though. > Works fine so far! I can confirm ffodivxvdpau not working with a 8600GT. Thanks for the work on getting this done Tobias ___ 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: science/paraview: gmake[2]: *** [bin/QVTKCxxTests] Error 1, gmake[1]: *** [VTK/GUISupport/Qt/Testing/Cxx/CMakeFiles/QVTKCxxTests.dir/all] Error 2,gmake: *** [all] Error 2,*** Error code 1
On Sun, 10 Jan 2010 12:10:38 +0100 "O. Hartmann" wrote: > Since a while I'm incapable of compiling ports/science/paraview on the > most FreeBSD 8.0-STABLE/amd64 boxes around here. > > I do portmaster -dv on a regular basis on all of those machines and I > suspect the port maintanance facility beeing corrupted since this error > shows up on nearly every FreeBSd box. > > How can I check what's going wrong? > > Please reply to my eMail also, I'm not subsribing questions/ports list. > > Thanks, > I decided to install this as a test on my 9-CURRENT amd64 box. I encountered no errors at all. Note that, since this was never installed before, I ended up installing most of the dependencies from scratch. That may be a clue. I personally would try deinstalling/reinstalling its dependencies _by hand_. Note that I personally never use portmaster and can't comment on that. --- Gary Jennejohn ___ 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: Call for testers - mplayer svn port
Thomas Zander wrote:
> This should work without further changes (at least it does on my amd64
> test machine). NOTE that ONLY if you want to test it with x264 (only
> available for mencoder, mplayer uses ffmpeg's internal h264 decoder
> now.), you HAVE to apply the supplied x264 patch to
> ${PORTSDIR}/multimedia/x264.
can you axplain that a little bit further? If I install the mplayer,
than ffmpeg and x264 aro not touched.
Heino
___
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: Call for testers - mplayer svn port
Hello Heino, On Sun, Jan 10, 2010 at 14:55, Heino Tiedemann wrote: > => Patch patch-CVE-2008-3162 failed to apply cleanly. > *** Error code 1 This looks like a leftover patch from the old mplayer port. There is no patch-CVE-* anymore. It is probably best if you delete the mplayer and mencoder dirs before extracting the tarball. Riggs ___ 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: Call for testers - mplayer svn port
Thomas Zander wrote:
> To the topic: On
> http://www.rrr.de/~riggs/mplayer/m20100107.tar.bz2
> you can get a small tarball. It contains three items: The ports for
> mplayer and mencoder. Both are drop-in replacements for the respective
> directories in ${PORTSDIR}/multimedia
> This should work without further changes (at least it does on my amd64
> test machine). NOTE that ONLY if you want to test it with x264 (only
> available for mencoder, mplayer uses ffmpeg's internal h264 decoder
> now.), you HAVE to apply the supplied x264 patch to
> ${PORTSDIR}/multimedia/x264.
Hey Riggs,
I replaced mplayer (and mencoder, but this is not important to me),
und got this:
...
There are some knobs which *can* *not* be selected via the
OPTIONS framework. You might want to check the Makefile in
order to learn more about them.
If you want to use the GUI, you can either install
/usr/ports/multimedia/mplayer-skins
or download official skin collections from
http://www.mplayerhq.hu/homepage/dload.html
===> Vulnerability check disabled, database not found
===> Found saved configuration for mplayer-1.0rc20100104
=> MD5 Checksum OK for mplayer-1.0rc20100104.tar.bz2.
=> SHA256 Checksum OK for mplayer-1.0rc20100104.tar.bz2.
===> Patching for mplayer-1.0rc20100104
===> Applying FreeBSD patches for mplayer-1.0rc20100104
2 out of 2 hunks failed--saving rejects to libavformat/psxstr.c.rej
=> Patch patch-CVE-2008-3162 failed to apply cleanly.
*** Error code 1
Stop in /usr/ports/multimedia/mplayer.
*** Error code 1
Stop in /usr/ports/multimedia/mplayer.
** Command failed [exit code 1]: /usr/bin/script -qa
/tmp/portupgrade20100110-3409-tq12px-0 env UPGRADE_TOOL=portupgrade
UPGRADE_PORT=mplayer-0.99.11_14 UPGRADE_PORT_VER=0.99.11_14 make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! multimedia/mplayer (mplayer-0.99.11_14) (checksum mismatch)
___
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"
Webmin and the installation
Dear reader, Sending a email to olg...@freebsd.org did not work. The maintainer is not to reach. Please contact him and give him below information I did a fresh installation from Freebsd 8 with as first a installation of the webmin 1.490 from the ports selection. During running from the setup.sh file I get 2 time the announcement that a permission is denied. Searching on Internet learns me that maybe has something todo with pearl. Can you tell me if the webmin-1.500 ports installation will have not this problem? And if the problem still exist what can I do do make the installation good working? -- With warmest regards, Ronald RiemVis ___ 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: Call for testers - mplayer svn port
Hi, tried the patch, works :) Many Thanks But after patching x264, the configure file has a "#!/bin/sh" shebang instead of "#!/bin/bash" or equal, which makes some if [ ] tests fail. ___ 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"
[www/sams] #make package doesn't stick an empty dir.
Hi all, Right after the installation process there is a backup directory (that is empty yet) relevant to the prefix. After typing #make package there is a .tbz appears. I don't know the reason but there is no backup directory in it. On the other hand, pkg-plist does include backup, so if I try to #make deinstall it can't find the directory and stops (couldn't find a ./backup. Incorrectly specified huh?) The strange thing is that if you type #cd /usr/ports/www/sams && make install clean #pkg_delete sams-1.0.5,1 there are no warnings! How to fix this? OR Can I skip the warning and go ahead submitting the upgrade? Thank you. -- Yuriy Grishin. ___ 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: Linux - Skulltag / FMOD issue
On Tue, Jan 05, 2010 at 08:30:27PM +1100, Edwin Groothuis wrote: > On Tue, Jan 05, 2010 at 08:15:28PM +1100, Edwin Groothuis wrote: > > Hello Sean, > > > > On Mon, Jan 04, 2010 at 03:34:20PM -0600, Sean C. Farley wrote: > > > > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > > > > I System::init returned error code 62 > > > > GSound init failed. Using nosound. > > > > > > Does this fix it: export SDL_AUDIODRIVER=dsp > > > > It didn't help, but the following did help: Selecting the SDL Audio > > Driver in Doom. > > > > Sorry have to be brief, there are monsters to chainsaw! > > > > (Will submit port later. Once I've killed the end-level boss) > > I hate motionsickness > AFK, laying down for a moment. games/linux-skulltag has been commited :-) I don't like motionsickness. AT ALL! Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ ed...@mavetju.org Weblog: http://www.mavetju.org/weblog/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
science/paraview: gmake[2]: *** [bin/QVTKCxxTests] Error 1, gmake[1]: *** [VTK/GUISupport/Qt/Testing/Cxx/CMakeFiles/QVTKCxxTests.dir/all] Error 2,gmake: *** [all] Error 2,*** Error code 1
Since a while I'm incapable of compiling ports/science/paraview on the most FreeBSD 8.0-STABLE/amd64 boxes around here. I do portmaster -dv on a regular basis on all of those machines and I suspect the port maintanance facility beeing corrupted since this error shows up on nearly every FreeBSd box. How can I check what's going wrong? Please reply to my eMail also, I'm not subsribing questions/ports list. Thanks, regards Oliver Linking CXX executable ../../../../../bin/QVTKCxxTests ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_open' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_close' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_ndims' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_dimid' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_nvars' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_strerror' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_dimname' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_varndims' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_varid' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_varname' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_vartype' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_vardimid' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_attlen' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_get_att_double' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_inq_dimlen' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_get_att_text' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_get_vars' ../../../../../bin/libvtkIO.so.pv3.6: undefined reference to `nc_get_var_double' gmake[2]: *** [bin/QVTKCxxTests] Error 1 gmake[1]: *** [VTK/GUISupport/Qt/Testing/Cxx/CMakeFiles/QVTKCxxTests.dir/all] Error 2 gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/science/paraview. ___ 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"
