https://bugs.winehq.org/show_bug.cgi?id=52037
Bug ID: 52037
Summary: MaiDenSnow Eve trial crashes upon entering load menu
Product: Wine
Version: 6.19
Hardware: x86-64
URL: https://trial.dlsite.com/doujin/RJ116000/RJ115762_tria
l.zip
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: galtgendo(a)o2.pl
Distribution: ---
I'm reporting against 6.19, but IIRC this predates 6.0.
I have no proof that the problem stems from the code in win32u/gdiobj.c, as gdb
backtraces report stack being corrupted. Yet after changing the warning in
handle_entry to print handle value, I can see the handle (font) being accessed
after being freed by free_gdi_handle. Also, 'all,-heap' somehow sidesteps the
crash, for a price of a major slowdown. The crash is 'illegal instruction', so
once again, stack corruption.
To reproduce:
- run the trial
- pick the last option (fourth) in the menu
- pick 'New Game'
- go with the first option in the next menu
- as the game starts, access menu (press X) and save (first option)
- press F12 to quickly restart the game
- back at the title screen pick 'Load Game'
- ...get the crash
(if at any point you get a splash screen with some text and a clock image, you
need to press 'up,left,up,down,right' on the keyboard)
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=19841
Summary: Wolfenstein (2009): mouse cursor remains onscreen
during FPS gameplay even after all menus are closed.
Product: Wine
Version: 1.1.28
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ben.r.xiao(a)gmail.com
In Wolfenstein (2009), browsing the intelligence reports or upgrading weapons
sometimes causes the mouse cursor to remain on screen even when the in-game
menus are closed. In other words, during FPS gameplay, the cursor sits right
where the crosshairs should be and does not disappear. Needless to say this is
quite distracting. This cursor bug seems to appear randomly, but always after
browsing an intelligence report or upgrading weapons. The only way to get rid
of the cursor is to restart the game. I'll post an attachment showing this bug
the next time I see it.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52732
Bug ID: 52732
Summary: Garbage user-name crated with wine, not the proper
user-name like in older versions.
Product: Wine
Version: 7.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rencer(a)euromail.hu
Distribution: ---
I'm not sure exactly when (the latest 7.4 version or which previous version)
this started to happen, because for a very long time I used Lutris to manage
Wine-versions and my Windows programs. Because of Lutris,I don't even have Wine
installed system-wide.
Sadly with the newest system (Manjaro XFCE) update someting in Python is
totally broken, and because of that Lutris won't work anymore, so I had to
install wine from system repo.
The latest version in 7.4
The problem is when I createa a new (or try to change an existing wineprefix to
use this system version), the user name is not my real username that I logged
in with. Now wine creates a strange garbage user name: "u@". Previously it was
correct and alway created the proper user folder, with the user who logged in
and run wine.
Long time ago, before I started using Lutris (I'm not sure which wine version
that was, around 4.x) I used command line to run wine, create prefixes, or run
any Windows programs and never was this bug. Also most of the progrmas I
installed with older versions and later never changed it, I think the last
version that I used with Lutris is 6.something and it also don't had this
user-name bug.
Problem is that all programs in any existing Wine-prefixes that was created
with Lutris, (with the PROPER user-name) are broken, settings are lost, saves
won't find, etc.,etc.,etc. because all the settings/saves are located in the
correct user-name folder and not in this new bugged garbage "@u" name. First I
thouth I lost all my files, and when I checked them with file-manager, that is
how I realised this strange behaviour.
Copying the files to the new garbage name location in NOT working all the time,
because many times programs store their settings, saved files, etc. in the
registry-database, so, this bug really broke many things.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52598
Bug ID: 52598
Summary: Update instructions for repository key usage due to
deprecation of apt-key
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: shtetldik(a)gmail.com
CC: dimesio(a)earthlink.net
Distribution: ---
When using the repo, apt update produces such warning:
W: https://dl.winehq.org/wine-builds/debian/dists/testing/InRelease: Key is
stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the
DEPRECATION section in apt-key(8) for details.
>From man apt-key
DEPRECATION
Except for using apt-key del in maintainer scripts, the use of apt-key
is deprecated. This section shows how to replace existing use of apt-key.
If your existing use of apt-key add looks like this:
wget -qO- https://myrepo.example/myrepo.asc | sudo apt-key add -
Then you can directly replace this with (though note the recommendation
below):
wget -qO- https://myrepo.example/myrepo.asc | sudo tee
/etc/apt/trusted.gpg.d/myrepo.asc
Make sure to use the "asc" extension for ASCII armored keys and the
"gpg" extension for the binary OpenPGP format (also known as "GPG key public
ring"). The binary OpenPGP format works for all apt versions, while the ASCII
armored format
works for apt version >= 1.4.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46936
Bug ID: 46936
Summary: cannot upgrade to wine-devel 4.5~bionic (libfaudio0
dependency missing)
Product: Packaging
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: a34ypool3voiz(a)t-online.de
CC: michael(a)fds-team.de, sebastian(a)fds-team.de
Distribution: ---
Created attachment 64049
--> https://bugs.winehq.org/attachment.cgi?id=64049
log showing missing libfaudio0 deps
I have installed winehq-devel 4.4 on Ubuntu 18.04 amd64.
Currently version 4.5 is available, but installation fails.
Trying the usual "apt-get update && apt-get upgrade && apt-get dist-upgrade"
lists winehq-devel as package that has been kept back.
Then I tried the following:
sudo apt-get install winehq-devel wine-devel wine-devel-amd64 wine-devel-i386
-f
Now two unmet dependencies are listed, which cause the failure: libfaudio0 and
libfaudio0:i386.
Those packages do not exist in the repository.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50251
Bug ID: 50251
Summary: Wrong public key from the repo prevents installation.
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: kristijan.zic(a)gmail.com
CC: dimesio(a)earthlink.net
Distribution: ---
Distro: Ubuntu 20.04
Followed instructions for Focal Fossa here:
https://wiki.winehq.org/Ubuntu
Got this error:
Err:10 https://dl.winehq.org/wine-builds/ubuntu focal InRelease
The following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 76F1A20FF987672F
Reading package lists... Done
W: GPG error: https://dl.winehq.org/wine-builds/ubuntu focal InRelease: The
following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 76F1A20FF987672F
E: The repository 'https://dl.winehq.org/wine-builds/ubuntu focal InRelease' is
not signed.
N: Updating from such a repository can't be done securely, and is therefore
disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration
details.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51920
Bug ID: 51920
Summary: Official package for Arch Linux
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: joseskvolpe(a)gmail.com
CC: dimesio(a)earthlink.net
Distribution: ArchLinux
Wine has packages on the Arch Linux multilib and community repository, they're
currently maintained by Felix Yan (Wine) and Daniel Bermond (Wine-gecko &
Wine-mono)
Problem is... Sometimes there's a huge delay on these packages when they get an
update. This is not a issue only with Wine, it occurs with many other packages
that are maintained in these repositories.
Wine has just released version 6.20, but these repositories are still in
6.16... If we had a official WineHQ repository for Arch Linux distributions
like we got in Ubuntu and Debian, we could get updates for Wine much quicker.
Additionally, having git versions on the official repository would also be neat
to get nightly builds of Wine. ^w^
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51849
Bug ID: 51849
Summary: Debian packaging: When building debian packages,
HARDENING flags will be passed to cross-compiler
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: cybermax(a)dexter.no
CC: dimesio(a)earthlink.net
Distribution: ---
When packages are built on debian, the default "hardening" flags will be passed
to wine/configure. The result from this is that wine/configure tries to do
checks for cross-compiler (mingw-w64) with flags meant to be used for ELF
binaries.
The flags are -Wl,-z,relro
This causes configure to fail several checks for cross-compiler.
The logs from WineHQ official OBS builds here for Debian 11:
https://build.opensuse.org/public/build/Emulators:Wine:Debian/Debian_11/x86…
Failing these checks will cause mingw-w64 to create loads of warnings like:
[ 1042s] In file included from dlls/cabinet/fdi.c:72:
[ 1042s] dlls/cabinet/fdi.c: In function 'FDI_read_string':
[ 1042s] dlls/cabinet/fdi.c:485:9: warning: format '%ld' expects argument of
type 'long int', but argument 6 has type 'INT_PTR' {aka 'long long int'}
[-Wformat=]
[ 1042s] 485 | TRACE("(fdi == %p, hf == %ld, cabsize == %ld)\n", fdi, hf,
cabsize);
[ 1042s] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~
[ 1042s] | |
[ 1042s] |
INT_PTR {aka long long int}
If you however build without passing -Wl,-z,relro to mingw-w64, configure will
pass a lot more tests, and the compile is quite a lot less noisy:
https://build.opensuse.org/build/home:SveSop/Debian_11/x86_64/wine-devel/_l…
Is there a possibility to avoid passing this flag to the cross-compiler in
wine/configure? From what i gather, the -Wl,-z,relro flag is meant for ELF
binaries, but afaik wine mostly (if not only) uses mingw-w64 to build PE libs,
and thus these flags fail.
You can add export DEB_LDFLAGS_MAINT_STRIP = -Wl,-z,relro to debian/rules, but
that ofc means the ELF binaries built by gcc will not get these hardening
flags.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=50891
Bug ID: 50891
Summary: Fedora 33 repository missing wine-*-common x86_64
packages
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: blacknova(a)tut.by
CC: dimesio(a)earthlink.net
Distribution: ---
After recent update of Fedora repository, all x64_64 versions of wine-*-common
packages are missing.
DNF upgrade command complain on broken dependencies:
Problem 1: cannot install the best update candidate for package
wine-staging64-1:6.4-1.1.x86_64
- nothing provides wine-staging-common = 1:6.5-1.2 needed by
wine-staging64-1:6.5-1.2.x86_64
Problem 2: package winehq-staging-1:6.5-1.2.x86_64 requires wine-staging64 =
1:6.5-1.2, but none of the providers can be installed
- cannot install the best update candidate for package
winehq-staging-1:6.4-1.1.x86_64
- nothing provides wine-staging-common = 1:6.5-1.2 needed by
wine-staging64-1:6.5-1.2.x86_64
Problem 3: problem with installed package wine-staging64-1:6.4-1.1.x86_64
- package wine-staging64-1:6.4-1.1.x86_64 requires wine-staging-common =
1:6.4-1.1, but none of the providers can be installed
- cannot install both wine-staging-common-1:6.5-2.1.i686 and
wine-staging-common-1:6.4-1.1.i686
- cannot install the best update candidate for package
wine-staging-common-1:6.4-1.1.i686
- nothing provides wine-staging-common = 1:6.5-1.2 needed by
wine-staging64-1:6.5-1.2.x86_64
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.