Bug#857926: Building the fglrx kernel module untested beyond Linux 4.4
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.
Bug#794410: debian-installer: Installer hangs during 'select and install software'
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/eng/FY_0055_ReleaseNotes.pdf Changes in version 55: - Security Enhancements - Changed the time it takes to enter the power button recovery menu to 4 seconds - Improved the BIOS update function by disabling the keyboard and power button during the flash/recovery process - Added Windows firmware update function - Added NVRAM preserved variables: DmiData, UUID, OA3Data - Fixed an issue that when the User Access Level= limited, the User could still access the following restricted Setup options: Minimum/Maximum Duty Cycle (%); Primary/secondary Temperature Sensor - Updated Visual BIOS to 2.2.20 from 2.2.19 - Hotfix to remove download driver and automatic BIOS update feature Changes in version 53: - Changed the time it takes to enter the power button menu to 3 seconds after G3 sleep state - Changed the time it takes to enter the power button menu to 4 seconds after S4/S5 sleep state I fail to see anything that might be related to our issue... But then I don't understand the issue either.
Bug#840005: yowsup-cli: Whatsapp registration fails with "reason":"old_version"
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 up to date with
Whatsapp current protocol.
$ yowsup-cli registration -c .yowsup -r sms -C 43 -p 33609537924
yowsup-cli v2.0.15
yowsup v2.4.102
Copyright (c) 2012-2016 Tarek Galal
http://www.openwhatsapp.org
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://openwhatsapp.org/yowsup/donate
INFO:yowsup.common.http.warequest:{"status":"fail","reason":"old_version"}
status: fail
reason: old_version
Bug#680987:
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 .deb packages were generated using https://github.com/mscurtescu/ant-deb-task [4] I do not know whether they are in any way correct to the Debian standard of whether they might even help a Debian packager, but meanwhile they are better than nothing. Links: -- [1] http://dbeaver.jkiss.org/files/dbeaver-ce_latest_i386.deb [2] http://dbeaver.jkiss.org/files/dbeaver-ce_latest_amd64.deb [3] https://github.com/serge-rider/dbeaver/blob/master/plugins/org.jkiss.dbeaver.core/docs/help/html/techdoc.html, [4] https://github.com/mscurtescu/ant-deb-task
Bug#794410: (no subject)
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 USB flash dongle), the Debian installer completed successfully using the debian-8.2.0-amd64-netinst.iso image. Users who encountered this bug with a Jessie DI version older than the 8.2.0 that was published in September 2015 might want to try again with that one.
Bug#789326: libhtml-html5-entities-perl: Can't locate HTML/Entities.pm
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--compilation aborted. # ln -s /usr/share/perl5/HTML/HTML5/Entities.pm /usr/share/perl5/HTML/Entities.pm $ perl -MHTML::Entities -ne 'print encode_entities($_)' testfile aeiuoé So, we have /usr/share/perl5/HTML/HTML5/Entities.pm but invoking the module yields a complain that it should be at /usr/share/perl5/HTML/Entities.pm Since http://search.cpan.org/~tobyink/HTML-HTML5-Entities-0.004/lib/HTML/HTML5/Entities.pm says "HTML::HTML5::Entities - drop-in replacement for HTML::Entities" I believe that Entities.pm should be located at /usr/share/perl5/HTML/Entities.pm since it fixes the incorrect behaviour. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789324: libhtml-html5-entities-perl: Missing depends on libhtml-parser-perl
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 line 1, <> line 1. # apt-get install libhtml-parser-perl $ perl -MHTML::Entities -ne 'print encode_entities($_)' testfile aeiuoé So the package libhtml-html5-entities-perl should depend on package libhtml-parser-perl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750500: installation-reports: Jessie amd64 netinst encrypted LVM: stuck at /target/boot/efi vfat partition creation
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 of an encrypted LVM full-disk setup. Switching between consoles and using consoles other than the DI remains possible, but the DI won't exit the screen announcing the creation of a vfat partition at /target/boot/efi. No suspect syslog or dmesg entry is evident. The Wheezy Debian Installer is perfectly functional using the same options on the same host. As I am currently waiting for the Wheezy DI to wipe the aforementioned host's encrypted partition, I am unable to gather more details from it, but I will upon request. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722471: (no subject)
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 Strangely, it is not included in the 1.2.3 release (https://github.com/clementine-player/Clementine/releases/tag/1.2.3) - for example see this two histories of /src/core/database.cpp : - Head : https://github.com/clementine-player/Clementine/commits/4c23072bef94314e3833f807e25d77114ced2759/src/core/database.cpp - includes 4c23072bef94314e3833f807e25d77114ced2759 - Tag 1.2.3 : https://github.com/clementine-player/Clementine/commits/1.2.3/src/core/database.cpp - no mention of that patch. Does anyone know why 4c23072bef94314e3833f807e25d77114ced2759 has not been picked for 1.2.3 ? Anyway... The 1.2.3 upstream Debian package at https://github.com/clementine-player/Clementine/releases/tag/1.2.3 is therefore not even worth testing. On the other hand, https://github.com/clementine-player/Clementine/commit/56dade25981da1656cbb68447e8518529e229978 claims to "fix slow library search on sqlite 3.8" and it is included in version 1.2.3 - but that is much less important than the aforementioned bug which this thread is about. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729765: (no subject)
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 @@
*/
int ATI_API_CALL KCL_IOMMU_CheckInfo( KCL_PCI_DevHandle pcidev)
{
+#ifdef IOMMUV2_SUPPORT
struct pci_dev* pdev = (struct pci_dev*)pcidev;
if ( pdev->dev.archdata.iommu )
{
return 1;
}
+#endif
return 0;
}
A 'dpkg-reconfigure fglrx-modules-dkms' and a reboot later, I am
enjoying the soothing movement of glxgears.
Most glory goes to Gindek who had fixed this on his own Debian system
last October and posted the patch which I stumbled upon:
http://forums.amd.com/game/messageview.cfm?catid=488&threadid=168661&enterthread=y
Most glory but not all since he apparently did not bring it to the
attention of the Debian maintainer...
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729765: fglrx-modules-dkms: fglrx module does not compile on recent x86 kernels
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 or above (up to 3.12) - 13.12 - Linux kernel 2.6 or above (up to 3.11) Sources: http://support.amd.com/en-us/kb-articles/Pages/Latest-LINUX-Beta-Driver.aspx http://support.amd.com/en-us/kb-articles/Pages/AMDCatalyst13-12LINReleaseNotes.aspx Do you confirm that you have fglrx 13.12-2 working with a 3.12 Kernel ? Anyway, with 3.11-0.bpo.2-686-pae and fglrx 13.12-2, I get a failure to build the module: Unpacking fglrx-modules-dkms (1:13.12-2) over (1:13.12-2) ... Setting up fglrx-modules-dkms (1:13.12-2) ... Loading new fglrx-13.12 DKMS files... Building for 3.11-0.bpo.2-686-pae and 3.12-1-686-pae Building initial module for 3.11-0.bpo.2-686-pae Error! Bad return status for module build on kernel: 3.11-0.bpo.2-686-pae (i686) Consult /var/lib/dkms/fglrx/13.12/build/make.log for more information. root@kitandara:/home/jm# cat /var/lib/dkms/fglrx/13.12/build/make.log DKMS make.log for fglrx-13.12 for kernel 3.11-0.bpo.2-686-pae (i686) Sun Jan 5 23:59:22 CET 2014 make: Entering directory `/usr/src/linux-headers-3.11-0.bpo.2-686-pae' LD /var/lib/dkms/fglrx/13.12/build/built-in.o CC [M] /var/lib/dkms/fglrx/13.12/build/firegl_public.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_acpi.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_agp.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_debug.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_ioctl.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_io.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_pci.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_str.o CC [M] /var/lib/dkms/fglrx/13.12/build/kcl_iommu.o /var/lib/dkms/fglrx/13.12/build/kcl_iommu.c: In function ‘KCL_IOMMU_CheckInfo’: /var/lib/dkms/fglrx/13.12/build/kcl_iommu.c:191:28: error: ‘struct dev_archdata’ has no member named ‘iommu’ make[3]: *** [/var/lib/dkms/fglrx/13.12/build/kcl_iommu.o] Error 1 make[2]: *** [_module_/var/lib/dkms/fglrx/13.12/build] Error 2 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 make: Leaving directory `/usr/src/linux-headers-3.11-0.bpo.2-686-pae' According to http://phoronix.com/forums/showthread.php?85672-AMD-Catalyst-Beats-NVIDIA-To-Linux-3-12-Support&p=368339#post368339 it may be caused by something expecting hardware iommu support while my Intel i7 processor uses a software one that uses DMA remapping (DMAR). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714789: Useless rts/spring.exe.manifest file
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 from the Debian package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654656: /etc/init.d/dnsmasq should support the statistics dump trigger
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 number of names that have been inserted into the cache.
For each upstream server it gives the number of queries sent, and the
number which resulted in an error.
/etc/init.d/dnsmasq should provide a method to trigger that statistics
dump method.
Here is the patch to let /etc/init.d/dnsmasq provide a method to
trigger that statistics dump method:
root@arua:/etc/init.d# diff -pu dnsmasq.dist dnsmasq
--- dnsmasq.dist2012-01-04 23:00:07.931824846 +0100
+++ dnsmasq 2012-01-04 23:25:50.059820719 +0100
@@ -256,8 +256,12 @@ case "$1" in
*) log_success_msg "(unknown)" ; exit 4 ;;
esac
;;
+ stats)
+ echo "Dumping stats to syslog..."
+kill -s USR1 `cat /var/run/dnsmasq/$NAME.pid`
+ ;;
*)
- echo "Usage: /etc/init.d/$NAME
{start|stop|restart|force-reload|status}" >&2
+ echo "Usage: /etc/init.d/$NAME
{start|stop|restart|force-reload|status|stats}" >&2
exit 3
;;
esac
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520393: Confirmed on wired Ethernet too
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. I don't know how long arpwatch had been running wild - probably a few days at least, and I do not know what triggered this behavior either. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515835: flickrfs hangs on any access to the mounted directory
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' output while the
abovementioned commands remain hung :
ls 5242 jim3r DIR 0,18 0 1
/home/jim/tmp/flickr_mount_point
ls11323 jim cwd DIR 0,18 0 1
/home/jim/tmp/flickr_mount_point
ls11323 jim3r DIR 0,18 0 1
/home/jim/tmp/flickr_mount_point
ls11887 jim3r DIR 0,18 0 1
/home/jim/tmp/flickr_mount_point
Killing them does not work, nor does unmounting while the device is busy.
Here are the alst lines of the output of 'strace ls' performed on the
mounted directory :
stat64("flickr_mount_point", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("flickr_mount_point",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
getdents64(3,
The flickr account I am experimenting with contains about eight thousand
pictures in a few hundred sets.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
