Bug#1031649: wine: /usr/bin/wine64 still required
On zondag 19 februari 2023 20:08:54 (+01:00), Jens Reyer wrote:
> Source: wine
> Version: 8.0~repack-4
> Severity: serious
>
> Hi Mike,
>
> I wasn't aware of this, but it seems indeed that /usr/bin/wine64 is
required somehow: winetricks fails to start with 8.0~repack-4, but works
with 8.0~repack-2.
>
> I don't understand yet what's exactly going wrong (winetricks complains
about some empty output, but if I execute said command manually I get the
output), but I think the recent change should be reverted.
>
> Greets anyway!
> jre
>
>
>
> Winetricks fails with 8.0~repack-4:
>
> jens@thing:~$ wine --version
> wine-8.0 (Debian 8.0~repack-4)
> jens@thing:~$ winetricks
> Executing mkdir -p /home/jens
> --
> warning: You are using a 64-bit WINEPREFIX. Note that many verbs only
install 32-bit versions of packages. If you encounter problems, please
retest in a clean 32-bit WINEPREFIX before reporting a bug.
> --
> --
> WINEPREFIX INFO:
> Drive C: total 28
> drwxr-xr-x 7 jens jens 4096 Feb 13 21:28 .
> drwxr-xr-x 4 jens jens 4096 Feb 19 19:50 ..
> drwxr-xr-x 3 jens jens 4096 Feb 13 21:28 ProgramData
> drwxr-xr-x 6 jens jens 4096 Feb 13 21:28 Program Files
> drwxr-xr-x 6 jens jens 4096 Feb 19 19:28 Program Files (x86)
> drwxr-xr-x 4 jens jens 4096 Feb 13 21:28 users
> drwxr-xr-x 21 jens jens 4096 Feb 19 19:28 windows
>
> Registry info:
> /home/jens/.wine/system.reg:#arch=win64
> /home/jens/.wine/user.reg:#arch=win64
> /home/jens/.wine/userdef.reg:#arch=win64
> --
> --
> warning: wine cmd.exe /c echo '%AppData%' returned empty string, error
message ""
> --
> jens@thing:~$ echo $?
> 1
> jens@thing:~$ wine cmd.exe /c echo '%AppData%'
> 0098:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling
back to RandR 1.0. Please consider using the Nouveau driver instead.
> 0034:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling
back to RandR 1.0. Please consider using the Nouveau driver instead.
> C:\users\jens\AppData\Roaming
>
>
Isn't this a bug in winetricks? When Wine is compiled the new way
(--enable-archs=i386,x86_64), there isn't, as far as I know, a wine64 file.
From
https://github.com/Winetricks/winetricks/blob/master/src/winetricks#L3113
---
# Wrapper around winetricks_early_wine()
# Same idea, but use $WINE_ARCH, i.e., always use wine64 for 64-bit
prefixes
# Currently only used by w_expand_env()
winetricks_early_wine_arch()
{
WINE="${WINE_ARCH}" winetricks_early_wine "$@"
}
---
Bug#899623: *prod* Please fix omniorb-dfsg bug #899623?
Hello, On Sat 28 Mar 2020 at 17:28 +0100, Ivo De Decker wrote: > On Sun, Mar 10, 2019 at 01:59:50PM +, Steve McIntyre wrote: >> Hi guys, >> >> I don't know if you've even seen this RC bug. Could you please update >> the maintainer address to point to something that works? > > Any news on this? Are you still interested in maintaining omniorb-dfsg? > > The last maintainer upload was in 2015. Maybe this package should be orphaned > instead? Yes, this package should really be orphaned and possibly even removed now if there are RC bugs and no dependencies for it. I've never been a DD myself only maintained this for a few years together with Thomas, but AFAIK both me or Thomas have stopped maintaining this for years now. IIRC I attempted to orphan this at some point, but it may never have had the upload and svn seems gone by now too... Apologies for not getting the state of the package correctly and the extra work it causes you. Cheers, Floris
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Andreas Beckmann schreef op 2018-06-25 17:38: On 2018-06-24 11:49, floris wrote: What about the following /etc/nvidia/current/nvidia-drm-outputclass.conf --- Section "Files" ModulePath "/usr/lib/xorg/modules/linux" ModulePath "/usr/lib/xorg/modules" EndSection Section "OutputClass" Identifier "nvidia" MatchDriver "nvidia-drm" Driver "nvidia" EndSection --- That seems to work for stable ... what about sid? Andreas Hmmm, this should work, but the NVidia glx module will always be loaded for all screens by the xserver. This will break a multiseat system with multiple gpu vendors and maybe other glvnd dispatch goodness. Is the following situation a possibility? We can consider such fancy setup for 396.xx and newer, since that will change a lot anyway. For 390.xx I want to have a version in sid that can be uploaded with minimal changes to stretch once the next CVE arrives ... I understand you ideally want one nvidia package for all Debian versions. Stable -> nvidia-driver (up to version 390.xx in backports), compatible with all versions of the xserver This version is shipped with a separate Files section in nvidia-drm-outputclass.conf If xserver 1.20 is in backports, this version can be upgraded to match the new Testing/Sid version Testing and Sid -> nvidia-legacy-390xx-driver, xserver > 1.20 -> nvidia-driver (version > 396.xx), xserver > 1.20 These versions will have the ModulePath option in the OutputClass section. (and we can drop the glx-alternative system) Nope, we have to keep glx-alternatives around as long as 340xx is still in the game. Sorry, I forgot 340xx doesn't support glvnd --- Floris
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
What about the following /etc/nvidia/current/nvidia-drm-outputclass.conf --- Section "Files" ModulePath "/usr/lib/xorg/modules/linux" ModulePath "/usr/lib/xorg/modules" EndSection Section "OutputClass" Identifier "nvidia" MatchDriver"nvidia-drm" Driver "nvidia" EndSection --- That seems to work for stable ... what about sid? Andreas Hmmm, this should work, but the NVidia glx module will always be loaded for all screens by the xserver. This will break a multiseat system with multiple gpu vendors and maybe other glvnd dispatch goodness. Is the following situation a possibility? Stable -> nvidia-driver (up to version 390.xx in backports), compatible with all versions of the xserver This version is shipped with a separate Files section in nvidia-drm-outputclass.conf If xserver 1.20 is in backports, this version can be upgraded to match the new Testing/Sid version Testing and Sid -> nvidia-legacy-390xx-driver, xserver > 1.20 -> nvidia-driver (version > 396.xx), xserver > 1.20 These versions will have the ModulePath option in the OutputClass section. (and we can drop the glx-alternative system) --- Floris
Bug#751082: Siduction
I made a temporary workaround for the problem I mentioned above in this comment: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755020#15 Or use the long-lived branch release (340.24 version) from Siduction floris -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624740: python-omniorb: FTBFS without python2.5
Hi On 1 May 2011 06:37, Scott Kitterman deb...@kitterman.com wrote: Package: python-omniorb Version: 3.5-1 Severity: serious Justification: fails to build from source This has been fixed in r267 of svn.debian.org/svn/pkg-corba/trunk/python-omniorb, so someone needs to upload this now. Usually Thomas Girard does this but I don't know how much time he has (we don't tend to be the fastest team ;-)) so if this is urgent for the transition then maybe someone else could upload this after checking with him? Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571417: omniorb4: superseded by omniorb-dfsg, should be removed?
On Thu, Feb 25, 2010 at 02:11:35PM +0100, Lucas Nussbaum wrote: Shouldn't this package be removed from Debian? Looks like it is superseded by omniorb-dfsg. omniorb-dfsg provides replacement packages for all of the binary packages in omniorb4. It is my understanding from [0] that this makes omniorb4 an orphan and therefore an explicit request is not required. But not having much experience with this I might be wrong, so let me know if I should file an explicit removal request anyway. Regards Floris [0] http://www.debian.org/doc/developers-reference/pkgs.html#removing-pkgs -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550629: python-pyorbit-omg and python-omniorb-omg: error when trying to install together
On Sun, Oct 11, 2009 at 06:25:24PM +0200, Ralf Treinen wrote: This is a serious bug as it makes installation fail. Possible solutions are to have the two packages conflict, to rename the common file in one of the two packages, or to remove the file from one package and have this package depend on the other package. File diversions or a Replace relation are another possibility. Looking at the contents of both packages I think they should conflict. I will add this for the next version of python-omniorb-omg in our svn repo, with a note in the package description explaining this. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477438: roundup: Security update 1.2.1-5+etch1 breaks page rendering
Package: roundup Version: 1.2.1-5+etch1 Severity: grave Tags: patch Justification: renders package unusable Hi The recent security update into etch, 1.2.1-5+etch1 breaks the page rendering (templating) of roundup making all the trackers it runs useless. For the benefit of search engines, here the last part of the traceback: [...] File string, line 2, in f File /usr/lib/python2.4/site-packages/roundup/cgi/templating.py, line 1200, in __str__ return self.plain() File /usr/lib/python2.4/site-packages/roundup/cgi/templating.py, line 1760, in plain if escape: NameError: global name 'escape' is not defined Comparing the code of templating.py with the previous version makes the fix obvious luckily. In templating.py on line 2698 change: def plain(self): back into: def plain(self, escape=0): Note that I didn't cross-check the CVE (it mentions escaping user input in #472643) so maybe defaulting to the old '0' is not correct and it should be '1' to fix the CVE. I don't know that much about it, all I know is that I want a working system (and since it's internal I trust my users...) Regards Floris -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages roundup depends on: ii python2.4.4-2An interactive high-level object-o ii python-central0.5.12 register and build utility for Pyt roundup recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
