Hello Eric,
I dug around for why I filed for the change in behavior.
Here is the bug report that prompted it:
https://coq.inria.fr/bugs/show_bug.cgi?id=2726
ctags -e is not a perfect replacement for etags; in this
example, 'make tags' calls out to etags and expects the Emacs
version.
etags
Sure; I just copied the tagline from the website. The basic security
guarantees Ori gives is that all of the files that are replicated are
cryptographically hashed with SHA-256, so if a node knows the hash of a
file, it can verify that it actually got the file after doing some sort
of fetch.
Package: wnpp
Severity: wishlist
Owner: Edward Z. Yang ezy...@cs.stanford.edu
* Package name: ori
Version : 0.8.0
Upstream Author : Ori Developers orifs-de...@lists.stanford.edu
* URL : http://ori.scs.stanford.edu/
* License : MIT/X
Programming Lang: C
proceeds with the arguments I passed
Actual result: reportbug forgets I passed arguments (in the case of -B
debian, it then quits because it needs a flag).
Cheers,
Edward
-- Package-specific info:
** Environment settings:
EDITOR=vim
DEBEMAIL=ezy...@cs.stanford.edu
DEBFULLNAME=Edward Z. Yang
INTERFACE
Package: apt
Version: 0.9.9.1~ubuntu3
Severity: normal
When one entry in sources.list is incorrect, apt-get update may
incorrectly report that other sources (which are fine) are also broken.
This is because apt-get first looks for InRelease before actually
downloading Release.gpg; so a single
Package: etckeeper
Version: 1.10
Severity: normal
Similar to bug #651168, I believe /etc/cups/printers.conf*
should be ignored by default. From the manpage:
The printers.conf file defines the local printers that are available.
It is normally located in the /etc/cups directory
Package: etckeeper
Version: 1.10
Severity: important
Currently, store-metadata respects ignored files, but does not
respect unversioned files. .etckeeper should not record data for
unversioned files. This can be problematic, for example, if
you are incrementally staging some edits to
I think the easiest way to implement this without swapping /etc is to
set up some extra per-process mounts of /etc of different versions.
So when you run dpkg, it has /etc mounted to a pristine copy of the repository
that isn't what is actually in /etc; then we do a merge and if the merge
goes
Package: exuberant-ctags
Version: 1:5.9~svn20110310-2
Severity: normal
Currently, exuberant-ctags has higher priority than emacs for the
'etags' executable. Since etags stands for 'emacs tags', it seems
that it would make more sense for the emacs executable to take
priority; if a user desires
I just committed a workaround to HTML Purifier master (unreleased), we think
this
is an upstream php/glibc bug.
Edward
Excerpts from Jörg Ludwig's message of Sat Jun 25 13:24:40 -0400 2011:
Package: php-htmlpurifier
Version: 4.3.0+dfsg1-1
Severity: important
We use HTML Purifier to clean
That might have some unintended consequences, in particular, cache
files should not be shared between users because there's no integrity
checking and a user could poison someone elses configuration. Of
course, as it stands right now doesn't work either. Maybe a per
user cache?
Cheers,
Edward
Package: ldirectord
Version: 1:1.0.3-3~bpo50+1
Severity: important
Tags: patch
Our LVS setup uses ldirectord's real configuration option to check
if servers were alive.
real=18.181.0.53 gate heartbeat/services, 1
Upon upgrading to the latest version of ldirectord on lenny-backports,
we
I assume this has been forwarded upstream?
I was attempting to check out the fenix website to find out whether or
not the fenix developers were handling the issue on their bugtracker,
and I get a generic your webserver has been configured correctly error
[1], as well as most of the pages on
There have been several new versions of Grub since you first posted this
report. Could you try to reproduce with a newer version?
Cheers,
Edward
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
It looks like the bug lies in the nvidia-glx-legacy-96xx-dev install
scripts, which don't set up the appropriate symlinks if
nvidia-glx-legacy-96xx was installed previously. Also, the uninstall
scripts sucks (although this is not a rc-blocking issue).
Cheers,
Edward
--
To UNSUBSCRIBE, email
The basic way to reproduce this issue on a blank machine is as such:
sudo apt-get install nvidia-glx-legacy-96xx
sudo apt-get install nvidia-glx-legacy-96xx-dev
ls /usr/lib | grep libGL.so
The source of this problem is a sorry chain of diversions and hacks that
have caused nvidia-glx-legacy-69xx
Edward Z. Yang wrote:
I will attempt to
cook and test a patch.
Patch attempt failed. Does the package manager have anything to say
about this?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
17 matches
Mail list logo
