Bug#882378: alsaequal: change order of link flags to ensure libasound is linked to .so files
Source: alsaequal Severity: normal Tags: patch upstream Dear Maintainer, the $(LDFLAGS) in the Makefile, containing -lasound, should come after the .o objects in the final linking to be sure it is linked against the .so (the libasound is present in the ELF tables/things/whatever). Actually, with my current version of Debian (testing), this is not a problem, but for a popular 'derivative distribution', it is. When using the equalizer with PulseAudio (my fingers almost burned while typing this!), this beast cannot load the .so because it is not linked to libasound. So I don't know if it's the right place for a bug report, but I have to do it somewhere. The upstream (www.thedigitalmachine.net) does not exist anymore, and I don't feel like I want to be in more contact with the 'derivative distribution'. The patch is very simple. Edit Makefile and put $(LDFLAGS) at the end of the two lines where it is used. I apalogize by advance if this is the wrong place to report the bug (which is non-existing in my current Debian setup). But I struggled a lot with it because of another bug in alsa-lib (they don't use dlerror when loading a library so we don't see why it fails). Anyway, there it is. Have a nice day! By the way, it's all the fault of people from Mozilla who seem to have decided that talking to ALSA was too... something, and now only use the P..A.. beast (my fingers don't need more pain today). This world is a strange place. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.13.5-custom (SMP w/8 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 /bin/dash Init: sysvinit (via /sbin/init) *** patch.txt 34c34 < $(Q)$(LD) $(LDFLAGS) $(SND_PCM_LIBS) $(SND_PCM_OBJECTS) -o $(SND_PCM_BIN) --- > $(Q)$(LD) $(SND_PCM_LIBS) $(SND_PCM_OBJECTS) -o $(SND_PCM_BIN) > $(LDFLAGS) 38c38 < $(Q)$(LD) $(LDFLAGS) $(SND_CTL_LIBS) $(SND_CTL_OBJECTS) -o $(SND_CTL_BIN) --- > $(Q)$(LD) $(SND_CTL_LIBS) $(SND_CTL_OBJECTS) -o $(SND_CTL_BIN) > $(LDFLAGS)
Bug#762604: base: debian testing and unstable don't work with a 486 PC
Package: base Severity: critical Justification: breaks the whole system Dear Maintainer, I need to boot a linux system on my old 486 to access the parallel port to do some JTAG debugging. I use my recent PC as a NFS root server. I ran: debootstrap --arch=i386 stable /tmp/debian.stable debootstrap --arch=i386 testing /tmp/debian.testing debootstrap --arch=i386 unstable /tmp/debian.unstable And served those directories to the 486, the one after the other. Debian stable is working. Debian testing is not. Debian unstable is not. Running ls crashes with illegal instruction. I found out that the illegal instruction is cpuid (this one does not exist on 486 PC) which is in libpthread.so, function __get_cpu_features. Why is that called? I don't know. It should not. I tried to recompile the whole gnu libc beast to not include that function, but failed. I skip the details, I surely did something wrong. And I don't have much time nor energy for that thing. So I report the problem to you, just in case you plan to turn testing into stable, because that would mean that debian will not work on 486 PC anymore. Maybe someone somewhere knows what to do and cares enough to fix things. My bet is that the gnu libc thinks it will run on at least a 586 and includes code for such computer. Is it something in the configure of libc? Is it something with your configuration of gcc (I see include/cpuid.h down in /usr/lib/gcc, I suspect it should not be here, but I really don't know). Well, I don't know. In any case, please don't turn current testing into stable. That would mean no more debian on 486. In the future, if you think you fixed this problem, let me know so I can try with my 486. (Why do some neurons up in my brain shoot high levels of dopamine and serotonin when I read that previous sentence, I don't know.) Anyway, so be it. I did my part. The following system information is from my recent PC and is unrelated to the 486 at all, left here because, hum, why not. Regards, Cédric. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758110: base: suspend to ram key (Fn+F4) does not work anymore
Package: base Severity: normal Dear Maintainer, I did an upgrade of Debian testing yesterday and since then the Fn+F4 key on the laptop (ACER timeline X 5820TZG) does not suspend to RAM anymore. I removed (apt-get purge) acpid, acpi-supoprt, acpi-support-base. I use fvwm, not gnome/kde, that I run with startx. I tried a cold boot, I tried in a linux console (i.e. no X). I see that the key press is visible in /dev/input/event0 (the keyboard). I see with xev that it is reported as keysym XF86Sleep in the X world. I tried to look on the internet but could not find something that helps, thus this email. The apt-get dist-upgrade of yesterday seems to have installed systemd instead of what was there before. It might be related, but: journalctl -u systemd-logind.service -b reports: Watching system buttons on /dev/input/event3 (Sleep Button) So I don't think the problem is there. I suspect the kernel, since /dev/input/event3 seems to be silent (cat /dev/input/event3 shows nothing, whereas cat /dev/input/event0 does). Thanks for any hint. If you don't have enough information, I may provide more. Regards, Cédric. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
