Patch looks good. We will also need to update all the other languages and put in a redirect for the /downloads/debian page to the regular downloads page.
-N
On 07/22/2015 01:43 PM, Rosanne DiMesio wrote:
Updates the Debian links on the Downloads page to point to packages.debian.org and deletes the obsolete WineHQ Debian downloads page.
Ah, nice; I see you already caught the wine-development vs wine package differences.
-- Nate
Am 22.07.2015 um 21:27 schrieb Jeremy Newman:
Patch looks good. We will also need to update all the other languages and put in a redirect for the /downloads/debian page to the regular downloads page.
-N
On 07/22/2015 01:43 PM, Rosanne DiMesio wrote:
Updates the Debian links on the Downloads page to point to packages.debian.org and deletes the obsolete WineHQ Debian downloads page.
Jeremy, I think the intention was to link to the wine-development package, you changed the link to stable/wine which is quite old meanwhile...
On Wed, 22 Jul 2015 14:27:59 -0500 Jeremy Newman jnewman@codeweavers.com wrote:
Patch looks good. We will also need to update all the other languages and put in a redirect for the /downloads/debian page to the regular downloads page.
-N
I'm wondering why you changed the link to point to the packages for the stable release rather than the development release packages. All the other links on our Downloads page point to packages for the development releases, and that's what users are looking for when they come here.
I misunderstood the package. I thought it was just a meta package to install required development libs, like build-essential.
-N
On 07/22/2015 05:08 PM, Rosanne DiMesio wrote:
On Wed, 22 Jul 2015 14:27:59 -0500 Jeremy Newman jnewman@codeweavers.com wrote:
Patch looks good. We will also need to update all the other languages and put in a redirect for the /downloads/debian page to the regular downloads page.
-N
I'm wondering why you changed the link to point to the packages for the stable release rather than the development release packages. All the other links on our Downloads page point to packages for the development releases, and that's what users are looking for when they come here.
On Thu, 23 Jul 2015 09:10:42 -0500 Jeremy Newman jnewman@codeweavers.com wrote:
I misunderstood the package. I thought it was just a meta package to install required development libs, like build-essential.
-N
I understand why you thought that. It's the very reason I could never find the packages by googling "Debian wine," and probably the main reason Debian users can't find them either.
Now, the problem with what you changed it to is that it now points to the page for Debian Jessie (stable), which has outdated packages, and doesn't show the packages for Stretch (testing) or Sid (unstable). My patch linked to https://packages.debian.org/search?keywords=wine-development because the search results produce links to all three, which I think is easiest for users.
You can still switch to 'Sid' or 'Unstable' from that page. Most users are going to be running Debian Stable right now anyway.
Also, installing a Sid package on Stable is not recommended anyway due to dependency issues.
This is the root of the issue. How do Debian Stable users get the latest version of Wine that is built specifically for them?
-N
On 07/23/2015 10:02 AM, Rosanne DiMesio wrote:
On Thu, 23 Jul 2015 09:10:42 -0500 Jeremy Newman jnewman@codeweavers.com wrote:
I misunderstood the package. I thought it was just a meta package to install required development libs, like build-essential.
-N
I understand why you thought that. It's the very reason I could never find the packages by googling "Debian wine," and probably the main reason Debian users can't find them either.
Now, the problem with what you changed it to is that it now points to the page for Debian Jessie (stable), which has outdated packages, and doesn't show the packages for Stretch (testing) or Sid (unstable). My patch linked to https://packages.debian.org/search?keywords=wine-development because the search results produce links to all three, which I think is easiest for users.
On Thu, 23 Jul 2015 10:14:38 -0500 Jeremy Newman jnewman@codeweavers.com wrote:
You can still switch to 'Sid' or 'Unstable' from that page.
True; I overlooked the links on the upper right. Debian users familiar with the site would probably already know to do that.
Most users are going to be running Debian Stable right now anyway.
Testing and unstable users are more likely to want to upgrade every two weeks.
Also, installing a Sid package on Stable is not recommended anyway due to dependency issues.
I wasn't suggesting that. My thought was that users would click on the search results link to whatever version of Debian they were using. It's fine if they do that from the stable page; my one concern is that because the stable package is so out-of-date, some users might jump to the conclusion that that's true for all versions, and not even check.
This is the root of the issue. How do Debian Stable users get the latest version of Wine that is built specifically for them?
AFAICT, they don't. Debian seems to only build the latest version for testing and unstable. But I don't really know my way around the Debian site, so I may have missed something glaringly obvious.
On Thu, Jul 23, 2015 at 12:17 PM, Rosanne DiMesio dimesio@earthlink.net wrote:
On Thu, 23 Jul 2015 10:14:38 -0500 Jeremy Newman jnewman@codeweavers.com wrote:
I wasn't suggesting that. My thought was that users would click on the search results link to whatever version of Debian they were using. It's fine if they do that from the stable page; my one concern is that because the stable package is so out-of-date, some users might jump to the conclusion that that's true for all versions, and not even check.
This is the root of the issue. How do Debian Stable users get the latest version of Wine that is built specifically for them?
AFAICT, they don't. Debian seems to only build the latest version for testing and unstable. But I don't really know my way around the Debian site, so I may have missed something glaringly obvious.
That's correct, wine is 1.6.2 in Jessie, or wine-development is 1.7.29: https://packages.debian.org/jessie/wine https://packages.debian.org/jessie/wine-development
On 07/23/2015 10:02 AM, Rosanne DiMesio wrote:
and probably the main reason Debian users can't find them either.
Ding! I am a Debian Sid user, and I had no idea the wine-development packages existed nor what they were for. Turns out my 32-bit chroot/build-environment for Wine on 64-bit Debian was unnecessary, as Debian packages the Wine 1.7 tree. My previous email shows this candidly.
On 07/23/2015 10:02 AM, Rosanne DiMesio wrote:
Now, the problem with what you changed it to is that it now points to the page for Debian Jessie (stable), which has outdated packages, and doesn't show the packages for Stretch (testing) or Sid (unstable). My patch linked to https://packages.debian.org/search?keywords=wine-development because the search results produce links to all three, which I think is easiest for users.
What's the difference between the Stable and the Development releases of Wine? Given this thread of discussion, it seems the Wine team expects users to be using the Development release, not the Stable release. If that's the case, why even bother with Stable? Perhaps this is just a terminology thing; should Debian's wine package be packaging the Development release?
-- Nate
On 07/23/2015 11:14 AM, Nathan Schulte wrote:
On 07/23/2015 10:02 AM, Rosanne DiMesio wrote:
Now, the problem with what you changed it to is that it now points to the page for Debian Jessie (stable), which has outdated packages, and doesn't show the packages for Stretch (testing) or Sid (unstable). My patch linked to https://packages.debian.org/search?keywords=wine-development because the search results produce links to all three, which I think is easiest for users.
What's the difference between the Stable and the Development releases of Wine? Given this thread of discussion, it seems the Wine team expects users to be using the Development release, not the Stable release. If that's the case, why even bother with Stable? Perhaps this is just a terminology thing; should Debian's wine package be packaging the Development release?
I've migrated to Debian Stable within the past year (still think Ubuntu's great, just a minimalist that wanted to wander a bit upstream). If I understand everything, I think the main reason the wine team still bothers with a stable release is for distros like Debian Stable or Redhat. The slower-moving distros put a much heavier emphasis on testing; at the end of the day, they would rather package a version of wine that they can certify works ok, rather than one that works great in isolation but causes Gnome or dbus to explode.
On 07/23/2015 10:02 AM, Rosanne DiMesio wrote:
On Thu, 23 Jul 2015 09:10:42 -0500 Jeremy Newman jnewman@codeweavers.com wrote:
I misunderstood the package. I thought it was just a meta package to install required development libs, like build-essential.
I understand why you thought that. It's the very reason I could never find the packages by googling "Debian wine," and probably the main reason Debian users can't find them either.
I've actually been using the Debian package site a lot recently, and I was under a similar impression as Jeremy. I kept seeing wine-development, but I figured it contained headers (like most of the -dev packages) for compiling against libwine or something.
On Thu, Jul 23, 2015 at 12:17 PM, Rosanne DiMesio dimesio@earthlink.net wrote:
On Thu, 23 Jul 2015 10:14:38 -0500 Jeremy Newmanjnewman@codeweavers.com wrote:
This is the root of the issue. How do Debian Stable users get the latest version of Wine that is built specifically for them?
AFAICT, they don't. Debian seems to only build the latest version for testing and unstable.
Rosanne's right about the Debian repo, which means if you want to test the freshest wine on Debian Stable, you or someone else has to build it for you. Sure enough, that's exactly what I've been trying to figure out in my free time (and redo related pages on the wiki in the process). If you use chroot or LXC, it's tedious but pretty straight forward, but I'm trying to figure out precisely which wine dependencies still aren't multi-arch compatible.
IIUC, the funny thing about Debian is when they simultaneously took their leap of faith from ia32-libs and resisted the RPM "heresy" of just letting i386 and amd64 packages mingle freely, they made it *really* tricky to do things like build WoW64-wine without a chroot. However, the second all of wine's build-dependencies become multi-arch compatible, it *should* become very easy. In the long run, I think if we could go upstream and sort out architecture issues in wine's dependencies, that would give much bigger rewards.
Having a package of the development release definitely doesn't hurt though. One immediate way it helps is you can use apt-get build-dep without surprises. For example, the wine package on Jessie was still built with libgstreamer-0.10 libraries (which throw an error when you attempt a multi-arch build), but since then, the Debian packagers flirted with libgstreamer-1.0, then decided to drop it until it becomes more mature. I wonder though why the maintainers went with a separate wine-development package instead of just pointing the wine package in testing & unstable to the development release, then offering that to stable through Backports.
Sorry for the goofy formatting. One day Thunderbird doesn't wrap anything for me, the next it's cutting my lines short. I'm resending my message, hopefully with better formatting this time .
On 07/23/2015 11:14 AM, Nathan Schulte wrote:
On 07/23/2015 10:02 AM, Rosanne DiMesio wrote:
Now, the problem with what you changed it to is that it now points to the page for Debian Jessie (stable), which has outdated packages, and doesn't show the packages for Stretch (testing) or Sid (unstable). My patch linked to https://packages.debian.org/search?keywords=wine-development because the search results produce links to all three, which I think is easiest for users.
What's the difference between the Stable and the Development releases of Wine? Given this thread of discussion, it seems the Wine team expects users to be using the Development release, not the Stable release. If that's the case, why even bother with Stable? Perhaps this is just a terminology thing; should Debian's wine package be packaging the Development release?
I migrated to Debian Stable within the past year (still think Ubuntu's great, just a minimalist that wanted to wander a bit upstream). If I understand everything, I think the main reason the wine team still bothers with a stable release is for distros like Debian Stable or Redhat. The slower-moving distros put a much heavier emphasis on testing; at the end of the day, they would rather package a version of wine that they can certify works ok, rather than one that works great in isolation but causes Gnome or dbus to explode.
On 07/23/2015 10:02 AM, Rosanne DiMesio wrote:
On Thu, 23 Jul 2015 09:10:42 -0500 Jeremy Newman jnewman@codeweavers.com wrote:
I misunderstood the package. I thought it was just a meta package to install required development libs, like build-essential.
I understand why you thought that. It's the very reason I could never find the packages by googling "Debian wine," and probably the main reason Debian users can't find them either.
I've actually been using the Debian package site a lot recently, and I had a similar impression to Jeremy's. I kept seeing wine-development, but I figured it contained headers (like most of the -dev packages) for compiling against libwine or something.
On Thu, Jul 23, 2015 at 12:17 PM, Rosanne DiMesio dimesio@earthlink.net wrote:
On Thu, 23 Jul 2015 10:14:38 -0500 Jeremy Newmanjnewman@codeweavers.com wrote:
This is the root of the issue. How do Debian Stable users get the latest version of Wine that is built specifically for them?
AFAICT, they don't. Debian seems to only build the latest version for testing and unstable.
Rosanne's right about the Debian repo, which means if you want to test the freshest wine on Debian Stable, you or someone else has to build it for you. Sure enough, that's exactly what I've been trying to figure out in my free time (and redo related pages on the wiki in the process). If you use chroot or LXC, it's tedious but pretty straight forward, but I'm trying to figure out precisely which wine dependencies still aren't multi-arch compatible.
IIUC, the funny thing about Debian is when they simultaneously took their leap of faith from ia32-libs and resisted the RPM "heresy" of just letting i386 and amd64 packages mingle freely, they made it *really* tricky to do things like build WoW64-wine without a chroot. However, the second all of wine's build-dependencies become multi-arch compatible, it *should* become very easy. In the long run, I think if we could go upstream and sort out architecture issues in wine's dependencies, that would give much bigger rewards.
Having a package of the development release definitely doesn't hurt though. One immediate way it helps is you can use apt-get build-dep without surprises. For example, the wine package on Jessie was still built with libgstreamer-0.10 libraries (which throw an error when you attempt a multi-arch build), but since then, the Debian packagers flirted with libgstreamer-1.0, then decided to drop it until it becomes more mature.
I wonder though why the maintainers went with a separate wine-development package instead of just pointing the wine package in testing & unstable to the development release, then offering that to stable through Backports.
- Kyle
On 07/23/2015 05:23 PM, Kyle Auble wrote:
Sorry for the goofy formatting. One day Thunderbird doesn't wrap anything for me, the next it's cutting my lines short. I'm resending my message, hopefully with better formatting this time.
As a fellow Icedove user, I can say that you're not the only one who runs up against this. It's especially hairy for me around re-wrapping quoted content; I think I just don't understand how it works.
On 07/23/2015 05:23 PM, Kyle Auble wrote:
I migrated to Debian Stable within the past year (still think Ubuntu's great, just a minimalist that wanted to wander a bit upstream). If I understand everything, I think the main reason the wine team still bothers with a stable release is for distros like Debian Stable or Redhat.
Does Wine treat Stable this way? In that it receives bugfixes/security updates (from Development, mainline) that are applicable to making it more stable/secure? From the release log, it looks like Stable is basically dead; the last release was well over a year ago. I think with this scenario, as you hint at with your closing remarks Kyle, if there was a single release (no Stable/Development), Debian would just choose not to package the newer version and only release the one it believes is most stable (perhaps with Debian curated bugfix/security updates from upstream). It seems Stable is to help facilitate this (awesome!), but it doesn't actually work that way in practice.
On 07/23/2015 05:23 PM, Kyle Auble wrote:
On Thu, Jul 23, 2015 at 12:17 PM, Rosanne DiMesio dimesio@earthlink.net wrote:
AFAICT, they don't. Debian seems to only build the latest version for testing and unstable.
Rosanne's right about the Debian repo, which means if you want to test the freshest wine on Debian Stable, you or someone else has to build it for you. Sure enough, that's exactly what I've been trying to figure out in my free time (and redo related pages on the wiki in the process). If you use chroot or LXC, it's tedious but pretty straight forward, but I'm trying to figure out precisely which wine dependencies still aren't multi-arch compatible.
Looking at wine-development, it was packaged for Debian Stable, but due to the nature of Debian's release policy (which you seem familiar with; stable is stable), it doesn't receive but bugfix/security updates, and so is thus "stuck" at the version as packaged when Debian Stable was released.
This is to be expected, as that's how Debian wants Debian Stable. If you want the bleeding edge on Debian Stable (for any package), you're going to have to go outside of the Debian archives to get it if it's changed since Debian Stable's release. This holds for both the wine (Wine Stable) and wine-development (Wine Development) packages.
On 07/23/2015 05:23 PM, Kyle Auble wrote:
I wonder though why the maintainers went with a separate wine-development package instead of just pointing the wine package in testing & unstable to the development release, then offering that to stable through Backports.
We can always loop them in and ask: pkg-wine-party@lists.alioth.debian.org
It seems like the packaging in Debian of both Wine Stable and Wine Development as different "packages" in their own right was the wrong choice.
-- Nate
On 07/23/2015 04:29 PM, Nathan Schulte wrote:
On 07/23/2015 05:23 PM, Kyle Auble wrote:
Sorry for the goofy formatting. One day Thunderbird doesn't wrap anything for me, the next it's cutting my lines short. I'm resending my message, hopefully with better formatting this time.
As a fellow Icedove user, I can say that you're not the only one who runs up against this. It's especially hairy for me around re-wrapping quoted content; I think I just don't understand how it works.
I think that sometimes the packagers or developers change default settings between releases; I used to have that all the time with Firefox on Ubuntu. Apparently by default, the current Jessie version of Icedove wraps plain-text emails at 72 characters once you send them, but automatically unwraps them if you read them. You have to go to the config editor if you want to change that.
If I understand everything, I think the main reason the wine team still bothers with a stable release is for distros like Debian Stable or Redhat.
Does Wine treat Stable this way? In that it receives bugfixes/security updates (from Development, mainline) that are applicable to making it more stable/secure? From the release log, it looks like Stable is basically dead; the last release was well over a year ago.
The impression I get is that the wine project itself treats stable a little differently. Unless someone finds an egregious security issue in wine itself, it seems like the consensus is to keep wine-stable as inert as possible and let packagers apply their own minor patches on top.
It could be because so many features are still being improved, and there's still an expectation that the development release is more likely to work for your program anyway. Also, since wine works with so many other components on the system, it might be hard to assign blame to wine or the environment alone in a lot of cases. In that situation, it kind of makes sense to delegate minor, post-release fixes to the distros.
I wonder though why the maintainers went with a separate wine-development package instead of just pointing the wine package in testing & unstable to the development release, then offering that to stable through Backports.
We can always loop them in and ask: pkg-wine-party@lists.alioth.debian.org
It seems like the packaging in Debian of both Wine Stable and Wine Development as different "packages" in their own right was the wrong choice.
So I looked into it a little more, and it's arguably not so much a choice as the natural result of an improvement to the packaging on Debian. Apparently, there was traditionally a wine-unstable package in testing & unstable, it would conflict with an install of stable wine, and its packaging code is separate from the stable wine package's. The Debian packagers decided in the past year or so to change the name of wine-unstable to wine-development. At the same time though, someone put in a lot of work and managed to make the two packages capable of coinstallation via update-alternatives. This bug report gives a pretty good overview: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758291
I guess after doing that, they figured, "Why not offer both packages for Jessie? They don't conflict." I'm still going to ask on the mail-list about possibly having a Backports version though (plus I have some other questions related to multi-arch). While the difference between wine-development and wine is a little confusing at first, I don't think that's the real problem. In my mind, putting wine-development in the stable repo is self-defeating; you lose most of a development branch's value if it doesn't track upstream closely, and wine-development on Jessie is still stuck in last October.
- Kyle
On 07/24/2015 03:27 AM, Kyle Auble wrote:
On 07/23/2015 04:29 PM, Nathan Schulte wrote:
It seems like the packaging in Debian of both Wine Stable and Wine Development as different "packages" in their own right was the wrong choice.
So I looked into it a little more, and it's arguably not so much a choice as the natural result of an improvement to the packaging on Debian.
Yes, poor word choice on my part. Thanks for digging into this.
Michael's reply is insightful as well; it definitely sounds like this isn't an entirely unknown issue. I look forward to the discussion.
-- Nate
On 07/24/2015 01:29 AM, Nathan Schulte wrote:
On 07/23/2015 05:23 PM, Kyle Auble wrote:
I migrated to Debian Stable within the past year (still think Ubuntu's great, just a minimalist that wanted to wander a bit upstream). If I understand everything, I think the main reason the wine team still bothers with a stable release is for distros like Debian Stable or Redhat.
Does Wine treat Stable this way? In that it receives bugfixes/security updates (from Development, mainline) that are applicable to making it more stable/secure? From the release log, it looks like Stable is basically dead; the last release was well over a year ago. I think with
We already have a topic "Wine Stable Considered Harmful" for the WineConf in September, see http://wiki.winehq.org/WineConf2015
this scenario, as you hint at with your closing remarks Kyle, if there was a single release (no Stable/Development), Debian would just choose not to package the newer version and only release the one it believes is most stable (perhaps with Debian curated bugfix/security updates from upstream). It seems Stable is to help facilitate this (awesome!), but it doesn't actually work that way in practice.
On a high level view this are IMHO the good and bad things about the current stable process in Wine:
Good Bad ---- --- Code freeze/stabilization Way too old Marketing Release slips with features slippage Some distributions want it Distributions insist on using it Bug reports for stable are ignored
bye michael
On 07/24/2015 01:46 AM, Michael Stefaniuc wrote:
We already have a topic "Wine Stable Considered Harmful" for the WineConf in September, see http://wiki.winehq.org/WineConf2015
...
On a high level view this are IMHO the good and bad things about the current stable process in Wine:
Good Bad
Code freeze/stabilization Way too old Marketing Release slips with features slippage Some distributions want it Distributions insist on using it Bug reports for stable are ignored
When you think about it, isn't the idea of a separate, stable release by upstream a hold-over from the days before distributed VCS became widespread? I mean, a stable release is useful partly because it signifies upstream has invested a lot of time in testing and clearing out the bugs from existing features, which is still just as important as ever. At the same time though, it served an administrative function; if you were more involved downstream, how easy was it to stick your own patches on top of a moving target upstream without easy merging & rebasing?
It seems like other major projects, e.g. mozilla and the linux kernel, switched over to a rapid-release schedule soon after migrating their code to a DCVS. Funny enough, if you look back at old issues of WWN, even wine converged to the bimonthly release soon after dumping CVS. At this point, I figure it's still important to have regular code freezes and bug-hunts (perhaps even more often, like semi-annually?) Nowadays though, it makes a lot more sense than it once did, to let the distros decide which one of those to branch from and make their "stable."
It's an interesting question actually, how the technology effects the organization. It should probably be in a new thread, but I imagine there are some other procedures the project could revamp to fit the newer tools.
- Kyle
On Thu, 23 Jul 2015, Kyle Auble wrote: [...]
IIUC, the funny thing about Debian is when they simultaneously took their leap of faith from ia32-libs and resisted the RPM "heresy" of just letting i386 and amd64 packages mingle freely, they made it *really* tricky to do things like build WoW64-wine without a chroot.
I have dug into the multiarch issues that impact Wine and made bug reports and tried to propose patches. I don't have time to push things forward currently so here's the list in case someone wants to pick it up.
Note that at the time the header situation was still not quite clear. Now it's easy, just put them in /usr/include/i386-linux-gnu and /usr/include/x86_64-linux-gnu.
Also note that a bunch of these are actually so GStreamer 0.10 can be made multiarch, which may well never happen.
(the date corresponds to the last bug update)
2015/02/10 Bug 689068 libxi-dev is not Multi-Arch compatible 2013/05/20 Bug 666761 [libfreetype6-dev] Make libfreetype6-dev multiarch-installable 2015/02/07 Bug 689082 Patch: libxcomposite-dev is not Multi-Arch compatible [patch] 2015/02/10 Bug 689089 libglu1-mesa-dev is not Multi-Arch compatible 2012/09/29 Bug 689090 libgstreamer0.10-dev is not Multi-Arch compatible 2015/02/12 Bug 689097 libgtk2.0-dev is not Multi-Arch compatible 2015/02/10 Bug 689122 libcairo2-dev is not Multi-Arch compatible 2015/02/11 Bug 683592 libpango1.0-dev: mark libpango1.0-dev multi-arch:same 2015/02/11 Bug 689124 libatk1.0-dev is not Multi-Arch compatible 2015/05/23 Bug 683593 Patch: libglib2.0-dev: please mark libglib2.0-dev multi-arch: same [patch] 2012/09/29 Bug 689125 libgdk-pixbuf2.0-dev is not Multi-Arch compatible 2015/05/23 Bug 714589 Request Multi-Arch support for package libgcrypt11-dev 2013/07/26 Bug 717883 python-gtk2: Please convert python-gtk2 to multiarch 2015/02/11 Bug 760370 libpcap0.8-dev is not Multi-Arch compatible 2015/02/06 Bug 777200 Patch: libcdaudio1 is not Multi-Arch compatible [patch] 2015/02/06 Bug 777202 Patch: libzbar0 is not Multi-Arch compatible [patch] 2015/02/06 Bug 777209 Patch: libkate1 is not Multi-Arch compatible [patch] 2015/02/06 Bug 777211 Patch: libgtkglext1 is not Multi-Arch compatible [patch] 2015/07/27 Bug 777222 Patch: libcdio13 is not Multi-Arch compatible [patch] 2015/05/22 Bug 786562 libexif-dev is not Multi-Arch compatible
(I'm omitting the 34 other multiarch bugs that got fixed)
On 09/11/2015 08:09 AM, Francois Gouget wrote:
I have dug into the multiarch issues that impact Wine and made bug reports and tried to propose patches. I don't have time to push things forward currently so here's the list in case someone wants to pick it up.
I saw some of your bug reports when I was looking into the exact state of play for Wine's build-dependencies. Thanks for providing the full list; if someone wants to, they can add your bug-list to the multi-arch page on the wiki: http://wiki.winehq.org/WineMultiArch ... or I can the next time I have some down-time to edit the wiki.
Note that at the time the header situation was still not quite clear. Now it's easy, just put them in /usr/include/i386-linux-gnu and /usr/include/x86_64-linux-gnu.
I'm glad you brought this up too. I read the Ubuntu wiki page on multi-arch for -dev packages, but it described everything as tentative, and the page hasn't been updated for 2 years. That simplifies things a lot now that the triplet system also works for /usr/include (it's not part of the FHS yet though, right?)
Also note that a bunch of these are actually so GStreamer 0.10 can be made multiarch, which may well never happen.
I mentioned on the wiki page that any work on making GStreamer multi-arch should probably focus on v1.0. That's the ultimate goal for reworking audio plugin support in Wine, isn't it? When we copy down your bug list, we can add comments to the ones that are only relevant to GStreamer 0.10.
- Kyle
-
André Hentschel -
Austin English -
Francois Gouget -
Jeremy Newman -
Kyle Auble -
Michael Stefaniuc -
Nathan Schulte -
Rosanne DiMesio