og back in. But I haven't 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 wrote:
> Package: gnome-sessio
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 upg
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 problem happens, this
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 i
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 theref
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 :
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 op
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 /build/linux-aqtDGz/linux-4.0.8/drivers/gpu/drm
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 -- n
PM, Simon McVittie wrote:
> On Mon, 17 Nov 2014 at 21:47:12 +0000, 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
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 --configu
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 rec
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 pa
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:
~
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
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 explai
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
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 vers
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
--
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 s
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". Alternativel
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:
>
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 a
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 CONTR
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) ...
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, the
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
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 wor
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
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/
* Lice
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
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 c
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 t
33 matches
Mail list logo
