After watching DiMesio on FOSDEM

[philipz]

I enjoyed watching your presentation at FOSDEM and wished that the presentation slide file could be found somewhere online. I would also like to assist you with any ubuntu, linux mint, and debian related help you need to improve the wiki, so please let me know. (i regularly use ubuntu and mint and though havent installed debian before, will do so if its needed).

After watching the presentation and visiting the website, i would like to make the following observations/comments.

* Ubuntu 14.04 will be shipping wine 1.6.1. Wine in Ubuntu is located in the universe repository and it would have been a good thing if the universe repository also contained the beta wine branch, so atleast users would have access to a more recent version from their package manager, even if they dont have the PPA enabled. The packages are found in the PPA and getting them put into the universe repo shouldnt be that much of a stretch. Atleast if not the beta wine branch, atleast the stable Wine branch, as for the last 2 years, Ubuntu never moved from 1.4.0, though 1.4.1 has been available for most of the 2 years.

* You mentioned that 1.5.9 fixed X11 problems users of 1.4.1 were having, so why wasn't a 1.4.2 release done which could have backported some of these solved problems, as 1.5.9 was released only 1 month after 1.4.1, as 1.4.x is supposed to be the stable branch.

* I visited the bugs page < http://wiki.winehq.org/Bugs > and it states that user's shouldn't submit bugs for stable Wine versions, which i found as strange. The page also states 'You tested with a clean Wine directory', but doesnt mention how to do this or link to such information. The page also states 'Your system has all the libraries that Wine needs (see Recommended Packages).' but if i'm not mistaken, those are packages for building wine, not running wine, so i'm assuming the user isnt coming to report a bug about compiling wine, but if so, they should be directed somewhere else i believe.

* I've update the recommended build packages for Ubuntu & Linux Mint on < http://wiki.winehq.org/Recommended_Packages >.

* You mentioned about outdated information about building wine on debian 64-bit and i'm ready to attempt to confirm the information you were linking users to, if you can provide me that link, unless someone has already done so.

* In the PulseAudio sticky thread < http://forum.winehq.org/viewtopic.php?f=8&t=16895 >, I think a link to the ubuntu forum thread about winepulse < http://ubuntuforums.org/showthread.php?t=1960599 > is useful to link to, especially after thats the error message wine displays regarding pulseaudio.

* Do WineHQ intend to make a PPA instruction page similar to Ubuntu's < http://www.winehq.org/download/ubuntu > for Linux Mint users, and if so, I can supply the necessary information.

* I visited < http://www.winehq.org/docs/wineusr-guide/wine-versions > and noticed it mentions 'CodeWeavers CrossOver Office' which is not sold anymore.

* As you stated, there needs to be a streamlined one login system for all of winehq, as i had to create 4 separate accounts and had to verify my email 3 times (wiki didnt ask me to verify).

* I think a sticky topic should be setup in the 'Wine Help' forum for new users of the forum with guidelines to view before creating a post, similar to instructions give before submitting a bug, as well as common questions that can later be shifted over to the FAQs.

* Expand the forum having the linux and mac os x subforums appear as main forums entries on the forum main page. Possibly have subforums under the linux forum for 1) ubuntu and debian distros and their derivatives (e.g. linux mint), 2) fedora and opensuse and other rpm based distros (e.g. centos/rhel) and their derivatives, 3) arch and gentoo distros, and 4) one for others. These subforums should be displayed well on the forum main page, so users will easily click them and not clicking on the linux forum first to get to them (which is how it currently feels now with the 'Wine Help' forum and the 'Linux' subforum), possibly with distro icons. Another benefit of having separate distro forums is to have separate sticky topics catered to that audience (more detailed instructions for ubuntu users and less for arch users).

* It would be great if there were a browse by category page in AppDB, so i could easily jump to the necessary category rather than searching, as sometimes i've really hated the searching.

* Improved search in AppDB, as searching for 'microsoft word' and 'microsoft excel' return no results, as microsoft is not mentioned in the application name field, but is in the description field.

