Bug#882662: gnome-session: something is resetting $PATH after .gnomerc runs, making it impossible to set a custom $PATH in .gnomerc

confirmed this. In any case, this thing of copying part of the environment from another session seems utterly bonkers to me, but at least it's not gnome-session's fault... On Sat, Nov 25, 2017 at 3:11 AM, Nathaniel Smith <n...@pobox.com> wrote: > Package: gnome-session > Version: 3.26.1-

Bug#882662: gnome-session: something is resetting $PATH after .gnomerc runs, making it impossible to set a custom $PATH in .gnomerc

Package: gnome-session Version: 3.26.1-1 Severity: important In my .gnomerc, I set a custom $PATH: PATH=blah:$PATH I also set some other variables: export GNOMERC_WAS_EXECUTED=yeah Until recently, this worked fine: the given $PATH was set for everything inside my session. Since my last

Bug#792746: Upgrading to 4.0.8-1 kernel makes external monitors unusable

Yes, I haven't seen one of these crashes in quite some time -- sorry for not updating. On Jul 12, 2016 6:54 PM, "Ben Hutchings" wrote: > On Mon, 2016-07-11 at 22:45 +0200, Enrico Zini wrote: > > On Sat, May 28, 2016 at 06:21:34PM +0200, Enrico Zini wrote: > > > > > When the

Bug#725848:

On Fedora, there's a line in /etc/skel/.bash_profile that adds ~/.local/bin to the default PATH. Debian doesn't have an equivalent. I just filed #820856 to hopefully get this added to Debian. (It's possible that in the mean time pip might need to grow some logic to check whether the user's PATH

Bug#820856: bash: Please add ~/.local/bin to the default $PATH

Package: bash Version: 4.3-14+b1 Severity: normal ~/.local/bin is a de-facto standard place to put per-user executables -- for example, Fedora automatically places it on the $PATH, and PEP 370 makes it the standard place for unprivileged installs of Python packages to put their scripts (and

Bug#797477:

Unfortunately, this 1-byte change -- while a good idea -- is ineffective on its own, because emacs does not verify TLS connections by default... and in fact the gnutls configuration in Debian's emacs is somehow so broken that it doesn't check certificates *even if* certificate checking is enabled

Bug#816063: emacs24: TLS certificate validation is silently broken

Package: emacs24 Version: 24.5+1-6+b1 Severity: serious Tags: security Justification: 5(b) of https://release.debian.org/testing/rc_policy.txt Debian's emacs builds are linked against gnutls: (gnutls-available-p) t By default, they aren't configured to validate TLS certificates, leaving users

Bug#792746: linux: Upgrading to thinkpad T440s laptop to 4.0.8-1 kernel causes external monitors to stop working, with fifo underrun error

Oh, it looks like switching to the text console also hits a WARNING, which might be relevant: Jul 17 17:11:17 branna kernel: [ 60.360540] [ cut here ] Jul 17 17:11:17 branna kernel: [ 60.360572] WARNING: CPU: 2 PID: 961 at

Bug#770979:

I also frequently experience what sounds like the same bug (clicks going right through a fullscreen Iceweasel or fullscreen game and being received by whatever is underneath; keyboard events are delivered correctly). For me, though, it happens with fullscreen applications on my single screen -- no

Bug#769072: Bug#769191: xorg: apt-get dist-upgrade somehow reconfigured my system to use the nvidia driver, even though I have no nvidia hardware

McVittie s...@debian.org wrote: On Mon, 17 Nov 2014 at 21:47:12 +, Nathaniel Smith wrote: Here's my apt history files. history.log.1 has the big upgrade that caused the problem; history.log has the mucking about I did to fix it. OK, thanks. At the top of history.log.1 you have: Upgrade

Bug#769072: Bug#769191: xorg: apt-get dist-upgrade somehow reconfigured my system to use the nvidia driver, even though I have no nvidia hardware

Here's my apt history files. history.log.1 has the big upgrade that caused the problem; history.log has the mucking about I did to fix it. Notice that the big upgrade got interrupted in the middle by libaudio2 failing to install (#768651), so there was some 'apt-get install -f' and 'dpkg

Bug#487913: devhelp segfaults on Control-f or Edit-Find

Package: devhelp Version: 0.19.1-3 Severity: important What it says on the tin, basically. To reproduce: 1) Start devhelp 2) Open up some manual page (or don't, doesn't matter) 3) Press Control-f OR click Edit - Find Result: devhelp segfaults, every time Backtrace from gdb: Program

