Re: Fix nvidia-like ports, help needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2012 14:36, Baptiste Daroussin wrote: On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote: On 2/28/2012 1:15 PM, Baptiste Daroussin wrote: Here is a patch to add support for includedir keyword to libmap.conf so that we I think this is overly complicated, and not generally useful. It also delays the utility of the solution until this gets into the base. What I would do instead is to incorporate an nvidia option into the xorg meta-port, and separate the GL libs into a separate port. If the nvidia option is checked the GL libs come from an nvidia slave port. If not, they come from an xorg-server slave port. Or, we just keep doing what we're doing now, since it works. I'm still not sure what problem we're trying to solve. :) Doug the problem we are trying to solve is to avoid having the nvidia drivers overwritting libGL.so.1 which break the package database consistency. In that case the solution I outlined above would work, and it's hard for me to see why it wouldn't be the best solution. Doug - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPUJQUAAoJEFzGhvEaGryEoIYIANJ0DHtcxIRCCY85rKB/2ENQ p8iSPhkuA99eGsbBukzhBpyivNskm10/W5XnhLy+VzuyX6UmxRfa1w+hxp7tej75 zZHrSnByb3j3iYG9MgiE/Doeo1Iwg8qknhr+W6JhVVTZQH0jM4Y3uPd4xxlLc8lT GDhtbPWPeQMggzJdjiajQSUJBLZMMoFzXGiaetr0yyz4HwEv8IjcUSTdkZ/ixHB5 5GoVODLr5RuGCErYWLTzR2DytZ9MroJwH+iRcWNuY5w7aAG6SF5Wqytsq3RgYqga bWUBVCtozaAah+clGR8dkyL0IC+RZxSRdoR3JqlXtfAbhZBnHuo9VYOlhLtPMIA= =+RmT -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 01:34:12AM -0800, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2012 14:36, Baptiste Daroussin wrote: On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote: On 2/28/2012 1:15 PM, Baptiste Daroussin wrote: Here is a patch to add support for includedir keyword to libmap.conf so that we I think this is overly complicated, and not generally useful. It also delays the utility of the solution until this gets into the base. What I would do instead is to incorporate an nvidia option into the xorg meta-port, and separate the GL libs into a separate port. If the nvidia option is checked the GL libs come from an nvidia slave port. If not, they come from an xorg-server slave port. Or, we just keep doing what we're doing now, since it works. I'm still not sure what problem we're trying to solve. :) Doug the problem we are trying to solve is to avoid having the nvidia drivers overwritting libGL.so.1 which break the package database consistency. In that case the solution I outlined above would work, and it's hard for me to see why it wouldn't be the best solution. There are hybrid machines which have both Intel and NVidia GPUs. Depending on a switch position, you may activate one of the GPU. Usually, on-CPU GPU gives power efficiency, while discrete one provdes a performance. For such machines, it is _very_ useful to have both libGL.so.1 installed and somehow switched around. It would be best to have Mesa and NVidia libGL.so.1 installed under other names, like libGL-mesa.so.1. and ligGL-nvidia.so.1, and provide a symlink for libGL.so.1 BTW, besides libGL.so.1, another conflicting file is /usr/local/lib/xorg/modules/extensions/libglx.so. pgpas3pLEG6Sa.pgp Description: PGP signature
Re: print/libpaper problem
Boris Samorodov b...@passap.ru wrote in 4f5075cc.9010...@passap.ru: bs So what if install a system wide default paper size while installing bs print/libpaper? That may help both in gs case (when a binary is linked bs with libpaper) and those that just use libpaper if it is installed. No. defaultpapername() returns a constant value at compile time. Nothing to do with the $PREFIX/etc/papersize file. bs I think WITH_A4SIZE option should be deprecated at some point and the bs default paper size can be selected by libpaper in run-time because it bs will be more consistent and flexible, bs bs I'd propose to leave a system wide default variable for a paper size. bs I don't care if it is WITH_A4SIZE, DEFAULT_PAPERSIZE=A4 or else. bs bs but the current code in gs bs prevents it because it uses defaultpapername(), not systempapername() bs for some reason. bs bs So, the functionality the libpaper provides in gs is only to define bs /DEFAULTPAPERSIZE but it is confusing due to the above reason. This bs was why I decided to disable libpaper at this moment. bs bs Yea, but those who will choose that non-default option and install bs print/libpaper (in current state, i.e. without installing bs /usr/local/etc/papersize file) will fall in trouble anyway. What is the non-default option and what trouble will occur by it? -- Hiroki pgp68RX1s1qAT.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 11:47:10AM +0200, Konstantin Belousov wrote: On Fri, Mar 02, 2012 at 01:34:12AM -0800, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2012 14:36, Baptiste Daroussin wrote: On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote: On 2/28/2012 1:15 PM, Baptiste Daroussin wrote: Here is a patch to add support for includedir keyword to libmap.conf so that we I think this is overly complicated, and not generally useful. It also delays the utility of the solution until this gets into the base. What I would do instead is to incorporate an nvidia option into the xorg meta-port, and separate the GL libs into a separate port. If the nvidia option is checked the GL libs come from an nvidia slave port. If not, they come from an xorg-server slave port. Or, we just keep doing what we're doing now, since it works. I'm still not sure what problem we're trying to solve. :) Doug the problem we are trying to solve is to avoid having the nvidia drivers overwritting libGL.so.1 which break the package database consistency. In that case the solution I outlined above would work, and it's hard for me to see why it wouldn't be the best solution. There are hybrid machines which have both Intel and NVidia GPUs. Depending on a switch position, you may activate one of the GPU. Usually, on-CPU GPU gives power efficiency, while discrete one provdes a performance. For such machines, it is _very_ useful to have both libGL.so.1 installed and somehow switched around. It would be best to have Mesa and NVidia libGL.so.1 installed under other names, like libGL-mesa.so.1. and ligGL-nvidia.so.1, and provide a symlink for libGL.so.1 BTW, besides libGL.so.1, another conflicting file is /usr/local/lib/xorg/modules/extensions/libglx.so. This was my first idea, the symlink to be able to switch though the alternative script, but this seems to be rejected, that is why I tried to fixed it using the libmap.conf, but libmap.conf won't solve the libglx.so solution as it is opened from its path iirc. regards, Bapt pgpAxUDtvPyGw.pgp Description: PGP signature
print/libpaper problem (was: Re: cvs commit: ports/print/ghostscript9 Makefile)
Hi! (moved from cvs@ list) 01.03.2012 01:37, Hiroki Sato пишет: Boris Samorodov b...@passap.ru wrote in 4f4e63a3.7060...@passap.ru: bs 29.02.2012 16:09, Hiroki Sato пишет: bs hrs 2012-02-29 12:09:03 UTC bs bsFreeBSD ports repository bs bsModified files: bs print/ghostscript9 Makefile bsLog: bsDisable libpaper by default because it can override the A4SIZE option bsunintentionally. bs bs Can you explain this a little bit wider? When libpaper is not linked, the default size is determined by constants in the gs drivers. It seems that libreoffice depends at the mere existance of libpaper. I.e. I've got a system with libreoffice installed. The default paper size was A4. (BTW I'm not sure why and how did I managed to do so since it's Makefile does not check for paper size neither do use print/libpaper). Sometime later as a result of ports upgrading I've got print/libpaper installed. And what do you think? The default paper size for libreoffice (libreoffice itself was not touched by the ports upgading) has changed! Let me state that it was not so simple to detect the culprit and fix it. BTW the (system wide) fix was to create a file /usr/local/etc/papersize with a line A4 in it. WITH_A4SIZE option makes them a4 in compile-time. When linking libpaper, gs defines a paper size returned by defaultpapername() (libpaper API) as /DEFAULTPAPERSIZE via .defaultpapesize (this corresponds to gp_defaultpapersize() in C) in gs_init.ps. It overrides the constants in the drivers. However, the libpaper's default size is always letter, so in that case the gs would use US letter size by default even if WITH_A4SIZE option in this port was enabled. So what if install a system wide default paper size while installing print/libpaper? That may help both in gs case (when a binary is linked with libpaper) and those that just use libpaper if it is installed. I think WITH_A4SIZE option should be deprecated at some point and the default paper size can be selected by libpaper in run-time because it will be more consistent and flexible, I'd propose to leave a system wide default variable for a paper size. I don't care if it is WITH_A4SIZE, DEFAULT_PAPERSIZE=A4 or else. but the current code in gs prevents it because it uses defaultpapername(), not systempapername() for some reason. So, the functionality the libpaper provides in gs is only to define /DEFAULTPAPERSIZE but it is confusing due to the above reason. This was why I decided to disable libpaper at this moment. Yea, but those who will choose that non-default option and install print/libpaper (in current state, i.e. without installing /usr/local/etc/papersize file) will fall in trouble anyway. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
How to submit a new port along with its distfile?
I'm ready to submit a new ports-mgmt port for a package I've written, but I need to have the distfile hosted on one of the FreeBSD sites (running an anonymous ftp server on my own machine would violate my ISP's TOS). How does one go about submitting a new port under these conditions? I need to submit both the port itself and the distfile. And should I set MASTER_SITES=LOCAL or MASTER_SITES=FREEBSD_ORG? Sorry, I couldn't find the answer to this one in the Porter's Handbook. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: On the usage of ${FILE}
On Thu, Mar 01, 2012 at 12:38:01PM +, Chris Rees wrote:
On 1 Mar 2012 11:26, Matthew Seaman matt...@freebsd.org wrote:
Dear all,
bsd.commands.mk has the following:
FILE?= /usr/bin/file
which is unfortunate, given that ${FILE} is used in several thousand
ports, generally as a loop control variable for iterating through a list
of files. In fact, I can only find about 8 places where the file(1)
program is intended.
This obvious conflict of meanings seems pretty undesirable to me. Am I
missing something? Is there any reason to keep the status quo rather
than changing the bsd.commands.mk variable to FILE_CMD and making the
corresponding changes in those 8 places?
Cheers,
Matthew
I think that the loop control variables should be renamed to lower case.
Except more of them in uppercase are bound to be added in the future,
despite the best warnings not to do so.
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
sysutils/dvdisaster coredumps on FreeBSD/amd64 RELENG_9
Hello, the port sysutils/dvdisaster dumps core on FreeBSD RELENG_9/amd64 when run in graphics mode. Using it with flags in text mode seems okay though (I think). Recompiling with CFLAGS=-g doesn't produce a usable backtrace. Maybe there's something broken in scsi-freebsd.c:DefaultDevice() or something called by DefaultDevice(); because if I short out DefaultDevice (with #if 0 ... #endif) and replace it with a simple call to g_strdup(no drives), the GUI seems to work well -- it just doesn't populate the list of available devices. This is on FreeBSD 9.0-STABLE #0 r232305 amd64 with dvdisaster-0.72.3 Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: On the usage of ${FILE}
On 2 Mar 2012 13:19, Wesley Shields w...@freebsd.org wrote:
On Thu, Mar 01, 2012 at 12:38:01PM +, Chris Rees wrote:
On 1 Mar 2012 11:26, Matthew Seaman matt...@freebsd.org wrote:
Dear all,
bsd.commands.mk has the following:
FILE?= /usr/bin/file
which is unfortunate, given that ${FILE} is used in several thousand
ports, generally as a loop control variable for iterating through a
list
of files. In fact, I can only find about 8 places where the file(1)
program is intended.
This obvious conflict of meanings seems pretty undesirable to me. Am
I
missing something? Is there any reason to keep the status quo rather
than changing the bsd.commands.mk variable to FILE_CMD and making the
corresponding changes in those 8 places?
Cheers,
Matthew
I think that the loop control variables should be renamed to lower case.
Except more of them in uppercase are bound to be added in the future,
despite the best warnings not to do so.
Can I say portlint? ;)
Chris
___
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: How to submit a new port along with its distfile?
On 2 Mar 2012 13:15, Conrad J. Sabatier conr...@cox.net wrote: I'm ready to submit a new ports-mgmt port for a package I've written, but I need to have the distfile hosted on one of the FreeBSD sites (running an anonymous ftp server on my own machine would violate my ISP's TOS). How does one go about submitting a new port under these conditions? I need to submit both the port itself and the distfile. And should I set MASTER_SITES=LOCAL or MASTER_SITES=FREEBSD_ORG? Sorry, I couldn't find the answer to this one in the Porter's Handbook. Thanks! Normally you need to find someone prepared to host it for you. Send it to me :) Chris ___ 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: How to submit a new port along with its distfile?
On Fri, Mar 2, 2012 at 10:23 AM, Chris Rees utis...@gmail.com wrote: On 2 Mar 2012 13:15, Conrad J. Sabatier conr...@cox.net wrote: I'm ready to submit a new ports-mgmt port for a package I've written, but I need to have the distfile hosted on one of the FreeBSD sites (running an anonymous ftp server on my own machine would violate my ISP's TOS). How does one go about submitting a new port under these conditions? I need to submit both the port itself and the distfile. And should I set MASTER_SITES=LOCAL or MASTER_SITES=FREEBSD_ORG? Sorry, I couldn't find the answer to this one in the Porter's Handbook. Thanks! Normally you need to find someone prepared to host it for you. Why not use a google code project or something like that? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: status of eclipse [WAS Re: No working IDE in FreeBSD!]
[Moved to freebsd-eclipse] On 02/28/12 13:32, Thomas Gellekum wrote: I'm working on it (3.7.1; there are no 3.7.2 source tarballs for download, AFAICS). I should have an update ready by the end of the week. That turned out to be too optimistic. Everything compiles, but there's a problem with the bundle versions used for the internal installation step. I'll need to dig a bit deeper here. Sorry for the delay. tg ___ 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: How to submit a new port along with its distfile?
On Fri, 2 Mar 2012 10:43:38 -0500 Eitan Adler li...@eitanadler.com wrote: On Fri, Mar 2, 2012 at 10:23 AM, Chris Rees utis...@gmail.com wrote: On 2 Mar 2012 13:15, Conrad J. Sabatier conr...@cox.net wrote: I'm ready to submit a new ports-mgmt port for a package I've written, but I need to have the distfile hosted on one of the FreeBSD sites (running an anonymous ftp server on my own machine would violate my ISP's TOS). How does one go about submitting a new port under these conditions? I need to submit both the port itself and the distfile. And should I set MASTER_SITES=LOCAL or MASTER_SITES=FREEBSD_ORG? Sorry, I couldn't find the answer to this one in the Porter's Handbook. Thanks! Normally you need to find someone prepared to host it for you. Why not use a google code project or something like that? You gave me an idea: I put it up on Sourceforge. About to submit the port now. Thanks! -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: On the usage of ${FILE}
On 03/02/2012 07:22, Chris Rees wrote:
On 2 Mar 2012 13:19, Wesley Shields w...@freebsd.org wrote:
On Thu, Mar 01, 2012 at 12:38:01PM +, Chris Rees wrote:
On 1 Mar 2012 11:26, Matthew Seaman matt...@freebsd.org wrote:
Dear all,
bsd.commands.mk has the following:
FILE?= /usr/bin/file
which is unfortunate, given that ${FILE} is used in several thousand
ports, generally as a loop control variable for iterating through a
list
of files. In fact, I can only find about 8 places where the file(1)
program is intended.
This obvious conflict of meanings seems pretty undesirable to me. Am
I
missing something? Is there any reason to keep the status quo rather
than changing the bsd.commands.mk variable to FILE_CMD and making the
corresponding changes in those 8 places?
Cheers,
Matthew
I think that the loop control variables should be renamed to lower case.
Except more of them in uppercase are bound to be added in the future,
despite the best warnings not to do so.
Can I say portlint? ;)
Won't help, as we have a non-trivial number of developers who can't be
bothered to learn the proper way to do things, or even to use a tool as
simple as portlint.
Matthew's proposal is the right way to go.
Doug
--
This .signature sanitized for your protection
___
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: [lang/perl5.14] Fails on amd64 when WITH_THREADS is enabled
On 2/28/2012 20:56, Spil Oss wrote: /bin/ln -s perldelta.pod pod/perl5142delta.pod LD_LIBRARY_PATH=/var/ports/usr/ports/lang/perl5.14/work/perl-5.14.2 ./miniperl -Ilib autodoc.pl *** Signal 10 I'm out of commission till Monday at least as I tore a muscle in my arm and as such can only type with one hand, but I remembered one more cause of SIGBUS: linking with libc.a (yes, the static library) and -pthread. Any chance that's happening here? -- Mel ___ 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: Fix nvidia-like ports, help needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/02/2012 01:47, Konstantin Belousov wrote: On Fri, Mar 02, 2012 at 01:34:12AM -0800, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2012 14:36, Baptiste Daroussin wrote: On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote: On 2/28/2012 1:15 PM, Baptiste Daroussin wrote: Here is a patch to add support for includedir keyword to libmap.conf so that we I think this is overly complicated, and not generally useful. It also delays the utility of the solution until this gets into the base. What I would do instead is to incorporate an nvidia option into the xorg meta-port, and separate the GL libs into a separate port. If the nvidia option is checked the GL libs come from an nvidia slave port. If not, they come from an xorg-server slave port. Or, we just keep doing what we're doing now, since it works. I'm still not sure what problem we're trying to solve. :) Doug the problem we are trying to solve is to avoid having the nvidia drivers overwritting libGL.so.1 which break the package database consistency. In that case the solution I outlined above would work, and it's hard for me to see why it wouldn't be the best solution. There are hybrid machines which have both Intel and NVidia GPUs. Depending on a switch position, you may activate one of the GPU. Usually, on-CPU GPU gives power efficiency, while discrete one provdes a performance. For such machines, it is _very_ useful to have both libGL.so.1 installed and somehow switched around. It would be best to have Mesa and NVidia libGL.so.1 installed under other names, like libGL-mesa.so.1. and ligGL-nvidia.so.1, and provide a symlink for libGL.so.1 BTW, besides libGL.so.1, another conflicting file is /usr/local/lib/xorg/modules/extensions/libglx.so. For us to support that would actually require a script of some sort, but it's not impossible. If the switch you're referring to provides a devd event it could even be automated, although (AFAIK) you'd have to restart X. I'm not opposed to what you're proposing, install both libs and symlink one or the other ... but that situation is still most easily handled by having the GL components of both xorg-server and nvidia-driver being split out into separate slave ports. Doug - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPURM8AAoJEFzGhvEaGryE1k0IAIk3Ah/29qsu43ivE0Twycc0 Mmv66FpgmVSxlBBuySpWhw+zHhGBVU9wN5X/fYSG1r70oYInq/lnFP65hBt/hyXj /Cpua4x/RtfWj7RCszz39FyAe7sY8F3qGVgzxYBr5k8+7q/TDh5ezQdKbb++zZZF 5VbyITwCI8+f3P8UL1kidUu8J8GEPSbYWv7O7nDlddeyv0rR4Sc7WtF+84hJIqlX XXzFCi64/5cC1tYstbUA4j8bMdEUYIAgCa07Ugs7OnLNiZVnnnxuuNqclEZBe5/w XRnda183Jbf+9zin9FTckNxjdZE9CH74VwW+cSCuNWPYmfuUvfg5ve8qx676Gs8= =oeZG -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 10:36:44AM -0800, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/02/2012 01:47, Konstantin Belousov wrote: On Fri, Mar 02, 2012 at 01:34:12AM -0800, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2012 14:36, Baptiste Daroussin wrote: On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote: On 2/28/2012 1:15 PM, Baptiste Daroussin wrote: Here is a patch to add support for includedir keyword to libmap.conf so that we I think this is overly complicated, and not generally useful. It also delays the utility of the solution until this gets into the base. What I would do instead is to incorporate an nvidia option into the xorg meta-port, and separate the GL libs into a separate port. If the nvidia option is checked the GL libs come from an nvidia slave port. If not, they come from an xorg-server slave port. Or, we just keep doing what we're doing now, since it works. I'm still not sure what problem we're trying to solve. :) Doug the problem we are trying to solve is to avoid having the nvidia drivers overwritting libGL.so.1 which break the package database consistency. In that case the solution I outlined above would work, and it's hard for me to see why it wouldn't be the best solution. There are hybrid machines which have both Intel and NVidia GPUs. Depending on a switch position, you may activate one of the GPU. Usually, on-CPU GPU gives power efficiency, while discrete one provdes a performance. For such machines, it is _very_ useful to have both libGL.so.1 installed and somehow switched around. It would be best to have Mesa and NVidia libGL.so.1 installed under other names, like libGL-mesa.so.1. and ligGL-nvidia.so.1, and provide a symlink for libGL.so.1 BTW, besides libGL.so.1, another conflicting file is /usr/local/lib/xorg/modules/extensions/libglx.so. For us to support that would actually require a script of some sort, but it's not impossible. If the switch you're referring to provides a devd event it could even be automated, although (AFAIK) you'd have to restart X. I'm not opposed to what you're proposing, install both libs and symlink one or the other ... but that situation is still most easily handled by having the GL components of both xorg-server and nvidia-driver being split out into separate slave ports. Well, the switch only works sometime, and for FreeBSD, you need to reboot the OS (basically, BIOS shall reprogram the video commutator and activate/deactivate PCI devices). Linux does have some alpha-stage support for switching GPUs on fly, but you are required to use the Nouveau. NVidia optimus (the newest variation of the dual-GPU systems) does not have commutator, and video signal is generated by on-CPU GPU always. I think that packaging libGL.so variants into separate packages from the nvidia driver/mesa has nothing to do with names/symlink issue. And yes, I use a script that checks PCI devices on boot and symlinks libGL.so.1 and libglx.so to appropriate implementations. The only trouble right now is that reinstall of libGL or nvidia driver ports requires manual fixing of the .so. pgp00NxSj9hTe.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov kostik...@gmail.com wrote: And yes, I use a script that checks PCI devices on boot and symlinks libGL.so.1 and libglx.so to appropriate implementations. The only trouble right now is that reinstall of libGL or nvidia driver ports requires manual fixing of the .so. Ah, but splitting the GL bits out into slave ports would fix that. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 10:54:46AM -0800, Freddie Cash wrote: On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov kostik...@gmail.com wrote: And yes, I use a script that checks PCI devices on boot and symlinks libGL.so.1 and libglx.so to appropriate implementations. The only trouble right now is that reinstall of libGL or nvidia driver ports requires manual fixing of the .so. Ah, but splitting the GL bits out into slave ports would fix that. :) No, it moves the moment of problem from mesa/nvidia update to mesa-libGL and nvidia-libGL update. And, libGl.so.1 from Mesa is already in the separate port, FWIW. pgpAExzofdBch.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
On Fri, Mar 2, 2012 at 11:02 AM, Konstantin Belousov kostik...@gmail.com wrote: On Fri, Mar 02, 2012 at 10:54:46AM -0800, Freddie Cash wrote: On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov kostik...@gmail.com wrote: And yes, I use a script that checks PCI devices on boot and symlinks libGL.so.1 and libglx.so to appropriate implementations. The only trouble right now is that reinstall of libGL or nvidia driver ports requires manual fixing of the .so. Ah, but splitting the GL bits out into slave ports would fix that. :) No, it moves the moment of problem from mesa/nvidia update to mesa-libGL and nvidia-libGL update. And, libGl.so.1 from Mesa is already in the separate port, FWIW. How? Unless the ports include the creation of the symlink (which they shouldn't), then there is no problem anymore. You install nvidia-gl port, you get libGL-nvidia.so installed. You install mesa-gl port, you get libGL-mesa.so installed. You run the alternatives script to create the symlink (or manually create it, or tweak a knob somewhere to create it), and then never touch it again. Update nvidia-gl port, only libGL-nvidia.so gets updated. The symlink doesn't change. Update mesa-gl port, only libGL-mesa.so gets updated. The symlink doesn't change. Where's the problem? -- Freddie Cash fjwc...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 11:10:06AM -0800, Freddie Cash wrote: On Fri, Mar 2, 2012 at 11:02 AM, Konstantin Belousov kostik...@gmail.com wrote: On Fri, Mar 02, 2012 at 10:54:46AM -0800, Freddie Cash wrote: On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov kostik...@gmail.com wrote: And yes, I use a script that checks PCI devices on boot and symlinks libGL.so.1 and libglx.so to appropriate implementations. The only trouble right now is that reinstall of libGL or nvidia driver ports requires manual fixing of the .so. Ah, but splitting the GL bits out into slave ports would fix that. :) No, it moves the moment of problem from mesa/nvidia update to mesa-libGL and nvidia-libGL update. And, libGl.so.1 from Mesa is already in the separate port, FWIW. How? Unless the ports include the creation of the symlink (which they shouldn't), then there is no problem anymore. You install nvidia-gl port, you get libGL-nvidia.so installed. So nvidia-something port needs to install libGL-nvidia.so.1, and not libGL.so.1. You install mesa-gl port, you get libGL-mesa.so installed. You run the alternatives script to create the symlink (or manually create it, or tweak a knob somewhere to create it), and then never touch it again. Update nvidia-gl port, only libGL-nvidia.so gets updated. The symlink doesn't change. Update mesa-gl port, only libGL-mesa.so gets updated. The symlink doesn't change. Where's the problem? Should I repeat what I said already, or can I just point to my other message ? The renames of the libGL.so inside the packages are orthohonal to package splits. The issue is that libGL.so.1 installed by both packages (graphics/libGL and x11/nvidia-driver). And not that the nvidia-driver contains some other stuff. pgpIOaZYI48Jp.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/02/2012 11:21, Konstantin Belousov wrote: The renames of the libGL.so inside the packages are orthohonal to package splits. The issue is that libGL.so.1 installed by both packages (graphics/libGL and x11/nvidia-driver). And not that the nvidia-driver contains some other stuff. Right, I see your point. If the symlink solution is used, slave ports are likely unnecessary. Another question that occurred to me, has anyone tested that ports built against one version of the GL stuff can safely be run if the other version suddenly appears at runtime? - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPUSEOAAoJEFzGhvEaGryE7rUIAJTF/d/aPffPT/4crdMDxYlo 8rQnDoZq+bE2Ona9jg3jZT1ZR3EmU8i8x2nubTUkd2r2y2+kEyZEy4VxWREaXN/t z0fqUFR9vmTl4DzxSNpHyNeFau9OU59B8CiLuUCDkHt/ypELmEyXvpqBjFI9aAHq 84wCYFrW6iOgVWLhefyKgAUbhFrJRp52v6TqNFQ7CmSW7AVgGqaNjb5m2d3nuUGH J0gtvifPdShnRorKIVDQ+3dRiry5LSRQTn6YeZBqkpOjJh3XO4AQhu9vmqOFp0wv tG1sknVt8R93FfPMa6wh7FP/W4JroGZNqVRmjdPkGLl6KrHuLTlApgs2BzVXe6k= =KVee -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 11:35:42AM -0800, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/02/2012 11:21, Konstantin Belousov wrote: The renames of the libGL.so inside the packages are orthohonal to package splits. The issue is that libGL.so.1 installed by both packages (graphics/libGL and x11/nvidia-driver). And not that the nvidia-driver contains some other stuff. Right, I see your point. If the symlink solution is used, slave ports are likely unnecessary. Another question that occurred to me, has anyone tested that ports built against one version of the GL stuff can safely be run if the other version suddenly appears at runtime? The different libGL.so versions should be ABI-compatible. The OpenGL extension mechanism assumes that OpenGL consumers test the presence of the optional features at runtime and adapts. You do not link directly to the new symbol in libGL, but call a function to get the function pointer for extension. On other systems, different OpenGL providers support different versions of OpenGL standard, and this usually not cause much problem for applications. Sure, there may be bugs (and usually there are). pgprWTqwCFhsJ.pgp Description: PGP signature
anyone else working on this? 'added independently by second party' Re: ports/165530: New port: devel/py-foolscap
cvs add py-foolscap ? py-foolscap/Makefile ? py-foolscap/distinfo ? py-foolscap/pkg-descr ? py-foolscap/pkg-plist Directory /home/pcvs/ports/devel/py-foolscap added to the repository cd py-foolscap/ %cvs add Makefile distinfo pkg-* cvs add: Makefile added independently by second party cvs add: distinfo added independently by second party cvs add: pkg-descr added independently by second party cvs add: pkg-plist added independently by second party -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 *| *SECNAP Network Security Corporation * Best Mobile Solutions Product of 2011 * Best Intrusion Prevention Product * Hot Company Finalist 2011 * Best Email Security Product * Certified SNORT Integrator ___ 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: anyone else working on this? 'added independently by second party' Re: ports/165530: New port: devel/py-foolscap
nevermind. ke...@freebsd.org committed an almost identical port 14 hours ago. (I looked at his Makefile and pkg-plist. a lot better then the one in 165530) On 3/2/12 4:49 PM, Michael Scheidell wrote: cvs add py-foolscap ? py-foolscap/Makefile ? py-foolscap/distinfo ? py-foolscap/pkg-descr ? py-foolscap/pkg-plist Directory /home/pcvs/ports/devel/py-foolscap added to the repository cd py-foolscap/ %cvs add Makefile distinfo pkg-* cvs add: Makefile added independently by second party cvs add: distinfo added independently by second party cvs add: pkg-descr added independently by second party cvs add: pkg-plist added independently by second party -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ 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: [HEADSUP][CFT] pkgng beta8 is out
Hi, We just released beta8 of pkgng, it comes with the usual fixes and some new features: pkg set is a new subcommand to modify the content of the local package database, currently only modifying -a [01] the status wether the package as been installed as a dependency or direct can be done. pkg check -r mypkg will recalculate the flatsize of the package pkg check -ra to recalculate for every packages the previous behaviour of pkg check (finding and repairing missing dependencies) is now pkg check -d (wit patterns or -a for the whole installation) pkg check -s (as always -a or pattern) will show you files that have changed since installation (checksum mismatch) pkg query has gain a new -e (evaluate option) to be able to query the packages that matches a boolean evalutation, for example to select all the packages that are bigger than 50MB: # pkg query -e %s 5000 %n-%v is bigger than 50MB: %sh perl-threaded-5.12.4_3 is bigger than 50MB: 54 MB python27-2.7.2_4 is bigger than 50MB: 66 MB qemu-devel-1.0_2 is bigger than 50MB: 67 MB qt4-doc-4.7.4 is bigger than 50MB: 204 MB or to select package bigger than 50MB which have been installed automatically: # pkg query -e %s 5000 %a == 1 %n-%v is bigger than 50MB: %sh and has been automatically installed python27-2.7.2_4 is bigger than 50MB: 66 MB and has been automatically installed regards, Bapt pgpIpKzECLoWF.pgp Description: PGP signature
packages missing: virtualbox, smplayer
Noticed that the virtualbox and smplayer packages just went missing from releng-8 ftp. Maybe an oversight or build race or breakage? An FYI. if it's not otherwise known. ___ 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: How to submit a new port along with its distfile?
On Fri, 2 Mar 2012 11:00:17 -0600 Conrad J. Sabatier conr...@cox.net wrote: On Fri, 2 Mar 2012 10:43:38 -0500 Eitan Adler li...@eitanadler.com wrote: On Fri, Mar 2, 2012 at 10:23 AM, Chris Rees utis...@gmail.com wrote: On 2 Mar 2012 13:15, Conrad J. Sabatier conr...@cox.net wrote: I'm ready to submit a new ports-mgmt port for a package I've written, but I need to have the distfile hosted on one of the FreeBSD sites (running an anonymous ftp server on my own machine would violate my ISP's TOS). How does one go about submitting a new port under these conditions? I need to submit both the port itself and the distfile. And should I set MASTER_SITES=LOCAL or MASTER_SITES=FREEBSD_ORG? Sorry, I couldn't find the answer to this one in the Porter's Handbook. Thanks! Normally you need to find someone prepared to host it for you. Why not use a google code project or something like that? You gave me an idea: I put it up on Sourceforge. About to submit the port now. Thanks! Just thought I'd follow up on this while I'm waiting to have the port reviewed: If anyone's interested, the package is call mkreadmes-1.0. It's a C language version of the port's collection's make readmes (or, if you will, the perl make_readmes script under the Tools directory). I wrote this because I was very dissatisfied with the speed of rebuilding the README.html files after I update my ports tree. This new tool I've written cuts the time down to practically nothing. I can now rebuild all the README.html files for the entire ports tree in less than 30 seconds. Depending on system load, I've actually seen it run in as little as @ 15 seconds. If you want to try it before it becomes an official port, it's already available on Sourceforge right now. It should compile and install very easily on any FreeBSD system, even without the port framework wrapper. The source archive is available at: http://sourceforge.net/projects/mkreadmes/files/mkreadmes-1.0.tar.bz2/download A README file is included in the distribution. Online help is also available via the -h command line option. Please don't hesitate to send me any questions, comments, suggestions, bug reports, etc. Enjoy! -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portupgrade - portmaster Rosetta Stone?
On Mon, 27 Feb 2012 07:57:02 -0800 Doug Barton do...@freebsd.org wrote: On 02/27/2012 02:18, Olivier Smedts wrote: Now I only need to find a way to ignore the errors when creating a backup package if there was a plist problem That's in the man page. :) Doug, is there a way to emulate portupgrade's -k (keep going) option, to have the remaining list of ports to be built still continue processing even if one port's build fails? I've been trying to figure out how to do this, but it eludes me. -- Conrad J. Sabatier conr...@cox.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
