Re: Virtualbox UI and remote X clients
On Fri, 22 Oct 2010 17:04:35 -0500, Ade Lovett a...@freebsd.org wrote: On Oct 22, 2010, at 16:21 , Bernhard Froehlich wrote: Could you please post that errors? freebsd% setenv DISPLAY remote:0 freebsd% VirtualBox Wait for UI to pop up, click on 'Settings' for any virtual host, VirtualBox crashes with: Qt WARNING: QGLContext::makeCurrent(): Cannot make invalid context current. Segmentation fault (remote) in this case has been (so far): MacOSX 10.6 with Apple's X11.app MacOSX 10.6 with XQuartz.app Windows XP with cygwin/X Windows 7 with cygwin/X Xvnc on the FreeBSD box, then using either the Mac or Windows box to fire up a vnc client to get to the Xvnc. That makes more sense now. Looks like the 2D acceleration unconditionally requires OpenGL. You will find a lot of MythTV users with exactly that problem and they usually switch to Qt rendering. Don't know if vbox has such a possibility. I think it makes sense to add an OpenGL option that disables it all together. Can you try if it works for you when you reenable VIDEOHWACCEL in the Makefile and add CONFIGURE_ARGS+=--disable-opengl somewhere? It sounds like an upstream bug so it would be good to collect a few details like why it happens on your system bug I cannot reproduce it here with Intel graphics. Please re-read what I said. The host machine (running the virtualboxes) has NO graphics of any kind. It's FreeBSD 8.1-STABLE/amd64 hooked up to a VT320 terminal as a serial console. It has X11 libraries and the various toolkits (QT etc) installed, but no Xorg server (other than Xvnc), no X11 drivers (graphics/keyboard/mouse). 3.2.8 was fine 3.2.8_1 broke things 3.2.10 (unsurprisingly) hasn't changed -- Bernhard Fröhlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: GIMP 2.4 - better ui usability
On Fri, Oct 22, 2010 at 11:10 AM, Konstantin Tokarev annu...@yandex.ru wrote: Maybe someone has similar feeling, so I thought maybe its not that bad idea to create GIMP 2.4 port that keep all of the nice features destroyed by a new design team in GIMP 2.6? Haven't you tried to take in contact with GIMP developers? Unfortunately yes [1], a new group of shitheads with better sense of taste got into project and they know better than users what is more comfortable. There are dozens of requests on bugzilla [2] to bring the menu back to the toolbox, even separate project dedicated to make this menu visible again in the toolbar [3]. All this is rejected, even no option to make it work is being left. The old work and good habits are destroyed with no alternative. The only arguments of Martin Nordholts that I had talked with is that I have no taste because he knows no another program that has two main menus (*) and so There is no arguing this, we won't add the menu back. Period.. I don't understand why they don't want to leave this menu in toolbox as user choice option. I only hope this kind of stuff never happens on FreeBSD project. [1] http://bugzilla.gnome.org/show_bug.cgi?id=623472 [2] http://bugzilla.gnome.org/buglist.cgi?query_format=specificorder=relevance+descbug_status=__all__product=content=toolbox+menu [3] http://sourceforge.net/projects/gimp-classic/ (*) Blender3D can have dozens of menus on the screen, but this was no argument to the guy. Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: GIMP 2.4 - better ui usability
23.10.2010, 18:38, Tomek CEDRO tomek.ce...@gmail.com: On Fri, Oct 22, 2010 at 11:10 AM, Konstantin Tokarev annu...@yandex.ru wrote: Maybe someone has similar feeling, so I thought maybe its not that bad idea to create GIMP 2.4 port that keep all of the nice features destroyed by a new design team in GIMP 2.6? Haven't you tried to take in contact with GIMP developers? Unfortunately yes [1], a new group of shitheads with better sense of taste got into project and they know better than users what is more comfortable. There are dozens of requests on bugzilla [2] to bring the menu back to the toolbox, even separate project dedicated to make this menu visible again in the toolbar [3]. All this is rejected, even no option to make it work is being left. The old work and good habits are destroyed with no alternative. The only arguments of Martin Nordholts that I had talked with is that I have no taste because he knows no another program that has two main menus (*) and so There is no arguing this, we won't add the menu back. Period.. I don't understand why they don't want to leave this menu in toolbox as user choice option. I only hope this kind of stuff never happens on FreeBSD project. Probably port of gimp-classic (or option in GIMP port to add this patch) would be better solution than using outdated version. UI is not the only component of GIMP being changed by developers -- Regards, Konstantin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: GIMP 2.4 - better ui usability
2010/10/23 Konstantin Tokarev annu...@yandex.ru: Probably port of gimp-classic (or option in GIMP port to add this patch) would be better solution than using outdated version. UI is not the only component of GIMP being changed by developers Thank you Konstantin for your support on the bugtracker, but I am afraid this wont change anything, you have seen the attitude of the developers. I can see that they try to bring back the new, save, close buttons on the toolbox again, just like they couldn't bring back the old good menu, idiots. They create vertical menus with elephant large icons, but still dont want to bring the little text menu back. Maybe they simply don't like to read. There are people on this planet that think when there is a change, no matter what change, it is for better. I have also proposed including this gimp-classic as an option to the current gimp port, but it was problematic, so I thought the simplest thing would be to bring the gimp24 port until there is anyone sensible in the developer team. I just wanted to ask if there are any pros and cons against this in the port tree. Best regads, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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
Suzy Zokaya. has forwarded a page to you from Wacom India
[1]Wacom India [2]Suzy Zokaya. thought you would like to see this page from the Wacom India web site. Message from Sender: suzyzok...@hotmail.fr Hello!!! I am Suzy Zokaya I saw your contact mail today when i was searching and browsing through internet,and i was deeply moved.I think that you are a very interesting person.So I decided to use the chance to get to know you.i do not think that the age appearance is so important. The most important is what is inside you and how do you feel about the life.I know this life from many sides and I am rather mature already to know how to make a man happy.I think we should use every chance to find our happiness. and I am contacting you for obvious reason which you will understand.Reply me through my email address (suzyzok...@hotmail.fr) so that i will send my photo and more details to you,and i have a very important thing to tell you,i still hope for your reply,have a pleasant day, Suzy Zokaya. [3]IKEA chooses Wacom's SignPad to reduce costs and paperwork Wacom, the leading manufacturer of pen tablets, interactive pen displays and intuitive interface devices, today announces that the major home furnishings retailer IKEA has adopted the electronic receipt storage solution from TeleCash GmbH Co. KG based on Wacom�s LCD signature tablet technology - the STU-500 (or SignPad)?- across Germany. In pionieering this solution, TeleCash is using the market leading technology from Wacom for generating electronical signatures. [4]Click here to read more on our site References 1. http://www.wacom.co.in/ 2. mailto:suzyzok...@hotmail.fr 3. http://www.wacom.co.in/forward/emailref/301 4. http://www.wacom.co.in/forward/emailref/301 ___ 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: License Framework: Develop Best Practices
On Tue June 15 2010 23:22:35 Wesley Shields wrote: On Tue, Jun 15, 2010 at 02:46:27AM +0200, Marco Bröder wrote: Hello, I know the ports license framework is very new and not mature yet. But it is not very useful in its current state, because several popular licenses are missing and some license foo is not right / specific enough to be considered legally correct (for example there is no 'one BSD License', there are at least three of them, all legally different). The legal consequences of even very small differences can be very huge. We actually have to make this legally right or the whole thing is useless. Some maintainers already added some license foo to their ports. At the moment there is more guessing than knowing what actually should be done from a maintainers point of view. This is especially true for dual / multi / combo licensing (for example 'GPLv2 or any later version' is not really the same as 'GPLv2 or GPLv3' combo). Before this even grows, could we please start developing best practices and document them into Porters Handbook, as soon as possible? Thanks! I couldn't agree more. I've been holding off until the Porter's Handbook has clear documentation on what maintainers need to know. I've included alepulver@ on this as he is the one that wrote the initial support for this. I'd hate to see this grow into a mess that has to be cleaned up later because there isn't proper documentation for maintainers. Hopefully Alejandro has a PH update in the wings? If not then I guess it's up to someone(TM) to do it. -- WXS I neither saw a reply from alepulver@ nor anything else on this subject. Are there any further news? There was nothing added to the Porter's Handbook, too. So I guess the situation did not change within the last months, right? Unfortunately, with a recent update to one of my ports (the software is -GPLv2 or any later version- licensed) the committer added the LICENSE / LICENSE_COMB foo at his own without asking. I find this annoying, because I purposely did not add it. Something like that should be the maintainer's choice, because he is also responsible for the port. I think the LICENSE stuff should generally not be added until the whole subject is clarified and properly documented, which does not seem to be the case, especially from the legal point of view. What should the license framework be? Looks like nobody really seems to care (enough). Will it remain a legally incorrect and unreliable stuff? Then, there is no need to actually care about it and the whole license framework is pretty much useless in a legal sense. But that must be stated explicitly. Or should it be as correct as possible? Then it is necessary to have the licenses at least correctly defined and used like they exist (see my original mail quoted above and below, especially the '[L]GPLv2 or any later version' and the three BSD licenses). Will there be an official consensus? Will there be rules or disclaimers for maintainer's and committer's responsibility? Will the whole thing be properly documented in the Porter's Handbook? Will the licenses be correctly defined in 'ports/Mk/bsd.licenses.db.mk' or will some of them remain incorrectly simplified? The license framework could be very nice and actually useful - if properly done ... I will start with a few points: *** bsd.license.db.mk *** We really need to rework it. It should at least contain the most popular / often used licenses -and- their -correct- versions. The latter is not always the case at the moment. And the versions should have only -one- format, not multiples. I suggest to always use a something like 'LGPLv2.1' and not 'LGPL21'. At least it has to be consistent across all licenses. I find it especially important to have a expression for 'version X or any later version' (for example 'LGPLv2+'), since the following dummy example is not adequate: LICENSE=LGPLv2 LGPLv2.1 LGPLv3 LGPLv3.1 LGPLv3.2 LICENSE_COMB=dual ... and so on for every future versions - it does not scale well and has to be changed with every new future version. Instead it should be just 'LGPLv2+' and stay there unchanged forever. Here is my suggestion what should be there at a minimum (probably more needed): *** ARTLv1.0# Artistic License 1.0 ARTLv2.0# Artistic License 2.0 ASLv1.1# Apache License 1.1 ASLv2.0# Apache License 2.0 BSD-2-clause# Simplified BSD License BSD-3-clause# Modified or New BSD License BSD-4-clause# Original BSD License BSLv1.0# Boost Software License 1.0 CDDLv1.0# Common Development and Distribution License 1.0 EPLv1.0# Eclipse Public License 1.0 GFDLv1.1# GNU Free Documentation License 1.1 GFDLv1.2# GNU Free Documentation License 1.2 GFDLv1.3# GNU Free Documentation License 1.3 GPLv2# GNU General Public
Re: License Framework: Develop Best Practices
On 10/23/2010 2:41 PM, Marco Bröder wrote: On Tue June 15 2010 23:22:35 Wesley Shields wrote: I neither saw a reply from alepulver@ nor anything else on this subject. Are there any further news? There was nothing added to the Porter's Handbook, too. So I guess the situation did not change within the last months, right? Unfortunately, with a recent update to one of my ports (the software is -GPLv2 or any later version- licensed) the committer added the LICENSE / LICENSE_COMB foo at his own without asking. I find this annoying, because I purposely did not add it. Something like that should be the maintainer's choice, because he is also responsible for the port. I think the LICENSE stuff should generally not be added until the whole subject is clarified and properly documented, which does not seem to be the case, especially from the legal point of view. What should the license framework be? Looks like nobody really seems to care (enough). Will it remain a legally incorrect and unreliable stuff? Then, there is no need to actually care about it and the whole license framework is pretty much useless in a legal sense. But that must be stated explicitly. Or should it be as correct as possible? Then it is necessary to have the licenses at least correctly defined and used like they exist (see my original mail quoted above and below, especially the '[L]GPLv2 or any later version' and the three BSD licenses). Will there be an official consensus? Will there be rules or disclaimers for maintainer's and committer's responsibility? Will the whole thing be properly documented in the Porter's Handbook? Will the licenses be correctly defined in 'ports/Mk/bsd.licenses.db.mk' or will some of them remain incorrectly simplified? The license framework could be very nice and actually useful - if properly done ... A few weeks ago I was very busy with exams (now I've started to update and clean up some of my ports). But about the PH entry I have previously asked about policies regarding creation of files (the first variables in bsd.licenses.mk) without answer, and I can't write anything. About the rest (what licenses to have, how to define them, etc) the only thing I could do is to look at what other projects did, but really it's not my area (which is writing the code to provide required functionality). I'm willing to make necessary changes to bsd.licenses.mk and/or write documentation if someone else could take care of the bureaucratic part. I will start with a few points: *** bsd.license.db.mk *** We really need to rework it. I have no problem to others taking care of the file. It was initially just an example, and the plan was to automatically classify ports and take the license list from there (which might happen after I update the fossology port to the recent release and fix a few issues). It should at least contain the most popular / often used licenses -and- their -correct- versions. The latter is not always the case at the moment. And the versions should have only -one- format, not multiples. I suggest to always use a something like 'LGPLv2.1' and not 'LGPL21'. At least it has to be consistent across all licenses. I find it especially important to have a expression for 'version X or any later version' (for example 'LGPLv2+'), since the following dummy example is not adequate: LICENSE=LGPLv2 LGPLv2.1 LGPLv3 LGPLv3.1 LGPLv3.2 LICENSE_COMB=dual ... and so on for every future versions - it does not scale well and has to be changed with every new future version. Instead it should be just 'LGPLv2+' and stay there unchanged forever. These could be achieved with groups, or as you suggested with individual names. Regards, Ale ___ 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: License Framework: Develop Best Practices
On 10/23/2010 2:41 PM, Marco Bröder wrote: On Tue June 15 2010 23:22:35 Wesley Shields wrote: I neither saw a reply from alepulver@ nor anything else on this subject. Are there any further news? There was nothing added to the Porter's Handbook, too. So I guess the situation did not change within the last months, right? Unfortunately, with a recent update to one of my ports (the software is -GPLv2 or any later version- licensed) the committer added the LICENSE / LICENSE_COMB foo at his own without asking. I find this annoying, because I purposely did not add it. Something like that should be the maintainer's choice, because he is also responsible for the port. I think the LICENSE stuff should generally not be added until the whole subject is clarified and properly documented, which does not seem to be the case, especially from the legal point of view. What should the license framework be? Looks like nobody really seems to care (enough). Will it remain a legally incorrect and unreliable stuff? Then, there is no need to actually care about it and the whole license framework is pretty much useless in a legal sense. But that must be stated explicitly. Or should it be as correct as possible? Then it is necessary to have the licenses at least correctly defined and used like they exist (see my original mail quoted above and below, especially the '[L]GPLv2 or any later version' and the three BSD licenses). Will there be an official consensus? Will there be rules or disclaimers for maintainer's and committer's responsibility? Will the whole thing be properly documented in the Porter's Handbook? Will the licenses be correctly defined in 'ports/Mk/bsd.licenses.db.mk' or will some of them remain incorrectly simplified? The license framework could be very nice and actually useful - if properly done ... A few weeks ago I was very busy with exams (now I've started to update and clean up some of my ports). But about the PH entry I have previously asked about policies regarding creation of files (the first variables in bsd.licenses.mk) without answer, and I can't write anything. About the rest (what licenses to have, how to define them, etc) the only thing I could do is to look at what other projects did, but really it's not my area (which is writing the code to provide required functionality). I'm willing to make necessary changes to bsd.licenses.mk and/or write documentation if someone else could take care of the bureaucratic part. I will start with a few points: *** bsd.license.db.mk *** We really need to rework it. I have no problem to others taking care of the file. It was initially just an example, and the plan was to automatically classify ports and take the license list from there (which might happen after I update the fossology port to the recent release and fix a few issues). It should at least contain the most popular / often used licenses -and- their -correct- versions. The latter is not always the case at the moment. And the versions should have only -one- format, not multiples. I suggest to always use a something like 'LGPLv2.1' and not 'LGPL21'. At least it has to be consistent across all licenses. I find it especially important to have a expression for 'version X or any later version' (for example 'LGPLv2+'), since the following dummy example is not adequate: LICENSE=LGPLv2 LGPLv2.1 LGPLv3 LGPLv3.1 LGPLv3.2 LICENSE_COMB=dual ... and so on for every future versions - it does not scale well and has to be changed with every new future version. Instead it should be just 'LGPLv2+' and stay there unchanged forever. These could be achieved with groups, or as you suggested with individual names. Regards, Ale P.S.: the mail was re-sent from the correct address (subscribed to the list) ___ 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: Virtualbox UI and remote X clients
On Oct 23, 2010, at 03:28 , Bernhard Froehlich wrote: I think it makes sense to add an OpenGL option that disables it all together. Can you try if it works for you when you reenable VIDEOHWACCEL in the Makefile and add CONFIGURE_ARGS+=--disable-opengl somewhere? I forcibly added --disable-opengl and recompiled. Same error. Looks like it's going to be a bit more tricky than that. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: transmission-daemon-2.04_1
Jeremy Messenger mezz.free...@gmail.com writes: 2010/10/21 Вадим Петряев vpetry...@tdnika.ru: Transmission was two times released after version 2.04 https://trac.transmissionbt.com/roadmap?show=completed 10 October released 2.10 and 17 October released 2.11 May be you need some help for port maintenance? As I understand, this port require only one patch changes - because patched libtransmission/fdlimit.c changed. I am not commit the update yet. Transmission have a bad history of release version that isn't stable enough as you can see they already have 2.11 in a very short peroid. I am able to reproduce a few of problems in 2.10 and 2.11. The 2.12 might be released sometimes soon (just a guess), so I will see how it goes. FYI, 2.04 is not bug-free either $ transmission-remote myhost -a http://foo/bar.torrent myhost:9091 responded: http error 0: No Response By waiting you're just trading one bunch of bugs for another. ;\ ___ 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