Ultimately, i think the main problem is that there is alot of information, but its distributed in various parts, i.e. forum, faq, wiki and user guide, instead of just one centralize definitive location. I think that definitive location should be the wiki and all information from the user guide should be put into the wiki (there isn't a page in the wiki on how to compile the 32-bit source, but its in the user guide). After going through the faq, i see that alot of information is being crammed into that one page (e.g. a guide to compiling the 32-bit source), rather than being distributed throughout the wiki. the faq should be of limited scope for common questions (like whats found in the general questions, application, and risks sections) and focus on short answers, and link to the wiki pages if the user wants more detailed information that require editing files, running terminal commands, etc.

I think you for your efforts for supporting the users in the forum and the wine team for making it an easier to transition from windows to linux for those that cant find linux alternative software.

[dimesio]

I enjoyed watching your presentation at FOSDEM and wished that the presentation slide file could be found somewhere online. I would also like to assist you with any ubuntu, linux mint, and debian related help you need to improve the wiki, so please let me know. (i regularly use ubuntu and mint and though havent installed debian before, will do so if its needed).

Glad you enjoyed it. Any help you can provide will be appreciated.

* You mentioned that 1.5.9 fixed X11 problems users of 1.4.1 were having, so why wasn't a 1.4.2 release done which could have backported some of these solved problems, as 1.5.9 was released only 1 month after 1.4.1, as 1.4.x is supposed to be the stable branch.

It was vcrun, not X11, and I believe it was not eligible for backporting because those patches were considered new features, not bugfixes.

* I visited the bugs page < http://wiki.winehq.org/Bugs > and it states that user's shouldn't submit bugs for stable Wine versions, which i found as strange.

It is correct. Bugs are fixed in the development branch, and the point is to make sure the person is not reporting a bug that has already been fixed.

The page also states 'You tested with a clean Wine directory', but doesnt mention how to do this or link to such information.

It has that info in parentheses right after the part you quoted: (default location: "~/.wine", z: drive -> / link exists, no DLL overrides). I will admit that is a bit terse.

The page also states 'Your system has all the libraries that Wine needs (see Recommended Packages).' but if i'm not mistaken, those are packages for building wine, not running wine, so i'm assuming the user isnt coming to report a bug about compiling wine, but if so, they should be directed somewhere else i believe.

Wine needs the libraries to run, too, and a common problem is users reporting bugs when they are simply missing a dependency. As for problems building Wine, if it is a legitimate bug, Bugzilla is the place to report that, too. But I agree that the link to the Recommended Packages page at that point is somewhat misleading.

* I've update the recommended build packages for Ubuntu & Linux Mint on < http://wiki.winehq.org/Recommended_Packages >.

Thank you.

* You mentioned about outdated information about building wine on debian 64-bit and i'm ready to attempt to confirm the information you were linking users to, if you can provide me that link, unless someone has already done so.

The blog I've been referring people to is http://verahill.blogspot.com/2013/08/49 ... ot-on.html.

* Do WineHQ intend to make a PPA instruction page similar to Ubuntu's < http://www.winehq.org/download/ubuntu > for Linux Mint users, and if so, I can supply the necessary information.

Maintaining information about downloading binaries is up to the package maintainers; it's only provided here as a convenience. Someone did file a bug here noting that the Ubuntu instructions don't work for Mint, http://bugs.winehq.org/show_bug.cgi?id=33549, but since Mint uses the Ubuntu packages, it's up to Scott and Maarten whether they want to write separate instructions for Mint.

* I visited < http://www.winehq.org/docs/wineusr-guide/wine-versions > and noticed it mentions 'CodeWeavers CrossOver Office' which is not sold anymore.

Please file a bug for that.

* As you stated, there needs to be a streamlined one login system for all of winehq, as i had to create 4 separate accounts and had to verify my email 3 times (wiki didnt ask me to verify).

There's a longstanding bug for that: http://bugs.winehq.org/show_bug.cgi?id=19386. For me, the bigger problem in finding information is that the four sections have separate search functions, and some work better than others.

* I think a sticky topic should be setup in the 'Wine Help' forum for new users of the forum with guidelines to view before creating a post, similar to instructions give before submitting a bug, as well as common questions that can later be shifted over to the FAQs.

There is one in Announcements. http://forum.winehq.org/viewtopic.php?f=7&t=288

*Possibly have subforums under the linux forum for 1) ubuntu and debian distros and their derivatives (e.g. linux mint), 2) fedora and opensuse and other rpm based distros (e.g. centos/rhel) and their derivatives, 3) arch and gentoo distros, and 4) one for others.

That one I don't agree with. It would make the forum too difficult to manage and harder for users to find known issues. The differences between MacOSX and Linux are significant enough to warrant separate subforums, but in Linux, most questions/problems are applicable to all distros.

* It would be great if there were a browse by category page in AppDB, so i could easily jump to the necessary category rather than searching, as sometimes i've really hated the searching.

* Improved search in AppDB, as searching for 'microsoft word' and 'microsoft excel' return no results, as microsoft is not mentioned in the application name field, but is in the description field.

The AppDB search is terrible. You could file a bug for those things, but the chances of them being fixed are practically nil.

