Bug#1001645: pulseaudio: My system has no sound at all, after upgrading
I have the same issue. Also caused by upgrade. Causes almost any program that attempts to play sound to freeze. I twigged that it was pulseaudio when a non-pulseaudio using video player was the only sound-playing thing on my system that DIDN'T freeze. And I found a workaround. When you are about to start an audio stream, open a terminal and enter the command: pulseaudio -k Then within a few seconds after that, go and start the audio stream. If you wait too long it doesn't work. However, even when it's working you may not hear it, or you may hear it at an absurdly low volume, because it may start up with a randomized volume level. I have a pulseaudio plugin named 'pavucontrol' on my taskbar. I open that plugin and set the pulseaudio output level to 100%. "pulseaudio -k" is a command to kill the pulseaudio daemon. I suspect that when a new instance of the daemon starts up it's in a usable state for a few seconds but then somehow becomes unusable unless actually put to work. I have no idea what triggers the unusable state, but it seems to happen within fifteen seconds of non-use. As long as there is continuous audio output after starting the audio stream, it works normally. Music players that start playing the next song immediately after the previous one ends don't have a problem. But if audio output ever completely stops, pulseaudio goes to the unusable blocking state within a few seconds. I've been starting an audiobook with the volume at 0.1% and then minimizing the reader. This keeps the audio channel open for days but is completely inaudible on my speakers. So I can use youtube, play sound files on the web, use music players, play games with sound effects, etc, at normal volume without problems. Bear
Bug#1010411: gucharmap installing without required version of libc6 (was: gucharmap displaying characters white on white)
package: gucharmap version:1:14.0.3 While preparing this bug report for the white-on-white characters, I checked the versions of everything gucharmap depends on and I think I found a packaging error. Gucharmap wants libc6 version 2.4, but installed without complaint even though I have libc6 version 2.33. Packages gucharmap depends on: libgucharmap (I have 2.90-7) dconf-settings-backend | gsettings-backend (I have dconf-gsettings-backend 0.40.0-3) libatk1.0-0 (I have 1.0-0) > libc6 2.4 (!!! I have 2.33-7 !!! ) <= libcairo2 (I have 1.16.0-5 ) libglib2.0-0 (I have 2.72.1-1 ) libgtk-3.0 (I have 3.24.33-1 ) libpango-1.1-0 (I have 1.50.6+ds-2 ) libpangocairo-1.0.0 (I have 1.50.6+ds-2 ) When I open gucharmap on my desktop machine, all characters are displayed as empty white boxes. If I select a character, the white background darkens and the white character is visible. When I use a different font, the white characters displayed in their white boxes are rendered in the new font. I searched a lot of resources and read a lot of documentation and tried a lot of things without success, but if this is actually just a packaging bug that's all irrelevant. I did a complete uninstall, then reinstalled, and I still have libc6 2.33, and gucharmap still lists libc6 2.4 as a requirement, and apt-get and dpkg did not even question it. And of course I still have gucharmap displaying all characters white on white. For now I'm blaming the packaging error, in sincere hopes that fixing the packaging error fixes it. Bear
Bug#1010288: 'Rotate' rotates entire image regardless of layer or selection.
package: gimp Version: 2.10.30-1+b1 Severity: Normal The 'rotate' tool in GIMP is now ignoring selection area and layer restrictions, making it impossible to rotate any part of the image relative to other parts. Note, there is a workaround. Cut to the last paragraph if that's all you're interested in. I opened gimp with the intention of creating printable specialized graph paper with a triangular grid. So I made a transparent layer and used 'snap to grid' to precisely draw and paste a set of exactly parallel lines. I intended to paste two more copies of this set of lines, at 60- and 120-degree rotations, to make the triangular grid. So I did select all, copy, paste, grab the rotation tool to rotate the pasted layer. When I attempted to use it, it rotated the entire image, including the layer boundaries of the base layer and the horizontal-lines layer. So I control-Z undid that, made sure I had selected the pasted layer, and tried again. Same result. I supposed maybe rotate had been changed and no longer worked on "pasted" layers for some reason, so I transformed the pasted layer into a normal layer. I made sure I had selected that layer and tried again. Same result. I thought maybe they changed rotate so it only works on explicit selected areas, so I made sure to select all, on that layer, and tried again. Same result. Just to see whether it mattered how the selection was made, I selected "most" of the area with the wrecked-angle select tool leaving about 5 pixels around the edges unselected, and tried again. Same result. At this point I concluded that it is not possible to rotate any part of the image relative to any other in normal use. As a workaround I rotated the entire image, exported a .png file, then rotated it again and exported another .png file. Then I opened those images as separate buffers, and cut and pasted from them into my main buffer. Note, when doing this make sure the alpha channel for transparency is preserved in the export options. Hope this helps! Bear
Bug#1000715: dpkg -S fails to identify package for coreutils files: says 'no path found matching pattern' instead
On Sun, 28 Nov 2021 09:48:22 +0100 Niels Thykier wrote: > This is a consequence of the currently incomplete "/usr-merge" > transition, where /bin has been merged into /usr/bin without dpkg's back. > > As such, dpkg knows those paths only by their "officially declared" > paths in /bin. It is obviously confusing to you as a user because you > then have to "know" whether to search for /usr/bin/P or /bin/P. > > As a work around you can use a wild card search, such as: > > dpkg -S '*/bin/ls' > I suppose this means I don't actually understand how dpkg works at all. The files are there in /usr/bin, and SOMETHING, presumably an installer run by dpkg the most recent time coreutils was updated, installed them. But dpkg does not know which installer was running at the time? Does it rely on some information separate from keeping track of the actual files written while an installer is running, to know which installer was responsible for writing the files? That's very unexpected at least to me. It seems like manually maintaining the lists would be a lot more work than coding the automatic tracking I had assumed was happening. I'd be interested in understanding the design constraints that make it preferable. Not that it makes much difference on the ground right now. The news relevant to this is, it's on your radar already as an issue with this migration/merge situation, and I'm not bringing up anything that wouldn't eventually get fixed otherwise. So I suppose all there is to say is "known issue" and "workaround available" and close this when you get to it in the due course of the migration work. I hope various aspects of this don't cause you too many more headaches. Honestly I don't have much opinion on the /bin and /usr/bin merger; the pros and cons seem balanced on a knife edge to me. It seems like an objectively good impulse to reduce complexity, but it also seems like a hell of a lot of work, pain, and confusion to go through right now for what will be, in any particular future year, only a very minor benefit. On the third hand there won't come a time in the future when it's easier or less painful than right now, so the choice is existential; rather than "when", we face "whether at all" because the pro and con arguments are unlikely to change. Bear
Bug#1000715: dpkg -S fails to identify package for coreutils files: says 'no path found matching pattern' instead
Package: dpkg Version: 1.20.9 Distribution: Bookworm Architecture: AMD64 Relevant because this could have something to do with which utilities are statically linked to bash or exactly which coreutils we're talking about: bash is version 5.1-3.1 and coreutils is version 8.32-4.1 At the command line I type: >dpkg -S /usr/bin/cp I expect it to tell me coreutils: /usr/bin/cp instead, it falsely reports dpkg-query: no path found matching pattern /usr/bin/cp So I check some other things and find it working correctly. >dpkg -S /usr/bin/dpkg dpkg: /usr/bin/dpkg >dpkg -S /usr/bin/xz xz-utils: /usr/bin/xz >dpkg -S /usr/bin/yelp yelp: /usr/bin/yelp In fact it responds correctly to everything I've tried EXCEPT files installed by coreutils: >dpkg -S /usr/bin/cp dpkg-query: no path found matching pattern /usr/bin/cp >dpkg -S /usr/bin/ls dpkg-query: no path found matching pattern /usr/bin/ls >dpkg -S /usr/bin/rmdir dpkg-query: no path found matching pattern /usr/bin/rmdir >dpkg -S /usr/bin/mv dpkg-query: no path found matching pattern /usr/bin/mv >dpkg -S /usr/bin/grep dpkg-query: no path found matching pattern /usr/bin/grep But it's not entirely consistent. There are some coreutils files it identifies correctly: >dpkg -S /usr/bin/yes coreutils: /usr/bin/yes I don't know why this is happening. But I thought I should report it. Bear
Bug#986176: openuniverse runs with crippled GUI, then crashes.
On 5/26/21 8:01 PM, Bernhard Übelacker wrote: > Testing in a VM with a more reasonable 6GB apparently does not provoke >> the crash. > > I fear the issue might also be specific to the graphics library > because the crash happens in nouveau_dri.so. > Therefore a VM might not show this issue. > I defer to your expertise. I'm not really familiar with how the graphics libraries and graphics drivers work with the software, so you're way more likely to be right. > >> ... and openuniverse seems to expand to fill available space. > > That would be a memory leak I guess. > Then the backtrace would be really not that interesting. > ??? I can't reproduce that now. It still crashes after a while but it doesn't expand to fill available space. Did something else get fixed that might affect it? >> ... but checking screenshots of it online I see many UI elements that >> simply are not present when I start it. > > I guess the gui needs a libglui, which is not "yet" > packaged for debian (see #801858). > I think that's a showstopper bug for OpenUniverse. It renders the program useless, even if it weren't crashing. I'm surprised to find it outside of the "Sid" distribution if it doesn't have that. > > But while writing this email, I got my hands on a nouveau capable laptop. > There I found openuniverse also crashing if I leave it some time alone, > at the very exact instruction [1]. Oh good. I mean, not good that it's crashing, but good that the crash can be reliably reproduced outside of my peculiar configuration. If other people are seeing it too, it means I haven't done something that puts my machine into a failure-prone configuration that I'll never figure out. > I tried to record with rr, but this forces the driver to software mode, > therefore the issue then does not show up. Hum, that's interesting. Now I need to go read man pages. Thank you for looking into it. Bear
Bug#986176: openuniverse runs with crippled GUI, then crashes.
On Wed, 14 Apr 2021 14:04:33 + Ray Dillinger wrote: > > Warning, a coredump from this system would be immense. Or, well anyway > pretty darn large. The machine has over 64G of RAM memory installed and > openuniverse seems to expand to fill available space. I could make a VM > with artificially small memory to produce a more manageable coredump, > but I wonder whether a VM environment would tickle the spot that > provokes this bug. Testing in a VM with a more reasonable 6GB apparently does not provoke the crash. It doesn't fix the interface issues, but it doesn't outright crash. But, in light of that fact, the clues seen so far point in one direction, and if I'm right about it the backtrace probably wouldn't even be relevant to finding the problem. Consider the facts: I have a system with an unusual amount of memory. I see Openuniverse expand to fill available memory and then crash. The crash happens at an instruction to allocate memory. A virtual machine with a less-unusual amount of memory doesn't provoke this crash. Admittedly not very much to go on but what do these clues add up to? I have not even looked at the source code of openuniverse, but this is pretty clearly a memory management bug, and I have a fairly solid theory/guess as to what kind. Managing memory in big chunks can provoke flawed applications to fail in at least three ways they don't fail when managing memory in smaller chunks: First, by extending the time between deallocations and allocations (giving other applications time to allocate and spoil memory availability, provoking a crash on the next allocation). Second, by provoking the allocation of proportional size buffers while deallocating on criteria not sufficient to ensure that such a large buffer remains available, again provoking a crash on the next allocation. Third, by some static structure that keeps track of pointers to allocated memory having a finite limit that is exceeded - resulting in a buffer with an overwritten or unrecorded pointer, provoking a memory leak. Although this theory may be incorrect, these are at the very least the first "obvious" places to look. Bear
Bug#986176: openuniverse runs with crippled GUI, then crashes.
On Wed, 14 Apr 2021 11:59:43 +0200 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= wrote: > Hello Ray, > from the "Code:" line you supplied I think the segfault happens > in create_cache_trans at ../src/mesa/state_tracker/st_cb_bitmap.c:402. > > https://sources.debian.org/src/mesa/20.3.5-1/src/mesa/state_tracker/st_cb_bitmap.c/#L402 > > > But I guess this information is not enough for the maintiner, > to find out what inputs causing the segfault in this function. > > Maybe you could install systemd-coredump and deliver the > output of 'journalctl --no-pager' following the last segfault line, > that appears in dmesg too. > > More details are in this link: https://wiki.debian.org/HowToGetABacktrace Warning, a coredump from this system would be immense. Or, well anyway pretty darn large. The machine has over 64G of RAM memory installed and openuniverse seems to expand to fill available space. I could make a VM with artificially small memory to produce a more manageable coredump, but I wonder whether a VM environment would tickle the spot that provokes this bug. Bear
Bug#986176: openuniverse runs with crippled GUI, then crashes.
Package: openuniverse version: 1.0beta3.1+dfsg-6.1 When I started openuniverse, it put up a window with no menu items and no other control elements. It responded to '?' or 'H' keystrokes by putting up a short list of keystroke shortcuts - presumably corresponding to nonexistent menu options. These keystroke shortcuts seemed to work, but within a few minutes openuniverse crashed. I started it a few more times trying for a while to figure out what I did that made it crash, but it seemed random. Finally I started it and went looking online for any discussion of the problem. It crashed after no more than 5 minutes, before I had even turned away from the browser and tried to do anything with it. So I'm pretty sure it's not something I did. In dmesg it says: [406058.660546] openuniverse[242638]: segfault at 20 ip 7f86f454ad63 sp 7ffefd7050a0 error 4 in nouveau_dri.so[7f86f4517000+d46000] [406058.660565] Code: 48 48 89 c7 b9 02 00 00 00 ff 90 08 03 00 00 4c 8b 54 24 10 be ff 00 00 00 48 89 c7 49 89 82 70 12 00 00 49 8b 82 60 12 00 00 <8b> 50 20 c1 e2 05 e8 52 c9 fc ff 4c 8b 54 24 10 48 89 ea 4c 89 fe Which appears to implicate a conflict with nouveau. I have an nvidia 1050TI video card but I have not downloaded drivers from nvidia's site for it. OpenUniverse documentation strongly suggests the proprietary drivers I am not using. I am not familiar with openuniverse, but checking screenshots of it online I see many UI elements that simply are not present when I start it. It's even missing a basic icon for a launcher shortcut. Checking dependencies I see that it conflicts with openuniverse-common(<=1.0beta3.1-3). I have installed version 1.0beta3.1+dfsg-6.1. That looks to me like it should not have installed with the current version of openuniverse-common, but these version numbers are inconsistent in format so I'm not certain. Checking dependencies I also see that it requires libjpeg26-turbo >= 1.3.1 and my installed version is 1:2.0.6-4. Again it looks to me like it shouldn't have installed with this version, but because of the inconsistency in version number format I'm not sure. Finally I see in its dependencies that it suggests package 'celestia' which has no installation candidate in the Testing/Bullseye release. This is very sad. I like Celestia. I miss it ever since Jessie. I have sometimes gone out and gotten the .deb from their site and installed it - but not yet this time. I tried openuniverse first looking for an adequate in-distro replacement. This is a fresh install of Bullseye, made using 'grml-debootstrap' less than a week ago. I have absolutely no software installed on this machine that is not downloaded from the 'Bullseye' archive. Packages openuniverse depends on: openuniverse-common: Installed version is 1.0beta3.1+dfsg-6.1 freeglut3 >= 2.8.1: Installed version is 2.8.1-6 libc6 >= 2.14: Installed version is 2.31-10 libgcc-s1 >= 3.0: Installed version is 10.2.1-6 libglu1-mesa | libglu1: Installed version is libglu1-mesa libjpeg62-turbo >= 1.3.1: installed version is 1:2.0.6-4 libplib1: Installed version is 1.8.5-8 libstdc++6 >= 5 : installed version is 10.2.1-6 Hope this helps! Ray "Bear" Dillinger
Bug#730224: The problem is with the nvidia software in debian.
As expected the problem is something about the interaction with the debian nvidia software, gdm, and my laptop. I have found a workaround. I did # apt-get remove *nvidia* And the configuration went back to the nouveau drivers, and the problem went away. The laptop isn't a gaming machine so I don't mind lack of graphics acceleration. But losing CUDA parallel processing is a real problem for me. Anyway, I've got something that works. Next up, I'll switch to cinnamon and see if I'm allowed to get CUDA working with that. Bear signature.asc Description: OpenPGP digital signature
Bug#730224: This error is happening on a fresh "Stretch" install.
X-Debbugs-Cc: b...@sonic.net Package: gnome Version: 1:3.20+2 Followup-For: Bug #730224 I installed "Stretch" on my laptop using ISO install snapshot CDs (specifically the image downloaded 6 January 2017). The laptop was working fine with "Jessie" before the (re)install. I did a clean install rather than an upgrade for unrelated reasons. It's a standard Toshiba AMD64 laptop with radeon display and nvidia graphics. But for now, when I boot up, I get the "Oh No" screen already mentioned. Its lack of useful information seems disrespectful to me; please consider actually telling people what went wrong. Some instances of this message can be closed using Alt-F4; this is not one of those times. It usually seems to ignore Alt-F4, but on one occasion it went dark and hung instead, requiring a reboot to even get to the error screen again. I can escape it to a virtual tty and run a bash shell, however. Switching to a tty, I ran "reportbug -o" to generate this email. It is not being sent from the laptop; it is being sent from the machine where I handle email. But the attached information refers to the laptop where the problem is happening. There is no ~/.cache directory. This happens on bootup, not login. This error screen is popping up before any user attempts to log in, so it would have no information about where to put a .cache. I looked for one anyway, but no. Not in my home directory, not in root's. I have attached the configuration output from modprobe -c (attached file modprobe.txt) and the X.1.log output (xlogoutput.txt). I hope this helps... I think my next move will be to attempt using the nouveau drivers instead. Bear -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome depends on: ii alacarte 3.11.91-2 ii avahi-daemon 0.6.32-1 ii bijiben 3.20.2-1+b2 ii brasero 3.12.1-4 ii cheese 3.22.1-1 ii cups-pk-helper 0.2.6-1 ii desktop-base 8.0.2 ii evolution3.22.3-1 ii evolution-plugins3.22.3-1 ii file-roller 3.22.2-2 ii gedit3.22.0-2 ii gedit-plugins3.22.0-1 ii gimp 2.8.18-1 ii gnome-clocks 3.22.1-1 ii gnome-color-manager 3.22.2-1 ii gnome-core 1:3.20+2 ii gnome-documents 3.22.0-1 ii gnome-games 1:3.20+2 ii gnome-getting-started-docs 3.22.0-1 ii gnome-logs 3.22.1-1 ii gnome-maps 3.22.2-1 ii gnome-music 3.22.2-1 ii gnome-nettool3.8.1-1+b1 ii gnome-orca 3.22.2-1 ii gnome-photos 3.22.2-1 ii gnome-sound-recorder 3.21.92-1 ii gnome-tweak-tool 3.22.0-1 ii gnome-weather3.20.2-1 ii goobox 3.4.2-2 ii gstreamer1.0-libav 1.10.2-1 ii gstreamer1.0-plugins-ugly1.10.2-1 ii inkscape 0.91-12 ii libgsf-bin 1.14.41-1 ii libgtk2-perl 2:1.2499-1 ii libreoffice-calc 1:5.2.4-2 ii libreoffice-evolution1:5.2.4-2 ii libreoffice-gnome1:5.2.4-2 ii libreoffice-impress 1:5.2.4-2 ii libreoffice-writer 1:5.2.4-2 ii nautilus-sendto 3.8.4-2 ii network-manager-gnome1.4.2-1 ii polari 3.22.2-1 ii rhythmbox3.4.1-2 ii rhythmbox-plugin-cdrecorder 3.4.1-2 ii rhythmbox-plugins3.4.1-2 ii rygel-playbin0.32.1-1 ii rygel-tracker0.32.1-1 ii seahorse 3.20.0-3 ii simple-scan 3.23.2-1 ii telepathy-gabble 0.18.3-2+b1 ii telepathy-rakia 0.8.0-3 ii telepathy-salut 0.8.1-5.1 ii totem-plugins3.22.0-2 ii transmission-gtk 2.92-1 ii vinagre 3.22.0-1 ii xdg-user-dirs-gtk0.10-1 gnome recommends no packages. Versions of packages gnome suggests: pn firefox-esr-l10n-all | firefox-l10n-all pn xul-ext-adblock-plus pn xul-ext-gnome-keyring Versions of packages gnome-core depends on: ii adwaita-icon-theme3.22.0-1 ii at-spi2-core 2.22.0-5 ii baobab3.22.1-1 ii caribou 0.4.21-1 ii dconf-cli 0.26.0-2 ii dconf-gsettings-backend 0.26.0-2 ii empathy 3.12.12-3 ii eog
Bug#487946: 'apt-get update' considers connection failures non-transient
There is no reason to have multiple sources in your /etc/apt/sources.list file, if apt-get update/upgrade only cares about the first one! I use multiple sources in the hopes that (a) The load should be distributed among those mirrors. (b) Multiple downloads should be happening at once. At least two or three, because any one download could stall and I don't want to waste time. (c) If a download from some mirror stalls, time when my bandwidth could be in use should not be wasted waiting for it. Downloads from available mirrors should continue, and if the number of downloads in progress drops too low, then a download from an additional mirror ought to be triggered to insure that bandwidth on my end remains reliably useful. (d) If a package turns out to be unavailable from some mirror, or if the download of that package from that source is still incomplete and stalled when there is available bandwidth because other downloads are finished, or if checksum of a downloaded package fails, that package ought to be downloaded from elsewhere rather than causing a failure. Apt should fail only if there are packages it can not get from ANY source. (e) A mirror that stalls or fails a lot should be lowered in priority over time, both so that its load is reduced as it apparently needs, and so my bandwidth is usually dedicated to downloading from the most reliable mirrors. I don't want any of the mirrors to be considered 'primary' - treating one as such just because of its position in the sources list is crazy! I'm pretty sure I remember these things all being true, way back in Lenny or Wheezy. When did they get disabled? Multiple sources now make apt take LONGER and fail MORE instead of saving time failing LESS as they used to. Bear signature.asc Description: OpenPGP digital signature
Bug#703932: Certificate problem =?= package integrity problem?
Hmm. On further inspection, it appears that you're right. So I suppose my "bug" is that debian appears not to give a crap about people monitoring who is downloading which packages and isn't providing their repositories via https. Or ftps. Or, really, via *any* confidential mechanism. Signatures are a half-measure; they provide for integrity/ source authentication, but not for confidentiality. Anyway, as you say that's a different issue and shouldn't be confused with this same bug. Bear signature.asc Description: OpenPGP digital signature
Bug#703932: Certificate problem =?= package integrity problem?
I'm getting a message that the certificate for "debian.org" is not applicable to "security.debian.org" and therefore none of these packages can be verified. On the one hand, of course that's just a configuration error where the certificate should be for *.debian.org instead of for debian.org. On the other hand, the https certificate ought to have no effect whatsoever on whether the packages can be verified. The package signatures are all down to the debian keyring, or ought to be. signature.asc Description: OpenPGP digital signature
Bug#794316: gdm3: had this problem. found something that fixed it in my case.
Package: gdm3
Version: 3.18.0-2
Followup-For: Bug #794316
Dear Maintainer,
I had an issue where login didn't work. The login screen would appear,
I'd enter username and password, and then I'd wind up back at the login
screen. It may be this bug or one closely related.
For a while I thought I might be misremembering the password, or might
have changed it and forgotten, because it was very much like what
happens when you get the password wrong. But as I eventually noticed,
not *exactly* like it. There was different behavior for the right
password and any wrong password.
I used ctrl-alt-f2 to login in text mode (which did work). Immediately
on login I got a message about a syntax error in my ~/.profile. I had
failed to close a quote on a $PATH= command. It happened to be the last
command in the file (and the most recently added) but I don't know if
that matters.
Anyway, when I fixed the .profile error and rebooted, the problem with
gdm refusing to start was gone.
One clue along the way was that I noticed a difference while attempting
to log in between getting the password actually wrong ("sorry that
didn't work" message and a new login prompt) and getting the password
right (screen blinks out for a half-second as the gdm login manager
restarts, and then the login prompt reappears with no "sorry that
didn't work" message). So I figured, login was probably working and
then control getting handed off to something that crashed, with the
error handling landing me back at the login screen.
So I figured it had to be something on the startup path and probably
something related to my account. When I got the message about the
~/.profile error, it made sense.
But it's an excessively poor way to handle something as trivial as a
~/.profile syntax error. In the first place it's deceptively mysterious
(looks almost exactly like getting the password wrong), counterintuitive
to most people ( ~./profile error --> graphical login doesn't work is
non-obvious when most of them won't think of trying to log in without
GUI and therefore won't even SEE a message about the ~/.profile error),
and it will lock any exclusively GUI-using folk (the ones who don't even
know a non-GUI login is possible) out of the machine entirely preventing
them from FIXING the profile error.
In other news and probably relevant to a different bug, the reason I
was rebooting in the first place is because there appears to be a memory
leak in gdm. It had consumed 8GBytes of memory over the course of a
few weeks.
Bear
Note about 'stretch/sid' below: this isn't a case of software version
incompatibilities. I use 'sid' exclusively for sources, and have compiled
3 packages against the 'stretch' environment for compatibility.
They run from ~/.bin. However, None of those programs uses the X server,
and none of them run at startup.
-- System Information:
Debian Release: stretch/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.5.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gdm3 depends on:
ii accountsservice 0.6.40-3
ii adduser 3.114
ii dconf-cli 0.26.0-1
ii dconf-gsettings-backend 0.26.0-1
ii debconf [debconf-2.0] 1.5.59
ii gir1.2-gdm3 3.18.0-2
ii gnome-session [x-session-manager] 3.18.1.2-1
ii gnome-session-bin 3.18.1.2-1
ii gnome-settings-daemon 3.18.2-1
ii gnome-shell 3.18.1-1
ii gnome-terminal [x-terminal-emulator] 3.20.0-1
ii gsettings-desktop-schemas 3.18.1-1
ii libaccountsservice0 0.6.40-3
ii libaudit1 1:2.4.5-1+b1
ii libc6 2.22-6
ii libcanberra-gtk3-00.30-3
ii libcanberra0 0.30-3
ii libgdk-pixbuf2.0-02.34.0-1
ii libgdm1 3.18.0-2
ii libglib2.0-0 2.48.0-1
ii libglib2.0-bin2.48.0-1
ii libgtk-3-03.18.9-1
ii libpam-modules1.1.8-3.2
ii libpam-runtime1.1.8-3.2
ii libpam-systemd229-4
ii libpam0g 1.1.8-3.2
ii librsvg2-common 2.40.15-1
ii libselinux1 2.4-3+b1
ii libsystemd0 229-4
ii libwrap0 7.6.q-25
ii libx11-6 2:1.6.3-1
ii libxau6 1:1.0.8-1
ii libxdmcp6 1:1.1.2-1.1
ii lsb-base 9.20
Bug#700946: nouveau module blacklisting bites when upgrading from wheezy to jessie
I had the proprietary nvidia drivers installed in my Jessie machine when I decided to move to Stretch. During the upgrade process, there was a message that the open-source driver was compatible with my hardware now, and did I want to switch to the nouveau system. I always prefer open-source when it works and didn't know if the one I had would work with the new kernel, so I said sure, go ahead and upgrade. The upgrade went smoothly, but I got a message that my video drivers were now incompatible with my configuration and I should fix this by rebooting. So I rebooted (x started just fine) and opened Synaptic to see what packages were available, and Synaptic immediately crashed with a message that said my software was unconfigured and I should immediately run 'dpkg --configure -a'. So I did that and a big bunch of messages went by -- apparently every package installed in the upgrade needed configuration. In the middle of that huge bunch of messages (1500+ packages) I saw a message go by that one of the packages being configured was the nouveau nvidia driver. So, after that was done, I rebooted again just to make sure everything was okay. It wasn't. When I rebooted, the X server did not start. I got a command-line login though, so I did that (with my head tilted sideways; I have dual displays in portrait orientation side by side). I fixed it by going back to the proprietary drivers using 'apt-get install nvidia-detect' to get the script that detects what driver ought to be used, ran it, and it (correctly) told me to go get the proprietary driver. So I did 'apt-get install nvidia-driver' and it downloaded, and I rebooted again. This time X started but it had lost my video config so my head was still turned sideways until I fixed that (rotate both screens 90 degrees, put them side-by-side). I'm attaching the log that Xorg made on the failed attempt to start. It looks as though the problem was that the kernel module didn't start and therefore the nouveau driver didn't find any screens. I think this is the right bug to send this to; it sounds a whole lot like the problem I'm having, anyway. I'm running an AMD64 system with an Intel i7 processor and 64Gbytes memory. (The large memory has outed a few bugs in the past, but doesn't appear to be related to this.) In case it helps, here is the output of lspci: 00:00.0 Host bridge: Intel Corporation Xeon E5/Core i7 DMI2 (rev 07) 00:01.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 1a (rev 07) 00:02.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 2a (rev 07) 00:03.0 PCI bridge: Intel Corporation Xeon E5/Core i7 IIO PCI Express Root Port 3a in PCI Express Mode (rev 07) 00:05.0 System peripheral: Intel Corporation Xeon E5/Core i7 Address Map, VTd_Misc, System Management (rev 07) 00:05.2 System peripheral: Intel Corporation Xeon E5/Core i7 Control Status and Global Errors (rev 07) 00:05.4 PIC: Intel Corporation Xeon E5/Core i7 I/O APIC (rev 07) 00:11.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Virtual Root Port (rev 06) 00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05) 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 06) 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 06) 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 06) 00:1c.0 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 1 (rev b6) 00:1c.1 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 2 (rev b6) 00:1c.2 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b6) 00:1c.3 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 4 (rev b6) 00:1c.4 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 5 (rev b6) 00:1c.5 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 6 (rev b6) 00:1c.7 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 8 (rev b6) 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 06) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) 00:1f.0 ISA bridge: Intel Corporation C600/X79 series chipset LPC Controller (rev 06) 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 06) 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 06) 02:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1) 02:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a1) 06:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller 07:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller 08:00.0 USB controller: ASMedia
Bug#706874: keyboard-configuration: Support for gaming keyboards (macro keys, mode switches, more than 127 keys)
Package: keyboard-configuration Version: 1.88 Severity: wishlist * What led up to the situation? I purchased a Corsair Vengeance K90 Keyboard, expecting to be able to configure a keyboard model/layout for it. So far I have been frustrated. * What exactly did you do (or not do) that was effective (or ineffective)? I attempted to use xev, then showkeys -s, to learn the scancodes for the additional keys (18 macro keys, a macro record button, and three macro 'mode switch' buttons that are used (in the Win driver anyway) to toggle between different macro profiles). It was my intent to then use autokeys or similar to have a nice set of macros without stomping on standard keyboard shortcuts or rendering half the functionality of emacs unusable. (Emacs uses many key combos that often get tied to shortcuts and thus grabbed from the input before emacs has a chance to see them). * What was the outcome of this action? xev reports mappable scancodes for only some of these items; the rest are 'silent' as far as it can tell. showkeys -s reports scancodes for all keys, but _identical_ scancodes for most of the macro keys. On further investigation I discovered that the keyboard shows up with several different USB id's. Specifically... bear@excessive:/etc/X11/xkb$ ls -la /dev/input/by-id total 0 drwxr-xr-x 2 root root 160 Apr 27 08:13 . drwxr-xr-x 4 root root 440 Apr 27 08:13 .. lrwxrwxrwx 1 root root 9 Apr 27 08:13 usb-Corsair_Corsair_Vengeance_K90_Keyboard-event-if01 -> ../event2 lrwxrwxrwx 1 root root 9 Apr 27 08:13 usb-Corsair_Corsair_Vengeance_K90_Keyboard-event-kbd -> ../event1 lrwxrwxrwx 1 root root 9 Apr 27 08:13 usb-Corsair_Corsair_Vengeance_K90_Keyboard-if02-event-kbd -> ../event3 lrwxrwxrwx 1 root root 9 Apr 27 08:13 usb-Kensington_Kensington_Expert_Mouse-event-mouse -> ../event0 lrwxrwxrwx 1 root root 9 Apr 27 08:13 usb-Kensington_Kensington_Expert_Mouse-mouse -> ../mouse0 lrwxrwxrwx 1 root root 9 Apr 27 08:13 usb-Wacom_Co._Ltd._MTE-450-mouse -> ../mouse1 bear@excessive:~$ xinput --list ⎡ Virtual core pointerid=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4[slave pointer (2)] ⎜ ↳ Wacom Bamboo stylus id=8[slave pointer (2)] ⎜ ↳ Kensington Expert Mouse id=9[slave pointer (2)] ⎜ ↳ Corsair Vengeance K90 id=11 [slave pointer (2)] ⎜ ↳ Wacom Bamboo eraser id=14 [slave pointer (2)] ⎜ ↳ Wacom Bamboo cursor id=15 [slave pointer (2)] ⎜ ↳ Wacom Bamboo padid=16 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ Power Buttonid=6[slave keyboard (3)] ↳ Power Buttonid=7[slave keyboard (3)] ↳ Corsair Vengeance K90 id=10 [slave keyboard (3)] ↳ Corsair Vengeance K90 id=12 [slave keyboard (3)] ↳ Eee PC WMI hotkeys id=13 [slave keyboard (3)] (Line wrap made a hash of that, so I edited somewhat). It's showing up as several different USB devices, with different events. So I used xinput to list the properties of each of these devices. Id 11 is apparently how the keyboard can send pointer events while playing back macros. id 10 appears to be the primary keyboard, roughly equivalent to pc105 plus minimal multimedia keys (play/stop/next/last/volume knob). The macro mode switch buttons and macro record buttons also show up on this device. The G-keys (macro keys) create events here, but are mostly mapped to the same keystroke, which has no symbolic keycode mapped to it. Id 12 is apparently the macro keypad itself. While id 11 shows the same scancode for most of these keys, id 12 shows different scancodes for these keys. (I monitored it with a 'hacked' version of showkeys so I could look at individual devices instead of just defaulting to the 'standard' keyboard). So, all right, it's complex and there are more than 127 keys so they're using an additional usb 'device'. At this point I thought I had enough information to go and write a keyboard model that would map all the keystrokes to scancodes, and help expand the keyboard database ... but as far as I can tell, it appears that xkb cannot be configured to use information from more than one 'device' to decode keystrokes. At the very least, if it can, then no one has discovered and documented how to describe such a device to it. Furthermore, there appear to be no keycodes in /usr/include/linux/input.h for G-keys/macro keys, for a dedicated macro-record button, or for macro mode switches or profile-switch buttons, so even if it turns out that there is a way I can write a description for the keyboard model, I would have to make up stuff and tie it to codes that someone else would unfortunately be using for something else. G-keys, or macro keys, are widely implemented on gaming keyboards; there are scores, possibly hundreds, of keyboard
Bug#629868: these man files are missing in libstdc++6-4.6-doc and libstdc++6-4.7-doc also
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/12/2012 10:13 AM, Matthias Klose wrote: > On 11.07.2012 19:21, Ray Dillinger wrote: >> This is the standard library. It's totally fundamental. We >> can't allow Debian systems for programmers to NOT have man pages >> on this. > > care to send a patch? > If you mean zip up the files that were in libstdc++6-4.4-doc that aren't in later versions, uh, I guess I could. But that doesn't make sense. They are in the source tree already, and I haven't modified them. They've just been skipped (not included) in the current packages. Is there any insight as to why? Somebody made a decision to not package these files when they changed from libstdc++6-4.4.doc to libstdc++6-4.5.doc (and later versions) and if I submitted a patch it would be to undo that change. So if I'm patching it I want to first understand the change. If it was a policy decision, then undoing it will make people who made that decision mad. If it's just a packaging error, then the patch would probably be fairly trivial and wouldn't require any man pages from me. If it's a policy decision, then *different* man page files are needed. It looks like we're talking about the removal of a bunch of doxygen-generated pages, which are only marginally helpful in the first place. Finally, how can I create the patch? I know how to use diff, and I can write troff or nroff man pages for anything I have enough information about, but I know nearly nothing about the .deb file format or how packages are built from the debian source trees. Ray D. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP/1wNAAoJEAOzWkqOibfNeFYH/3yyp0U8H1TGpOPG8RGqTvJy IkYYw6erpnd0JwKx0wEVf0cfUJnL08DD8WhwUTNydWqJDjWkKrq0NNRbEqDqfwuv TplFrzBvyfluVouy3fi0fIztCHxDvniWOET4xqbMx089M4P2oz6lMo0ZClHKpKBp 1duo6rHN3PA0NC0JHyqxqk7YVUZ5F36Y0UOdPdhdamJRWm10r/NTg1mq0I9/7SyA cx6ysoZzA+NFiWriBx/q9E58/skVFPPf1iX5z/Kp4QjTM2nFMQaiPBdEmyvZiQql zIRVfeklP7htJcPGaiuMcWlRwdcErRE1XYoX4+C/fOdgaUs3QbBGkViryKGxbuw= =ShiF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629868: these man files are missing in libstdc++6-4.6-doc and libstdc++6-4.7-doc also
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This bug also affects subsequent versions of this package, libstdc++6-4.6-doc and libstdc++6-4.7-doc Today I typed "man std::mutex" and my system told me there was no man page for something that I know is part of the c++ standard library. So I went Whiskey Tango Foxtrot? and came to find out what's going on. I came to Debian and searched for the package containing the file, and found it ONLY in libstdc++6-4.4-doc. A brief search led to this bug filed against libstdc++6-5.5-doc, and confirmed that many of the man pages for the c++ standard library have been missing ever since libstdc++6-4.4-doc. This is the standard library. It's totally fundamental. We can't allow Debian systems for programmers to NOT have man pages on this. Bear -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP/bYOAAoJEAOzWkqOibfN/1kH/3khZ8zpd/qMDxaoWvAvLu/0 ggMrGNbg7AQWgnN+hh6DRL5+T1J05FzDLHhnIoaTUYxIh+9+LfCcNhRDNEP8zprt uNm9ZpphAcgAKMmI525NAQ9I4CU+D03l0fFct+J4iPTPEBZUiEewmmQdR9XXpnjO gV3oe2AeycOw2f/QYedIz3cj1KPRWUBY6tU3dWSRiapKdJ6EfIGPnmaQFEv9LsQs vOyp9wCMV1PldZvVTRF/MjvqwwzUnzSyRmS5XdqPWqurUhav9aA9hTwI2QjFpD3B 7sysq/XBu5DL/Lz66Sxm81nhI03Cfn7W/OPnl2ZgIAkvjnVts+HsJ3zYw7+DwDE= =TZoh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677216: Further information...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Okay, some further information. After I start gnome-terminal from a command line with 'gnome-terminal -x /bin/sh' I can issue a 'w' command (in another terminal) and see that an instance of 'sh' for my account has been started. This has to be the sh in the gnome-terminal, because my default shell is 'bash'. So I was apparently wrong initially when I said no shell instance is being started. The issue, more accurately, is that no output appears in the gnome-terminal window. When I then focus the konsole where I issued the command to start gnome-terminal and hit control-z to suspend the running job, gnome-terminal freezes (will not repaint its window, etc). When I type 'fg' to resume the suspended job, gnome-terminal resumes (will repaint its window, etc). As a test, I did the following: echo "cat /home/bear/quotations.txt" > sayquotes chmod +x sayquotes gnome-terminal -x sayquotes gnome-terminal came up, very briefly, and then exited. The 'quotations.txt' file is fairly long, but I did not see any output on the gnome-terminal screen. The length of time the window was up however, was about the same as the length of time that a shell running in konsole takes to cat that same file. All this is consistent with gnome-terminal starting the shell (or command) process and running it normally, but failing to display any output. So I did another test, of using gnome-terminal 'blindly' assuming that a command shell is running. After starting gnome-terminal from konsole using 'gnome-terminal' I focused the gnome-terminal window and typed 'iceweasel' - and the browser came up. I quit out of iceweasel and typed 'exit' - and gnome-terminal quit, refocusing konsole. So. Evidently there is a shell process getting started, and it is reading and executing commands. But gnome-terminal is not displaying any output. So now it seems more like some kind of font problem that gnome- terminal is not detecting or reporting. Or, perhaps, if irony is particularly lovely today, it may be reporting the problem on the screen in the very same font that won't display due to the problem it's trying to report. Please downgrade this bug from 'grave' (which it would be if no shell were running, as I initially thought) to 'normal.' Bear -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP2p1YAAoJEAOzWkqOibfN3XwH/itdaXzCvy1CF9cyx/WGg2fx 9VGQG2ZqFvkUHYIhO8RbjxU2Dtz/i20/MFCf//HcLkLyBjGx6zKU2QSkea30UQMg LIWMVfUucN/xSac9Do8ouFBJcEH6FjTCghKeq+mV7zTslpQrBKfO2gQR5Xcv3WSt 7wNnbIU/ByjIYzDpkAOGQyW0c4eSJOW+SH+vvkuGyQG84AGLJCiPbQ8Yj5RFHJFL 7ZcrgnVCYe53BsHmPubN+eozxlXCXeILjtH+Ckd02ftliD+JCZgxJ7PtYzsOyK6N ZatDHy7sGVIIoeFNP0gjIkwiJufXPVJiS3Ik+cgMKga0n6jDAeRZzbnsndaUSVI= =Bsgj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677126: Found the issue.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 During a recent upgrade, a checkbox marked "use colors from system theme" got checked. I was using a black-on-yellow color scheme. The "colors from the system theme" apparently caused gnome-terminal to switch to a black background, but did not change the text color. So all this mess started with me trying to read black text on a black background. My immediate response was "well, that's borked, they'll have to fix that quick, meantime I'll just use konsole." Other people probably didn't see the bug because most of them weren't using black text, or had different 'system colors"? I didn't investigate further until it became apparent that nobody was trying to fix it. So the bug, apparently, amounts to this: The upgrade to 3.4.1.1-1 failed to leave user color settings the hell alone, AND failed to make sure that new settings it was making for colors actually made any sense. This is not a gnome-terminal bug. This was a packaging error in the upgrade to the current version. Please close this bug report. Bear -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP2qN5AAoJEAOzWkqOibfNZD8H/jOim0dlRrAhQbN5rzsnRtOX 5P6JFvQW9f8p7QhatJZlEO9PHldAfPN5zh67LRoOLCk1orY9TkC9Tml5tOZdimCH Pgu7n9LY0iY62S8skVMcMTgAMEYnvwXmUI1MSQeRKugq5fcgho1SWQkT3/JDm8sP FC1d0r52wsv5M9akomQlY/rnFdWqM3VWiUYc1BeJ/iek7xc5IhTKFD/XWcXNMd64 H1xBeVA+fwfSEqC31nkocfYxdGlV9jqHeffyLTkdsV7TnMts5LRhbFhDLHdVj4Fa hkV0es3fFrSUe96eFKJyH9GmS05NqU61YZIqXU76Fa6OwUp2/oCvVDX9AtIxaeE= =VF5q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677126: Subject: /usr/bin/gnome-terminal: No shell is started inside gnome-terminal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: gnome-terminal
Version: 3.4.1.1-1
Severity: grave
File: /usr/bin/gnome-terminal
Justification: renders package unusable
Dear Maintainer,
After recent upgrades (in the last 3-4 weeks I think), when I click
on the gnome-terminal shortcut in the shortcut bar at the top of my
screen, or type 'gnome-terminal' at a shell prompt (in a shell
running in, for example, konsole or xterm) gnome-terminal starts
- - but there is no shell prompt inside it. Inspecting the table of
running processes, I cannot find any instance of a command shell
corresponding to the new gnome-terminal window.
Obvious workarounds like 'gnome-terminal -x bash' and 'gnome-terminal
- -x /bin/bash' do not work either. There is no output at all in the
gnome-terminal window nor at the prompt where I type the command.
'gnome-terminal -x /nonexistent/file' gets the expected error bar at
the top of the new terminal offering buttons to edit the profile or
relaunch, so it's apparently getting as far as at least *finding*
the file for the shell it's supposed to execute.
It's clear to me that most people are not seeing this bug; if
they were, there would be a furor over it by now because the
package in the presence of this bug is completely unusable
('grave'). I am experiencing it as a 'grave' bug, but since
it apparently affects relatively few users,maybe it should be
'normal' instead.
Ray Dillinger
11 June 2012
- -- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-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
Versions of packages gnome-terminal depends on:
ii gconf-service 3.2.5-1
ii gnome-terminal-data3.4.1.1-1
ii gsettings-desktop-schemas 3.4.2-1
ii libatk1.0-02.4.0-2
ii libc6 2.13-33
ii libgconf-2-4 3.2.5-1
ii libgdk-pixbuf2.0-0 2.26.1-1
ii libglib2.0-0 2.32.3-1
ii libgtk-3-0 3.4.2-1
ii libice62:1.0.8-2
ii libpango1.0-0 1.30.0-1
ii libsm6 2:1.2.1-2
ii libvte-2.90-9 1:0.32.1-1
ii libx11-6 2:1.4.99.901-2
Versions of packages gnome-terminal recommends:
ii gvfs 1.12.3-1
ii yelp 3.4.2-1
gnome-terminal suggests no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJP1j0JAAoJEAOzWkqOibfNVi0H/0aZeqhlWOpoCu3h+sfg1e1F
tMK3BcO/zVHa2tx7P9jMrf0pU85d4eqHMYiIWLIoXvTorZkGwO3T/CD/JXfHt2zz
9cu4b7L0xBEKZeYJgRVZ2WawKOA2vpg6Ms6wbaylYzOOaU/Dc3ZpuVmc06ifVvqT
tjQ+TOYhBTqpk7cKoMZ+HsKQqUT1OvBm4SFuO7ehS25huabKjWzsJ3SNiM9Iuv4W
A8rqiwHkpFcjgMM35SmY/nPVeUBTEzsdIC4kuq/Q2GMmMtFaXGR46jMk6u8ac3QT
Rae1no8FGeBCoQJ9ENI7icpjG7LItTBeC0Nju1VqKTQT4gtZ2hA+JPvh8mGEGMw=
=4Rz3
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#647768: Workaround.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, that was a spectacularly unhelpful answer. I'll try to do better. The reason all these things went away is because they are, by default, disabled in the version of Gnome you've just upgraded to. The "bug" can't be fixed, because evidently it's not a bug at all, but rather an intended interface change. Which sort of explains, though it does not excuse, the indifference of someone whose mission is to fix actual bugs. Apparently there's some plan to provide the functionality in another way, but whatever it might be it doesn't seem to be obviously working yet. So until then, for your sake and the sake of all the people who are going to find this bug report when they search for the bug after experiencing the same unexpected and undesired change in desktop behavior To enable icons on the desktop, and right-click desktop configuration, 1. Press alt-f2. 2. In the dialog box that appears, type 'dconf-editor' 3. In the application that then appears, navigate to org -> gnome -> desktop using the list in the left panel. 4. Now in the right panel, there'll be a list of options. One of them, next to an unchecked box, will be 'show desktop icons'. Click on the box. This should make your 'home', 'trash', and 'computer' icons reappear. Beyond that, you can now use a right-click on the desktop to make launchers for various applications. So you can restore your familiar working environment to that extent. There's still a lot of stuff in the new dconf that isn't implemented yet, but this much anyway is working. Bear -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOzVfGAAoJEAOzWkqOibfNauQH/1VkJLyW8exdYY6fGVgq5Don MMfgH73lc4H4ej1RLakdi/xN94a30PyTCeYjmjBIuXtqsy157t6ldtiHSxrqaGBK NoHn5CyKVBPOcR4iGIjjDFL9+2BiCGcmL9TbI9OiqWbnaaBJefSv+XHTpo2TfO56 tFZBNVk47dQmeX6/HFvMeNa4ckErhFTeJjkR/FBkGEG3yQaYzZ2FQDlk3YPuCI9N lRmUBKwCSgFsO1KIvGyoYnJI8bZTV1cP2STZjylsmsynQEwu0fcx9HUbvH9AV74k NxWFBdmkE4jduCB2jYsQDwjnP2dqeyfXCpmwxGJRC5yBXwQC89WRTW1pWnFmBno= =ez19 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510319: workaround, requires root.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just by the way, this bug is annoying as hell. xscreensaver allowed setting individual options for different screensavers. Replacing it with gnome-screensaver when gnome-screensaver does not, AND gnome-screensaver still had bugs in power management on laptops, was a loss of user functionality in both functions. gnome-screensaver was not (and still is not) ready for prime time and should not have been made the default until it is fixed. That said, here's a hamfisted workaround. If you type pkg-config --variable=themesdir gnome-screensaver at a prompt, it will tell you the directory where the screensaver desktop files are stored. These files contain the .desktop files used to start the screensavers in gnome-screensaver. The settings you're interested in get passed to the individual screensavers via the command lines stored in these files. You can edit the settings of individual screensavers by editing the command line options in the respective desktop files. This workaround is hamfisted in the following ways. you have to be root to edit these files. you can 'break' screensavers if you get it wrong, so be sure you can revert your changes in case you mess it up. The changes you make will affect *ALL* user accounts (so you probably don't want to set a slideshow on your private photos if anyone else has an account on the machine). This workaround allows interesting functionality in the following ways: a different .desktop file will show up as a different screensaver in gnome-screensaver -- so you can invoke existing screensaver programs with different sets of arguments as though they were several different screensavers. Bear -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOOLgCAAoJEAOzWkqOibfN/bkH/ilj9LzBtkpM75bS2P+98EZo U6jJe7lCP2JGKr9tGVhmCO+QXfg25MCiqomSqnI8Ym3QGenZFx9EamVg4FIQy4mN aC5e2KRK2XAKiASCkn4XeQ7AoVOniaWgCep+308UpL31qakDwFQcvZYOiIvNiiLR rYlRcoDZBx0KTKJnKo19coIJFV7eC3xYipCTosAi4bqF2Qp7FuyNxfUHDnXdOarj hCTTu8O+SYfxUtdTMbksjcyqNSRrANaRfZKpnwEOOnoAuRd9XzLb80I/NoGrry8H hTuPZKrFrO2fyBPfkZZAcceqgxX+7OKI6+Vx4jWl4bdGikyd1B6gPfyEtxnq5BE= =k4m5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634200: gcc -Wall -Werror -lncurses fails to link wide-character ncursesw functions.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/18/2011 02:31 AM, Kalle Olavi Niemitalo wrote: > Ray Dillinger writes: > >> display.c starts with the lines: >> >> >> #define _X_OPEN_SOURCE_EXTENDED > > There is an extra underscore after the X. > Correcting that fixes the implicit-declaration error for me. D'oh! Okay, that's embarrassing, but it explains the whole thing. With the variable undefined, link warnings and errors were generated, and either -Wall or -Werror was enough to catch them and stop the build. So, no bug? Are we just looking at the agreed-upon semantics? Bear -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOJEAgAAoJEAOzWkqOibfNA7YH/ih4BOZaYW4S3EO8HRjNMRiq Rnp2E1+cyv3Bb7EqfkyXEL2y2RaudGPKZsioFoDVZq6+ONEpkmUCo2ygA0qZZiLB Ega5h5AQtqO44Nm9Rq8QtUA7komQrQyVTC3Sj9Sy7H2VahIL2r6bgznbkaIQyLfb 8I8f5yr9QL6w2rTC/nU5J5L+LO5lASMG7g7kX5x/a9G4gWDM6gnbanx0mN2dEm1k ZEj+02r0xk6fHS8hBqTNCXfsITD06Tjpj8G/vhgetysVHI2hsYZbJpFJpM/OeeL9 /4fw4NB1LsVwBQzaGdi7da4ke83+MvEbCbouAbaiWb9YhfwB42H5RvYi7Ie2F7w= =QWry -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634200: #634200 gcc -Wall -Werror -lncurses fails to link wide-character ncursesw functions.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> bear@janus:~/src/xxh$ make display.o >> gcc -D_XOPEN_SOURCE_EXTENDED -Wall -Werror -lncursesw -c -o display.o \ >> display.c >> bear@janus:~/src/xxh$ > > should't the ncursesw headers be used? Sorry, don't understand your message. The ncursesw header is invoked by the -lncursesw compile line option above, *and* by #include in the file itself; isn't that enough?! > pkg-config --cflags ncursesw Can't use pkg-config on this project; it must be compilable on machines that don't have it installed. > plus, your example will fail when using -Wl,--as-needed. move the library behind > the objects. Okay... The synopsis of gcc in the man page says the file to be compiled should come last in the compile line. That's the only thing I can see here that could be called an "object". The only thing that could be called a "library" is specified by an -l option. Rearranging according to the order of things given in the synopsis, I get: gcc -c -Wall -Werror -D_XOPEN_SOURCE_EXTENDED -lncursesw -o display.o \ display.c Is that what you meant? And in that case are you calling -Wall and - -Werror "objects"? and -D_XOPEN_SOURCE_EXTENDED a "library"? If so why? Bear -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOJEWGAAoJEAOzWkqOibfNdd4H/2Xo3kOmvArX4em1BBCalbrX uOwTO+WF5kjMrJNDfUalHhvqDZ6EoCiYjO12nCCQ+lht0vRfxdCySTPvuSo4gUhv vam9XLAbPZzg7lI9ugDdjZVQRvzAMM3QHCwnPvLtC0gw7qkdkpEGN/dnR331KfcZ dcDJPm+E2Xudmbtb9+1PjbZo6hMl4c9jDTBQ8+09TZxTbZE+lJsRXL/d/SHkZEVW EzOfxzQkF3BWWj3tmUZJ3dk/rxpVH/odUzg5WGgkgr2+0Bn67SPjdVnvOAPj245+ J32Iua+jwTBpFTbZqbeNlU8EiPoHzrVyDAr9jOcScmDe2efkkK7aQNUHrlzFGjQ= =xasB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634200: #634200 gcc -Wall -Werror -lncurses fails to link wide-character ncursesw functions.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/17/2011 05:10 PM, Thomas Dickey wrote: > You're seeing implicit for get_wch, since there's no _XOPEN_SOURCE_EXTENDED > in the compile line. Okay, after checking: bear@janus:~/src/xxh$ make display.o gcc -D_XOPEN_SOURCE_EXTENDED -Wall -Werror -lncursesw -c -o display.o \ display.c bear@janus:~/src/xxh$ using the compile line to specify the option (in this case in addition to #define _XOPEN_SOURCE_EXTENDED at the beginning of the file) bypasses the problem. These two methods of establishing a compile option are supposed to be equivalent according to gcc's online docs, but here we have a case where specifying the option on the compile line seems to make the functions linkable even with -Wall and -Werror, while specifying it by #define at the start of the file instead exposes a bug where -Wall or -Werror prevent linking. This is a clearly superior workaround, since it leaves the functionality of -Wall and -Werror intact. But this is still a bug; these things are supposed to be equivalent, and neither is supposed to be affected by these "unrelated" build options. Bear -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOI8X/AAoJEAOzWkqOibfNmhYH/1ZYHNQJZtgq6aVzn0hGeAhC P4RAB+rgyL2FzQGM37+BCUS81dXVhneQvakifQyWurzR0lpIG1mVpc//lUecXuqq wah90qEGypKVoJpJxvyTnL2l8ZAWzmSCq+J+XOXbwgmDfOatqTUGCuU/R2yJFYPR hZp7+LmPeHqqI8bn/5v5HRGqMFDAI9c6+2cvVEIEDhSxw9KjbSO0/Y3iL73JhZLd EMGNgsoCokWa08fizVTri8DBh/dvakVTlK7e31fGz961E5QG+b2R469agoedYO/m 16OxHjrPqFWRX6N9WGlkbGChdxPGbSH2fR5A4nerGHtqm7EEYSPszSJ3brd8Dg4= =uYOE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634200: #634200 gcc -Wall -Werror -lncurses fails to link wide-character ncursesw functions.
On 07/17/2011 05:10 PM, Thomas Dickey wrote: > fwiw, I routinely build with warnings enabled (and don't have a use for > -Werror). > > For the rest - I'm typically seeing only extra warnings that > you wouldn't see with -Wall (such as const mismatches, which are > problematic). > > That's for ncurses itself, plus lynx and dialog. > > curses.h isn't including , since none of its declarations need it. > That's iswgraph and iswspace. > > You're seeing implicit for get_wch, since there's no _XOPEN_SOURCE_EXTENDED > in the compile line. Quoting from man ncurses Wait, the compile line? I took the documentation you quote for ncurses below > You must also define _XOPEN_SOURCE_EXTENDED when compiling for the > wide-character library to use the extended (wide-character) func- > tions. to mean #define _X_OPEN_SOURCE_EXTENDED in the c file before including headers, as shown in the head of the c file I submitted with the bug report. That seems to work for me to make these functions visible - provided I do NOT use --Wall or --Werror. If it's only possible to define it on the command line, isn't that a bug too? I'll check and see if I can use --Wall or --Werror with the ncursesw library if I include _X_OPEN_SOURCE_EXTENDED on the gcc command line instead of (or in addition to) in the file. But it still can't be correct behavior for these compile options to have an effect on what functions are visible/linkable. Bear -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#634200: gcc -Wall -Werror -lncurses fails to link wide-character ncursesw functions.
Package: gcc Version: 4:4.4.5-1 Severity: normal Tags: l10n In reply to your Fwd: Message with no Package: tag cannot be processed!(...) (reportbug fails on my system due to sendmail not being installed. Like most sane people I use Qmail. should I file a bug against reportbug?) original message--- I'm reporting this bug against GCC (current version installed is 4:4.4.5-1) This is an internationalization bug. This is "Normal" priority (priority 6). There is a workaround: never use -Wall or -Werror on the same gcc command line with -lncursesw or to link files that #include . My usual build options are "gcc -Wall -Werror ..." In attempting to link an ncursesw package I found that the wide-character functions in ncursesw were not linkable. In trying ever-more-trival cases to try to figure it out, I eventually (accidentally) built straight from the command line, leaving out the build options, and a call to a wide-character function linked. After some confusion, I realized that the relevant difference was the absence of my usual build options rather than whatever-it-was that I was testing. Taking the build options out of my makefile allowed the main project I was working on to build. Experimentation reveals that either of these build options (-Wall or -Werror) is sufficient to prevent linking. The bug against gcc is that regardless of the extreme macrology in /lib/include/ncursesw/ncurses.h and /lib/include/wctype.h these build options ought not affect the linker's view of available functions. Affected functions include basically everything which uses the wide character type defined in wctype.h or the functions defined on ints in ctype.h. These functions include, but are probably not limited to, in_wch, mvin_wch, mvwin_wch, win_wch, get_wch, wget_wch, mvget_wch, mvwget_wch, unget_wch, get_wstr, getn_wstr, wget_wstr, wgetn_wstr, mvget_wstr, mvgetn_wstr, mvwget_wstr, mvwgetn_wstr,get_wstr, getn_wstr, wget_wstr, wgetn_wstr, mvget_wstr, mvgetn_wstr, mvwget_wstr, mvwgetn_wstr, ins_wch, mvins_wch, mvwins_wch, wins_wch, iswgraph, isgraph, iswspace, isspace, iswalnum, isalnum, iswctype, etc. example of the error: bear@janus:~/src/xxh$make display.o make display.o gcc -Wall -Werror -lncursesw -c -o display.o display.c cc1: warnings being treated as errors display.c: In function ‘Disp_GetKey’: display.c:183: error: implicit declaration of function ‘get_wch’ display.c: In function ‘Disp_GetKeynames’: display.c:334: error: implicit declaration of function ‘iswgraph’ display.c: In function ‘Disp_Say’: display.c:1333: error: implicit declaration of function ‘iswspace’ ..etc make: *** [display.o] Error 1 bear@janus:~/src/xxh$ display.c starts with the lines: #define _X_OPEN_SOURCE_EXTENDED /* stdlib for qsort */ #include /* wchar for wint_t type */ #include /* wide ncurses for display and input handling */ #include /* malloc for calloc and free */ #include /* string.h for memcpy */ #include #include ..etc... Ray "Bear" Dillinger My system: AMD64, dual-core, prefer 'stable' release, up-to-date as of July 16 2011. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#611392: sshd_config should warn against use of RC4.
Agreed. In light of RC4's vulnerability to replay attacks
(explained in the context of SSH at
https://www.kb.cert.org/vuls/id/565052 )
sshd_config and ssh_config should at least specifically warn
against using RC4, as they currently do regarding DES.
OpenSSH itself should not enable RC4 or DES by default, and should
print a warning to stderr when weak ciphers are enabled explicitly.
Do we have any idea how much trouble it would cause for these
deprecated insecure ciphers to be completely disabled?
Ray Dillinger
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#461489: A clarification; X settings for numlock-on not useful on keyboards that lack a numlock key.
A clarification: This laptop has no numlock key as such - not even in its overlay keyset. The only way to toggle the numlock is to plug in an external (USB) keyboard and press the key on that - or to have the numlock setting inherited from my standard X settings, which is what was happening here. Thus, every time I booted up, my X settings were setting the numlock state (and by implication the fn-key state), and there's no way on the keyboard to unset it. The "fix" then is to change my X settings so as to NOT have numlock- by-default (which is my preference on fullsize keyboards). Bear -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461489: Wow, that's embarassing...
Yes, in fact it turns out to be that simple. X regards the num-lock behavior as implying the 'function key' behavior, even for keys that don't have anything to do with the numeric keypad overlay. So the workaround is, turn the numlock off. And the 'fix' that demotes this from regular to nearly insignificant as a bug is, DOCUMENT THIS UNEXPECTED BEHAVIOR!!! Ray. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461489: Documentation is nearly useless here
On Thu, 2008-02-28 at 03:23 +0100, Mohammed Adnène Trojette wrote: > You're contributing to a solution. I just did not have the time to check > the issue. If you want, you can report the bug directly to upstream > (http://bugs.freedesktop.org/ - xkeyboard-config component). That is indeed a good idea. I will go to do that, and hopefully find some discussion of similar bugs by developers which might contain "hints" as to where to look. Bear
Bug#461489: Documentation is nearly useless here
I've spent several days reading man pages, configuration directory README's, configuration files, ISO standards to figure out what the README's were saying, etc And aside from there being no useful mention whatsoever of laptop function keys, as far as I can tell keyboard configuration has become an arcane, confusing, and poorly documented mess. It's spread over dozens of directories and hundreds of files. I get that it's a complicated problem, but this is nuts. There doesn't even seem to be any way to get X to tell me what keyboard configuration files it's actually using. I can't even begin to tell what file I ought to try modifying to fix my problem. Documentation that says what steps are applied to keyboard input, in what order, and what files control the transformations involved in those steps, and how, is very very necessary here, and I don't have the ability to write it. If it existed I might have the ability to fix this damn bug, but I haven't been able to assimilate the myriad oblique and subtle clues yet to figure out where the one or two lines I probably need to change might be found. Surely it can't be necessary to learn all of X11R6 to figure out where to go to fix a keyboard bug?? I have heard in email from several people who say they're having the exact same problem and want to know if I've found a solution yet. I have not. And the silence from Debian-bugs is very very depressing. Is anybody out there? Does anybody even have any questions about my system or configuration that I could answer just to give me the illusion that I'm contributing to a solution? Bear -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461489: sense of laptop 'fn' key reversed on gateway MX6453
Package: xkbd-data Version: 0.9-4 I have a Gateway MX6453 laptop, and I'm having a problem with the keyboard. I believe that this is an xkbd-data 0.9-4 bug. I am using debian 'etch' or stable, and my system is 'up to date' according to the update tool. There's a 'fn' key in the lower left corner which is supposed to turn on special meanings for some of the keys: 7,8,9,U,I,O,J,K,L,M, in particular, map to digits 7,8,9,4,5,6,1,2,3,0 in an effort to mimic a numeric keypad. There are several other keys that should acquire special meanings when 'fn' is depressed, mostly having to do with brightness, loudness, screen contrast, multimedia settings, and internet shortcuts. My problem is that the keyboard behaves like the 'fn' key is pressed, _all_the_time_, unless it is actually pressed. For example, I have to push and hold the 'fn' key and then press 'l' in order to get a lower-case 'l' instead of a '3'. Mysterious extra information: On a reboot, it doesn't seem to affect the initial login and password (this is with X running, but before any user has logged in). Once a user session has started, however, the keyboard bug pops up immediately and doesn't go away even if that user logs out. (subsequent logins are affected). Right now I have two workarounds: if I plug in a standard keyboard with the USB interface, it is not affected by this craziness. (Note the Gateway MX6453 has no PS/2 connections). Second, it doesn't happen unless I start X, so I can still work (to some extent, most of my regular applications don't run without X) in runlevel 3. If I can be of any help in extracting further information from my system, please let me know how. If anyone knows what file to twiddle and how, I'll have a go at seeing if the solution works. Ray Dillinger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
