Bug#971984: installation-reports: installation report
Package: installation-reports Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: Boot method: usb Image version: debian 10.0 iso Date: Machine: Dell Inspiron 15-3567 Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="10 (buster) - installer build 20190702" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux zues 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5904] (rev 02) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:5916] (rev 02) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Skylake Processor Thermal Subsystem [8086:1903] (rev 02) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: 00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] [8086:9d03] (rev 21) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 [8086:9d14] (rev f1) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.5 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #6 [8086:9d15] (rev f1) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:9d4e] (rev 21) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-LP PMC [8086:9d21] (rev 21) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Device [8086:9d71] (rev 21) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: Kernel driver in use: snd_hda_intel lspci -knn: Kernel modules: snd_hda_intel, snd_soc_skl lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus [8086:9d23] (rev 21) lspci -knn: Subsystem: Dell Device [1028:078b] lspci -knn: 01:00.0 Network controller [0280]: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter [168c:0042] (rev 31) lspci -knn: Subsystem: Dell Device [1028:1810] lspci -knn: Kernel driver in use: ath10k_pci lspci -knn: Kernel modules: ath10k_pci lspci -knn: 02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller [10ec:8136] (rev 07) lspci -knn:
Bug#941576: qemu: Cant use virtio-gpu with some hardware
Source: qemu Severity: important Dear Maintainer, I cannot use libvirt and virtio-gpu together, after search it often appearr with amd gpu. I have tested that a patch from fedora can solve it. https://koji.fedoraproject.org/koji/fileinfo?rpmID=17131016=0001-qemu- seccomp-dont-kill-process-for-resource-contro.patch -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#925562: Acknowledgement (libreadline7: readline exits on ctrl-c even when SIGINT is caught)
I think this is actually expected behavior. Sorry for the bug report. I'll just use siglongjmp. https://stackoverflow.com/questions/16828378/readline-get-a-new-prompt-on-sigint On Tue, Mar 26, 2019 at 6:09 PM Debian Bug Tracking System wrote: > > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 925562: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925562. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > dwk...@gmail.com > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > Matthias Klose > > If you wish to submit further information on this problem, please > send it to 925...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 925562: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925562 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#714014: dhex has high CPU usage (30%) due to input processing
Package: dhex
Version: 0.68-2
Severity: important
Tags: upstream patch
Hello,
I have been looking for a useful console-based hex editor and dhex is a good
candidate, except that it uses a lot of CPU when idling and waiting for the
user's next key press. This happens with an input file of any size
(including
an empty file). The CPU usage ranges from 30% on an i5 to 50% on an AMD
E-350.
I have run dhex through a debugger and looked at the source and the problem
appears to be entirely due to its input processing. The function getkey() in
dhex-0.68/input.c consists of a busy-loop waiting for input, delaying for a
maximum of one microsecond (through usleep(1)).
However, the program still seems to function correctly when asynchronous
input
is disabled. I have tested editing, searching, go to position, etc. This is
assuming ncurses is in cbreak() mode which mine appears to be by default (a
call to cbreak() could also be included). Here is a patch that disables
asynchronous input:
diff --git a/dhex-0.68-orig/main.c b/dhex-0.68/main.c
index e6f014c..21cef37 100644
--- a/dhex-0.68-orig/main.c
+++ b/dhex-0.68/main.c
@@ -525,7 +525,6 @@ int main(int argc,char** argv)
output-win=initscr();
pairsinit(output);
noecho();
- nodelay(output-win,1);
if (keyboardsetupreq) keyboardsetup(output,configfile);
readbuf(buf1,0);
firstpos1=cursorpos1;
Of course the getkey() input routine could be much simpler if it knows that
getkey() will block, and I recommend that it be rewritten (by someone who
knows
more about ncurses than I). It seems like the routine is trying to handle
multi-character extended keys (arrow keys, function keys) by receiving
blocks
of characters at once and comparing them with a list. This should be
equivalent
to blocking on each getch() call and searching through the list after each
character (which is what my patch will induce, since getch() never returns
ERR
in a blocking context).
If that patch seems too risky, at the very least, the usleep(1) call
(input.c
line 72) could be changed to usleep(1000) to sleep for a millisecond
instead of
a microsecond. This still uses CPU but normally less than 5%. The program
still
functions without apparent latency (the maximum latency introduced would be
1
ms), and it will never miss any input.
diff --git a/dhex-0.68-orig/input.c b/dhex-0.68/input.c
index 34e2e93..8ead185 100644
--- a/dhex-0.68-orig/input.c
+++ b/dhex-0.68/input.c
@@ -69,7 +69,7 @@ tInt16 getkey(tKeyTab* pKeyTab,tBool inputfield)
// =1 this is an inputfield. w
lastch=ch;
done=1; // a key was pressed
} else {
- usleep(1);
+ usleep(1000);
donecnt=donecnt-partial;
done=!donecnt;
}
In this second case, the initial donecnt value should perhaps be
initialized to
a smaller value (for less async getch() calls since there is a bigger delay
between each one). It is curious however that donecnt is never reset to a
nonzero value once it hits zero; is that another bug?
All in all, I recommend that one or the other of my patches be adopted, and
perhaps someone else take a look at the getkey() function. It seems in need
of
review. Cheers.
~ dwk
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dhex depends on:
ii libc62.17-3
ii libncurses5 5.9+20130608-1
ii libtinfo55.9+20130608-1
dhex recommends no packages.
dhex suggests no packages.
-- no debconf information
Bug#637294: bug is still reproducible
I have this bug with inkscape 0.48.3.1-1.1 and libgnomevfs2-0 1:2.24.4-1. The suggested fix, uncommenting the line file: file in /etc/gnome-vfs-2.0/modules/default-modules.conf, has resolved the issue. The SVG file I was originally trying to open was created with inkscape 0.45.1: /usr/share/kde4/apps/kgoldrunner/themes/default/set.svg from kgoldrunner 4:4.8.4-1. I suspect the issue would happen with any SVG file, but I cannot go back to the old behaviour now by re-commenting-out the file: file line, so I do not know for sure. Here is the error message reproduced for completeness: $ inkscape default/set.svg (inkscape:21058): libgnomevfs-CRITICAL **: gnome_vfs_uri_is_local: assertion `uri != NULL' failed ** (inkscape:21058): WARNING **: Invalid URI ** (inkscape:21058): WARNING **: Error: Could not open file 'default/set.svg' with VFS
Bug#594071: ntp: dies with no reason
Hi, Same here, with Expert mouseCLOCK. Suddenly it's gone and I didnt find anything in the logs. I never noticed that bug in Lenny. The squeeze is a fresh install, not an upgrade from lenny. Default ntp.conf, except ntp pool was replaced by Expert mouseCLOCK (and local clock). Bye, Wolfgang -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#318058: works fine under libdbd-mysql-perl 4.008-1 in unstable
2009/4/10 Alex Muntada al...@alexm.org:
I installed mysql-server on sid without changing a single
file, so the latin1 values seem the default to me.
Yes, it is. I wanted to make everything fully utf8 compliant, so i
changed those variables too.
I finally found the problem: DBD::mysql does not work on
UTF8 by default, please search for «mysql_enable_utf8»
in perldoc. It doesn't matter that the input strings and the
database are both in UTF8. You have to explicitly enable
UTF8 like this:
my $dbh = DBI-connect(
$data_source,
$user,
$password,
{ mysql_enable_utf8 = 1 },
) || die no connection\n;
Alternatively, you can also use this:
$dbh-do(SET NAMES utf8);
I think you are right, but i'm just confused now. I used the first
one, but i tried like this:
my $dbh = DBI-connect($data_source, $user, $password) || die no connection\n;
$dbh-{mysql_enable_utf8} = 1;
It reports back the same way it does in your connection, i tested it like that:
warn ($dbh-{mysql_enable_utf8} ? utf8 set up : utf8 not set up);
Only difference i noticed that your way has influence on data too.
Thank you! I think there is no bug in this package and it was my
fault.
One thing i can suggest: maybe this option (mysql_enable_utf8) could
be enabled automatically when database is in UTF8.
--
With best regards,
Kõike hääd,
WK
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#318058: about Bug#318058: lidbdb-mysql-perl and UTF8
Terr! Hans Ekbrand kirjutas 30. märtsil sel aastal: Have you tried to run perl with -C? On Lenny, I had the same problems as described in this bug report, but they went away when started perl with -C, or defined the environmental variable PERL_UNICODE=. As you can see some messages back there, i am. -C63, to be precise. It did not help. Did you try it with my testcase i posted here? Which number you tried with -C? Btw, i don't get messages which are posted to 318...@bugs.debian.org. Should i or no? That's why some messages are so long not answered. Today i just visited this site and noticed your answer/question here. -- With best regards, Kõike hääd, WK -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#318058: about Bug#318058: lidbdb-mysql-perl and UTF8
Terr! Some time ago i posted a testcase for reproducing this bug. Did you have time to test it? I can add some symptoms more. I tested today with version 4.005-1 on my Kubuntu laptop and i noticed following: 'š' becomes '�' but when i add use utf8 pragma and -C63 commandline switch, 'š' (and 'ž' and some more diacritics) just disappears. I tried also with cyrillic characters and when proper output should be 'Скажи-ка мне пожалуйста...' i got '?-?? ??? ??...' So, there is still something wrong with unicode handling. I hope you find time to figure out this bug. TIA, -- Kõike hääd, Gunnar Koppel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#325578: gnupg/528
Synopsis: --use-agent + no agent + successfull operation = failure return value State-Changed-From-To: open-feedback State-Changed-By: werner State-Changed-When: Tue, 30 Aug 2005 19:03:05 +0200 State-Changed-Why: Patch sent to Debian BTS. Comment added by werner on Tue, 30 Aug 2005 19:03:05 +0200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