Bug#474644: libffi4-dev Provides: libffi-dev, but does not appear to actually be compatible

Package: libffi4-dev Version: 4.1.2-6 Severity: normal I have python-gobject-dev installed; python-gobject-dev Depends: on libffi-dev. On my system, this dependency was satisfied by libffi4-dev, because libffi4-dev Provides: libffi-dev. However, this leaves me with a broken python-gobject-dev

Bug#468130: python-gobject-dbg: There is no convenient way to *use* the debugging pygobject library

Ah. Thanks for the tip. (How *was* I supposed to figure this out? Installing python-dbg does seem to give 'gdb python' access to python's own symbols, like other -dbg packages do; it never occurred to me that it would have more magic than that...) But, there still seems to be something wrong:

Bug#468130: python-gobject-dbg: There is no convenient way to *use* the debugging pygobject library

Package: python-gobject-dbg Version: 2.14.1-1 Severity: grave Justification: renders package unusable Most -dbg packages are set up so that when running under gdb, the debugging libraries are automatically used. Not so for pygobject. After flailing around for a while, the *only* way I could come

Bug#443796: Oops

I forgot that sending stuff to control@ does not make the attached text very visible. So in case people don't see it otherwise, here's an explanation of what's causing the bug, and how to fix it: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=19;bug=443796 -- Nathaniel -- If you can

Bug#445509: xserver-xorg: 'pygoocanvas' demo app reliably causes X server to segfault

On Sat, Oct 06, 2007 at 02:09:47PM +0200, Julien Cristau wrote: On Sat, Oct 6, 2007 at 14:01:44 +0200, Julien Cristau wrote: You don't need to do that. Just install xserver-xorg-core-dbg and libpixman-1-0-dbg, that should get you a usable backtrace. Hrm, except that won't have

Bug#431123: aptitude: Initializing package states takes very much longer than before +b1

On Tue, Jul 03, 2007 at 07:42:08AM -0700, Daniel Burrows wrote: On Mon, Jul 02, 2007 at 10:00:53PM -0700, Nathaniel Smith [EMAIL PROTECTED] was heard to say: On Sun, Jul 01, 2007 at 06:12:11PM -0700, Daniel Burrows wrote: Does installing the version in experimental fix the problem

Bug#431123: aptitude: Initializing package states takes very much longer than before +b1

On Sun, Jul 01, 2007 at 06:12:11PM -0700, Daniel Burrows wrote: Does installing the version in experimental fix the problem for you? Yes, the aptitude in experimental (0.4.4-5~2, which appears to be linked against apt 0.6.46.4-0.1, which is no longer in unstable?) works fine. -- Nathaniel --

Bug#431123: aptitude: Initializing package states takes very much longer than before +b1

I also confirm this bug. The easiest way to reproduce is to simply run 'aptitude search foo'. For me, the upgrade that caused the problem was: [UPGRADE] apt 0.6.46.4-0.1 - 0.7.2-0.1 [UPGRADE] apt-utils 0.6.46.4-0.1 - 0.7.2-0.1 [UPGRADE] aptitude 0.4.4-4 - 0.4.4-4+b1 update-manager seems to

Bug#426401: Search bar behavior reverted to firefox one

I can also confirm this bug -- since my last upgrade I've been running into it every 5 minutes :-(. To be clear: it used to be that if I typed foo bar (i.e., a string with a space in it) into the url bar and pressed enter, then epiphany went to the google search page for foo bar. Alternatively,

Bug#425957: laptop-mode-tools: [PATCH] CONTROL_CPU_FREQUENCY assumes governors are compiled as modules

Package: laptop-mode-tools Version: 1.33-1 Severity: normal When CONTROL_CPU_FREQUENCY=1, /usr/sbin/laptop_mode unconditionally tries to modprobe the relevant governor functions. This fails for kernels in which the governors are compiled in statically -- the laptop_mode script crashes, and

Bug#425957: laptop-mode-tools: [PATCH] CONTROL_CPU_FREQUENCY assumes governors are compiled as modules

On Fri, May 25, 2007 at 09:48:00AM +0200, Bart Samwel wrote: Hi Nathaniel, Thanks for the patch, I'll include it in the next update! Just checking: why does the laptop_mode script crash if the modprobe fails? The way I understand the code, when the modprobe fails it should just print an

Bug#425957: laptop-mode-tools: [PATCH] CONTROL_CPU_FREQUENCY assumes governors are compiled as modules

On Fri, May 25, 2007 at 09:56:31AM +0200, Bart Samwel wrote: Nathaniel Smith wrote: On Fri, May 25, 2007 at 09:48:00AM +0200, Bart Samwel wrote: Hi Nathaniel, Thanks for the patch, I'll include it in the next update! Just checking: why does the laptop_mode script crash if the modprobe

Bug#423947: lftp: postrm script fails if 'ftp' package is not installed

Package: lftp Version: 3.5.9-1 Severity: grave Justification: renders package unusable ~$ sudo dpkg -i /var/cache/apt/archives/lftp_3.5.10-1_i386.deb (Reading database ... 109953 files and directories currently installed.) Preparing to replace lftp 3.5.9-1 (using .../lftp_3.5.10-1_i386.deb) ...

Bug#412464: amarok-engines should have a _versioned_ dependency on amarok-xine

Package: amarok-engines Version: 1.4.5-2 Severity: normal The version of amarok in sid has an unversioned dependency on amarok-engines | amarok-engine This appears to be fixed in the version in experimental, which depends on amarok-engines (= 1.4.5-2) | amarok-engine (= 1.4.5-2) However,

Bug#407043: kcachegrind: Suggest making 'graphviz' a Recommends: instead of a Suggests:

Package: kcachegrind Version: 4:3.5.5-3 Severity: minor I was just surprised to aptitude install kcachegrind and discover that one of the basic piecs of functionality I was expecting, the call graph viewer, didn't work. Instead I was told I needed to install graphviz. That's easy enough, but I

Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15

On Wed, Nov 22, 2006 at 09:54:42AM -0700, Shaun Jackman wrote: On 11/22/06, Roman Zippel [EMAIL PROTECTED] wrote: ... 1. Is this more likely a bug in Boost or a bug in monotone? 2. Is it reasonable to workaround this bug by removing -DBOOST_SP_DISABLE_THREADS? 3. Is it worth going to the

Bug#384565: [Monotone-devel] Re: Bug#384565: monotone - FTBFS: Build killed with signal 15

On Tue, Nov 21, 2006 at 02:04:07PM -0700, Shaun Jackman wrote: It appears the BOOST_SP_DISABLE_THREADS is the source of monotone's cross-platform issues on Debian. Namely, that monotone fails to run (deadlock) on s390, hppa, sparc, mips, and mipsel, but runs fine on i386, amd64, ia64, alpha

Bug#388532: RFP: frysk -- A system monitor and debugger

Package: wnpp Severity: wishlist * Package name: frysk Version : Seems to be cvs-only for now, but is already usable for tasks that no other tool can handle Upstream Author : Redhat [EMAIL PROTECTED] * URL : http://sources.redhat.com/frysk/ *

Bug#350665: kernel-package: check for -j in MAKEFLAGS is not quite correct

Package: kernel-package Version: 10.033 Severity: normal make-kpkg has checks to make sure that MAKEFLAGS and MFLAGS do not contain -j. They are not quite correct. I have MAKEFLAGS set to kj3. This accords with the documentation in the make info page, which e.g. gives the example if you do

Bug#319149: Bug 319149

This is indeed a Boost/gcc 4.0 incompatibility, but it only affects code that monotone does not actually use; monotone 0.21's configure checks for boost 1.32 and does some preprocessor kluging to work around the problem. So, monotone 0.21 should fix this. -- Nathaniel -- Civil rights were not

Bug#290709: abcde silently corrupts track names containing '=' (equals sign)

Package: abcde Version: 2.2.2-1 Severity: normal Godspeed You! Black Emperor's CD Yanqui U.X.O. contains two tracks named Motherfucker=Redeemer (Part One) and Motherfucker=Redeemer (Part Two). abcde appears to chop off these titles after the = sign. Furthermore, it doesn't notice that this