Ultimately, i think the main problem is that there is alot of information, but its distributed in various parts, i.e. forum, faq, wiki and user guide, instead of just one centralize definitive location.

Yes. That was one of the main points I tried to make at FOSDEM.

After going through the faq, i see that alot of information is being crammed into that one page (e.g. a guide to compiling the 32-bit source), rather than being distributed throughout the wiki.

One barrier to breaking up the FAQ is that it would make things significantly harder for the translators. The page could use some reorganizing, though.

[philipz]

Glad you enjoyed it. Any help you can provide will be appreciated.

Please let me know how i can.

It is correct. Bugs are fixed in the development branch, and the point is to make sure the person is not reporting a bug that has already been fixed.

For a new user coming to linux trying to use wine on for example Ubuntu, and wine encourages a user to submit the bug report and this new user has to upgrade to the latest development version in order to confirm that the bug is still there, might be a stretch for a new user.

It has that info in parentheses right after the part you quoted: (default location: "~/.wine", z: drive -> / link exists, no DLL overrides). I will admit that is a bit terse.

I was trying to get at was there were no instructions on how to clean a wine directory: ( "$ rm -rf ~/.wine" )

Wine needs the libraries to run, too, and a common problem is users reporting bugs when they are simply missing a dependency. As for problems building Wine, if it is a legitimate bug, Bugzilla is the place to report that, too. But I agree that the link to the Recommended Packages page at that point is somewhat misleading.

Well maybe instructions should be given on what type of bug reporting they are doing. If they have dependency issues, then it should like to a dependency wiki page and if they are having problems building wine, then there should be a building wine wiki page that they should be visiting before coming to the bug page.

The blog I've been referring people to is http://verahill.blogspot.com/2013/08/49 ... ot-on.html.

Will test it out and give you my feedback.

Maintaining information about downloading binaries is up to the package maintainers; it's only provided here as a convenience. Someone did file a bug here noting that the Ubuntu instructions don't work for Mint, http://bugs.winehq.org/show_bug.cgi?id=33549, but since Mint uses the Ubuntu packages, it's up to Scott and Maarten whether they want to write separate instructions for Mint.

I've added a message to the bug.

Please file a bug for that.

Where to a file a bug for the user usage?

There's a longstanding bug for that: http://bugs.winehq.org/show_bug.cgi?id=19386. For me, the bigger problem in finding information is that the four sections have separate search functions, and some work better than others.

Luckily the search underneath the menu found on each section of the website does do a google search through the whole winehq.org domain. unfortunately the search found on the wiki page only searches the wiki.

There is one in Announcements. http://forum.winehq.org/viewtopic.php?f=7&t=288

Most people coming to the forum for help will likely not go into the Announcement forum and see that thread. Also why have the forum guidelines posted in the wiki rather than in the forum.

That one I don't agree with. It would make the forum too difficult to manage and harder for users to find known issues. The differences between MacOSX and Linux are significant enough to warrant separate subforums, but in Linux, most questions/problems are applicable to all distros.

Well why have linux and macosx as subforums rather than main forums, as when i came to the forum, i didnt even notice the subdomain links. I only noticed those subdomains after going into the Wine Help forum. Regarding subforums under linux, well i was suggesting this so that it might be easier for your statistical purposes and was assuming that the questions would be quite different coming from an ubuntu user than an arch user.

The AppDB search is terrible. You could file a bug for those things, but the chances of them being fixed are practically nil.

If its unlikely that reporting the bug would resolve the issue, then i'll simply stick with google.

One barrier to breaking up the FAQ is that it would make things significantly harder for the translators. The page could use some reorganizing, though.

In my opinion, reorganization the FAQ page wont help the issue as more and more information will likely be added or changed on the page. Editing the page as it is right now is a hassle as you have to scroll through an endless amount of text looking for the section you want to modify, and the wiki nags about give you a 10 minute window to modify that information, and what happens when multiple people are modify two separate sections around the same time. Atleast with the wiki system on wikipedia, you can go to a section and edit just that section, which will lessen the likelihood of overlapping edits. But ultimately, we need related sections to have their own dedicated wiki page for maximum benefit to the community and those translators who wish to assist with this will do so.

[dimesio]

For a new user coming to linux trying to use wine on for example Ubuntu, and wine encourages a user to submit the bug report and this new user has to upgrade to the latest development version in order to confirm that the bug is still there, might be a stretch for a new user.

Filing bugs for things that have already been fixed just wastes everyone's time, including the user's, and upgrading a package is well within the skill set of a normal user.

