Re: Including Mono within a Wine package - should Wine expect this?
On Wed, 16 Apr 2008 06:52:49 -0700 Scott Ritchie [EMAIL PROTECTED] wrote: Ove Kaaven wrote: Debian's ia32-libs package isn't an example of a whole lot. It grabs compiled binaries from the official Debian archive, and nowhere else. It isn't built on a 32-bit system. If ia32-libs had contained binaries that could not be built 100% automatically using Debian's official archive (and only the official archive), it probably wouldn't have gotten into Debian. Besides, ia32-libs is not meant to be a long-lived package, it'll go away eventually. We've been saying that for 3 years now, and we've only become MORE dependent on ia32-libs in the process. The chief culprit, of course, is Wine, and Wine's need to run 32 bit applications isn't going away soon. Really, what Debian (and Ubuntu) need is to replace the contents of the ia32-libs package with proper 32 versions of package (sorta like how lib32asound and lib32z1 are now). Fixing that, however, is a bit beyond the scope of the wine-devel list ;) The real problem with multi-arch libs is, that it's hard to maintain inside debian packages at all...not that it's difficult to compile on amd64 with -m32 , but regarding the different ways of debian/rules writing with all different maintainer ways to write Makefiles for accomplishing this tasks is the most difficult thing. When there are people interested in going a hard way of fixing todays situation in debian/ubuntu and other distris, please let's do it , sane and with a plan. Regards, \sh
Better Debugging Possibilities for Wine on Ubuntu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Colleagues, As Scott Ritchie knows, I'm at the moment the reponsible person for Wine on Ubuntu. I hope that you all know, Ubuntu has a new system for filing crash reports and stacktraces. (named apport aka automatic crash reports, some documentation is found at https://wiki.ubuntu.com/Apport) Those reports are working quite well for all apps in Ubuntu, but not as expected for Wine, especially when windows apps are involved. We discussed yesterday about this problem, and now we want your help, to make things better. What we need from you: - What do you need from us (Ubuntu) to get better backtraces when wine crashes (especially wine-preloader) - How can we work together in a better way? (e.g. crashreport will be filed in launchpad (http://www.launchpad.net) automatically, can we file a bugreport automatically in your bugzilla?) - If yes, what information do you really need, what can we tell the users, who are reporting those crashes, what they have to do to fullfill your needs for the bugreport and debugging (e.g. try to reproduce the crash while running wine in gbd, doing a backtrace with bt full, or what so ever) Finally, we would like to have more involvement of you, Wine Developers, to make Wine a vital piece of software for Ubuntu. And now a little call for help to Scott Ritchie :) Scott, we talked some time ago about having you in our MOTU team, for maintaining not only debian/ubuntu packages at winehq, but also for Ubuntu. We, the Ubuntu MOTU team, and I personally think, this would be quite good having you on board. I know, that you are working hard on your packages, and we need your help. If you want, please get in touch with me (email: [EMAIL PROTECTED],de or jabber JID:[EMAIL PROTECTED]) and let's discuss how we can get you easily in our MOTU team. Thanks for your attention, Stephan aka \sh @ freenode.net - -- Stephan Hermann Ubuntu Developer http://launchpad.net/~shermann [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGJcYqwYnnM8CY76gRApcrAJ4xIsAUY7pLQTGzfTXIf47jIrnmywCfSTiG yX7HXj4ZzR1WiKzy+IUlXwE= =BssM -END PGP SIGNATURE-
Re: Better Debugging Possibilities for Wine on Ubuntu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marcus, e.g. https://bugs.launchpad.net/ubuntu/+source/wine/+bug/90957 Please note, we can add more features to apport (Martin Pitt is the maintainer). Regards, \sh Am Wed, 18 Apr 2007 09:52:08 +0200 schrieb Marcus Meissner [EMAIL PROTECTED]: On Wed, Apr 18, 2007 at 09:18:00AM +0200, Stephan Hermann wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Colleagues, As Scott Ritchie knows, I'm at the moment the reponsible person for Wine on Ubuntu. I hope that you all know, Ubuntu has a new system for filing crash reports and stacktraces. (named apport aka automatic crash reports, some documentation is found at https://wiki.ubuntu.com/Apport) Those reports are working quite well for all apps in Ubuntu, but not as expected for Wine, especially when windows apps are involved. We discussed yesterday about this problem, and now we want your help, to make things better. What we need from you: - What do you need from us (Ubuntu) to get better backtraces when wine crashes (especially wine-preloader) We usually get a default wine backtrace using winedbg --auto ... Can you show us some not so good backtraces by your tool? Ciao, Marcus - -- Stephan Hermann Ubuntu Developer http://launchpad.net/~shermann [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGJc/LwYnnM8CY76gRAvQeAJ0WV+Ei40IFMU4+ROShRoglpUBbWwCfZ/gO NiQnZ6YXvfhuNTXQ+cZd6NU= =7fNf -END PGP SIGNATURE-
Re: Better Debugging Possibilities for Wine on Ubuntu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Am Wed, 18 Apr 2007 07:11:28 -0600 schrieb Vitaliy Margolen [EMAIL PROTECTED]: Stephan Hermann wrote: - What do you need from us (Ubuntu) to get better backtraces when wine crashes (especially wine-preloader) As Marcus mentioned the best trace you can get is from the Wine's own debugger. Of course it would be even better with debug symbols installed on the system. - How can we work together in a better way? (e.g. crashreport will be filed in launchpad (http://www.launchpad.net) automatically, can we file a bugreport automatically in your bugzilla?) I would say NO. Wine crashes all the time for a lots of reasons. Some of those reasons have nothing to do with Wine itself. Some times they are a result of the missing feature. Creating bug-report for each crash won't help anyone, but will deplete resources of the server hosting bugzilla. Looking at your test report, it's bug # 219 in Wine's bugzilla. No crash report is require there. It's enough to see secdrv.sys and mentioning of the ntoskrnl.exe. In general the most useful pieces of information are ... complete terminal output, $PWD and the command used to start an application. Also the exact Wine version $(wine --version), and where did it came from (self-compiled or binary). All of them are absent from the report. That's one report generated by apport, which is, as you and others were writing, totally useless (that was my first impression, too) So, I'll go back to normal business for bugreporting and pointing the users to winedbg. Thx for all your answers :) Regards, \sh - -- Stephan Hermann Ubuntu Developer http://launchpad.net/~shermann [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGJkAfwYnnM8CY76gRAgUbAKCMDmqJGnFk6Vyxh9z/NT52DnE9UACfYFGD HHkA/895J4k/9jUv2qDyxm8= =CjkI -END PGP SIGNATURE-
Re: Licensing and technical issues with a Wine package that includes the Mozilla ActiveX Control
Hi Scott, On Sat, 2005-11-19 at 22:01 -0800, Scott Ritchie wrote: Greetings, As part of my work to create the ultimate works-out-of-the-box Wine package, I've begun to ponder the idea of including the Mozilla ActiveX control inside the Wine package. Currently, to install applications that use Internet Explorer internally, such as Steam, the user has to download the Mozilla ActiveX control as a tar file and then manually register the DLL to get Wine to use it (see the Howto in the AppDB entry here: http://appdb.winehq.org/appview.php?versionId=1554 ) When I read the Howto (http://www.linux-gamers.net/modules/wfsection/article.php?articleid=17) there is one section about If you don't want to install the MozActiveX Control. In this section of the Howto the author wrote, that you don't need the mfc dll when you installed the actviveX control of Mozilla. Thinking about security risks to have activeX applets anyways, and thinking about the possibilty if there is a Wine installation with enabled ActiveX out of the box (which I, as a normal user wouldn't want), I'm not quite sure, if we should ever ship this with a winepackage. Modifying Wine to recognize when the Mozilla ActiveX Control is installed without having to register it manually should be easy enough, however distributing it with the Wine package or as a separate side package presents an unusual licensing issue. Now, the Mozilla ActiveX control is freely licensed, and we can redistribute it however we please. Unfortunately, to make it work in Wine we also need to use the dlls for the Microsoft Foundation Classes that it's written in such as msvcp70.dll, as Wine does not currently implement those. As I understand the Howto, Steam somehow needs this mfc dll, but doens't ship it. That can mean, that the Steam developer don't have the rights to distribute it, which sounds a bit strange to me. If they don't deliver a vital dll for their software, they have a problem, which we or better you should not solve, with shipping any propietary software in the wine app. I think wine has to be an running environment for MS Windows applications, yes, but installing windows software should be in the responsibily of the user who is using Wine. These files have an unusual license. Someone who owns the compiler (such as MSVC 7) is allowed to distribute them, however redistribution further from there isn't necessarily allowed, as the person receiving the file doesn't have a license to redistribute like the EULA for the compiler grants. This doesn't seem to prevent us from giving out the package with the DLL included, however users wouldn't be able to redistribute it. This is a no go. I don't think we're allowed to ship it in any way, because (ok, I don't really know the correct distribution license, but MS is in any form very restrictive) we don't comply to their rules. MFC dll stuff is user orientated and should not be shipped by default. This sounds much like the way the situation is with the NVidia drivers. Would building the package be the right way to go here, with the ultimate destination being the restricted copyright repository in Ubuntu? Or is there something I'm overlooking here (perhaps reading the license wrong)? Well, it sounds more like the distribution license of Sun Java. ,-) Honestly, I don't like the idea to distribute userland windows applications or libraries in our packages. If wine upstream will include them, I, as one of the universe maintainer, would remove them from the upstream source package. Actually I'm quite frightend that someone will develop a new spyware tool, which runs only on wine environments and using unseen buffer overflows to inject malicious code or starts linux binaries, which are installed during the installtion of those tools. And the easiest way to do it, is to activate activeX by default. That's all IMHO, and I would like to hear James (elmo) and/or Martin (pitti) about their concerns regarding security and licensing issues. Regards, \sh
