https://bugs.winehq.org/show_bug.cgi?id=8051
--- Comment #119 from Baggypants <junk(a)therobinsonfamily.net> ---
fixme:d3d:wined3d_device_set_software_vertex_processing device 0x6af20f0,
software 0x1 stub!
still occurs with Wine 1.7.45
--
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=625
--- Comment #22 from Ken Sharp <imwellcushtymelike(a)gmail.com> ---
No change in Wine 1.7.44
--
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=38170
Bug ID: 38170
Summary: wine fails to start on raspian/raspberry pi
Product: Wine
Version: 1.7.37
Hardware: arm
OS: Linux
Status: NEW
Keywords: download, source
Severity: critical
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Distribution: ---
I recently got a raspberry pi for a project, and tried wine on it.
It compiles (slowly, took 320 minutes), but trying to start anything fails:
pi@raspberrypi ~ $ ./wine-git/wine notepad
wine: failed to map the shared user data: c0000018
pi@raspberrypi ~ $ ./wine-git/wine winecfg
wine: failed to map the shared user data: c0000018
pi@raspberrypi ~ $ ./wine-git/wine winemine
wine: failed to map the shared user data: c0000018
pi@raspberrypi ~/wine-git $ git describe
wine-1.7.37-143-g3b2cf06
pi@raspberrypi ~/wine-git $ uname -a
Linux raspberrypi 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015
armv7l GNU/Linux
pi@raspberrypi ~/wine-git $ cat /etc/issue
Raspbian GNU/Linux 8 \n \l
There was a previous report, bug 33578, but it has been abandoned.
--
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=34645
Bug #: 34645
Summary: Updating menubar bar icon content.
Product: Wine
Version: 1.7.3
Platform: x86-64
OS/Version: Mac OS X
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: winemac.drv
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: f.platte(a)platte-web.de
Classification: Unclassified
I am using an application which has a menubar icon with the ability of showing
updates. In this case it is not a change of the icon itself (I don't know
whether this works) but giving some additional textual information. This output
does not appear.
--
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=37884
Bug ID: 37884
Summary: Proposal: remove 'ipc' keyword from Bugzilla (no
longer in use, questionable benefit)
Product: WineHQ Bugzilla
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: bugzilla-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: focht(a)gmx.net
Distribution: ---
Hello folks,
there were only three bugs that used the 'ipc' keyword and two of them were
incorrect.
It was never properly used in the past and a lot more bugs would need to be
tagged if the description is taken seriously - not 100 though as I wrote in the
other bug.
I propose to remove this keyword. There is no real benefit.
https://bugs.winehq.org/describekeywords.cgi
'winelib' might be also a candidate (has two). It might be useful as Bugzilla
component though. I found at least a dozen bug reports from the past which
would qualify for this.
Regards
--
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=8332
--- Comment #25 from oiaohm <oiaohm(a)gmail.com> ---
Sebastian Lackner
> Using exec in Wine in general is not necessarily bad, but it would of course be
> better to have only one "ping service" running instead of one application for
> each request.
Kinda agree kinda don't. Yes less applications but there is a limit.
One ping service per application is the valid limit but then it comes when will
you stop the ping service.
Remember Linux, Freebsd and Solaris have per application security. I can talk
way better about Linux.
So a global service for running ping shared between all wine applications is
directly breaking the Posix world security models. Same with the set
capability on the loader to fix things. Both are using a sledge hammer for
what should be carefully done.
Wine project for a very long time has taken the point of view that posix
security models can be disregarded.
Lets say I wish to individually cgroup wrap a Wine applications into
individually name-spaces at the moment. Anything done by shared services for
applications become problematic.
Binding to ports, pinging, sending network traffic these are all per
applications things and need to operate per application .exe so items like
Linux Security Modules(LSM:think Selinux, apparmor) and cgroups can in fact
work.
There are other issues like Linux binfmt-misc not being supported properly.
If binfmt-misc worked properly the "setcap cap_net_raw+epi" could have been put
in the .exe file instead of the loader so be per application. This would mean
that using environmental vars to set wine settings would have to mirrored in
xattrs or a file pointed to by a xattr containing instructions for the loader
to follow. binfmt is where the Linux kernel picks up file set capabilities.
You will not find no caps set on any native Linux loader. getcap
/lib/ld-linux.so.2 and on on will all return no cap set. So the fact that
getcap on /usr/bin/wine-preloader on Linux at times returns capabilities set is
in fact a bug coming from poor integration.
In fact there are important reasons why capabilities should not be set on
loaders. A loader does not contain a predefined task. So granting
capabilities to a loader is granting those capabilities to every application
run by that loader so breaking the per application security model into bits.
I was the one who pointed out that setcap privilage could be used instead of
just running as root. But truly its only minorally better than running the
applications as root. There are ways using CAP_NET_RAW to perform a privilege
escape by messing with traffic. CAP_NET_BIND_SERVICE also in some cases allows
privilege escapes by for example overriding local ldap server with your own yes
the cannot bind to under 1024 on Linux is a security restriction to protect
core services from random applications replacing them. Almost Linux every
capability provides a means to take control the system if it configured in
attackable ways. So using setcap is truly a mother of a hack with very bad
security ramifications. So neither of the Caps users of wine are having to
set are harmless. Its more luck than good management that systems are not
being hacked because of wine.
Poor integration with the host OS is a fairly major wine problem. Lot of
windows does X so should wine without proper consideration that there might be
2 or 3 ways to achieve X and the other ways may fit the host OS security model
way better.
Basically from my point calling a privileged executable/service to perform a
ping from a Windows application running in wine should not be a fall back
position it should be the default. This is what Linux and other posix
applications do when they want ping data. Behaving like a native application
demands it. Not breaking native OS security demands it. If wine is taking a
path that is completely different to how a host native applications are
expected todo it then its a hack and need to be serous-ally considered if this
is anywhere near correct because the security risk are no joke.
Sorry for being blunt.
Sebastian Lackner I do like your patch better question does it work with
http://bahai-education.org/ocean/ that this bug was opened with and is still
the only associated application.(If it does it grounds to close this bug if the
patch is applied then maybe other people will learn to associate their
application with bugs effecting them)
--
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.