I was trying to get at was there were no instructions on how to clean a wine directory: ( "$ rm -rf ~/.wine" )

That's in the FAQ. Possibly we should add a line reminding new users to read the FAQ before they file a bug.

Well maybe instructions should be given on what type of bug reporting they are doing. If they have dependency issues, then it should like to a dependency wiki page and if they are having problems building wine, then there should be a building wine wiki page that they should be visiting before coming to the bug page.

Users with dependency issues don't usually realize that is the problem. Users who are reporting bugs related to building usually know what they're doing.

Where to a file a bug for the user usage?

In bugzilla. The component should be documentation, the severity trivial.

Well why have linux and macosx as subforums rather than main forums, as when i came to the forum, i didnt even notice the subdomain links. I only noticed those subdomains after going into the Wine Help forum.

I tend to agree with you, but I'm not the one who makes that decision.

Editing the page as it is right now is a hassle as you have to scroll through an endless amount of text looking for the section you want to modify, and the wiki nags about give you a 10 minute window to modify that information, and what happens when multiple people are modify two separate sections around the same time.

I've never been nagged by the wiki about a time limit, but other than that, I agree editing the FAQ is a hassle because of the sheer size of it. But again, the decision to break it up is not mine to make.

[dimesio]

FYI, I changed the "Welcome to..." announcement to a global one, so it should now appear at the top of every subforum (an option I hadn't noticed before).

[philipz]

Thank you for taking the time to reply to my questions and suggestions and i look forward to your next presentation. Do you know where i can find last year's fosdem wine presentations as its not in fosdem's video archive.

[dimesio]

Not all of them are available, but there are links to the ones that are at the bottom of http://wiki.winehq.org/FOSDEM2013.

[philipz]

Well i did the building as requested on Debian 7.4 XFCE 64-bit for Wine 1.7.14 and the instructions worked, as many others in the comments confirmed it would.

I installed the package but didnt find icons for wine in the xfce menu. I'm going to check over the current instructions in the wiki and see if i can get it to work. Is there a set of portable windows applications that i can test to make sure everything is working correctly?

I visited the Debian Sid download page and noticed that the regression link doesnt work and that the last time the beta build was built for Sid was 1.7.11. The page also doesnt have any stable builds.

[dimesio]

Thanks for verifying the instructions work.

If the icons you mean are ones for winecfg, etc., those aren't part of Wine. They are something some distros add to their packages.

I filed a bug for the dead link on the Debian download page. http://bugs.winehq.org/show_bug.cgi?id=35746

As for the Debian packages, as with all other packages/repositories, the person to contact about that is the package maintainer. Maintainers are volunteers, and when and what to build is entirely their decision.

[philipz]

Well i tried to use the instructions from the wiki but it wasnt possible to install pkg-config and pkg-config:i386 at the same time, which is why i assume the instructions were to install wine in a chroot.

Is there anything else you'd like me to help out with?

[spoon0042]

Do you know how to build debian packages from source? I think the debian packaging on that page builds both 32 and 64 bit without the chroot mess (if you're running 64 bit, which I'm not). I did use it to build packages on stable; I don't remember having any issues. The one thing I did was to edit the top of debian/changelog since that's where the packaging tools get the version from.

e: One thing I remembered is it has a bogus dependency on an old version of wine-gecko. I should probably try to contact the maintainer about that.

[philipz]

I dont have experience building debian packages from source, but i followed the instructions from the wiki page and that didnt work for me on Debian 64-bit stable.

[spoon0042]

Well I'm pretty sure I'm wrong anyway about it building both at once. It may be possible to build both from source by setting the architecture with dpkg-buildpackage, but that's just a guess.

Anyway, both the page linked from winehq.org/download and official debian unstable have updated to 1.7.14, not sure what the difference is between them but that should make things (slightly) easier. (I only know this from seeing this topic about getting wine on mint: http://forum.winehq.org/viewtopic.php?f=8&t=22027 )

Did you manage to get wine installed one way or another? (and/or was it just the wiki instructions you had problems with?)

[philipz]

Got it packaged with the blogspot link instructions but with the wiki instructions, i wasnt able to install all the required packages from the instructions, so i didnt attempt to compile it.

[dimesio]

The instructions in the wiki for building on Debian were written before the switch to multiarch. AFAIK, they should still work on pre-multiarch Debian, but won't work on multiarch Debian. The instructions in the blogspot post do work on multiarch Debian.

I tried to put a link to the blogspot post in the wiki, but found that blogspot.com is on the wiki's blocked list due to spammers.

[philipz]

Maybe we should copy the instructions over to the wine wiki and use a url shortener to point to it.