Package description for fglrx-driver version 1:15.12-2~bpo8+3 (current
jessie-backports) says: "Building the kernel module has been tested up to Linux
4.4"
Looks like we just did the testing - I confirm your results.
On Mon, 05 Dec 2016 20:38:46 +0100
Tuxicoman wrote:
> I got the same issue with an Intel NUC 2820
>
> dpkg was stuck at 12% during installation.
> I updated the bios (v52 to v56) and this seemed to solve the issue.
Release notes for Intel NUC 2820 BIOS:
https://downloadmirror.intel.com/26318/en
Package: yowsup-cli
Version: 2.4.102-1~bpo8+1
Severity: important
Package from jessie-backports
https://github.com/tgalal/yowsup/search?utf8=%E2%9C%93&q=old_version does
not return any file containing the string "old_version" so I'm guessing
that this issue might be caused by a library not being
Upstream offers .deb packages:
http://dbeaver.jkiss.org/files/dbeaver-ce_latest_i386.deb [1]
http://dbeaver.jkiss.org/files/dbeaver-ce_latest_amd64.deb [2]
According to
https://github.com/serge-rider/dbeaver/blob/master/plugins/org.jkiss.dbeaver.core/docs/help/html/techdoc.html,
[3] those
I encountered this perfectly reproducible exact 12% total freeze bug
using a Jessie installer image dating back a few months on an Intel
J1900 host with integrated Realtek network hardware - I'm afraid I don't
know which Jessie sub-version.
However, on the exact same hardware (including the US
Package: libhtml-html5-entities-perl
Version: 0.004-1
Severity: grave
Tags: patch
Justification: renders package unusable
On Debian Jessie,
$ perl -MHTML::Entities -ne 'print encode_entities($_)' testfile
Can't locate HTML/Entities.pm: ./HTML/Entities.pm: Permission denied.
BEGIN failed--compil
Package: libhtml-html5-entities-perl
Version: 0.004-1
Severity: important
Tags: patch
On Debian Jessie,
$ perl -MHTML::Entities -ne 'print encode_entities($_)' testfile
Undefined subroutine &main::encode_entities called at -e li
Package: installation-reports
Severity: normal
Tags: d-i
Dear Maintainer, the Debian Installer from
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
remains stuck and unresponsive right after committing the partitioning and
formatting o
So, dear maintainer - did you have a chance to package a version that
includes https://github.com/paperbagcorner/Clementine/commit/4c23072bef9
? This patch has been merged in the main branch as
https://github.com/clementine-player/Clementine/commit/4c23072bef94314e3833f807e25d77114ced2759
Stra
Problem fixed - here is the patch, tested on the aforementioned
system... Just a missing #ifdef that caused the failure on systems with
no hardware IOMMU:
--- kcl_iommu.c.orig2014-01-06 23:40:00.09033 +0100
+++ kcl_iommu.c2014-01-06 23:40:52.013271589 +0100
@@ -187,11 +187,13 @@
*/
On Sun, Jan 5, 2014 at 7:33 AM, Ronny Standtke wrote:
> Would you mind trying the linux 3.12 kernel? That is in jessie now and at
> least works for me.
According to AMD, there is a regression in the AMD Catalyst driver that should
prevent that combination:
- 13.11 Beta V9.4 - Linux kernel 2.6 o
Package: spring
Version: 89.0+dfsg1-1
Severity: minor
In the spring package (89.0+dfsg1-1 but also 88.0+dfsg1-1.1 and
0.81.2.1+dfsg1-6) the rts folder contains a file named spring.exe.manifest
This file is obviously related to the Microsoft Windows build. While harmless,
it should be removed fro
Package: dnsmasq
Version: 2.55-2
Severity: wishlist
Tags: patch
When it receives a SIGUSR1, dnsmasq writes statistics to the system log.
It writes the cache size, the number of names which have had to removed
from the cache before they expired in order to make room for new names
and the total num
Using Arpwatch version 2.1a13-2.1 on a dual NIC host that performs routing and
a few services for a three stations LAN, I have also encountered surprisingly
high CPU usage - arpwatch was competing with other running processes to hog the
whole single core CPU. Restarting arpwatch solved the problem.
Bug confirmed with the same version of flickrfs.
flickrfs performs correct authentication and then logs a line for each
piece of metadata being read from flickr - so far so good.
But any access (I tried 'cd' and 'ls') on the mounted directory returns
nothing. Here is an extract from the 'lsof' ou
15 matches
Mail list logo
