Announcement

Collapse
No announcement yet.

Wine-Staging Will No Longer Be Putting Out New Releases

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by debianxfce View Post

    All i can say that you are wine religious that can accept technical facts. Bug reporting system is for whole winehq, it is developers job to react them. You can not run so many games with the current wine 3.2 that you can with wine-staging 2.21 and csmt is hidden in the registry, so wine sucks.
    With 3.0+ CSMT its on by default. No one has put in a feature request to have a on/off option in winecfg in mainline for CSMT. Developers are not mind readers. There was a bug requesting CSMT and that has been closed.

    Patches require to be submitted and its wine rules. If someone does not submit to the wine-devel mailing list or posts them directly into the bugzilla they do not get reviewed the mailing list makes sure of review. Wine developers don't go pulling from github or other places. This goes back to a 2004 event where something was pulled from third party repo and it turned out to be a developer working tree that was not ready. So its submit the patches if you want them included not create a github account somewhere and expect developers to get the stuff because they are not allowed to by the project rules.

    Again developers are not mind readers and processes exist that have to be followed due to historic errors or the stuff you want included will not be included..

    Developers will not waste their time on incorrect process bug reports comments. I could bug triage those bugs of yours. But I have to wait 90 days. I have told you what need to be done and I will tell you again in 90 days. Yes 90 days will pass and you issue will not be fixed most like and developer will not look at it will be left to triage to dispose of.

    In the wine world ending up with triage is a really bad place as we are not developers we will not rewrite patches instead triage will ask for correction and triage don't get correction possibly close bug.

    Really how long do you wish to have to maintain it. You have just created another staging fail.

    Us triage will go to a github and tell you want can be submitted to our rough inspection. No developer will.

    Really you suck debianxfce you complain about wine but you cannot follow the correct process and are not willing to-do correct process. If you want the changes seen by developers and reviewed for include into wine you follow the process of submit the patches to the correct places.

    Otherwise all I can believe is you never want those games to work with mainline wine and you want to have something to make yourself feel good that keeps on breaking all the time, Boy its a pain in tail dealing with masochists like debianxfce I understand why developers leave them to us triage.

    Originally posted by Vistaus View Post
    I don't think debianxfce should report bugs in the first place, given his weird, hacky Linux setup. It's hard to nail it down with such a setup and he's the only one with such a setup, so...
    Wine program turns out to be resistant to hacky Linux setups. Wine works on way worse than debianxfce setup without showing any extra side effects.

    Comment


    • #42
      Originally posted by oiaohm View Post
      If you want the changes seen by developers and reviewed for include into wine you follow the process of submit the patches to the correct places.
      Not to judge any one or to take any sides here but, this quote of yours is mildly naive. You're describing what it would work like under ideal circumstances. Wine development is hardly ideal. Things break without bug reports for it being confirmed for years. Literally, years. In part why I personally gave up trying to report bugs for Wine. It simply gets lost in the shuffle. Which is not the Wine developers' fault, mind you. Not implying that, at all.

      Just saying that Wine, as it currently stands, is not in an ideal state and its development is not in an ideal state either.

      Comment


      • #43
        Originally posted by geearf View Post

        Yup, that's the package.

        I don't know much about the problem though, it might be my fault I haven't done much testing yet.
        When you start your game do you see the little green text saying nine is active? If so, I would assume the package to work as expected.
        Maybe it's related to something newer in the release I use than in Sarnex' patches that are used for the other nine related packages?

        I just added a check to Wine >= 3.0 in case people tried with 2.x. I assume that was not your issue though.
        It does work well (as expected) with other games I've tried tho, I don't know for sure either, what I do know is that problem did not exist on wine-staging-nine package in official repos, as well as with patched 3.2. Having on mind that it does work diferently in overriding D3D dll's compared to staging-nine and pached version, and since game takes quite a bit more time to load and works at half of the performance, my uneducated guess is that wine attempts (and uses) both nine dll's and translation layer and somehow doesn't crash (if it's possible???). From the package itself, it doesn't seem like you did anything wrong, so it is likely implementation problem or something on my system (I have to re-test, couldn't get time to do it today). Anyway, if you can test it, just compare it to 2.21 staging-nine in official repository, or here's PKGBUILD I've did to patch 3.2 (just need to download patch files):
        Code:
        # $Id$
        # Maintainer: Sven-Hendrik Haase <[email protected]>
        # Contributor: Jan "heftig" Steffens <[email protected]>
        # Contributor: Eduardo Romero <[email protected]>
        # Contributor: Giovanni Scafora <[email protected]>
        
        pkgname=wine-gallium-nine-pached
        pkgver=3.2
        pkgrel=1
        
        _pkgbasever=${pkgver/rc/-rc}
        
        source=(https://dl.winehq.org/wine/source/3.x/wine-$_pkgbasever.tar.xz
                harmony-fix.diff
                30-win32-aliases.conf
                wine-binfmt.conf
                d3d9-helper.patch
                wine-d3d9.patch)
        sha512sums=('94b4903d628bf7aacd712a2bf566b53161880bf28311611106776df222222f592edb212d491f02e4c1b0c60d88e4b4a126981d445d1e18018238ff993c6c3092'
                    'SKIP'
                    'SKIP'
                    'SKIP'
                    'SKIP'
                    'SKIP')
        
        pkgdesc="A compatibility layer for running Windows programs"
        url="http://www.winehq.com"
        arch=(x86_64)
        options=(staticlibs)
        license=(LGPL)
        depends=(
          fontconfig      lib32-fontconfig
          lcms2           lib32-lcms2
          libxml2         lib32-libxml2
          libxcursor      lib32-libxcursor
          libxrandr       lib32-libxrandr
          libxdamage      lib32-libxdamage
          libxi           lib32-libxi
          gettext         lib32-gettext
          freetype2       lib32-freetype2
          glu             lib32-glu
          libsm           lib32-libsm
          gcc-libs        lib32-gcc-libs
          libpcap         lib32-libpcap
          desktop-file-utils
        )
        makedepends=(autoconf ncurses bison perl fontforge flex
          'gcc>=4.5.0-2'
          giflib                lib32-giflib
          libpng                lib32-libpng
          gnutls                lib32-gnutls
          libxinerama           lib32-libxinerama
          libxcomposite         lib32-libxcomposite
          libxmu                lib32-libxmu
          libxxf86vm            lib32-libxxf86vm
          libldap               lib32-libldap
          mpg123                lib32-mpg123
          openal                lib32-openal
          v4l-utils             lib32-v4l-utils
          libpulse              lib32-libpulse
          alsa-lib              lib32-alsa-lib
          libxcomposite         lib32-libxcomposite
          mesa                  lib32-mesa
          mesa-libgl            lib32-mesa-libgl
          opencl-icd-loader     lib32-opencl-icd-loader
          libxslt               lib32-libxslt
          gst-plugins-base-libs lib32-gst-plugins-base-libs
          samba
          opencl-headers
        )
        optdepends=(
          giflib                lib32-giflib
          libpng                lib32-libpng
          libldap               lib32-libldap
          gnutls                lib32-gnutls
          mpg123                lib32-mpg123
          openal                lib32-openal
          v4l-utils             lib32-v4l-utils
          libpulse              lib32-libpulse
          alsa-plugins          lib32-alsa-plugins
          alsa-lib              lib32-alsa-lib
          libjpeg-turbo         lib32-libjpeg-turbo
          libxcomposite         lib32-libxcomposite
          libxinerama           lib32-libxinerama
          ncurses               lib32-ncurses
          opencl-icd-loader     lib32-opencl-icd-loader
          libxslt               lib32-libxslt
          gst-plugins-base-libs lib32-gst-plugins-base-libs
          cups
          samba           dosbox
        )
        makedepends=(${makedepends[@]} ${depends[@]})
        install=wine.install
        
        conflicts=('wine' 'wine-staging')
        
        prepare() {
          # Allow ccache to work
          mv wine-$_pkgbasever $pkgname
        
          # https://bugs.winehq.org/show_bug.cgi?id=43530
          export CFLAGS="${CFLAGS/-fno-plt/}"
          export LDFLAGS="${LDFLAGS/,-z,now/}"
        
          patch -d $pkgname -Np1 < harmony-fix.diff
          patch -d $pkgname -Np1 < d3d9-helper.patch
          patch -d $pkgname -Np1 < wine-d3d9.patch
        
          cd "$srcdir/$pkgname"
          autoreconf -f
          cd "$srcdir"
        
          sed 's|OpenCL/opencl.h|CL/opencl.h|g' -i $pkgname/configure*
        
          # Get rid of old build dirs
          rm -rf wine-{32,64}-build
          mkdir $pkgname-32-build
        }
        
        build() {
          cd "$srcdir"
        
          msg2 "Building Wine-64..."
        
          mkdir $pkgname-64-build
          cd "$srcdir/$pkgname-64-build"
          ../$pkgname/configure \
            --prefix=/usr \
            --libdir=/usr/lib \
            --with-x \
            --with-gstreamer \
            --enable-win64
          # Gstreamer was disabled for FS#33655
        
          make
        
          _wine32opts=(
            --libdir=/usr/lib32
            --with-wine64="$srcdir/$pkgname-64-build"
          )
        
          export PKG_CONFIG_PATH="/usr/lib32/pkgconfig"
        
          msg2 "Building Wine-32..."
          cd "$srcdir/$pkgname-32-build"
          ../$pkgname/configure \
            --prefix=/usr \
            --with-x \
            --with-gstreamer \
            "${_wine32opts[@]}"
        
          make
        }
        
        package() {
          msg2 "Packaging Wine-32..."
          cd "$srcdir/$pkgname-32-build"
        
          make prefix="$pkgdir/usr" \
            libdir="$pkgdir/usr/lib32" \
            dlldir="$pkgdir/usr/lib32/wine" install
        
          msg2 "Packaging Wine-64..."
          cd "$srcdir/$pkgname-64-build"
          make prefix="$pkgdir/usr" \
            libdir="$pkgdir/usr/lib" \
            dlldir="$pkgdir/usr/lib/wine" install
        
          # Font aliasing settings for Win32 applications
          install -d "$pkgdir"/etc/fonts/conf.{avail,d}
          install -m644 "$srcdir/30-win32-aliases.conf" "$pkgdir/etc/fonts/conf.avail"
          ln -s ../conf.avail/30-win32-aliases.conf "$pkgdir/etc/fonts/conf.d/30-win32-aliases.conf"
          install -Dm 644 "$srcdir/wine-binfmt.conf" "$pkgdir/usr/lib/binfmt.d/wine.conf"
        }
        
        # vim:set ts=8 sts=2 sw=2 et:
        Originally posted by geearf View Post

        Well someone else mentioned a similar performance problem with Halo, but in my USFIV benchmarks I don't see a difference :/
        I don't know, it's rather strange problem, but might be less visible with strong CPU's, or it is exclusive to some mess on my system.


        PS: On topic, forked version of staging based on 3.2 someone did: https://github.com/wine-staging/wine-staging
        Last edited by leipero; 02-18-2018, 07:06 PM. Reason: adding link to staging fork on wine 3.2

        Comment


        • #44
          Originally posted by oiaohm View Post
          This causes trouble if an application tries to manually load the target of a redirection while the same library is already loaded under a different name. Wine does not notice that the library was already loaded and tries to load it a second time. The behaviour of builtin/native DLLs is slightly different, but in both cases an application might be confused.
          I call this "FEATURE"

          Anyway why not to let user decide how to `confuse` applications. Windows registry contains lot of options to `kill` system, why not to add some into wine registry.

          Also even Linux kernel have STAGING.
          Code:
          $ zcat /proc/config.gz | grep STAGING
          # CONFIG_STAGING is not set
          So add similar option into WINE's config and let people test more experimental stuff.
          Code:
          menuconfig STAGING
          bool "Staging drivers"
          default n
          ---help---
           This option allows you to select a number of drivers that are
           not of the "normal" Linux kernel quality level.  These drivers
           are placed here in order to get a wider audience to make use of
           them.  Please note that these drivers are under heavy
           development, may or may not work, and may contain userspace
           interfaces that most likely will be changed in the near
           future.
          
           Using any of these drivers will taint your kernel which might
           affect support options from both the community, and various
           commercial support organizations.
          
           If you wish to work on these drivers, to help improve them, or
           to report problems you have with them, please see the
           driver_name.README file in the drivers/staging/ directory to
           see what needs to be worked on, and who to contact.
          
           If in doubt, say N here.

          Comment


          • #45
            Originally posted by iyxwsoekthsv View Post
            Not to judge any one or to take any sides here but, this quote of yours is mildly naive. You're describing what it would work like under ideal circumstances. Wine development is hardly ideal. Things break without bug reports for it being confirmed for years. Literally, years. In part why I personally gave up trying to report bugs for Wine. It simply gets lost in the shuffle. Which is not the Wine developers' fault, mind you. Not implying that, at all.

            Just saying that Wine, as it currently stands, is not in an ideal state and its development is not in an ideal state either.
            Do note how many times I said since he had patches they need to be at least in the bugzilla but to be reviewed for sure had to be sent to wine-devel mailing list.

            Yes due to the number of faults in wine there is not enough developer time to fix everything. So it has to be prioritised. Have a bug report in wine effects the priority of the developer time same with paying money to code weavers.

            Basically I know the process is not ideal. But the process has to be done right or it does stand a chance at all. Its not like the developers and even use triage have enough to time do hand holding on all the bugs.

            Comment


            • #46
              Originally posted by leipero View Post

              It does work well (as expected) with other games I've tried tho, I don't know for sure either, what I do know is that problem did not exist on wine-staging-nine package in official repos, as well as with patched 3.2. Having on mind that it does work diferently in overriding D3D dll's compared to staging-nine and pached version, and since game takes quite a bit more time to load and works at half of the performance, my uneducated guess is that wine attempts (and uses) both nine dll's and translation layer and somehow doesn't crash (if it's possible???). From the package itself, it doesn't seem like you did anything wrong, so it is likely implementation problem or something on my system (I have to re-test, couldn't get time to do it today). Anyway, if you can test it, just compare it to 2.21 staging-nine in official repository, or here's PKGBUILD I've did to patch 3.2 (just need to download patch files):

              I don't know, it's rather strange problem, but might be less visible with strong CPU's, or it is exclusive to some mess on my system.


              PS: On topic, forked version of staging based on 3.2 someone did: https://github.com/wine-staging/wine-staging
              If it using both you should be able to trace it using WINEDEBUG=+loaddll could be using one of the wine versioned direct x entries replacements for Microsoft entries. This could also go wrong when using Dllredirects in staging. So it is possible to be using both wine direct x 9 and galluim 9 at the same time.

              Comment


              • #47
                Originally posted by wpupkin View Post
                I call this "FEATURE"

                Anyway why not to let user decide how to `confuse` applications. Windows registry contains lot of options to `kill` system, why not to add some into wine registry.[/CODE]
                Other than the fact we have had people report faults and not be able to work out what had gone wrong to report to the staging maintainer. So its not only confusing the application its confusing anyone attempting to debug the programs why they are not working at times.

                Originally posted by wpupkin View Post
                Also even Linux kernel have STAGING.
                Code:
                $ zcat /proc/config.gz | grep STAGING
                # CONFIG_STAGING is not set
                So add similar option into WINE's config and let people test more experimental stuff.
                Code:
                Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future.
                Please note the bit I kept out the staging define in the Linux kernel.

                https://lwn.net/Articles/324279/
                Then read this and wake up that Greg KH would have deleted over halve of Wine staging because the patches are not maintained.

                To keep patches in Linux kernel staging the patches have to keep on being modified to progress to leave Linux kernel staging and enter mainline. If you application no longer works due to Greg deleting a staging patch in the Linux kernel stiff if you did not what the patched delete you would have to have someone work on them. We would not be in the same mess now if this was happening to wine staging. Remember Greg deleted hyper-v drivers because he could not contact the developer behind the patch for 1 month.

                Who could tell me how to contact who wrote those patches in staging to confirm copyright for including in wine? So some of the really old patches in staging are also a legal mess where someone need to rewrite them to be legal because you cannot confirm copyright.

                I do not have a problem with the idea of staging but when you have 4 year old patches that have never reviewed on wine-devel and are sitting bit rotting in wine staging sooner or latter that is going to bite again. Basically there is a very big problem having a stack of patches bit rotting.

                Comment


                • #48
                  Originally posted by leipero View Post

                  It does work well (as expected) with other games I've tried tho, I don't know for sure either, what I do know is that problem did not exist on wine-staging-nine package in official repos, as well as with patched 3.2. Having on mind that it does work diferently in overriding D3D dll's compared to staging-nine and pached version, and since game takes quite a bit more time to load and works at half of the performance, my uneducated guess is that wine attempts (and uses) both nine dll's and translation layer and somehow doesn't crash (if it's possible???). From the package itself, it doesn't seem like you did anything wrong, so it is likely implementation problem or something on my system (I have to re-test, couldn't get time to do it today). Anyway, if you can test it, just compare it to 2.21 staging-nine in official repository, or here's PKGBUILD I've did to patch 3.2 (just need to download patch files):
                  I've tested it against 2.21 staging and 2.21 staging-wine, you'll see all numbers on AUR

                  I assume the patch you use is from Sarmex, if so it's probably older, which may mean that something got changed in a newer commit.
                  If you wouldn't mind, please compile the full wine using your pkgbuild from the nine release I use (I just compile the nine files) and try, if it's same as with my package please file an issue with nine. I don't have many games with benchmarks and so far I have not found a difference so I'm not the best to ask for help in this case.

                  Actually you mentioned something about CPU, well maybe, just maybe, the new indirection costs more CPU which becomes a problem in more CPU limited situation whereas SFIV is maybe too light for this? Just a pure logical guess
                  Though I've measure CPU time for SFIV and it's about the same between the 2 nine.

                  Thank you for your detailed report!
                  Last edited by geearf; 02-19-2018, 04:13 AM.

                  Comment


                  • #49
                    oiaohm It was a messup with overrides of some d3dx9_x files, I just had to use different overrides and it works fine now, WINEDEBUG is really helpful .

                    geearf Yes, I used sarnex patches, but it was mess up with my overrides, same happens if whole wine is compiled. So it's all fine now with that implementation, still there are some things to be done (as always) to get it on pair with solutions used in staging .

                    Comment


                    • #50
                      Originally posted by leipero View Post
                      geearf Yes, I used sarnex patches, but it was mess up with my overrides, same happens if whole wine is compiled. So it's all fine now with that implementation, still there are some things to be done (as always) to get it on pair with solutions used in staging .
                      I've tried another game and it looked about the same, a few % of higher CPU usage but nothing interesting, so I have nothing to report myself.

                      Comment

                      Working...
                      X