I have not experienced either of these issues with the 3.14 kernel
image. Brightness controls work as they should and the display manager
loads just fine.
Thank you for your reply though.
On 2014-05-08 9:24 PM, Matteo Cypriani wrote:
Hi Alex,
On Thu, 02 Jan 2014 19:33:04 -0500, Alex
Package: src:linux
Version: 3.13~rc6-1~exp1
Severity: important
Dear Maintainer,
This package (version 3.13~rc6-1~exp1) is exhibiting some symptoms that lead me
to believe it's buggy, namely:
1: My display manager (GDM) fails to start when the system finishes booting.
2: The Intel graphics
On 2013-10-25 4:02 AM, John Wright wrote:
On Sun, Oct 20, 2013 at 10:25:31PM -0400, Alex Vanderpol wrote:
Unfortunately I no longer have any of those crash dumps available to
send you anything, I had sent what I had gotten to the kernel
maintainers previously in an attempt to track down
somewhat useful.
On 2013-10-20 10:29 PM, John Wright wrote:
Hi Alex,
On Fri, Aug 16, 2013 at 10:12:39PM -0400, Alex Vanderpol wrote:
Package: makedumpfile
Version: 1.5.4-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
There seems to be a serious issue with makedumpfile
Package: gnome-shell
Version: 3.8.4-2
Severity: normal
Dear Maintainer,
Just want to inform you that the current version of GNOME Shell (3.8.4-2) no
longer displays the network status icon in the top bar. If you could please fix
that so the network status icon is displayed again, that would be
I figured out what's happening, so hopefully you can look into it and
maybe fix it now.
Apparently the width of the status column in the individual file details
table is being reduced to zero by all of the other columns beside it,
the only way to get it to appear is to stretch the dialog
Just want to let you know this bug can be closed now, I haven't once had
the kernel crash due to Folding@Home since my last message and I've gone
through several work units since then, all of which had been resumed
several times through their progress. I think it's quite safe to say
whatever
I would like to report that this issue seems to have been resolved in
kernel 3.11-rc7, I am able to run Folding@Home without the kernel
crashing. I do currently appear to be working on a different type of
unit than I had been with the previous kernel, however, but it does
appear to be using
(In reply to your earlier email) The problem is that I'm already using
version 1.5.4-1 from Unstable, and it's having that issue, so either
something's been changed in the recent kernel version that broke it
again, or makedumpfile has regressed since version 1.5.1-1. Either way
I've already
I've discovered that the kernel only crashes when the Folding@Home core
attempts to resume a work unit already in progress. After configuring
kdump-tools to not collect unused memory pages (something apparently
recommended if your system has a larger amount of memory), I attempted
to trigger a
Well, I've discovered why makedumpfile continues to run even after the
dump files show up in the folder. It's failing to properly dump the
kernel log, and is continually appending the line [ 0.00] to the
dmesg file. I just ended up with a 3 GB file, nano ended up kaput trying
to open it
Package: makedumpfile
Version: 1.5.4-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
There seems to be a serious issue with makedumpfile that causes it to fail to
dump the kernel log when collecting crash dump information. Instead, the
program continues to run
Apparently having the kernel image debug package installed is a good
idea when trying to do anything with crash dumps... After installing the
~2GB (unpacked) package I was able to use the crash utility to analyze
(to a degree) the crash dump file made by kdump-tools, however I am
unable to
Ah, I didn't know exactly what you meant. Unfortunately I don't know how
to extract anything from the dump files I got with kdump-tools. There
are two files in the crash dump directory I made and pointed kdump-tools
to, dmesg.201308111839 (which is the 2.9 GB file) and dump.201308111839
(the
I was unable to get a photo of the screen output, apparently neither of
the cameras I have available can take high enough resolution shots to
actually read the output even slightly, so I carefully wrote down
(nearly) everything that was displayed and carefully typed it out into a
text file
It would seem the issue isn't so much that the kernel is causing the
display manager to fail to start, apparently the kernel is crashing
after the system finishes booting but before the display manager starts.
I attempted to boot the system using SysV on the off chance it was an
issue with
So I figured out what's crashing the kernel, apparently kernel 3.11-rc4
and Folding@Home (when run as a system service) don't get along. I
suspect this may be an issue with Folding@Home rather than the kernel, I
may need to get in touch with them and inform them of this issue so it
can be
Oh, well, in that case, I guess reporting it was a good idea then. I can
probably capture a crash dump some time later, if you need it, right now
though I need to get some rest.
On 11/08/13 07:50 AM, Ben Hutchings wrote:
On Sun, 2013-08-11 at 07:40 -0400, Alex Vanderpol wrote:
So I figured
I have to ask: Is it normal for a crash dump (and, apparently, a dmesg
dump as well) to be several GB in size? I ask, because my dump file from
the crash is 1.5 GB and the dmesg dump is 2.9 GB.
I would like to submit these somehow but I don't think via email would
be the best way to do so,
Package: src:linux
Version: 3.11~rc4-1~exp1
Severity: important
Dear Maintainer,
It would seem that with the current RC of kernel 3.11 my display manager (GDM)
fails to start after the system finishes booting, and I am unable to switch to
any of the virtual consoles. It seems the system freezes
Package: libqtcore4
Version: 4:4.8.5+dfsg-1
Severity: important
Dear Maintainer,
The recent update for libqtcore4 (version 4:4.8.5+dfsg-1) brings in a new
dependency on qtcore4-l10n, which appears to be an arch-independent package,
however, on multiarch systems, the i386 package does not
I finally managed to get a window where the download status column is
visible before any files have started downloading, I'm attaching a
screenshot of this so you can compare it with the one in my previous
message and see exactly what I'm talking about.
Hopefully once you can see the problem
Package: gnome-keyring
Version: 3.8.2-2+a1
Severity: important
Tags: lfs
Dear Maintainer,
I think there may be a mistake with gnome-keyring's dependency on the non-
existent package libgcr-base-3-1.
There is a package libgcr-3-1 that may be the correct dependency.
I've altered the dependency
(Replying for the bug tracker.)
On 09/06/13 11:21 AM, Geert Stappers wrote:
Op 2013-05-30 om 02:54 schreef Alex Vanderpol:
On 30/05/13 12:55 AM, Geert Stappers wrote:
For what it is worth: this from syslinux (3:6.00~pre4+dfsg-10)
* Correcting typo in extlinux debhelper install file
Package: libreoffice-core
Version: 1:4.1.0~beta1-2
Severity: important
Dear Maintainer,
Recent updates in SID/Unstable have replaced libharfbuzz0 with a newer package
now named libharfbuzz0a. Libreoffice's dependency needs to be updated to use
this new package, otherwise it cannot be installed.
:01PM -0400, Alex Vanderpol wrote:
Recent updates in SID/Unstable have replaced libharfbuzz0 with a newer package
now named libharfbuzz0a. Libreoffice's dependency needs to be updated to use
this new package, otherwise it cannot be installed.
I know. I followed that one closely.
Will do
Package: libreoffice
Version: 1:4.1.0~beta1-2
Severity: important
Dear Maintainer,
As stated in the bug subject, the .desktop files for all of the LibreOffice
applications are missing.
As such, LibreOffice applications do not appear in the GNOME Shell overview,
and I imagine this means they
On 13-06-01 05:25 AM, Rene Engelhard wrote:
Hi,
On Sat, Jun 01, 2013 at 03:20:23AM -0400, Alex Vanderpol wrote:
As stated in the bug subject, the .desktop files for all of the LibreOffice
applications are missing.
Sorry, but this is not true completely.
$ for i in *beta1-2*deb; do dpkg
Package: extlinux
Version: 3:6.00~pre4+dfsg-9
Followup-For: Bug #710212
Dear Maintainer,
Latest version (3:6.00~pre4+dfsg-9) still fails to install.
Terminal output is as follows:
P: Checking for EXTLINUX directory... not found.
P: Creating EXTLINUX directory...mkdir: cannot create directory
Attempting to narrow down the cause of this bug led me to an interesting
discovery.
There's a rather large difference between the /usr/sbin/extlinux-update
files in 3:6.00~pre4+dfsg-7 and 3:6.00~pre4+dfsg-8 that appears (in
part, at least) to be related to this issue.
This difference also
Package: libwebkitgtk-1.0-0
Version: 1.11.91-1
Severity: important
Dear Maintainer,
It would seem that a recent update to libharfbuzz0 (from 0.9.17-2 to 0.9.17-3)
has rendered Hotot unable to be launched. The Traceback I get in the terminal
when attempting to launch Hotot from there points to an
Package: imagemagick
Version: 8:6.8.5.6-1
Severity: normal
Dear Maintainer,
As the bug subject hopefully indicates, the imagemagick post-installation
script fails to complete due to a non-existent alternative path. This prevents
anything dependent on imagemagick (eg. Prey) from being able to be
Checking into things a little further...
The binaries are completely missing from this recent package update, no
wonder the script fails.
There appear to be a few other files missing as well that are linked to
the missing binaries. (Appears to be some icons and the imagemagick
display
Package: synaptic
Version: 0.80.1
Severity: minor
Dear Maintainer,
I suspect recent GTK3 updates may be the cause of this issue. After the recent
updates, when viewing the download progress of individual files, the Status
column where the progress bars for the individual files would appear
Package: gnome-screensaver
Version: 3.6.0-1
Severity: normal
Dear Maintainer,
gnome-screensaver currently depends on libgnome-desktop-3-4, which has recently
become obsolete. This dependency should probably be changed to libgnome-
desktop-3-7.
-- System Information:
Debian Release: jessie/sid
And I realize now, after submitting that report, that gnome-screensaver
is still only version 3.6, so its dependency kind of makes sense... I
suspect this means gnome-screensaver needs to be updated in general, and
an updated version should hopefully be using libgnome-desktop-3-7, given
that
Package: brasero
Version: 3.4.1-4
Severity: normal
Tags: lfs
Dear Maintainer,
brasero currently depends on libtracker-sparql-0.14-0, which has recently
become obsolete. As brasero is still currently at version 3.4, while GNOME in
Experimental is at version 3.8, it might be a good idea to release
Package: alacarte
Version: 3.5.3-1
Severity: important
Dear Maintainer,
Recent updates have made Alacarte unusable due to an import error from util.py.
Here is the terminal output when I try to launch it:
Traceback (most recent call last):
File /usr/bin/alacarte, line 23, in module
from
Package: gnome-calculator
Version: 3.8.0-1
Severity: important
Dear Maintainer,
After much frustration I finally discovered why GNOME's Calculator is not
showing up in the GNOME applications menu. The applications menu file is
looking for a differently named desktop file than is currently being
Just correcting the folder name, I mistyped it as sdg instead of xdg.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Actually, this was an update from version 1.32.5-1, I had downgraded
back to it after the issues I had with missing modules (which it turns
out are built-in now) and the issue with i386 arch packages dependent on
libpango1.0-0 not recognizing the all arch package on my amd64 system.
However,
Package: gedit
Version: 3.8.0-1
Severity: wishlist
Dear Maintainer,
gedit package needs rebuild to use libgtksourceview-3.0-1 instead of
libgtksourceview-3.0-0, as a recent update has replaced the old package.
-- Package-specific info:
Active plugins:
- 'spell'
- 'filebrowser'
-
Package: gnome-sushi
Version: 3.8.0-1
Severity: wishlist
Dear Maintainer,
gnome-sushi package needs a rebuild to use libgtksourceview-3.0-1 instead of
libgtksourceview-3.0-0, as a recent update has replaced the old package.
NOTE: I have already built and installed a version that uses the new
I should also add I've already built and installed a version of the
package locally that uses the new package (libgtksourceview-3.0-1),
however the official repository package needs to be rebuilt.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Package: libpango1.0-0
Severity: important
Dear Maintainer,
Unfortunately, the latest update to libpango1.0-0 did not end up fixing the
issue I was having previously, and creates a new problem on top of that as now
the all arch package and the i386 package are no longer equivalent versions
and
I probably should have mentioned I applied a patch for Plymouth that
updated the hook to work with the newer versions of Pango (at least, the
ones that still supplied separate modules). I don't think the patch was
done properly though as it relies on pango-querymodules from the
development
Package: libpango1.0-0
Version: 1.32.5-3
Severity: important
Dear Maintainer,
The latest version of Pango appears to be fairly problematic, first with i386
packages not recognizing the transitional package for all architectures
(already filed a separate bug about that), and now I discover that
Package: libpango1.0-0
Version: 1.32.5-3
Severity: normal
Dear Maintainer,
A recent upgrade of Pango turned the libpango1.0-0 package into a transitional
package for all architectures, however on my amd64 arch system with i386 as a
foreign arch, i386 packages depending on libpango1.0-0 do not
Package: systemd
Version: 44-11
Severity: grave
Justification: renders package unusable
Dear Maintainer,
***I'm marking this as grave because it causes some fairly serious usability
issues for me, if you feel this status is incorrect please feel free to change
it.***
As you might know, much of
...Wow, I feel really dumb right now. That was all it took to get things
working.
Thank you so much!
(I have to wonder now, though... if that package is necessary to make
things work properly, why isn't a dependency of the package?)
--
To UNSUBSCRIBE, email to
Ah, I noticed that just a while ago when I updated.
In truth, EOG was the only application still dependent on that old
package (at least, installed on my system), so with it updated to use
libgnome-desktop-3-7, I don't have a reason to keep libgnome-desktop-3-2
around anymore.
That said, if
Package: libgnome-desktop-3-2
Version: 3.4.2-1
Severity: normal
Dear Maintainer,
This has actually been an issue since GNOME 3.6 entered Experimental.
libgnome-desktop-3-2 version 3.4.2-1 depends on gnome-desktop3-data being
exactly the same version, preventing gnome-desktop3-data from being
Package: src:linux
Version: 3.8.3-1~experimental.1
Severity: important
Dear Maintainer,
Recently it was discovered in Ubuntu that version 3.8.3 of the linux kernel had
issues that caused xrandr to detect an external monitor connected to a laptop
with Intel integrated graphics when in fact no
I just want to report that I found a work-around for this issue:
Disable PulseAudio's flat volumes.
Apparently having this setting enabled (Debian's default state) causes
PulseAudio to increase the master volume to 100% if an application (ie.
Banshee) sets it's volume to 100%.
To disable
I just recently installed the latest version of Banshee from
experimental (2.6.0-4) and I would like to update the status of this bug.
There no longer seems to be an issue with Banshee messing up other
applications audio output, nor does Banshee seem to be setting audio
output to some sort of
Package: banshee
Version: 2.6.0-1+b1
Severity: important
Dear Maintainer,
Banshee 3.6 is doing unusual things to audio playback on my system.
When I start playing music in Banshee, my system volume immediately jumps to
100%, which is very unpleasant when using headphones. Also, audio output
This is just a follow-up to my previous message.
The message I get on the console when the system finishes booting but
fails to switch to GDM is as follows:
startpar: service(s) returned failure: plymouth ...Failed!
I hope this may be helpful.
Something else I noticed, if I uninstall
Package: plymouth
Version: 0.8.8-1
Followup-For: Bug #687500
I've begun experiencing this issue since my update to GDM 3.6 from
Experimental, with GDM 3.4 there seemed to be no issue with Plymouth handing
off to GDM once the computer finished booting.
Occasionally I can drop to a console and
Package: libgstreamer-plugins-base0.10-0
Version: 0.10.36-1
Severity: important
Dear Maintainer,
*** 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
59 matches
Mail list logo
