Package: gimp
Version: 2.10.8-2
Severity: grave
Justification: renders package unusable
In the curent state of available packages from stable (buster) the program GIMP
cannot be used. After start it shows following message:
"GEGL operation missing!
GIMP requires the GEGL operation
Package: calendar-google-provider
Version: 1:60.9.0-1~deb10u1
Severity: grave
Justification: renders package unusable
There is missing build of the package for thunderbird/lightning of current
versions 1:65.* and 1:68.* what makes the package unusable with any version of
the given tools higher
Package: libkscreenlocker5
Version: 5.8.6-2
Severity: important
The problem is, after the resume from suspend to disk, the login screen does
not appear.
Workaround how to log-in again is to press Ctrl-Alt-F1, log in to the text
console and kill the process kscreenlocker_greet. Then this process
Package: network-manager-openvpn
Version: 1.2.8-2
Followup-For: Bug #848024
The bug is still there in the version 1.2.8-2, because the g|UI for the editing
of connection properties still generates the invalid option "tls-remote" always
if you want to specify the X509 properties.
The problem is
Package: src:linux
Version: 4.6.4-1~bpo8+1
Severity: important
Problem occurs on the notebook display only, the attached screen display does
no flickering at all with any kernel tried. After the last version of package
the flickering is very massive after the boot of the system and start of
is
currently in the testing phase?
Artur Linhart
smime.p7s
Description: Elektronicky podpis S/MIME
I have one new message to this bug, I think this is the bug either in
the given new kernel - so it would the mean the package
linux-image-3.16.0-0.bpo.4-amd64 (version 3.16.7-ckt9-2~bpo70+1),
which I have used, or in the firewall (Sophos UTM 9.x) which acts
between both hosts or even somwhere
Hello Carsten,
in the attachments you can find the results. But it seems to be
restarted correctly. I have tested it also with the brand new kernel and
the problem still persist. I cannot recognize any ps output differences
between the 3.x kernels (wrong functionality) and 2.x kernels (works
is running.
with best regards, Artur Linhart
Dne 21.4.2015 v 22:30 Geert Stappers napsal(a):
On Tue, Apr 21, 2015 at 09:38:11PM +0200, Artur Linhart wrote:
Package: bacula-director-common
Version: 5.2.6+dfsg-9
Severity: normal
The director is not able under some circumstances communicate
Package: bacula-director-common
Version: 5.2.6+dfsg-9
Severity: normal
The director is not able under some circumstances communicate with Bacula
communication console, after (service) restart it is not able to listen on the
specified configured port even if the service seems to be running.
The
Just the same error like Justin wrote during the regular update of the
new updates on jessie/sid version
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Thanks for reporting this and sorry for the long quiet. Can you
reproduce this using a sid kernel for the dom0? I think the only
packages that should be needed for this test from outside squeeze are
the kernel image itself, linux-base, and initramfs-tools.
Jonathan
Hello, Jonathan,
Package: zabbix-agent
Version: 1:1.8.2-1squeeze2
Severity: important
The problem is, after the package is purged in aptitude,it removes correctly
the /etc/zabbix
folder or the content of this folder, but it seems still there are some files
left.
If after purge the package should be reinstalled
Package: xen-utils-common
Version: 4.0.0-1
Severity: important
The script /etc/xen/scripts/block contains an error in the part which
is checking the sharing of the already created loop devices. This error
leads in the case of somespecific file inode values
to the wrong report of the loop device
Package: linux-2.6
Version: 2.6.32-27
Severity: important
If the kernel is used for paravirtual DomU, then the DomU is normally started
orshutdown. Ifthe xm save and xm restore
is invoked explicitely,then the DomU also restores normally. Only in the case
the DomU is
restored automatically via
Additional info - I figured out, the domain is paused only, so after calling of
xm unpause DomId
the domain continues to respond and to run.
So, maybe it is not a bug, but a feature?
If it is so, then there should be a possibility to start the domain
immediatelly.
One more remark: It does not
...
Unfortunately, I will not have the chance to test the patch directly, I use
vanilla kernel from the package only...
-Original Message-
From: Timo Juhani Lindfors [mailto:timo.lindf...@iki.fi]
Sent: Wednesday, November 17, 2010 2:11 PM
To: Artur Linhart
Cc: 603...@bugs.debian.org
Subject
One more correctlion to my last message - I have figured out, some instances
have had still the kernel from version 2.6.32-21 what
was the reason why they started correctly... So it seems the effect can be seen
on all DomUs with the kernel from package version
2.6.32-27
--
To UNSUBSCRIBE,
-Original Message-
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Monday, September 20, 2010 6:08 PM
To: Artur Linhart - Linux communication
Cc: 'Ian Campbell'; 596...@bugs.debian.org
Subject: Re: Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64:
causes
Hello, Ian,
your theory with the out-of-memory seems to be the step into the
right direction.
It looks like the problems did not really start with the
instalaltion of the new packages, but with the set of the xen kernel
parameter
dom0_mem=1024M
which I made approximatelly at the
Even after the downgrade of kernel and of the corresponding files to the
version 2.6.32-18 and downgrade of mdadm the problem still persists, so it
is not bound specificallz to this package and to this version.
I have identified now (after the downgrades to 2.6.30-18) the following
initial
One more remark - the last tests from the previous post were done on the
synced array, so there was not other heavy load on it at the time of this
last crash. The crash happened also during the
xendomains stop
before the system shutdown. It happened not immediatelly, but first after
sime time
Hello,
If booting on non-xen kernel, then no problems can be seen. But it
is true, exactly the same asction cannot be tested, the xendomains script
can be started only if running under xen and also there had to be some
virtual instances to be suspended...
If I boot with xen and
Package: xen-linux-system-2.6.32-5-xen-amd64
Version: 2.6.32-21
Severity: critical
Justification: breaks the whole system
On the system is installed sw raid, raid1 is used.
There are 3 RAID1 volumes made as partition mirroring of 3 partitions,
1. for the system (is installed there), 2. and 3.
Package: xen-linux-system-2.6.32-5-xen-amd64
Version: 2.6.32-21
Severity: critical
Justification: causes serious data loss
During the shutdown there comes a system hangup somehow related to aacraid.
It first came now after the upgrade of the package to the version specified
below.
It makes it
This bug is a duplicate of the bug 596419, so it can be closed.
-Original Message-
From: Debian BTS [mailto:debb...@busoni.debian.org] On Behalf Of Debian Bug
Tracking System
Sent: Saturday, September 11, 2010 11:06 AM
To: Artur Linhart
Subject: Bug#596422: Acknowledgement (xen-linux
, September 11, 2010 10:15 AM
To: Artur Linhart
Subject: Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64:
causes a system hangup by the shutdown of the system, aacraid (sw raid)
involved in hangup)
Thank you for filing a new Bug report with Debian.
This is an automatically generated reply
Additional info:
Downgrading of the package and kernel image to 2.6.35-18 did not helped,
Running of
/etc/init.d/xendomains stop
Still brought an error, containing also following message:
kernel bug /source_amd_xen/drivers/scsi/aacraid/aachba.c:2825!
(the dots were not there, there
28 matches
Mail list logo
