On Sat, 22 Mar 2025 07:32:58 -0400 =?UTF-8?Q?Jeremy_B=C3=ADcha?=
wrote:
Control: severity -1 serious
Control: affects -1 src:fuse3
On Sat, Mar 22, 2025 at 7:15 AM Jens Yllman wrote:
> I also wonder why we who have this problem have version 1.57.2-1+b1 when
> the official sites like P
d on it, and it's not yet apparent
>> to me what happened with this one.
>
> I researched bit the lists, and there was the inclusion request on the
> stable list itself. Looking into the io-uring list I found
> https://lore.kernel.org/io-uring/CADZouDRFJ9jtXHqkX-PTKeT=gxswdmc42zesakr34psug9t...@mail.gmail.com/
> which I think was the trigger to later on include in fact the commit
> in 6.1.120.
Yep indeed, was just looking for the backstory and that is why it got
backported. Just missed the fact that it should've been an
io_cqring_wake() rather than __io_cqring_wake()...
--
Jens Axboe
; As a start I set the above issue as a forward, to have the issues
>> linked (and we later on can update it to the linux upstream report).
>
> I suspect this might be introduced by one of the io_uring related
> changes between 6.1.119 and 6.1.123.
>
> But we need to be abl
Jens Thiele writes:
> Hi,
>
> I uploaded a version fixing bug #1057426 to mentors.debian.net and I am
> now looking for a sponsor.
>
> The URL of the package is:
>
> https://mentors.debian.net/package/mit-scheme/
>
> The respective dsc file can
-scheme_12.1-3.1.dsc
Greetins
Jens T.
Jens Thiele writes:
> maybe the expected directory was renamed from mit-scheme-ffi to
> mit-scheme-ffi_html?
looks like a change in texi2any:
https://lwn.net/Articles/914120/
"
HTML output:
use manual_name_html as output directory for split HTML instead of
manual_name or manua
Jens Thiele writes:
> Jens Thiele writes:
>
>> maybe the expected directory was renamed from mit-scheme-ffi to
>> mit-scheme-ffi_html?
>
> looks like a change in texi2any:
> https://lwn.net/Articles/914120/
> "
> HTML output:
> use manual_name_html as o
rectory was renamed from mit-scheme-ffi to
mit-scheme-ffi_html?
> # I tried to subscribe to debian-sch...@lists.debian.org, as Jens
> # suggested the other day, but no success. Again, I'm trying now by
> # sending debian-scheme-requ...@lists.debian.org.
looks like this worked
jens
When I do this change virtualbox-dkms is compiles fine. But now the
kernel from 6.4.0-3 will not boot. It gets stuck early in the boot process.
So I have to boot into the older, 6.4.0-2 that still is on my system.
Jens
=console and running grub-install and update-grub
got the system up and running again.
Jens
but refuses all dns queries
with the Extended DNS Error Code 14 "Not Ready".
This error is reproducible on new installation.
Setting severity to grave because it affects clean installs.
Regards,
Jens
Steps to reproduce to problem:
1. Create a new instance from the generic book
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
ong (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
in
the first place. Not finding what to boot.
Jens
Jonas Smedegaard writes:
> Quoting Jens Thiele (2023-01-08 12:03:22)
>> Jonas Smedegaard writes:
>>
>> > Unfortunately both my TERES I laptops are dead (voltage regulator
>> > circuit let out their blue smoke), so I can no longer test U-boot for
>> >
Jonas Smedegaard writes:
> Unfortunately both my TERES I laptops are dead (voltage regulator
> circuit let out their blue smoke), so I can no longer test U-boot for
> that platform :-(
a little bit off-topic but:
Is this a known hardware bug? is olimex aware of the problem?
I also have a broken
upstream fixed it
fix will be in 0.9.13
Bastian Germann writes:
> Source: gauche
> Severity: serious
> Version: 0.9.10-3
>
> debian/ext/srfi/srfi-19.scm has a license that reads "However, this document
> itself may not be modified in any way"
> and is documented in d/copyright for lib/srfi-11.scm, which does not
> have that license (a
Would you like me to provide additional info or reformat my patch?
Turns out bugtracker messes up whitespace in text/patch attachments. :(
Re-attaching same patch, but gziped, hoping it's left intact now.
python3fix.patch.gz
Description: application/gzip
s the game due to 3 exceptions. (magic.py)
* Playing as Pyralis and using Spin-slash ([C][S]) hangs gameplay, you have
to abort the current level to be able to move again. (play_level.py)
Bug-Debian: https://bugs.debian.org/1001823
Signed-off-by: Jens Rottmann
--- ardentryst/controls.py
+++ pytho
* Playing as Nyx and casting Ice ([D][S]) or Implosion ([D][W]) instantly
crashes the game with an exception. (magic.py)
* Playing as Pyralis and using Spin-slash ([C][S]) hangs gameplay, you have
to abort the current level to be able to move again. (play_level.py)
Signed-off-by: Jens Rottmann
slave {
pcm {
type a52
bitrate 448
channels 6
card $CARD
}
rate 48000
}
}
== End a52.conf
Therefore I assume the shipped config file with debian has an error somewhere.
Please fix this.
Best reagards
Jens
-- System Information:
Debian Release: 11.1
APT prefers s
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,
Fabian Brosda fixed gauche-c-wrapper for Arch Linux:
https://aur.archlinux.org/packages/gauche-c-wrapper/
The new patches are 11 to 14:
https://aur.archlinux.org/cgit/aur.git/tree/11_fix_jp_encoding.patch?h=gauche-c-wrapper
https://aur.archlinux.org/cgit/aur.git/tree/12_float128.patch?h=gauch
Hi,
This is needed in stable. That is where we need to run dnscrypt. Is
there any plans to update to stable?
Jens Yllman
were the case, we'd have seen something from the OOM-killer
in the syslog. I just double checked to make sure.
On 23.03.20 20:58, Tormod Volden wrote:
> Jens, can you please also attach an Xorg log from the crash? If I
> understand the original report right, the X session continued
&g
So, I tried another self compiled version, this time without any of the
Debian patches to see if the crashes happen with a pure upstream
version: They do (see attached log), so I'll inform upstream of the
problem as well.
> When using
> xscreensaver -nosplash -log /tmp/x.log -verbose &
> I di
Hi,
Just want to add that I also have problem do get nvidia-kernel-dkms
435.21 to compile on my debian unstable.
Linux jpyc031 5.4.0-3-amd64 #1 SMP Debian 5.4.13-1 (2020-01-19) x86_64
GNU/Linux
/Jens
his is reproduceable on all (7) of our workstations. Same hardware, same
software.
Regards
Jens
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
K
p()!r})")
This will give bad error messages but allow things to work.
/jp
--
jens persson
Mäster Olofsväg 24
S-224 66 LUND;SWEDEN
Package: chromium-driver
Version: 70.0.3538.110-1~deb9u1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
when using my page test tool, which is using python-selenium, I could no longer
start the browser.
There was an error message thrown by the python selenium binding:
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
probably non-free file with the same code in it.
>
> It seems we need to keep looking, and in the meantime assume we have no
> free license in this file.
FWIW, fio.c includes the following mention:
* The license below covers all files distributed with fio unless otherwise
* noted in the file itself.
followed by the GPL v2 license. I'll go through and add SPDX headers to
everything to avoid wasting anymore time on this nonsense.
--
Jens Axboe
On 2/11/19 3:50 AM, Martin Steigerwald wrote:
> Adding in ax...@kernel.dk, as I am not sure whether the oracle.com address
> from Jens is actually valid / up to date.
>
> Domenico Andreoli - 11.02.19, 08:22:
>> On Mon, Feb 11, 2019 at 12:08:32AM +0100, Kristian Fiskerstrand
I upgraded two machines. Did not see any problem during the upgrade. But
now both of the machines have problem booting. One I can get started by
starting in recovery mode. The other boots anyway. But that machine I
never boot into any GUI.
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.
Package: ltrace
Version: 0.7.3-6+b1
Severity: serious
Justification: unkown
Dear Maintainer,
* What led up to the situation?
Trying to debug a memory leak in an program on a BeagleBone Black
board.
* What exactly did you do (or not do) that was effective (or
ineffective)?
another idea would be to allow to skip macros via some keyword :skip-macro
example patch:
--- gauche-c-wrapper-0.6.1/lib/c-wrapper/c-parser.scm 2009-08-08
16:44:52.0 +0200
+++ gauche-c-wrapper-0.6.1.new/lib/c-wrapper/c-parser.scm 2018-02-09
16:56:03.390344967 +0100
@@ -1099,7 +10
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
Adrian Bunk writes:
> Testing c-wrapper ...
> :444:13: error: invalid "#pragma GCC warning" directive
[...]
> ././ffitest.h:828: GCC exitted abnormally (at token: *eoi*)
> ././ffitest.h:828: #f
> ././ffitest.h:828: process 44299 exitted abnormally wit
Yes, the change is probably in libclang1-3.9. But to me it only looks
like libclang1-3.9 got stricter on reading JSON. In the error message
you can see the error in the JSON that is sent to libclang1-3.9 from
ycmd. So, I think it is ycmd that is wrong. But earlier versions of
libclang1-3.9 was
Package: ycmd
Version: 0+20161219+git486b809-2.1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
After libclang1-3.9 was upgraded to 1:3.9.1-16 ycmd cou
Stéphane Lavergne writes:
> Upgrading to the "+deb8u1" version of xserver-xorg-core and
> xserver-common and restarting X loses keyboard and mouse entirely,
> with nothing obvious showing up in Xorg.0.log. Downgrading to the
> version without this suffix fixes the issue, so this is some kind of
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
curity.io/advisories/cli_arbitrary-file-write> and blames all
modules referencing it even in version 1.0.0, e.g
https://david-dm.org/deadratfink/jy-transform/development
<https://david-dm.org/deadratfink/jy-transform/development>.
Thx and best,
Jens
Jens Thiele writes:
> forwarded upstream:
> https://github.com/shirok/Gauche-gtk2/issues/5
upstream commited a fix:
commit 6fca535f7bb950f81db066bd1afdca9d55e9b460 (refs/remotes/origin/master,
refs/remotes/origin/HEAD)
Author: Shiro Kawai
Date: Tue Sep 27 01:43:54 2016 -1000
Fix
forwarded upstream:
https://github.com/shirok/Gauche-gtk2/issues/5
upstream git [1] has the same problem
[1] https://github.com/shirok/Gauche-gtk2.git
ually fixing those i still get an error:
gcc: error: pango-enum-types.o: No such file or directory
greetings,
jens
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
* Axel Beckert schrieb am 2016-01-22 um 13:23 Uhr:
> The connection you've chosen, is that a wireless or a wired one? I
> suspect a wireless one.
Your suspicion is right. It's wireless.
--
Jens Kubieziel http://www.kubieziel.de
My advice (whic
or
message (list index out of range) was the same in both cases.
--
Jens Kubieziel http://www.kubieziel.de
Lache nie über die Dummheit der anderen. Sie kann deine Chance sein.
Winston Churchill
maybe at least play a bit safer:
Index: gauche-c-wrapper-0.6.1/src/c-parser.c
===
--- gauche-c-wrapper-0.6.1.orig/src/c-parser.c
+++ gauche-c-wrapper-0.6.1/src/c-parser.c
@@ -1668,6 +1668,8 @@ ScmObj Scm_ParseMacroCode(ScmObj in, Scm
Matthias Klose writes:
> you could use -P, or fix the parsing.
a first minimal hackish patch (not using -P)
likely this is not really good enough yet (but yes it compiles and
passes the tests)
Maybe a version using -P just using the last n lines of the cpp output
would be better?
Index: gauche
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
reassign 803499 gnome-settings-daemon 3.14.2-3
thanks
2015-10-30 20:43 GMT+01:00 Michael Biebl :
> Am 30.10.2015 um 19:23 schrieb Jens Seidel:
>> 2015-10-30 18:59 GMT+01:00 Michael Biebl :
>>> So rsyslog logs your (user) messages.
>>> I fail to see how this is a bug in
2015-10-30 18:59 GMT+01:00 Michael Biebl :
> Am 30.10.2015 um 18:56 schrieb Jens Seidel:
>> Package: rsyslog
>> Version: 8.4.2-1+deb8u1
>> Severity: grave
>
> So rsyslog logs your (user) messages.
> I fail to see how this is a bug in rsyslog, even more a grave one?
Package: rsyslog
Version: 8.4.2-1+deb8u1
Severity: grave
Hi,
some time ago I was affected by a really nasty bug. I tried to start a new
X session to login as a new user but did not remember how to do so (from
an XFCE session). So I ended up calling X as root and this was a big problem:
This star
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
can't reproduce using 38.2.0esr-1~deb7u1
Severity: important
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: xserver-xorg-input-evdev
Version: 1:2.9.0-2
Severity: serious
Hi,
I upgraded the system from stable to testing and could not get a working
system. A few minutes (2-3) after boot the system seems to be tired and
goes into suspend mode.
Clicking the power button the system wakes up to star
Jens Thiele writes:
> Don't have the time to test this now and will wait for the security
> update. (downgraded to 3.2.63-2+deb7u2 for now now)
For the archive:
After updating to 3.2.65-1+deb7u1 suspend works for me again.
Thanks,
jens
--
To UNSUBSCRIBE, email to debian-b
he author had to use a backup,
which I believe is the reason for the wrong date 2012 on the website. I
know for sure that there was the more recent version date stated on the site,
before this happened.
http://www.floodgap.com/software/ttytter/dist2/
Jens
--
To UNSUBSCRIBE, email to debian-bug
Dear maintainer,
This bug is also reported in GNOME bugzilla [1]. I could also reproduce
it with i3wm/Jessie and version 3.2 build from source (and also the
3.0.1-4+b1 from the repositories).
Jens
[1]: https://bugzilla.gnome.org/show_bug.cgi?id=738655
--
Jens Erat
[phone]: tel:+49-151
Source: pcre3
Severity: serious
Tags: patch
Justification: fails to build from source
Dear Maintainer,
The package fails to build on hurd because the pthread stack size in
only 2024 kb instead of the 8192 kb that linux has.
Would it be a good idea to use the heap instead of the stack to fix
this
Hi,
gtk-gnutella crashes for me as well.
stderr log and gdb backtrace attached.
Both the amd64 and i386 versions show the same behavior.
--
Mit freundlichen Grüßen
Jens Mühlenhoff
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1.1+b1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU
Worked perfectly. Can see I need to update my kernel knowledge and get to
know systemd.
Thanks a lot.
6d -> ../../dm-2
Regards
Jens
Package: systemd
Severity: critical
Justification: breaks the whole system
The bug is properly related to #754059, but unlike Filippo, I was stupid enough
to update to systemd, which resulted in the removal of sysvinit-core and
resulted in an unbotable system.
Using emergency mode (which is als
Andrew Shadura writes:
> retitle 753402 gosh segfaults on s390x causing libguess to FTBFS
first looked at the wrong build log
the relevant one seems to be:
https://buildd.debian.org/status/fetch.php?pkg=libguess&arch=s390x&ver=1.2%7Egit20131128.cc43cefc-2&stamp=1405322861
--
To UNSUBSCRIBE,
Jens Thiele writes:
> Andrew Shadura writes:
>
>> retitle 753402 gosh segfaults on s390x causing libguess to FTBFS
>
> first looked at the wrong build log
>
> the relevant one seems to be:
> https://buildd.debian.org/status/fetch.php?pkg=libguess&arch=s390x&a
1 - 100 of 237 matches
Mail list logo
