Hi Paul
On 09.03.23 15:50, Paul Gevers wrote:
Hi,
On Sun, 19 Feb 2023 18:17:39 -0600 Austin English
wrote:
Yes, it's arguably a bug in winetricks. Film what I gather upstream,
it's also not yet fully supported.
On Sat, 25 Feb 2023 17:10:47 +0100 Jens Reyer
wrote:
ftr: I just
On 20.02.23 01:17, Austin English wrote:
On Sun, Feb 19, 2023, 17:33 Jens Reyer <mailto:jre.wine...@gmail.com>> wrote:
Yes, it's arguably a bug in winetricks. Film what I gather upstream,
it's also not yet fully supported.
I would advise reverting for now. At least u
On 19.02.23 21:45, Floris Renaud wrote:
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 winetrick
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 complain
Hi
On 25.04.21 16:27, Adrian Bunk wrote:
> bullseye users would also benefit more from wine 6.0 in
> bullseye-backports
[not commenting on the whole issue]
I maintained the wine backports in the past, but stepped down
(https://lists.debian.org/debian-wine/2020/09/msg7.html).
But I agree tha
On 12.03.21 11:40, Andreas Beckmann wrote:
> Unpacking libwine-development:amd64 (5.6-1) over (4.2-4+b1) ...
> dpkg: error processing archive
> /tmp/apt-dpkg-install-mfCwgB/93-libwine-development_5.6-1_amd64.deb
> (--unpack):
>trying to overwrite '/usr/lib/wine-development/wineserver', wh
Hi,
libmspack in unstable fixes a bug in cabextract (#914263
cabextract: -F option doesn't work correctly.) which affects winetricks.
But cabextract and libmspack don't migrate because of this bug here.
This issue is already fixed upstream, but afaics not released yet. Do
you know if this will
Package: wine-development
Version: 3.17-1
Severity: serious
Tags: upstream, fixed-upstream
wine-development 3.17-1 ftbfs on arm64:
https://buildd.debian.org/status/fetch.php?pkg=wine-development&arch=arm64&ver=3.17-1&stamp=1539395513&raw=0
It looks like upstream already fixed this in 3.18 with
On 7/6/18 5:11 PM, Graham Inggs wrote:
> Source: unicode-data
> Version: 11.0.0-1
> Severity: serious
> Tags: ftbfs
> Control: affects -1 gucharmap libxmlada utf8proc wine wine-development
>
> Hi Maintainer
>
> The recent upload of unicode-data 11 causes several packages to FTBFS in
> unstable.
control: forwarded -1 https://github.com/Winetricks/winetricks/issues/912
> I won't be able to fix upstream for a few weeks, but I've filled a bug in
> the meantime:
>
> https://github.com/Winetricks/winetricks/issues/912
There have been a few patches upstream, so I guess we'll have a solution
s
Source: wine-development
Version: 3.0~rc3-2
Severity: serious
Forwarded: https://bugs.winehq.org/show_bug.cgi?id=44365
Tags: upstream
gcc -c -o relay.o relay.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_
-D_REENTRANT -fPIC -Wall \
-pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wem
control: tags -1 patch
Hi
On 07/12/2017 09:03 PM, Niko Tyni wrote:
> Package: wine
> Version: 1.8.7-2
>
> This package fails to build on current sid.
>
> From the timing I'm guessing it regressed with unicode-data_10.0.0-1.
> ./tools/make_unicode
> unknown matra Bottom_And_Left at ./tools/m
I'm just catching up, and am not working on Wine yet. So just fyi
recently there was a patchset at WineHQ for Unicode 10:
https://www.winehq.org/pipermail/wine-patches/2017-July/163321.html
https://www.winehq.org/pipermail/wine-patches/2017-July/163322.html
That one got rejected, but I assume i
On 02/02/2017 02:30 PM, Steve McIntyre wrote:
> Dropping the -nostdlib argument to the gcc call inside sonames2elf
> makes a difference - it'll add libc6 to the mix and force the output
> to match the system you're building for. You may then need to filter
> out the libc6 entry afterwards, but that
On 02/01/2017 04:34 PM, Steve McIntyre wrote:
> Hey folks,
>
> On Wed, Feb 01, 2017 at 05:08:50AM +0100, Guillem Jover wrote:
>> On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote:
>>>
>>> Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to
>>> generate a library which do
On 02/01/2017 05:08 AM, Guillem Jover wrote:
> On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote:
>> The new ABI mismatch detector seems to be a bit too strict on armel and
>> armhf.
Thanks to both of you for quickly handling this!
>> This was first seen with wine:
>> https://buildd.debi
control: severity -1 important
Hi Vincent,
this only affects users that actually use Wine (if at all, see below).
Only then the .desktop file gets created (e.g. on running "winecfg" the
first time). Downgrading to important for now.
Funnily I can't reproduce this here. Despite having the problem
On 23.11.2016 18:06, Matthias Klose wrote:
> ta, and the fix will be in the next binutils upload too.
Great, given your recent binutils upload rate I expect that to happen
soon. So I'll probably stay lazy and avoid changing wine-development.
Control: reassign 845171 winbind/2.27.51.20161118-2
Control: affects 845171 wine-development
Control: tags 845171 - help moreinfo
Control: tags 845452 = patch
[ Referencing the other related bug here. ]
Matthias Klose wrote in https://bugs.debian.org/844847#35
> This looks like another regressio
On 21.11.2016 22:07, Michael Gilbert wrote:
> On Sun, Nov 20, 2016 at 9:16 PM, Jens Reyer wrote:
>> wine-development 1.9.22-1 (in stretch) built successfully on all
>> architectures when it was uploaded to unstable, but fails to
>> build in a stretch environment on i386 now
Source: wine-development
Version: 1.9.22-1
Justification: FTBFS on i386, armel and armhf
Severity: serious
Tags: help
wine-development 1.9.22-1 (in stretch) built successfully on all
architectures when it was uploaded to unstable, but fails to
build in a stretch environment on i386 now (amd64 is
Package: wine-development
Version: 1.9.16-1
Severity: serious
Justification: Maintainer decision, prevent too early testing migration
wine-development 1.9.16-1 breaks wine < 1.8.3-3 to avoid file name
conflicts resulting from the Debian alternatives system, which was
introduced in these versions.
them to 814...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Jens Reyer (supplier of updated khronos-api package)
(This message was generated automatically at their request; if you
believe that there is a problem with it
control: tags -1 + pending
On 30.06.2016 12:04, Santiago Vila wrote:
> Package: src:wine-development
> Version: 1.9.12-1
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> Severity: serious
>
> Dear maintainer:
>
> This package currently fails to build in stretch:
This will
intainer upload. "DebConf upload."
+ * Fix FTBFS. Add build-depends python-debian and python-dateutil
+(closes: #814914).
+
+ -- Jens Reyer Fri, 01 Jul 2016 16:46:18 +0200
+
khronos-api (0~svn29735-1) unstable; urgency=medium
* Fix a lintian warning.
diff -Nru khronos-api-
control: tags -1 + pending
Fix committed, based on the previously mentioned 2 commits. Some
files/contents were moved between Wine 1.8 and 1.9.13 (which carries the
Unicode 9.0 changes), which made spotting changes to autogenerated files
a bit harder.
In the resulting patch there are still some da
Package: wine
Version: 1.8.3-1
Severity: serious
Justification: FTBFS/BD-Uninstallable
wine build-depends on missing unicode-data (< 9.0-1), but that isn't
available anymore.
I started working on a patch to backport the Unicode 9 changes to Wine
1.8, but haven't it ready yet. Basically it should
Package: khronos-api
Version: 0~svn29735-1
Severity: serious
Tags: patch
Hi,
khronos-api FTBFS in a clean chroot. It requires python-debian and
python-dateutil.
Otherwise the build fails due to:
ImportError: No module named dateutil.parser
or:
ImportError: No module named debian.changelog
G
control: tags -1 + pending
On 02/10/2016 06:12 PM, Jens Reyer wrote:
> Imo the dependency on libwine-gecko-xxx should stay a recommends, a
> suggests imo doesn't meet the importance of Gecko in Wine.
>
> So I'll commit a change to remove (comment) that from wine
On 02/09/2016 08:14 PM, Rhonda D'Vine wrote:
> Unfortunately unsatisfyable recommends are a policy violation though,
> and even while I understand the sentiments of not wanting to have to
> reupload wine to add it, I don't see a way around this.
[...]
>> Rhonda, do you see any flexibility in inter
On 02/09/2016 08:10 PM, Austin English wrote:
> On Feb 9, 2016 11:08 PM, "Rhonda D'Vine" wrote:
>>
>>Hi,
>>
>> * Austin English [2016-02-09 17:45:02 CET]:
>>> On Feb 9, 2016 8:39 PM, austinengl...@gmail.com wrote:
On Feb 9, 2016 8:25 PM, "Rhonda D'Vine" wrote:
>>> Hi!
>>>
Hi
In Wine we depend on libwine-gecko-xxx before it's added to the archive,
knowing/hoping/assuming that it will be added to the archive, which has
always been true for Debian stable releases, but not for all
intermittent Gecko versions that were needed in between (maintainer is
in both cases the
control: tags -1 + pending
Hi,
I just committed a patch that should fix that:
commit e3a8b8a90d62493f0097e4ff0d560743ca312c03
Author: Jens Reyer
Date: Fri Feb 5 05:47:38 2016 +0100
Move Wine binaries to common directory.
This fixes the WoW64 setup for wine-development (closes
On 11/05/2015 11:26 AM, Klaus Ethgen wrote:
>> I see that you only have wine64, but not wine32 installed. Is this a
>> result of the current issue, or did you really use Wine without the
>> 32-bit packages installed previously? I was under the impression that a
>> 64-bit only setup has no *real* us
control: forcemerge 803778 -1
Hi,
thanks for reporting this. I already filed bug #803778 and committed a
fix. As a workaround you may build wine-development locally for the i386
architecture.
I see that you only have wine64, but not wine32 installed. Is this a
result of the current issue, or did
Package: wine-development
Version: 1.7.54-1
Severity: serious
Justification: arch indep FTBFS on 64-bit architectures
Hi
The manpages are now built by upstream together with the binaries [1,
2]. The wine manpage is built together with wine32 (there is no separate
manpage for wine64). So manpages
control: severity -1 normal
Hi
> pytrainer disappeared from repositories (jessie and up)
> Severity: grave
> Justification: renders package unusable
Somewhat ironic, but I guess this bug report prevents pytrainer to
reenter testing due to its RC severity. Therefore I downgrade it to normal.
I ho
37 matches
Mail list logo
